From sroy at openjdk.org  Mon Apr  1 10:17:33 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 1 Apr 2024 10:17:33 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v6]
In-Reply-To: <W1SnnV44hPNw3e68q02PdHyBBuDUiUZaq3llF0oEso8=.9979f6bd-33d4-47bc-be80-0643c9448c14@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <g-HvEzEqrWTaXItMHcUAXO2HF9BB-ivlOK-oCJI022I=.c2adf1d4-f67f-4cc5-a406-2843b08963d0@github.com>
 <W1SnnV44hPNw3e68q02PdHyBBuDUiUZaq3llF0oEso8=.9979f6bd-33d4-47bc-be80-0643c9448c14@github.com>
Message-ID: <mmZMuQ4DRJ_A_XgIFJ79_ZTbDgbWFzE29mFtLqUZjNk=.d0f75428-de25-4302-8b02-58c0d371ac4f@github.com>

On Thu, 28 Mar 2024 16:57:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `System::loadLibrary("systeminfo")` should call `JVM_LoadLibrary` with "/usr/lib/libsysteminfo.so" argument (let the .a file exists under "/usr/lib") which in turn calls `os::dll_load`. JDK-8320005 changed `os::dll_load` to first load the given filename; if fails, it will call `dll_load_library` with "/usr/lib/libsysteminfo.a".
> 
> You can turn on `-Xlog:library` and it should print log message loading "/usr/lib/libsysteminfo.so" if you have `loadLibraryOnlyIfPresent` to return false. If you don't see log message loading "/usr/lib/libsysteminfo.so", `loadLibraryOnlyIfPresent` still returns true.
> 
> Turn on "-Xlog:os" should print "attempting shared library load of /usr/lib/libsysteminfo.so" and "attempting shared library load of /usr/lib/libsysteminfo.a" log message.

@mlchung  That should work, but then the mapAlternateName is called in NativeLibraries.java . I think the classloaderhelper for the respective platform needs to implement it. So if i remove mapAlternateName I need to probably remove the entire file from AIX, so that the classloaderhelper of unix is referred.
Also in ClassLoaderHelper of unix, the mapAlternateName return null. So should i keep it that way ? 
Other optioon is to set loadLibraryOnlyIfPresent to false in the unix classloaderhelper ? I am not sure if that would be allowed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2029530668

From jiefu at openjdk.org  Mon Apr  1 12:22:34 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 1 Apr 2024 12:22:34 GMT
Subject: RFR: 8329354:
 java/text/Format/MessageFormat/CompactSubFormats.java fails
In-Reply-To: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
References: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
Message-ID: <JJi9A4fzPShfZI2e2t4BHFbhHHhetP7QjCVwaR24swo=.372a997b-c35a-4c84-9b1d-cb0c679999d2@github.com>

On Sat, 30 Mar 2024 02:26:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing machines.
> I'm not an expert in this area and just guess it can be fixed like this.
> Please review it.
> 
> Thanks.
> Best regards,
> Jie

May I get one more review from a reviewer?  Maybe @naotoj ?
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18557#issuecomment-2029673242

From sroy at openjdk.org  Mon Apr  1 16:35:02 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 1 Apr 2024 16:35:02 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v7]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <HAhko5XNVg1c_x6OtzXw7FTEMGAQfunsX7K05Qo5K90=.708a6bad-8d9b-4dea-9e57-8845ae82ca9e@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  remove .so to .a mapping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/4c068e78..92e35692

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=05-06

  Stats: 29 lines in 1 file changed: 5 ins; 14 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From naoto at openjdk.org  Mon Apr  1 16:58:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Apr 2024 16:58:31 GMT
Subject: RFR: 8329354:
 java/text/Format/MessageFormat/CompactSubFormats.java fails
In-Reply-To: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
References: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
Message-ID: <Z0l5NlAe8Bb4KziRwFgOMKNONkFGl8X8wp30Lch4on0=.67e7d9e1-1668-4407-b7cf-fca4f7ccd7b4@github.com>

On Sat, 30 Mar 2024 02:26:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing machines.
> I'm not an expert in this area and just guess it can be fixed like this.
> Please review it.
> 
> Thanks.
> Best regards,
> Jie

LGTM. Thanks for the fix.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18557#pullrequestreview-1971707267

From sroy at openjdk.org  Mon Apr  1 17:07:47 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 1 Apr 2024 17:07:47 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/92e35692..1ad4b33d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/17945

From mdoerr at openjdk.org  Mon Apr  1 18:10:01 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 1 Apr 2024 18:10:01 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
Message-ID: <Jrr66x9v39xqbDFdgjzHW-E7cAen-yesNskRmPPNHs8=.963b48a2-6386-45f2-81a1-1035108d03bf@github.com>

On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spaces

Now, I'm getting "java.lang.UnsatisfiedLinkError: no libname.a in java.library.path" when trying `System.loadLibrary("libname.a")` even though the file exists in the library path. Is this intended?

It may be ok. It seems to work when I use System.loadLibrary("name"). Maybe only the exception message is confusing in the previous case.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2030261780
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2030266833

From mchung at openjdk.org  Mon Apr  1 18:30:04 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 1 Apr 2024 18:30:04 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
Message-ID: <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>

On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spaces

I adjust the comment which also answer your question.   Please add a AIX-only test to verify this behavior.

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.


New file.  Copyright header start year should be 2024.

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 38:

> 36:     /**
> 37:      * Returns true if loading a native library only if
> 38:      * it's present on the file system.

Suggestion:

     * Shared objects may be loaded from .a archive object on AIX and .so may not exist.
     * This method returns false so that loading of shared library continues if libname.so is not present.

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 48:

> 46:     * file may be located at the alternate location.
> 47:     * For most platforms, this behavior is not supported and returns null.
> 48:     */

Suggestion:

    /**
    * AIX implementation of JVM_LoadLibrary handles the alternate path name mapping.
    * If loading of the given library name with ".so" suffix fails, it will attempt to load the library of
    * the same name with ".a" suffix as the alternate name.
    * 
    * This method simply returns null.  It could implement the alternate name converting ".so" with ".a" suffix but redundant.

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

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-1971830272
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1546680293
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1546662648
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1546679104

From mchung at openjdk.org  Mon Apr  1 18:30:05 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 1 Apr 2024 18:30:05 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
Message-ID: <4EJTR63tNfsoZdIjRVVXs7ZaZhXh5ijFSb_NyWg639A=.dfac6ad1-f16a-4cec-b1f6-592f890d6572@github.com>

On Mon, 1 Apr 2024 18:24:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spaces
>
> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 48:
> 
>> 46:     * file may be located at the alternate location.
>> 47:     * For most platforms, this behavior is not supported and returns null.
>> 48:     */
> 
> Suggestion:
> 
>     /**
>     * AIX implementation of JVM_LoadLibrary handles the alternate path name mapping.
>     * If loading of the given library name with ".so" suffix fails, it will attempt to load the library of
>     * the same name with ".a" suffix as the alternate name.
>     * 
>     * This method simply returns null.  It could implement the alternate name converting ".so" with ".a" suffix but redundant.

Nit: please add a new line above line 43.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1546683634

From mchung at openjdk.org  Mon Apr  1 18:34:01 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 1 Apr 2024 18:34:01 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <Jrr66x9v39xqbDFdgjzHW-E7cAen-yesNskRmPPNHs8=.963b48a2-6386-45f2-81a1-1035108d03bf@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <Jrr66x9v39xqbDFdgjzHW-E7cAen-yesNskRmPPNHs8=.963b48a2-6386-45f2-81a1-1035108d03bf@github.com>
Message-ID: <BMhDAket_cvkXdb-r9L93YKqqX9zAE_TjL4OnSTohBQ=.2d2cb422-8323-4d22-9de1-3a1772f0baa5@github.com>

On Mon, 1 Apr 2024 18:02:26 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Now, I'm getting "java.lang.UnsatisfiedLinkError: no libname.a in java.library.path" when trying `System.loadLibrary("libname.a")` even though the file exists in the library path. Is this intended?

To load a library file, you should use `System.load(<lib-absolute-path>)` instead.

For `System::loadLibrary` API, it loads the native library specified by the `libname` argument. The `libname` argument must not contain any platform specific prefix, file extension or path.  See the javadoc [1].

[1] https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/System.html#loadLibrary(java.lang.String)

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2030310318

From mdoerr at openjdk.org  Mon Apr  1 18:40:01 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 1 Apr 2024 18:40:01 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <BMhDAket_cvkXdb-r9L93YKqqX9zAE_TjL4OnSTohBQ=.2d2cb422-8323-4d22-9de1-3a1772f0baa5@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <Jrr66x9v39xqbDFdgjzHW-E7cAen-yesNskRmPPNHs8=.963b48a2-6386-45f2-81a1-1035108d03bf@github.com>
 <BMhDAket_cvkXdb-r9L93YKqqX9zAE_TjL4OnSTohBQ=.2d2cb422-8323-4d22-9de1-3a1772f0baa5@github.com>
Message-ID: <HuTAEwp0cPMLvxxuGOduCK-oDIxeAMxuYjwUw3N7HbY=.649d7231-9662-44db-9be3-a9854c095ffe@github.com>

On Mon, 1 Apr 2024 18:31:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > Now, I'm getting "java.lang.UnsatisfiedLinkError: no libname.a in java.library.path" when trying `System.loadLibrary("libname.a")` even though the file exists in the library path. Is this intended?
> 
> To load a library file, you should use `System.load(<lib-absolute-path>)` instead.
> 
> For `System::loadLibrary` API, it loads the native library specified by the `libname` argument. The `libname` argument must not contain any platform specific prefix, file extension or path. See the javadoc [1].
> 
> [1] https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/System.html#loadLibrary(java.lang.String)

Ok, you convinced me that getting an exception is the correct behavior. Nevertheless, the exception message is wrong. It claims that the file didn't exist, but it does. The problem is a different one.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2030328475

From mchung at openjdk.org  Mon Apr  1 18:43:01 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 1 Apr 2024 18:43:01 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
Message-ID: <49qYdOh7cVrV2Eq_SLMXRsmno2oaSzI1Ed8Je82YERE=.dcb1ab3c-403c-4314-a557-097b2c0bd681@github.com>

On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spaces

The message is correct because `System.loadLibrary("libname.a")` is asking to load a library name with "libname.a" which will be prepended with "lib" and appended with ".so" which is the platform-specific behavior.    No library named "liblibname.a.so" exists

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2030335079

From mdoerr at openjdk.org  Mon Apr  1 18:50:00 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 1 Apr 2024 18:50:00 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
Message-ID: <gWIKCV8srEZifCgMD4u2LAEkUVTqewHGf76nhRD_rCY=.bdef7d6e-eb94-41ee-94a0-ca9d5dc1da52@github.com>

On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spaces

Well, it says "java.lang.UnsatisfiedLinkError: no libname.a in java.library.path". It should rather say "java.lang.UnsatisfiedLinkError: no liblibname.a.so in java.library.path".

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2030343903

From mchung at openjdk.org  Mon Apr  1 18:56:06 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 1 Apr 2024 18:56:06 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
Message-ID: <HfKabpK4f0B_pM4W7zWUn4RE9v0I69lAo4U1Z5TMRJQ=.26f56b75-2796-4b06-bdcc-3fba9f25fcdc@github.com>

On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spaces

Without the alternate name, "liblibname.a.so" would work but not for the case with alternate names though.   It would be confusing printing "liblibname.a.so" or "liblibname.a.a" either way.    Since it's a user error, printing the argument value is better IMO.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2030354793

From mdoerr at openjdk.org  Mon Apr  1 19:02:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 1 Apr 2024 19:02:06 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
Message-ID: <ayvftzU93dEiCcVMU1p4haJ2-UxNelmfP9y5jWNfSRY=.3976a335-327b-4ae2-8229-ef8f9b83aedb@github.com>

On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spaces

I don't agree with that, but we don't need to discuss this here. Exception messages should never lie and always help the programmer.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2030362593

From sgibbons at openjdk.org  Mon Apr  1 21:30:19 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 1 Apr 2024 21:30:19 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory`.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Use non-sse fill (old left in)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/401a2a96..c5cb30cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=00-01

  Stats: 795 lines in 2 files changed: 765 ins; 12 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From cushon at openjdk.org  Mon Apr  1 22:22:19 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 1 Apr 2024 22:22:19 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v5]
In-Reply-To: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
Message-ID: <JWx7o66uJrnstfhnilMY2CHfaxdkBGv2dIJ6hCMGW2k=.a60250fe-fb7b-49b3-97f6-2975fea94e89@github.com>

> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add some more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18479/files
  - new: https://git.openjdk.org/jdk/pull/18479/files/d475de76..c2e16e12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=03-04

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18479/head:pull/18479

PR: https://git.openjdk.org/jdk/pull/18479

From cushon at openjdk.org  Mon Apr  1 22:22:19 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 1 Apr 2024 22:22:19 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <Gqic1iX5dcKEkn0uBtvcBpqloUH1QcLCEjGgHMjaQ-8=.1ddc1947-f7f9-4d1d-8b43-656753218957@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
 <xG1cGAbW9_N7rp3sc5O4_Ph0MdGcuGzWDn2_w8TdJJs=.19418892-e737-4f5f-8b80-3aebcbb09270@github.com>
 <XUYODMuRS6XfGuAgXViZ_L5ESbwqlPu5SfJmODyv6KI=.0ff24f29-9c13-41e3-948d-fa2c20d32df6@github.com>
 <Gqic1iX5dcKEkn0uBtvcBpqloUH1QcLCEjGgHMjaQ-8=.1ddc1947-f7f9-4d1d-8b43-656753218957@github.com>
Message-ID: <YwpXSZhjAGj8y3jSzm4s6VAN5nUpmtS3cbBjfZkW1z8=.c08f4744-af2b-47ec-8130-3c507d1779bf@github.com>

On Fri, 29 Mar 2024 19:54:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> I think it doesn't matter, because the validation below only uses `cenoff`. If `cenoff` fits in 32 bits, we don't need to read the zip64 extra info.
>
> Thanks for the explanation. Could you please add a comment with the info above the `if` statement?

I added a comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1546911662

From cushon at openjdk.org  Mon Apr  1 22:22:19 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 1 Apr 2024 22:22:19 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <ePAi2R36NWMQgnISXwJIT-Z2bdqOOtNlC2TZue59gEA=.24c4b498-1002-4399-b79b-e5b6378be258@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <blggcSb-HpSewfmO6nB5JZQL0m8PR4IfxFLO1VV6Xeo=.cd6807c8-efd1-4758-aec9-7920d7c5e180@github.com>
 <ePAi2R36NWMQgnISXwJIT-Z2bdqOOtNlC2TZue59gEA=.24c4b498-1002-4399-b79b-e5b6378be258@github.com>
Message-ID: <SMr5gg1c46FGHwzOFbA4Wv1h2nyDkHYNhN-v26wLedg=.5d9c7281-2d71-4789-bfcb-92d343522088@github.com>

On Fri, 29 Mar 2024 17:40:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make cendsk an unsigned short
>
> src/java.base/share/native/libjli/parse_manifest.c line 503:
> 
>> 501:                   || cenoff == ZIP64_MAGICVAL)
>> 502:                 && cenext > 0) {
>> 503:               Byte *base = p + CENHDR + CENNAM(p);
> 
> How about adding a comment describing the start of then extended fields calculation?
> 
> // The start of the extended fields = cen_header_start + cen_header_fixed_fix + file_name_length

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1546911714

From cushon at openjdk.org  Mon Apr  1 22:22:19 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 1 Apr 2024 22:22:19 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <OKE0ysEr8Br1-Ak6EXkkYySwyQOS-O8D1ErKl_eIPQM=.7e7e4414-4b11-44aa-9000-00f76bf345ed@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <blggcSb-HpSewfmO6nB5JZQL0m8PR4IfxFLO1VV6Xeo=.cd6807c8-efd1-4758-aec9-7920d7c5e180@github.com>
 <eLlN9xKKhG3Md5AMkeDNeZdQcOSGAZp04H3Y2yBg5NY=.6706b887-df23-4370-8f6b-7a40d753afe4@github.com>
 <z4JT0QIuvUJIgVz_aAl5WI2z9gPBDODSZfFW_dGgJnw=.eb26c9e8-2a71-4eff-b24b-e5896b73c56c@github.com>
 <lK1mFZnmip-6IIjs_pM5VGLWwjD0QKPaBHkIB1sUf68=.79fbc369-36e0-4a82-8db1-0a7d829029bc@github.com>
 <wCTC6i8z29iUpV_UoHdDvN5yLycOsMm3tMhleFQPnhE=.a9e54535-1749-4de2-bda6-fdb67f37bb83@github.com>
 <OKE0ysEr8Br1-Ak6EXkkYySwyQOS-O8D1ErKl_eIPQM=.7e7e4414-4b11-44aa-9000-00f76bf345ed@github.com>
Message-ID: <fuaPCekKwUpjbo9sXtdhOCUudMG94rmmj5_aa_m1OSI=.6af6dc74-a68e-4eb9-8db7-66d9002d46a6@github.com>

On Fri, 29 Mar 2024 18:25:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> it's in APPNOTE.TXT 4.5, the extra field structure is `header1+data1 + header2+data2 . . .`, and we have to iterate through to see if there's an entry that's a zip64 extended information extra field
>
> Thanks! That's helpful. I couldn't find the information earlier.
> 
> According to the spec (quoted below), finding the `Header ID` field can be used to identify the type of data, which is the logic done here. Could you please a comment above the `while` block with some of the related details? Thanks.
> 
> 
> 
>    The Header ID field indicates the type of data that is in
>    the following data block.
> 
>    4.5.2 The current Header ID mappings defined by PKWARE are:
> 
>       0x0001        Zip64 extended information extra field
>       0x0007        AV Info
>       0x0008        Reserved for extended language encoding data (PFS)
>                     (see APPENDIX D)
>       0x0009        OS/2
>       0x000a        NTFS 
>       0x000c        OpenVMS
>       0x000d        UNIX
>       0x000e        Reserved for file stream and fork descriptors
>       0x000f        Patch Descriptor
>       0x0014        PKCS#7 Store for X.509 Certificates
>       0x0015        X.509 Certificate ID and Signature for 
>                     individual file
>       0x0016        X.509 Certificate ID for Central Directory
>       0x0017        Strong Encryption Header
>       0x0018        Record Management Controls
>       0x0019        PKCS#7 Encryption Recipient Certificate List
>       0x0020        Reserved for Timestamp record
>       0x0021        Policy Decryption Key Record
>       0x0022        Smartcrypt Key Provider Record
>       0x0023        Smartcrypt Policy Key Data Record
>       0x0065        IBM S/390 (Z390), AS/400 (I400) attributes 
>                     - uncompressed
>       0x0066        Reserved for IBM S/390 (Z390), AS/400 (I400) 
>                     attributes - compressed
>       0x4690        POSZIP 4690 (reserved)

Added a comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1546911763

From jiefu at openjdk.org  Mon Apr  1 23:06:02 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 1 Apr 2024 23:06:02 GMT
Subject: RFR: 8329354:
 java/text/Format/MessageFormat/CompactSubFormats.java fails
In-Reply-To: <Z0l5NlAe8Bb4KziRwFgOMKNONkFGl8X8wp30Lch4on0=.67e7d9e1-1668-4407-b7cf-fca4f7ccd7b4@github.com>
References: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
 <Z0l5NlAe8Bb4KziRwFgOMKNONkFGl8X8wp30Lch4on0=.67e7d9e1-1668-4407-b7cf-fca4f7ccd7b4@github.com>
Message-ID: <9z4nlROI1w3aFalEQlOkj1YMe2BervzBPLCaRXgIzDc=.19287182-704f-4d42-9316-fd684184ad30@github.com>

On Mon, 1 Apr 2024 16:55:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi all,
>> 
>> java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing machines.
>> I'm not an expert in this area and just guess it can be fixed like this.
>> Please review it.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> LGTM. Thanks for the fix.

Thanks @naotoj .

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

PR Comment: https://git.openjdk.org/jdk/pull/18557#issuecomment-2030741871

From jiefu at openjdk.org  Mon Apr  1 23:06:03 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 1 Apr 2024 23:06:03 GMT
Subject: Integrated: 8329354:
 java/text/Format/MessageFormat/CompactSubFormats.java fails
In-Reply-To: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
References: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
Message-ID: <xplLw1VUDr_ArLrwyOsoPoSZKza5KpUI4u1xIT8izB4=.6bf173c7-5c03-4865-9c9b-7df909590a2d@github.com>

On Sat, 30 Mar 2024 02:26:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing machines.
> I'm not an expert in this area and just guess it can be fixed like this.
> Please review it.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: ecd2b711
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecd2b7112a7617b11997da341d6185756bf1fb0f
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8329354: java/text/Format/MessageFormat/CompactSubFormats.java fails

Reviewed-by: jlu, naoto

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

PR: https://git.openjdk.org/jdk/pull/18557

From tprinzing at openjdk.org  Mon Apr  1 23:37:21 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 1 Apr 2024 23:37:21 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  Add support for AsynchronousFileChannel.force().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/005db0df..8e20527e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=00-01

  Stats: 124 lines in 5 files changed: 111 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542

From dholmes at openjdk.org  Tue Apr  2 02:18:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Apr 2024 02:18:58 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
Message-ID: <MFXU-XkLXbcoiQBKpOe01HTfNH_5mW471a6VENQKBxA=.02f372cb-6c09-483a-bf44-772dcbdd2047@github.com>

On Mon, 1 Apr 2024 21:30:19 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory`.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use non-sse fill (old left in)

This looks like it is still a Draft/work-in-progress. There is only code for x64 and it doesn't appear it will build on other platforms. Also there are still a bunch of `if 0` in the code that should not be there.

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

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-1972492070

From alanb at openjdk.org  Tue Apr  2 04:51:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Apr 2024 04:51:04 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
Message-ID: <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>

On Mon, 1 Apr 2024 23:37:21 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for AsynchronousFileChannel.force().

src/java.base/share/classes/jdk/internal/event/FileForceEvent.java line 35:

> 33:  * {@link #commit(long, long, String, boolean)} method
> 34:  * must be the same as the order of the fields.
> 35:  */

You may have to re-word this comment to avoid confusion with the metaData parameter. That is, there is event metaData and there is file metaData, if you see what I mean.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1547136136

From alanb at openjdk.org  Tue Apr  2 04:58:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Apr 2024 04:58:00 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
Message-ID: <Voj05vqYWf71oQ8xC9o2VU93cPVbJ5XS3oo5yprutHE=.a9904013-20df-434f-9887-62d088138481@github.com>

On Mon, 1 Apr 2024 23:37:21 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for AsynchronousFileChannel.force().

test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 50:

> 48: 
> 49:     public static void main(String[] args) throws Throwable {
> 50:         File blah = File.createTempFile("blah", null);

Can you change this to use the tests's scratch rather that /tmp, meaning `Files.createTempFile(Path.of("."), "blah", "jfr")`. That way the recording is available in the event that the test fails.

test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 64:

> 62: 
> 63:             data.flip();
> 64:             ch.write(data, 0);

This just initiates the write operation, it doesn't wait until it completes. It returns a Future so adding .get() will ensure that it waits and that there is potentially data to write back to the file system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1547139762
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1547138525

From dnsimon at openjdk.org  Tue Apr  2 08:12:02 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 2 Apr 2024 08:12:02 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
Message-ID: <4ECS4yQ0YXQVSt352CQhkQ4dax4VBYv6ZXzK9eBIio0=.baabfef1-2b9e-4b2f-ba0f-e358f6a83af1@github.com>

On Mon, 1 Apr 2024 21:30:19 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory`.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use non-sse fill (old left in)

Wouldn't it be better to do this intrinsification directly in the JIT without calling out to a stub?

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2031348841

From sroy at openjdk.org  Tue Apr  2 08:17:01 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 2 Apr 2024 08:17:01 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
Message-ID: <AIBNzoCFTcp5VlHJfjL9qmpeR-VdNdF-tFwSZqJ-ozg=.7bc2aa08-3622-4de2-8c01-cd1a8782c0e8@github.com>

On Mon, 1 Apr 2024 18:27:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I adjust the comments which also answer your question. Please add an AIX-only test to verify this behavior.

By test you mean provide the use case  for  pure .a files ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2031357165

From jpai at openjdk.org  Tue Apr  2 08:39:17 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 08:39:17 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <AIBNzoCFTcp5VlHJfjL9qmpeR-VdNdF-tFwSZqJ-ozg=.7bc2aa08-3622-4de2-8c01-cd1a8782c0e8@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
 <AIBNzoCFTcp5VlHJfjL9qmpeR-VdNdF-tFwSZqJ-ozg=.7bc2aa08-3622-4de2-8c01-cd1a8782c0e8@github.com>
Message-ID: <aoNPqBbY1b4GtdkNLRDqG4WRjfuEg9BS_4f5Rh1l7Ug=.ef68803c-14de-40f5-9296-c9613db29842@github.com>

On Tue, 2 Apr 2024 08:14:25 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> I adjust the comments which also answer your question.   Please add an AIX-only test to verify this behavior.
>
>> I adjust the comments which also answer your question. Please add an AIX-only test to verify this behavior.
> 
> By test you mean provide the use case  for  pure .a files ?

Hello @suchismith1993,

> > I adjust the comments which also answer your question. Please add an AIX-only test to verify this behavior.
> 
> By test you mean provide the use case for pure .a files ?

In the JDK repo, changes like these are backed by jtreg tests https://openjdk.org/guide/#jtreg. So for this change, you would need to add a jtreg test which only runs on AIX (the jtreg documentation explains how to do that) and will exercise the `System.loadLibrary` call for a AIX specific library and verify that the library can be loaded as per the expectations that are set in the changes proposed and finalized in this PR.

For example, the test should verify that, after the changes proposed in this PR, calling `System.loadLibrary(<libname>)` on AIX will load from `<libname>.a` if `<libname>.so` is absent.

For reference, you can take a look at the existing tests for loadLibrary in the `test/jdk/java/lang/RuntimeTests/loadLibrary` directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2031403158

From vklang at openjdk.org  Tue Apr  2 08:53:08 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 2 Apr 2024 08:53:08 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v20]
In-Reply-To: <zaNYbEwbrsNO0cHpiVOQdTHoRah2Y7mNtnx7TBlFvU8=.5bf10d68-1a75-4a80-a6e1-64b97be266a1@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <zaNYbEwbrsNO0cHpiVOQdTHoRah2Y7mNtnx7TBlFvU8=.5bf10d68-1a75-4a80-a6e1-64b97be266a1@github.com>
Message-ID: <6OqL9Enn3MN8ydugWcadfrupzyMo8y4r7BXWfwNeo5U=.34bab5e5-1d44-4b26-8b72-b804ddeef601@github.com>

On Fri, 29 Mar 2024 20:48:09 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stray blank line

src/java.base/share/classes/java/lang/ref/Reference.java line 641:

> 639:      * reference to this {@code Resource}.  The
> 640:      * {@code reachabilityFence} call is placed in a {@code finally} block to ensure
> 641:      * that it is invoked across all paths in the method. A more complex method

Suggestion:

     * reference to this {@code Resource}.
     * The {@code reachabilityFence} call is placed in a {@code finally} block to ensure
     * that it is invoked across all paths in the method. A more complex method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1547426722

From duke at openjdk.org  Tue Apr  2 09:18:00 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 2 Apr 2024 09:18:00 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
Message-ID: <x1OGYrq6WVNi7k9azvbWDKTqunfNpcgZkyolJ0Qu_DU=.a0ee8ec4-9afb-4de5-914f-62bf347ed19d@github.com>

On Mon, 1 Apr 2024 21:30:19 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory`.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use non-sse fill (old left in)

src/hotspot/share/opto/library_call.hpp line 235:

> 233:   bool inline_unsafe_copyMemory();
> 234: 
> 235:   bool inline_unsafe_setMemory();

Maybe?remove the?empty?line between?these `inline_unsafe_*Memory` methods?
Suggestion:

  bool inline_unsafe_copyMemory();
  bool inline_unsafe_setMemory();

src/hotspot/share/prims/unsafe.cpp line 391:

> 389:   size_t sz = (size_t)size;
> 390: 
> 391: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1546092398
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1546093297

From asotona at openjdk.org  Tue Apr  2 09:43:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 Apr 2024 09:43:11 GMT
Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory
 methods  accepting Opcode
Message-ID: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>

`IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented:

- `ArrayLoadInstruction`
- `ArrayStoreInstruction`
- `BranchInstruction`
- `ConvertInstruction`
- `DiscontinuedInstruction`
- `FieldInstruction`
- `InvokeInstruction`
- `LoadInstruction`
- `MonitorInstruction`
- `NewPrimitiveArrayInstruction`
- `OperatorInstruction`
- `ReturnInstruction`
- `StackInstruction`
- `StoreInstruction`
- `TypeCheckInstruction`

`NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument.

This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check.

Please review.

Thank you,
Adam

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

Commit messages:
 - 8329099: Undocumented exception thrown by Instruction factory methods accepting Opcode

Changes: https://git.openjdk.org/jdk/pull/18578/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18578&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329099
  Stats: 36 lines in 15 files changed: 36 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18578/head:pull/18578

PR: https://git.openjdk.org/jdk/pull/18578

From jpai at openjdk.org  Tue Apr  2 09:54:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 09:54:01 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar
In-Reply-To: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
Message-ID: <nrRnCbkFKbbRDyAM6ByGF9O6foVNLEtkFXawfPiMQ6o=.1bcf00a1-5a56-4562-96fe-5ed6e90895af@github.com>

On Thu, 28 Mar 2024 15:55:12 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
> This patch adds logic to the EventHelper class to detect recursion and prevent it.

Hello Sean, from what I understand of this proposed fix, what we are attempting here is to prevent a re-entrant call into `System.getLogger()`? Is my understanding correct? The linked JBS issue has a stacktrace from Java 8 and doesn't match the current mainline code so it isn't fully clear to me what's triggering the StackOverFlowError. I tried to reproduce this with the jtreg test that's part of this PR, without including your proposed fix, but that didn't reproduce the StackOverFlowError but the test seems to have uncovered some kind of deadlock in running the shutdown hook that the LogManager installs in the Runtime. I will check that issue separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/18534#issuecomment-2031560133

From coffeys at openjdk.org  Tue Apr  2 10:29:58 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 2 Apr 2024 10:29:58 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar
In-Reply-To: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
Message-ID: <xqjceTZHn5qFubU_kO3W8icMjte6xWJ8ilkS94vP9Uo=.a1952552-f206-464e-8892-58d66b61ccec@github.com>

On Thu, 28 Mar 2024 15:55:12 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
> This patch adds logic to the EventHelper class to detect recursion and prevent it.

Thanks for taking a look at this Jai. Without the src patch, the test should create an SOE. Have a look at the resulting jtr file[1]. jtreg complains about a timeout due to some other lock up issue. I figured that since the test shouldn't fail, then it shouldn't be an issue. Probably worth logging another issue to track that.

The `EventHelper` class can be called to log crypto events - if these events occur during logging initialization, then recursive calls can cause problems. This patch should fix up that area and block recursive calls (by returning false in the 2nd recursive call into same method)

[1]

`Java HotSpot(TM) 64-Bit Server VM warning: Potentially dangerous stack overflow in ReservedStackAccess annotated method java.util.logging.LogManager.ensureLogManagerInitialized()V [1]
java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.event.EventHelper$ThreadTrackHolder
        at java.base/jdk.internal.event.EventHelper.endLookup(EventHelper.java:146)
        at java.base/jdk.internal.event.EventHelper.isLoggingSecurity(EventHelper.java:169)
        at RecursiveEventHelper.getProperty(RecursiveEventHelper.java:56)
        at java.logging/java.util.logging.LogManager.getLevelProperty(LogManager.java:2340)
        at java.logging/java.util.logging.LogManager$LoggerContext.addLocalLogger(LogManager.java:802)
        at java.logging/java.util.logging.LogManager$LoggerContext.ensureDefaultLogger(LogManager.java:752)
        at java.logging/java.util.logging.LogManager$LoggerContext.ensureInitialized(LogManager.java:660)
        at java.logging/java.util.logging.LogManager$LoggerContext.getLoggerNames(LogManager.java:852)
        at java.logging/java.util.logging.LogManager.resetLoggerContext(LogManager.java:1461)
        at java.logging/java.util.logging.LogManager.reset(LogManager.java:1451)
        at java.logging/java.util.logging.LogManager.readConfiguration(LogManager.java:1581)
        at java.logging/java.util.logging.LogManager.readConfiguration(LogManager.java:1384)
        at java.logging/java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:446)
        at java.logging/java.util.logging.LogManager$2.run(LogManager.java:395)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.logging/java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:383)
        at java.logging/java.util.logging.LogManager.getLogManager(LogManager.java:431)
        at java.logging/sun.util.logging.internal.LoggingProviderImpl.demandJULLoggerFor(LoggingProviderImpl.java:409)
        at java.logging/sun.util.logging.internal.LoggingProviderImpl.demandLoggerFor(LoggingProviderImpl.java:438)
        at java.base/jdk.internal.logger.DefaultLoggerFinder.getLogger(DefaultLoggerFinder.java:159)
        at java.base/jdk.internal.logger.LazyLoggers.getLoggerFromFinder(LazyLoggers.java:410)
        at java.base/jdk.internal.logger.LazyLoggers.getLogger(LazyLoggers.java:437)
        at java.base/java.lang.System.getLogger(System.java:1831)
        at RecursiveEventHelper.main(RecursiveEventHelper.java:47)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1575)
Caused by: java.lang.StackOverflowError
`

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

PR Comment: https://git.openjdk.org/jdk/pull/18534#issuecomment-2031635027

From pminborg at openjdk.org  Tue Apr  2 10:42:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 2 Apr 2024 10:42:25 GMT
Subject: RFR: JDK-8329089: Empty immutable list throws the wrong exception type
 for remove(first | last) operations
Message-ID: <VqsB3uxDN8_H2wgkRz56gdTz5Ot1i5zOD3KlgjtR8FA=.74bfc834-647c-4cf7-bd60-5b846f780f06@github.com>

This PR proposes to make empty immutable lists always throw UOE on `removeFirst` and `removeLast`.

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

Commit messages:
 - Make empty immutable lists always throw UOE on remove(F|L)

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

PR: https://git.openjdk.org/jdk/pull/18581

From jpai at openjdk.org  Tue Apr  2 11:21:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 11:21:58 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar
In-Reply-To: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
Message-ID: <7mPue4ufNIbI8hLs1vrx2LDjfwuqecR4gECS-3If3NA=.1c54f7cf-ef8b-455a-9ba9-4195a319c132@github.com>

On Thu, 28 Mar 2024 15:55:12 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
> This patch adds logic to the EventHelper class to detect recursion and prevent it.

You are right, turns out the jtr file did have the StackOverFlowError from the test introduced in this PR - I just didn't check it given the other issue. 

Now that I look at the stacktrace and the complex checks we are adding, I am starting to wonder if these re-entrancy checks should actually be added within the `jdk.internal.logger` implementation code/classes, instead of at these call sites. As far as I can see, the `jdk.internal.event.EventHelper` isn't doing anything out of the ordinary and the same issue could probably end up in some other parts during the logging initialization.

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

PR Comment: https://git.openjdk.org/jdk/pull/18534#issuecomment-2031738798

From duke at openjdk.org  Tue Apr  2 12:57:08 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 2 Apr 2024 12:57:08 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
Message-ID: <vudrAiU0bDuHOJxeXOhPTr6cGZzajM_xwkCqmmizFsU=.ad583459-b9c3-4162-a8e1-d1771dc446a9@github.com>

On Thu, 28 Mar 2024 14:08:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 1415:

> 1413:                                                      canonicalConstructorTypes,
> 1414:                                                      List.nil());
> 1415:         createNew.constructor = init;

Maybe?instead of?hardcoding the?constructor that?is?canonical at?compile?time (in?case new?components get?added), it?might be?better to?go?through some?sort of?`indy`?callsite?like (at?least when?not in?the?same compilation?unit):

DynamicCallSiteDesc[java.lang.runtime.RecordSupport::derivedConstructor(modified component names...):(T extends Record, Class<?>... /*?modified component types?*/)T]


with?the `derivedConstructor` bootstrap?method:

public static MethodHandle derivedConstructor(MethodHandles.Lookup lookup, String unused, MethodType type, String... modifiedComponents) throws ReflectiveOperationException {
	requireNonNull(lookup);
	requireNonNull(type);
	// implicit null-check:
	List<String> modifiedComponentNames = List.of(modifiedComponents);

	Class<?> rtype = type.returnType();
	if (
		!rtype.isRecord()
		|| type.parameterCount() != modifiedComponents.length + 1
		|| type.parameterType(0) != rtype
	) {
		throw new IllegalArgumentException("...");
	}

	Set<String> remainingComponentNames = new HashSet(modifiedComponentNames);
	if (remainingComponentNames.size() != modifiedComponentNames.size()) {
		throw new IllegalArgumentException("Duplicate component names in modifiedComponents");
	}

	RecordComponent[] recordComponents = rtype.getRecordComponents();

	var componentTypes = new Class<?>[recordComponents.length];
	var filters = new MethodHandle[recordComponents.length];
	var reorder = new int[recordComponents.length];

	for (int i = 0, j = 1; i < recordComponents.length; i++) {
		var component = recordComponents[i];
		componentTypes[i] = component.getType();

		var getter = lookup.findVirtual(rtype, component.getName(), MethodType.methodType(component.getType()));
		if (modifiedComponentNames.contains(component.getName())) {
			remainingComponentNames.remove(component.getName());
			filters[i] = null;
			reorder[i] = j++;
		} else {
			filters[i] = getter;
			reorder[i] = 0;
		}
	}

	if (!remainingComponentNames.isEmpty()) {
		throw new IllegalArgumentException("Components " + remainingComponentNames + " are not present in the record " + rtype);
	}

	var canonicalConstructor = lookup.findConstructor(rtype, MethodType.methodType(rtype, componentTypes);
	var filteredConstructor = MethodHandles.filterArguments(canonicalConstructor, 0, filters);
	// implicitly verifies that type's parameter types match the actual component types
	var permutedConstructor = MethodHandles.permuteArguments(filterArguments, type, reorder);

	return permutedConstructor;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1547819538

From dfuchs at openjdk.org  Tue Apr  2 13:44:01 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 Apr 2024 13:44:01 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar
In-Reply-To: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
Message-ID: <4bgpFCLC-ev2CYiJiwhWuC4liqoAzCZAIIBXiyCvkPU=.31553606-cbfb-4ad2-85ed-d0038d0399a9@github.com>

On Thu, 28 Mar 2024 15:55:12 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
> This patch adds logic to the EventHelper class to detect recursion and prevent it.

The code changes LGTM. Some comments on the test.

test/jdk/jdk/security/logging/RecursiveEventHelper.java line 56:

> 54:         // a recursive call (via EventHelper.isLoggingSecurity) back into
> 55:         // logger API
> 56:         EventHelper.isLoggingSecurity();

As an additional check you could set a static volatile boolean to true here and double check that it's been set at the end of the main method,

test/jdk/jdk/security/logging/RecursiveEventHelper.java line 59:

> 57:         return super.getProperty(p);
> 58:     }
> 59: }

add newline?

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

PR Review: https://git.openjdk.org/jdk/pull/18534#pullrequestreview-1973842520
PR Review Comment: https://git.openjdk.org/jdk/pull/18534#discussion_r1547904127
PR Review Comment: https://git.openjdk.org/jdk/pull/18534#discussion_r1547897811

From sgehwolf at openjdk.org  Tue Apr  2 14:08:08 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 2 Apr 2024 14:08:08 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
Message-ID: <N9RY-jflyONMXhaqhOEm7Z4i6EOiDEVlYkDw7H7qTjg=.38ae4224-7fad-453a-a3e7-4530ef9aaf9b@github.com>

On Tue, 19 Mar 2024 16:55:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move CreateLinkableRuntimePlugin to build folder
>   
>   Keep runtime link supporting classes in package
>   jdk.tools.jlink.internal.runtimelink

I'm posting this for posterity, since I did some research on the `jimage` format in light of being able to re-create an existing `jimage` file with potentially a few resources being added. One use-case for this would be to add the "diff" data to an pre-existing, optimized `jimage` in `images/jdk/lib/modules`. The way that the `jimage` write algorithm works is based on the fact that it knows the resources and bytes at `jlink` time in **full**. Therefore, it can iterate over all resources, generate an index (and header) for them and then can serialize resource bytes as well as container (folder) information for them so as to support various iteration entry points. Since it's inherently relying on the header, index and container information at `jimage` read-time the format doesn't lend itself nicely for "appending". By adding just a few resources, the header, index, and container iteration information get invalidated. Therefore, a new `jimage` would need to be created, based on the old 
 `jimage`'s resources inferring `ResourcePoolEntry`s and then working with them. The additional resources would then get added and header/index/container info generated afresh. In order to support this, the existing `jimage` file would need to have sufficient information in it, to re-constitute a "similar" jimage from it (at the infer `ResourcePoolEntry` step). There are two specific issues that need to be overcome to support this: resource ordering and resource compression. There might be more, that I'm missing.

## Ordering of Resources

`jlink` supports ordering of resources. In other words, the `--order-resources` plugin instructs `jlink` to produce a `jimage` where resources will end up in the target `jimage` in a specified order. This can be observed by listing `jimage` contents sorted by content byte offsets. For example, the default JDK build for Linux adds this expression: `--order-resources=**module-info.class,@/path/to/build/output/support/link_opt/classlist,/java.base/java/**,/java.base/jdk/**,/java.base/sun/**,/java.base/com/**,/jdk.localedata/**` to the `jlink` invocation at build time. That is, `module-info.class` files come first in the resulting `jimage`, then class bytes as specified by CDS's `classlist` file, then `java.base/java` classes and so on. How would one re-constitute the desired ordering given only the `jimage` file as input? I think this could be solved by looking at the content byte offsets in the existing `jimage` for each resource. This would allow one to re-constitute the ordering in t
 he derived image. The question would be how ordering of the added resources should be handled in such a case.

## Compression of Resources

`jlink` suppports compression of resources. Currently, only `zip` and `compact-cp` are supported. There is still code handling multiple compressions. In fact, the `jimage` format itself doesn't put a bound on the number of levels of compressions. In other words, a resource could be compressed with the `zip` compressor multiple times or use the `compact-cp` compressor in conjunction with the `zip` compressor. In my investigation, I've focused on the `zip` compressor for now. In my research I've not found a reliable way to detect the **input level** compaction level, like `zip-1` by looking only at a `jimage` file. `jlink` uses `Inflater` and `Deflater` classes internally to decompress and compress respectively, but the `zlib` format doesn't seem to expose the 10 input levels (`zip-0` to `zip-9`). It only has a notion of it's three compression levels that's exposed in the `zlib` header. Fastest compression, fast compression and max compression (default compression level being the fourt
 h). However, for example `zip-1` compaction level has the following config in terms of `good`, `lazy`, `nice` and `chain` configs: `4`, `4`, `8`, `4` together with `deflate_fast` compression function (compress level exposed in the `zlib` header). One possible way to overcome this would be to support some kind of pass-through compressor in `jlink` code. I haven't looked much into `compact-cp` code, but the challenges there might be similar.

It's also worth noting that the current `jlink` code seems to support compression only for a select set of files. That would likely also need investigation how it could be handled. The "pass-through" idea could be viable for this too as compressed bytes would be "passed through" to the target `jimage`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2032140826

From jpai at openjdk.org  Tue Apr  2 14:49:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 14:49:12 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
In-Reply-To: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
Message-ID: <tqTfOs3OsGnGuNjeZSyKn94BHNFvqLtSx9ulVZceDJw=.09a55777-5bd4-49a7-a588-1595841c010a@github.com>

On Tue, 26 Mar 2024 18:18:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/nio/channels/unixdomain/Bind.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java line 68:

> 66:             // or exception could be thrown otherwise
> 67:         } finally {
> 68:             Files.deleteIfExists(addr.getPath());

Hello Bill, `addr` can be `null` here, so this has a potential of a `NullPointerException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1548038473

From jpai at openjdk.org  Tue Apr  2 14:56:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 14:56:01 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
In-Reply-To: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
Message-ID: <hjGGd5cVG-hz1bHQi2Idj1sEPFmbGAPJtPe9c0B41OU=.057d651f-3341-47c9-94df-1102eaa32fbf@github.com>

On Tue, 26 Mar 2024 18:18:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/nio/channels/unixdomain/Bind.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

For the changes in `test/jdk/java/nio/file/Files/CheckPermissions.java` it would be good to have Alan and/or Brian's inputs. The test documentation says that the test relates to SecurityManager checks (and not filesystem permission checks), so the proposed changes in this PR to use a different parent directory for the temporary file(s) should be OK, but I am not familiar with that area to be certain about it.

test/jdk/sun/security/pkcs12/P12SecretKey.java line 69:

> 67: 
> 68:         File ksFile = File.createTempFile("test", ".test");
> 69:         ksFile.deleteOnExit();

Is there a reason why this change is done differently than the rest of the changes in this PR? Can we delete the `File` in a try/finally instead of enrolling a shutdown hook to delete it?

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2032269381
PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1548045308

From coffeys at openjdk.org  Tue Apr  2 14:59:33 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 2 Apr 2024 14:59:33 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar [v2]
In-Reply-To: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
Message-ID: <G8JZKtt7WNbGOiU64q49mIryLJY-gTK9VThLK5W_tOc=.d40c83b7-962d-4de8-89ed-9bae98a5ed63@github.com>

> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
> This patch adds logic to the EventHelper class to detect recursion and prevent it.

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

  incorporate testcase feedback from Daniel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18534/files
  - new: https://git.openjdk.org/jdk/pull/18534/files/196634ec..90c8467a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18534&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18534&range=00-01

  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18534/head:pull/18534

PR: https://git.openjdk.org/jdk/pull/18534

From coffeys at openjdk.org  Tue Apr  2 15:04:12 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 2 Apr 2024 15:04:12 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar
In-Reply-To: <7mPue4ufNIbI8hLs1vrx2LDjfwuqecR4gECS-3If3NA=.1c54f7cf-ef8b-455a-9ba9-4195a319c132@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
 <7mPue4ufNIbI8hLs1vrx2LDjfwuqecR4gECS-3If3NA=.1c54f7cf-ef8b-455a-9ba9-4195a319c132@github.com>
Message-ID: <EnKawCXDo3qieX4ZbIp1TMOLWb7ZqQlXrOrwOUssEKo=.ba3d6e39-0bc8-44e3-9012-785e70b0406d@github.com>

On Tue, 2 Apr 2024 11:16:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
>> This patch adds logic to the EventHelper class to detect recursion and prevent it.
>
> You are right, turns out the jtr file did have the StackOverFlowError from the test introduced in this PR - I just didn't check it given the other issue. 
> 
> Now that I look at the stacktrace and the complex checks we are adding, I am starting to wonder if these re-entrancy checks should actually be added within the `jdk.internal.logger` implementation code/classes, instead of at these call sites. As far as I can see, the `jdk.internal.event.EventHelper` isn't doing anything out of the ordinary and the same issue could probably end up in some other parts during the logging initialization.

@jaikiran  I did look at adding logic in the Logger libraries also to correct this issue. Significant work was done in that area last year via JDK-8314263

I guess the question is what sort of Logger and LoggerFinder would you return in cases where recursion is detected ? Extra issues might arise from the System.getLogger method being public and widely used. Additional issues might stem from the fact that Logger libraries can be plugged in and returned Logger might be stored as a static variable etc.

It seemed safer to catch the issue at the EventHelper level - a library that's confined to internal JDK use.

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

PR Comment: https://git.openjdk.org/jdk/pull/18534#issuecomment-2032295584

From sgibbons at openjdk.org  Tue Apr  2 15:14:34 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 2 Apr 2024 15:14:34 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v3]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <DaVxHk7QSm-o1ckol0BJEjezB-A9mvAn4fJn8tqFlTY=.9da4f532-fe54-4d6a-bbff-d36e9000326e@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory`.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision:

 - Addressing review comments.
 - Remove dead code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/c5cb30cc..3aa60a48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=01-02

  Stats: 605 lines in 5 files changed: 16 ins; 567 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From jpai at openjdk.org  Tue Apr  2 15:26:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 15:26:00 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar [v2]
In-Reply-To: <G8JZKtt7WNbGOiU64q49mIryLJY-gTK9VThLK5W_tOc=.d40c83b7-962d-4de8-89ed-9bae98a5ed63@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
 <G8JZKtt7WNbGOiU64q49mIryLJY-gTK9VThLK5W_tOc=.d40c83b7-962d-4de8-89ed-9bae98a5ed63@github.com>
Message-ID: <jQaSHEEhWdCr4ftUfXMgtWqfdyhFfMIg66kQiKKBqqc=.9408c9fa-a119-46b9-808b-800b0cf04db8@github.com>

On Tue, 2 Apr 2024 14:59:33 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
>> This patch adds logic to the EventHelper class to detect recursion and prevent it.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate testcase feedback from Daniel

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18534#pullrequestreview-1974181831

From jpai at openjdk.org  Tue Apr  2 15:26:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 15:26:01 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar
In-Reply-To: <EnKawCXDo3qieX4ZbIp1TMOLWb7ZqQlXrOrwOUssEKo=.ba3d6e39-0bc8-44e3-9012-785e70b0406d@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
 <7mPue4ufNIbI8hLs1vrx2LDjfwuqecR4gECS-3If3NA=.1c54f7cf-ef8b-455a-9ba9-4195a319c132@github.com>
 <EnKawCXDo3qieX4ZbIp1TMOLWb7ZqQlXrOrwOUssEKo=.ba3d6e39-0bc8-44e3-9012-785e70b0406d@github.com>
Message-ID: <7_cIqnWAnwdjrlfjVRM9MZnImyPdVG-LT8UUelggYpE=.cd7b44f2-6e2f-4e38-9e3b-1a871b14749f@github.com>

On Tue, 2 Apr 2024 15:01:15 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> I guess the question is what sort of Logger and LoggerFinder would you return in cases where recursion is detected ? Extra issues might arise from the System.getLogger method being public and widely used. Additional issues might stem from the fact that Logger libraries can be plugged in and returned Logger might be stored as a static variable etc.

Agreed - a lot of questions will need to be answered before attempting any change in that code. I don't have answers to any of those though :) 

Given that `System.getLogger()` is public API and from the looks of it, any application code can trigger this issue without a JDK internal class involvement (I'm guessing if you modify the test in this PR to replace the call to `EventHelper.isLoggingSecurity();` with `var foo = System.getLogger("bar");` the StackOverFlowError issue will reproduce?), I think the real issue will continue to exist after this change.

Having said that, I didn't mean to stop you from doing this change in `EventHelper`. My question was merely an observation. Your change in the current form looks OK to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/18534#issuecomment-2032348980

From acobbs at openjdk.org  Tue Apr  2 15:55:20 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 2 Apr 2024 15:55:20 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream
 semantics
Message-ID: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>

`GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.

There are several issues with this:

1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.

On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).

So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.

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

Commit messages:
 - Javadoc wording tweaks.
 - Merge branch 'master' into JDK-8322256
 - Clarify exceptions: sometimes ZipException, sometimes EOFException.
 - Merge branch 'master' into JDK-8322256
 - Javadoc wording tweaks.
 - Add "allowConcatenation" and "allowTrailingGarbage" to GZIPInputStream.

Changes: https://git.openjdk.org/jdk/pull/18385/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322256
  Stats: 303 lines in 2 files changed: 286 ins; 2 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/18385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385

PR: https://git.openjdk.org/jdk/pull/18385

From duke at openjdk.org  Tue Apr  2 16:10:55 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 2 Apr 2024 16:10:55 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
Message-ID: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>

Performance. Before:

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s

Performance, no intrinsic:

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s

Performance, **with intrinsics**

Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  10384.591 ?  65.274  ops/s
SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3   9592.912 ? 236.411  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3   3479.494 ?  44.578  ops/s
SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3   3402.147 ?  26.772  ops/s
Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  2527.678 ? 64.791  ops/s
o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  2541.258 ? 66.634  ops/s
Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
PolynomialP256Bench.benchMultiply           true  thrpt    3  3021.139 ? 98.289  ops/s


Summary on design (see code for 'ASCII art', references and details on math):
- Added a new `IntegerPolynomial` field (`MontgomeryIntegerPolynomialP256`) with 52-bit limbs
   - `getElement(*)/fromMontgomery()` to convert numbers into/out of the field
 - `ECOperations` is the primary use of the new field
   - flattened some extra deep nested class hierarchy (also in prep for further other field optimizations)
   - `forParameters()/multiply()/setSum()` generates numbers in the new field
 - `ProjectivePoint/Montgomery{Imm|M}utable.asAffine()` to convert out of the new field
 - Added Fuzz Testing and KAT verified with OpenSSL

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

Commit messages:
 - remove trailing whitespace
 - Remeasure performance
 - Fix rebase typo
 - Address comments from Anas and thorough cleanup
 - conditionalAssign intrinsic
 - rebase

Changes: https://git.openjdk.org/jdk/pull/18583/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329538
  Stats: 2335 lines in 34 files changed: 2037 ins; 162 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

PR: https://git.openjdk.org/jdk/pull/18583

From bhuang at openjdk.org  Tue Apr  2 16:29:21 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 2 Apr 2024 16:29:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v5]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

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

  Implemented review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/0f4130a9..81244609

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=03-04

  Stats: 30 lines in 2 files changed: 12 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

PR: https://git.openjdk.org/jdk/pull/18352

From alanb at openjdk.org  Tue Apr  2 16:32:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Apr 2024 16:32:09 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <I-I4lM6idN5RDH-PmDJKAjbK2RuRYP-q60cMBLAxfi0=.e6648bbd-5cfa-4e0b-9812-50c2de4edb8b@github.com>

On Tue, 2 Apr 2024 15:42:05 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

src/java.base/share/classes/module-info.java line 265:

> 263:         jdk.jfr,
> 264:         jdk.unsupported,
> 265:         jdk.crypto.ec;

jdk.crypto.ec has been hollowed out since JDK 22, the sun.security.ec are in java.base. So I don't think you need this qualified export.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1548199507

From dfuchs at openjdk.org  Tue Apr  2 17:25:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 Apr 2024 17:25:12 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar [v2]
In-Reply-To: <4bgpFCLC-ev2CYiJiwhWuC4liqoAzCZAIIBXiyCvkPU=.31553606-cbfb-4ad2-85ed-d0038d0399a9@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
 <4bgpFCLC-ev2CYiJiwhWuC4liqoAzCZAIIBXiyCvkPU=.31553606-cbfb-4ad2-85ed-d0038d0399a9@github.com>
Message-ID: <JweIAyKPJjR5q97LOKq63hrNqQ4uAjVym7yBE0MKRWM=.fcc17671-6516-4f09-bbc2-b6264ca49504@github.com>

On Tue, 2 Apr 2024 13:38:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   incorporate testcase feedback from Daniel
>
> test/jdk/jdk/security/logging/RecursiveEventHelper.java line 56:
> 
>> 54:         // a recursive call (via EventHelper.isLoggingSecurity) back into
>> 55:         // logger API
>> 56:         EventHelper.isLoggingSecurity();
> 
> As an additional check you could set a static volatile boolean to true here and double check that it's been set at the end of the main method,

In fact it doesn't need to be volatile since it all happens in the main thread - but that's not a big issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18534#discussion_r1548280946

From dfuchs at openjdk.org  Tue Apr  2 17:25:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 Apr 2024 17:25:10 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar [v2]
In-Reply-To: <G8JZKtt7WNbGOiU64q49mIryLJY-gTK9VThLK5W_tOc=.d40c83b7-962d-4de8-89ed-9bae98a5ed63@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
 <G8JZKtt7WNbGOiU64q49mIryLJY-gTK9VThLK5W_tOc=.d40c83b7-962d-4de8-89ed-9bae98a5ed63@github.com>
Message-ID: <HtdJzhotrBZ3H2Jkm3UT9nCBjB5F-YqmhFG3YPmSJr4=.20151ece-5152-4aa4-81b9-556bf8a9da45@github.com>

On Tue, 2 Apr 2024 14:59:33 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
>> This patch adds logic to the EventHelper class to detect recursion and prevent it.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate testcase feedback from Daniel

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18534#pullrequestreview-1974475681

From coffeys at openjdk.org  Tue Apr  2 17:35:08 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 2 Apr 2024 17:35:08 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar [v2]
In-Reply-To: <G8JZKtt7WNbGOiU64q49mIryLJY-gTK9VThLK5W_tOc=.d40c83b7-962d-4de8-89ed-9bae98a5ed63@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
 <G8JZKtt7WNbGOiU64q49mIryLJY-gTK9VThLK5W_tOc=.d40c83b7-962d-4de8-89ed-9bae98a5ed63@github.com>
Message-ID: <RBPsFranrA6X9_6Kdx1udA6Bmi_3s84Bi2esA5XDuc0=.63a8cf38-72cd-447d-9164-c6e12c48b527@github.com>

On Tue, 2 Apr 2024 14:59:33 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
>> This patch adds logic to the EventHelper class to detect recursion and prevent it.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate testcase feedback from Daniel

Thanks for the reviews. Yes - your suggestion would be another example of how recursion could occur with the System Logger Jai. I'll have a look to see if some sort of Noop Logger could be returned if recursion is detected at System Logger end.

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

PR Comment: https://git.openjdk.org/jdk/pull/18534#issuecomment-2032641881

From coffeys at openjdk.org  Tue Apr  2 17:35:09 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 2 Apr 2024 17:35:09 GMT
Subject: Integrated: 8329013: StackOverflowError when starting Apache Tomcat
 with signed jar
In-Reply-To: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
References: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@github.com>
Message-ID: <1t_I2AxLHrvm8nKZi5DXdOHyCI8asjvAvxKy6L0wdOY=.7b3b01d1-7e0e-45d2-b1bf-399ab64c7b6e@github.com>

On Thu, 28 Mar 2024 15:55:12 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Calling extra logging calls during initialization of Logger libraries can cause recursion leading to StackOverflowError
> This patch adds logic to the EventHelper class to detect recursion and prevent it.

This pull request has now been integrated.

Changeset: 925d8293
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/925d82931c09dc11ea5a3bc410ea5cfd67ee14aa
Stats:     94 lines in 2 files changed: 86 ins; 1 del; 7 mod

8329013: StackOverflowError when starting Apache Tomcat with signed jar

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.org/jdk/pull/18534

From darcy at openjdk.org  Tue Apr  2 18:08:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Apr 2024 18:08:09 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
Message-ID: <LNXC3butqNvq566NxesHBtfldFXC4irGFLvII-f3kPo=.644dd63f-0901-4bae-878a-c0d5b7cbe5b1@github.com>

On Thu, 28 Mar 2024 14:08:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

For the `javax.lang.model` changes, as a new ElementKind is being introduced, there should be a matching layer of new concrete visitors and selected updates to existing visitor implementations, etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18509#issuecomment-2032717646

From darcy at openjdk.org  Tue Apr  2 18:12:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Apr 2024 18:12:09 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <LNXC3butqNvq566NxesHBtfldFXC4irGFLvII-f3kPo=.644dd63f-0901-4bae-878a-c0d5b7cbe5b1@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <LNXC3butqNvq566NxesHBtfldFXC4irGFLvII-f3kPo=.644dd63f-0901-4bae-878a-c0d5b7cbe5b1@github.com>
Message-ID: <xedikVjcXFBPNR3yrDWrR70EQ50R00FE9YCF_fC3jxY=.984cb642-db6d-48c9-b976-3e55f9b5a23f@github.com>

On Tue, 2 Apr 2024 18:05:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> For the `javax.lang.model` changes, as a new ElementKind is being introduced, there should be a matching layer of new concrete visitors and selected updates to existing visitor implementations, etc.

I can help develop the visitor changes if you'd like.

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

PR Comment: https://git.openjdk.org/jdk/pull/18509#issuecomment-2032724647

From mchung at openjdk.org  Tue Apr  2 18:55:12 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 2 Apr 2024 18:55:12 GMT
Subject: Integrated: 8326979: (jdeps) improve the error message for
 FindException caused by InvalidModuleDescriptorException
In-Reply-To: <Kk24dug_yvI5s_W8v636SACpzJia3TDHPDbCrOQiKHg=.edcd1d99-564c-4308-b914-53eaf7c7180d@github.com>
References: <Kk24dug_yvI5s_W8v636SACpzJia3TDHPDbCrOQiKHg=.edcd1d99-564c-4308-b914-53eaf7c7180d@github.com>
Message-ID: <PqcIILqvCeo8EV0x28U1IlwOFSwt6Sn9k8CZl0vv7gc=.a012c6c1-481b-4e2b-9ecb-92be4169bf71@github.com>

On Thu, 14 Mar 2024 17:35:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Trivial fix.  Improve the error message to print the cause of the module resolution failure if present.

This pull request has now been integrated.

Changeset: 044f4ed5
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/044f4ed55dfce7f1aed9e10accf459b4af9b975e
Stats:     89 lines in 2 files changed: 88 ins; 0 del; 1 mod

8326979: (jdeps) improve the error message for FindException caused by InvalidModuleDescriptorException

Reviewed-by: jpai, alanb

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

PR: https://git.openjdk.org/jdk/pull/18308

From duke at openjdk.org  Tue Apr  2 19:19:59 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 2 Apr 2024 19:19:59 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

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

  remove use of jdk.crypto.ec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/dbe6cd3b..82b6dae7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

PR: https://git.openjdk.org/jdk/pull/18583

From duke at openjdk.org  Tue Apr  2 19:20:00 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 2 Apr 2024 19:20:00 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <I-I4lM6idN5RDH-PmDJKAjbK2RuRYP-q60cMBLAxfi0=.e6648bbd-5cfa-4e0b-9812-50c2de4edb8b@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <I-I4lM6idN5RDH-PmDJKAjbK2RuRYP-q60cMBLAxfi0=.e6648bbd-5cfa-4e0b-9812-50c2de4edb8b@github.com>
Message-ID: <KL8koHs_O8HuRDXGgdQZMehRwqkJxiqTVB5vgqH7c6Q=.238cae4c-f93b-4644-ba4a-0fd41eb5f0c1@github.com>

On Tue, 2 Apr 2024 16:29:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove use of jdk.crypto.ec
>
> src/java.base/share/classes/module-info.java line 265:
> 
>> 263:         jdk.jfr,
>> 264:         jdk.unsupported,
>> 265:         jdk.crypto.ec;
> 
> jdk.crypto.ec has been hollowed out since JDK 22, the sun.security.ec are in java.base. So I don't think you need this qualified export.

Thanks, fixed. (Started this when `jdk.crypto.ec` was still in use.. missed a few spots during rebase I guess)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1548460157

From darcy at openjdk.org  Tue Apr  2 23:48:28 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Apr 2024 23:48:28 GMT
Subject: RFR: JDK-8329557: Fix statement around MathContext.DECIMAL128 rounding
Message-ID: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>

Happened to notice a semantic typo in the description of MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, and added some additional information to make the related descriptions more informative.

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

Commit messages:
 - JDK-8329557: Fix statement around MathContext.DECIMAL128 rounding

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

PR: https://git.openjdk.org/jdk/pull/18587

From jpai at openjdk.org  Wed Apr  3 01:00:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Apr 2024 01:00:16 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v5]
In-Reply-To: <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>
Message-ID: <kgWfaiFMCrvzhuGiWqxLcTEAdH5Tr-n31QeprERgKnA=.df1f42ef-6069-46ff-9985-f0731bb1c5b3@github.com>

On Tue, 2 Apr 2024 16:29:21 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Thank you for the update, Bill. The latest changes look OK to me.
I also heard from Bill that Alan has approved the changes too.

Before integrating, please run tier1, tier2 and tier3 (I haven't checked which tiers these changed tests belong to) to make sure nothing breaks unexpectedly.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1975307573

From duke at openjdk.org  Wed Apr  3 01:37:37 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 3 Apr 2024 01:37:37 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v6]
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <OawnS0uxsJYWlbNcXWteJTVR0H5NCXoU4o4MJwSglIQ=.b91bd0d4-f84d-4b00-85e3-ab84f9d2ceef@github.com>

> Add notes for `HashMap::putAll()` conservative resizing.
> 
> Note: everything below this line is from the original change. After discussion, we decided to keep the conservative resizing, but we should add an `@implNote` for the decision.
> 
> ---
> 
> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
> 
> ---
> 
> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
> 
> Before change:
> 
> 
> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       87...

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

 - Update implNotes to explain conservative resizing decisions and suggest
   options to avoid expensive resizing
 - Merge branch 'master' into hashmap
 - Add note about conservative resizing
 - Merge branch 'master' into hashmap
 - extract msize variable
 - Use max of both sizes and other maps size in case of overflow
 - Add benchmark with all duplicate keys
 - 8324573: HashMap::putAll should resize to sum of both map sizes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17544/files
  - new: https://git.openjdk.org/jdk/pull/17544/files/0edb86f1..030f7d50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=04-05

  Stats: 485332 lines in 5236 files changed: 50925 ins; 101748 del; 332659 mod
  Patch: https://git.openjdk.org/jdk/pull/17544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17544/head:pull/17544

PR: https://git.openjdk.org/jdk/pull/17544

From duke at openjdk.org  Wed Apr  3 01:37:38 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 3 Apr 2024 01:37:38 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v4]
In-Reply-To: <5_NlZ_BIRHaToTQyjCxCBqW1Ua_EWaZt8p17trx5e_g=.afc2a52f-129d-4be5-99b2-8cfa0ea2868f@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
 <5_NlZ_BIRHaToTQyjCxCBqW1Ua_EWaZt8p17trx5e_g=.afc2a52f-129d-4be5-99b2-8cfa0ea2868f@github.com>
Message-ID: <cTjqSItdiSNXqzaz3rioWN37MeXQmrnRSbcr-ZWngmo=.0f079f2a-d613-4bbb-87b6-03a82f492e63@github.com>

On Fri, 9 Feb 2024 14:05:56 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extract msize variable
>
> I agree that a comment would be helpful but I'm afraid that it will not be of much help if its buried in the code. So instead maybe better add an `@implNote` to the `putAll()` method which describes the current, conservative resizing heuristic and give the advice that users can presize the destination map accordingly if they want to avoid resizing when merging in other maps.

@simonis Used your comment with some rewritten English

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-2033382004

From bpb at openjdk.org  Wed Apr  3 01:44:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Apr 2024 01:44:11 GMT
Subject: RFR: JDK-8329557: Fix statement around MathContext.DECIMAL128
 rounding
In-Reply-To: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
References: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
Message-ID: <vNetKRkBE_Ttv7LqjvmfXeuz-FHtft3PIaNSQin3114=.a6e5fb22-92cf-4535-80f0-4b3e3b9c14ba@github.com>

On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Happened to notice a semantic typo in the description of MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, and added some additional information to make the related descriptions more informative.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18587#pullrequestreview-1975341809

From iris at openjdk.org  Wed Apr  3 02:51:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 3 Apr 2024 02:51:08 GMT
Subject: RFR: JDK-8329557: Fix statement around MathContext.DECIMAL128
 rounding
In-Reply-To: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
References: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
Message-ID: <aqAA3pJiwK4akyjMnKQQR6X1ZwORSrIhEIzmZBJGz5Y=.ac09c2b2-cbf0-41ad-8e78-87653754c465@github.com>

On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Happened to notice a semantic typo in the description of MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, and added some additional information to make the related descriptions more informative.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18587#pullrequestreview-1975387023

From darcy at openjdk.org  Wed Apr  3 06:00:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 06:00:09 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <xedikVjcXFBPNR3yrDWrR70EQ50R00FE9YCF_fC3jxY=.984cb642-db6d-48c9-b976-3e55f9b5a23f@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <LNXC3butqNvq566NxesHBtfldFXC4irGFLvII-f3kPo=.644dd63f-0901-4bae-878a-c0d5b7cbe5b1@github.com>
 <xedikVjcXFBPNR3yrDWrR70EQ50R00FE9YCF_fC3jxY=.984cb642-db6d-48c9-b976-3e55f9b5a23f@github.com>
Message-ID: <6fCRor2HD_QqKJVqLkMG7ON3rnHkZ_B9dNLLuOSebcg=.0b0d66c6-1523-4858-857a-f9ebfb02516b@github.com>

On Tue, 2 Apr 2024 18:09:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > For the `javax.lang.model` changes, as a new ElementKind is being introduced, there should be a matching layer of new concrete visitors and selected updates to existing visitor implementations, etc.
> 
> I can help develop the visitor changes if you'd like.

PS On top the state of the code in webrev 04, I took a first pass over what I think the javax.lang.model support should look like:

https://github.com/openjdk/jdk/pull/18590

HTH

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

PR Comment: https://git.openjdk.org/jdk/pull/18509#issuecomment-2033598036

From darcy at openjdk.org  Wed Apr  3 06:02:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 06:02:04 GMT
Subject: RFR: JDK-8329556: javax.lang.model suppor for Derived Record Creation
 (Preview)
Message-ID: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>

Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

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

Commit messages:
 - Add more support for component local variables.
 - Add uses of new visitor types.
 - JDK-8329556: javax.lang.model suppor for Derived Record Creation (Preview)
 - Baseline on 04 version of the webrev.

Changes: https://git.openjdk.org/jdk/pull/18590/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18590&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329556
  Stats: 1640 lines in 49 files changed: 1550 ins; 20 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/18590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18590/head:pull/18590

PR: https://git.openjdk.org/jdk/pull/18590

From duke at openjdk.org  Wed Apr  3 07:07:15 2024
From: duke at openjdk.org (=?UTF-8?B?VG9tw6HFoQ==?= Zezula)
Date: Wed, 3 Apr 2024 07:07:15 GMT
Subject: RFR: JDK-8329564: [JVMCI] TranslatedException::debugPrintStackTrace
 does not work in the libjvmci compiler.
Message-ID: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>

Problem:
The debugging stack traces in the `jdk.internal.vm.TranslatedException` do not work in the libjvmci compiler becuase they are enabled using the system property `jdk.internal.vm.TranslatedException.debug`. However, the libjvmci compiler does not copy HotSpot VM system properties. Instead, the HotSpot system properties are copied only into properties returned by `Services::getSavedProperties()`.

Fix:
A debug boolean flag is passed to the `VMSupport::decodeAndThrowThrowable()` method.

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

Commit messages:
 - JDK-8329564: jdk.internal.vm.TranslatedException::debugPrintStackTrace does not work in the libjvmci compiler.

Changes: https://git.openjdk.org/jdk/pull/18591/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18591&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329564
  Stats: 25 lines in 4 files changed: 8 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18591.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18591/head:pull/18591

PR: https://git.openjdk.org/jdk/pull/18591

From jlahoda at openjdk.org  Wed Apr  3 07:16:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 3 Apr 2024 07:16:09 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <vudrAiU0bDuHOJxeXOhPTr6cGZzajM_xwkCqmmizFsU=.ad583459-b9c3-4162-a8e1-d1771dc446a9@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <vudrAiU0bDuHOJxeXOhPTr6cGZzajM_xwkCqmmizFsU=.ad583459-b9c3-4162-a8e1-d1771dc446a9@github.com>
Message-ID: <7-WZgG_hU3f6D54H_mjzaGKwyxs_R0a0zF_LVonbjOs=.6f2b3b1a-35bf-4151-80ae-d76c8b2925a4@github.com>

On Tue, 2 Apr 2024 12:50:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 1415:
> 
>> 1413:                                                      canonicalConstructorTypes,
>> 1414:                                                      List.nil());
>> 1415:         createNew.constructor = init;
> 
> Maybe?instead of?hardcoding the?constructor that?is?canonical at?compile?time (in?case new?components get?added), it?might be?better to?go?through some?sort of?`indy`?callsite?like (at?least when?not in?the?same compilation?unit):
> 
> DynamicCallSiteDesc[java.lang.runtime.RecordSupport::derivedConstructor(modified component names...):(T extends Record, Class<?>... /*?modified component types?*/)T]
> 
> 
> with?the `derivedConstructor` bootstrap?method:
> 
> public static MethodHandle derivedConstructor(MethodHandles.Lookup lookup, String unused, MethodType type, String... modifiedComponents) throws ReflectiveOperationException {
> 	requireNonNull(lookup);
> 	requireNonNull(type);
> 	// implicit null-check:
> 	List<String> modifiedComponentNames = List.of(modifiedComponents);
> 
> 	Class<?> rtype = type.returnType();
> 	if (
> 		!rtype.isRecord()
> 		|| type.parameterCount() != modifiedComponents.length + 1
> 		|| type.parameterType(0) != rtype
> 	) {
> 		throw new IllegalArgumentException("...");
> 	}
> 
> 	Set<String> remainingComponentNames = new HashSet(modifiedComponentNames);
> 	if (remainingComponentNames.size() != modifiedComponentNames.size()) {
> 		throw new IllegalArgumentException("Duplicate component names in modifiedComponents");
> 	}
> 
> 	RecordComponent[] recordComponents = rtype.getRecordComponents();
> 
> 	var componentTypes = new Class<?>[recordComponents.length];
> 	var filters = new MethodHandle[recordComponents.length];
> 	var reorder = new int[recordComponents.length];
> 
> 	for (int i = 0, j = 1; i < recordComponents.length; i++) {
> 		var component = recordComponents[i];
> 		componentTypes[i] = component.getType();
> 
> 		var getter = lookup.findVirtual(rtype, component.getName(), MethodType.methodType(component.getType()));
> 		if (modifiedComponentNames.contains(component.getName())) {
> 			remainingComponentNames.remove(component.getName());
> 			filters[i] = null;
> 			reorder[i] = j++;
> 		} else {
> 			filters[i] = getter;
> 			reorder[i] = 0;
> 		}
> 	}
> 
> 	if (!remainingComponentNames.isEmpty()) {
> 		throw new IllegalArgumentException("Components " + remainingComponentNames + " are not present in the record " + rtype);
> 	}
> 
> 	var canonicalConstructor = lookup.findConstructor(rtype, MethodType.methodType(rtype, componentTypes);
> ...

While this is very smart, I would prefer not to do that. JLS 13.4.27 talks about binary compatibility for record, and warns that adding or removing components may break record usages. So I don't think we need to provide too much support for adding or removing record components.

Overall, I believe the current code adheres to what the JLS draft says. If the author of the record wants to add or remove components, they can make it so that the existing compiled code still works (by adding constructor overloads and keeping the accessors for removed component). It is better, IMO, to keep the behavior predictable, and leave adjustments after record component modifications up to the record author, than to introduce some magic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1549052694

From sroy at openjdk.org  Wed Apr  3 07:38:10 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 3 Apr 2024 07:38:10 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <aoNPqBbY1b4GtdkNLRDqG4WRjfuEg9BS_4f5Rh1l7Ug=.ef68803c-14de-40f5-9296-c9613db29842@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
 <AIBNzoCFTcp5VlHJfjL9qmpeR-VdNdF-tFwSZqJ-ozg=.7bc2aa08-3622-4de2-8c01-cd1a8782c0e8@github.com>
 <aoNPqBbY1b4GtdkNLRDqG4WRjfuEg9BS_4f5Rh1l7Ug=.ef68803c-14de-40f5-9296-c9613db29842@github.com>
Message-ID: <epFdOXeyudAthLSGQdzYTk-nl1laagxbQ3mJZAIi9xA=.197bb0f4-6a2e-4cd3-92b2-940db7c9cbdb@github.com>

On Tue, 2 Apr 2024 08:36:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> test/jdk/java/lang/RuntimeTests/loadLibrary

I see. Thank you. Got to check some test cases files and how they are structured. 
For this case, i feel the use case would be to have a pure .a file. Usually there is not such pure .a files that comes packaged with the OS. They are provided by some applications. So i am not sure how i can make the tests consistent for such cases. 
Do you have any suggestions here ?  We are anyways passing it down to the hotspot code , which is taking care of it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2033773591

From asotona at openjdk.org  Wed Apr  3 08:20:34 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Apr 2024 08:20:34 GMT
Subject: RFR: 8329527: Opcode.IFNONNULL.primaryTypeKind() is not ReferenceType
Message-ID: <GCAjVjLuCMwjMYVac3LXuPRayFffbsoUraQkqbwlW44=.89d26e9c-b406-4aee-b801-bf1b9c81e114@github.com>

`Opcode.IFNONNULL.primaryTypeKind()` wrongly returned `IntType` instead of the right `ReferenceType`.
Primary type kinds of `BRANCH` opcodes have yet no functional effect in the Class-File API.
This simple patch fixes the typo.

Please review.

Thank you,
Adam

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

Commit messages:
 - 8329527: Opcode.IFNONNULL.primaryTypeKind() is not ReferenceType

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

PR: https://git.openjdk.org/jdk/pull/18593

From asotona at openjdk.org  Wed Apr  3 08:53:14 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Apr 2024 08:53:14 GMT
Subject: RFR: 8325371: Missing ClassFile.Option in package summary
Message-ID: <oH5hWpwJW9-6CtItagQJvZERRGqJn4D4l7raxEpPe90=.be44eb4f-1e8a-412e-b4df-8991368c7e44@github.com>

Some of the Class-File API options were not mentioned in the package summary and one exception mentioned `ClassFile.DeadLabelsOption` javadoc was wrong.
This patch fixes the javadoc.

Please review.

Thank you,
Adam

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

Commit messages:
 - 8325371: Missing ClassFile.Option in package summary

Changes: https://git.openjdk.org/jdk/pull/18594/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18594&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325371
  Stats: 23 lines in 2 files changed: 12 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18594.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18594/head:pull/18594

PR: https://git.openjdk.org/jdk/pull/18594

From duke at openjdk.org  Wed Apr  3 09:37:08 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 3 Apr 2024 09:37:08 GMT
Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory
 methods  accepting Opcode
In-Reply-To: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
References: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
Message-ID: <W-89il5N-x4o2XZCzFA80QUsCyWZN_DQn5zQn86184E=.08e5affa-41d3-4069-a592-538ab2d66165@github.com>

On Tue, 2 Apr 2024 09:37:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented:
> 
> - `ArrayLoadInstruction`
> - `ArrayStoreInstruction`
> - `BranchInstruction`
> - `ConvertInstruction`
> - `DiscontinuedInstruction`
> - `FieldInstruction`
> - `InvokeInstruction`
> - `LoadInstruction`
> - `MonitorInstruction`
> - `NewPrimitiveArrayInstruction`
> - `OperatorInstruction`
> - `ReturnInstruction`
> - `StackInstruction`
> - `StoreInstruction`
> - `TypeCheckInstruction`
> 
> `NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument.
> 
> This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check.
> 
> Please review.
> 
> Thank you,
> Adam

src/java.base/share/classes/java/lang/classfile/instruction/NewPrimitiveArrayInstruction.java line 31:

> 29: import java.lang.classfile.Instruction;
> 30: import java.lang.classfile.TypeKind;
> 31: import static java.util.Objects.requireNonNull;

Suggestion:

src/java.base/share/classes/java/lang/classfile/instruction/NewPrimitiveArrayInstruction.java line 59:

> 57:      */
> 58:     static NewPrimitiveArrayInstruction of(TypeKind typeKind) {
> 59:         if (requireNonNull(typeKind).newarraycode() < 0) {

Suggestion:

        // Implicit null-check:
        if (typeKind.newarraycode() < 0) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18578#discussion_r1549343564
PR Review Comment: https://git.openjdk.org/jdk/pull/18578#discussion_r1549341918

From daniel.fuchs at oracle.com  Wed Apr  3 09:38:12 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 3 Apr 2024 10:38:12 +0100
Subject: Result: New Core Libraries Group Member: Per-Ake Minborg
Message-ID: <dd7f6e71-ea70-43f8-abc3-ff067e175dbd@oracle.com>

Hi,

The vote for Per-Ake Minborg (pminborg) [1] is now closed.

Yes:     11
Veto:     0
Abstain:  0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

best regards,

-- daniel

[1] https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/120617.html


From ihse at openjdk.org  Wed Apr  3 09:49:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Apr 2024 09:49:01 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
Message-ID: <Yu1B1Mj6OZLQK65dk1gggNxa_0WP-OSrAvmO705011U=.d5ee8e6a-ed73-4456-9fd8-67034b419adf@github.com>

On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove use of jdk.crypto.ec

Build changes are trivially fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18583#pullrequestreview-1976208258

From ihse at openjdk.org  Wed Apr  3 10:04:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Apr 2024 10:04:01 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

The build changes look okay. 

Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1976255818

From asotona at openjdk.org  Wed Apr  3 10:06:31 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Apr 2024 10:06:31 GMT
Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory
 methods  accepting Opcode [v2]
In-Reply-To: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
References: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
Message-ID: <fopFWL3jDdRU9cKL4l5-zQLNfKNrRAhs6_bWtKnjJtw=.49a8afa4-4b02-4f77-8a8c-8fbabad5b062@github.com>

> `IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented:
> 
> - `ArrayLoadInstruction`
> - `ArrayStoreInstruction`
> - `BranchInstruction`
> - `ConvertInstruction`
> - `DiscontinuedInstruction`
> - `FieldInstruction`
> - `InvokeInstruction`
> - `LoadInstruction`
> - `MonitorInstruction`
> - `NewPrimitiveArrayInstruction`
> - `OperatorInstruction`
> - `ReturnInstruction`
> - `StackInstruction`
> - `StoreInstruction`
> - `TypeCheckInstruction`
> 
> `NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument.
> 
> This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check.
> 
> Please review.
> 
> Thank you,
> Adam

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

  Apply suggestions from code review
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18578/files
  - new: https://git.openjdk.org/jdk/pull/18578/files/185dda1a..68949904

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18578&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18578&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/18578

From duke at openjdk.org  Wed Apr  3 11:44:59 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 3 Apr 2024 11:44:59 GMT
Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory
 methods  accepting Opcode [v2]
In-Reply-To: <fopFWL3jDdRU9cKL4l5-zQLNfKNrRAhs6_bWtKnjJtw=.49a8afa4-4b02-4f77-8a8c-8fbabad5b062@github.com>
References: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
 <fopFWL3jDdRU9cKL4l5-zQLNfKNrRAhs6_bWtKnjJtw=.49a8afa4-4b02-4f77-8a8c-8fbabad5b062@github.com>
Message-ID: <KperT_eR8DR69wo8I6aohxNXOqTKn693gOVNDJkjA1o=.8b6cfae8-123b-44d9-89d4-8ee9d3bc039d@github.com>

On Wed, 3 Apr 2024 10:06:31 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> `IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented:
>> 
>> - `ArrayLoadInstruction`
>> - `ArrayStoreInstruction`
>> - `BranchInstruction`
>> - `ConvertInstruction`
>> - `DiscontinuedInstruction`
>> - `FieldInstruction`
>> - `InvokeInstruction`
>> - `LoadInstruction`
>> - `MonitorInstruction`
>> - `NewPrimitiveArrayInstruction`
>> - `OperatorInstruction`
>> - `ReturnInstruction`
>> - `StackInstruction`
>> - `StoreInstruction`
>> - `TypeCheckInstruction`
>> 
>> `NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument.
>> 
>> This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

The?following factory?methods are?also?missing `@throws?IllegalArgumentException`:
- `ConstantInstruction::ofIntrinsic`
- `ConstantInstruction::ofArgument`
- `ConstantInstruction::ofLoad`

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

PR Comment: https://git.openjdk.org/jdk/pull/18578#issuecomment-2034350493

From mchhipa at openjdk.org  Wed Apr  3 11:53:18 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 3 Apr 2024 11:53:18 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM flags
Message-ID: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>

Updated following tests to use ProcessTools methods:
 test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
 test/jdk/java/lang/annotation/LoaderLeakTest.java
 test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
 test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
 test/jdk/javax/naming/spi/providers/InitialContextTest.java

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

Commit messages:
 - JDK-8319678: Several tests from corelibs areas ignore VM flags

Changes: https://git.openjdk.org/jdk/pull/18602/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18602&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319678
  Stats: 138 lines in 5 files changed: 45 ins; 55 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/18602.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18602/head:pull/18602

PR: https://git.openjdk.org/jdk/pull/18602

From asotona at openjdk.org  Wed Apr  3 11:54:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Apr 2024 11:54:01 GMT
Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory
 methods  accepting Opcode [v2]
In-Reply-To: <KperT_eR8DR69wo8I6aohxNXOqTKn693gOVNDJkjA1o=.8b6cfae8-123b-44d9-89d4-8ee9d3bc039d@github.com>
References: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
 <fopFWL3jDdRU9cKL4l5-zQLNfKNrRAhs6_bWtKnjJtw=.49a8afa4-4b02-4f77-8a8c-8fbabad5b062@github.com>
 <KperT_eR8DR69wo8I6aohxNXOqTKn693gOVNDJkjA1o=.8b6cfae8-123b-44d9-89d4-8ee9d3bc039d@github.com>
Message-ID: <eCm3VVRo2XexaiS1KuGL09IVe5vFuU2LVAYtsEhPyp0=.a4981e17-a773-4d7c-8b94-d0e80ff71b74@github.com>

On Wed, 3 Apr 2024 11:42:04 GMT, ExE Boss <duke at openjdk.org> wrote:

> The?following factory?methods are?also?missing `@throws?IllegalArgumentException`:
> 
> * `ConstantInstruction::ofIntrinsic`
> * `ConstantInstruction::ofArgument`
> * `ConstantInstruction::ofLoad`

Great catch, I'll add them, thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/18578#issuecomment-2034372250

From asotona at openjdk.org  Wed Apr  3 12:08:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 Apr 2024 12:08:20 GMT
Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory
 methods  accepting Opcode [v3]
In-Reply-To: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
References: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
Message-ID: <Bh8PENH2AOnzsSIELxPL0L-qbSNZYLd0HZEaaO3pAbg=.963e14f2-6605-44db-ae5d-ec00e5bc84da@github.com>

> `IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented:
> 
> - `ArrayLoadInstruction`
> - `ArrayStoreInstruction`
> - `BranchInstruction`
> - `ConvertInstruction`
> - `DiscontinuedInstruction`
> - `FieldInstruction`
> - `InvokeInstruction`
> - `LoadInstruction`
> - `MonitorInstruction`
> - `NewPrimitiveArrayInstruction`
> - `OperatorInstruction`
> - `ReturnInstruction`
> - `StackInstruction`
> - `StoreInstruction`
> - `TypeCheckInstruction`
> 
> `NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument.
> 
> This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check.
> 
> Please review.
> 
> Thank you,
> Adam

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

  added missing @throws to ConstantInstruction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18578/files
  - new: https://git.openjdk.org/jdk/pull/18578/files/68949904..71165f1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18578&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18578&range=01-02

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18578/head:pull/18578

PR: https://git.openjdk.org/jdk/pull/18578

From sroy at openjdk.org  Wed Apr  3 12:32:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 3 Apr 2024 12:32:21 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v9]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  coding style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/1ad4b33d..c6ec69a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=07-08

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From duke at openjdk.org  Wed Apr  3 13:58:23 2024
From: duke at openjdk.org (=?UTF-8?B?VG9tw6HFoQ==?= Zezula)
Date: Wed, 3 Apr 2024 13:58:23 GMT
Subject: RFR: JDK-8329564: [JVMCI]
 TranslatedException::debugPrintStackTrace does not work in the libjvmci
 compiler. [v2]
In-Reply-To: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>
References: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>
Message-ID: <ee8bSNTaqMy8UkM8ddzIDCkj3UygLQh0yPrBHSg0WEc=.506074b6-d333-48bc-ad9b-0ba6e69853be@github.com>

> Problem:
> The debugging stack traces in `jdk.internal.vm.TranslatedException` do not work in libjvmci because they are enabled via the `jdk.internal.vm.TranslatedException.debug` system property. However, HotSpot system properties are not accessible via `System.getProperty()` in libjvmci.
> 
> Fix:
> The value of `jdk.internal.vm.TranslatedException.debug` is passed from the VM via a boolean flag to `VMSupport::decodeAndThrowThrowable()`.

Tom?? Zezula has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8329564: Fixed TestTranslatedException tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18591/files
  - new: https://git.openjdk.org/jdk/pull/18591/files/5e43f5f7..3a34ce27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18591&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18591&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18591.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18591/head:pull/18591

PR: https://git.openjdk.org/jdk/pull/18591

From rgiulietti at openjdk.org  Wed Apr  3 14:58:00 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 3 Apr 2024 14:58:00 GMT
Subject: RFR: JDK-8329557: Fix statement around MathContext.DECIMAL128
 rounding
In-Reply-To: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
References: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
Message-ID: <VA8rIE30yeNJwF2FiaRA_J_QyT4Mxhj6qmJnmn6Zm20=.1a06f927-ad81-4d4e-9970-0d002d5a82e4@github.com>

On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Happened to notice a semantic typo in the description of MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, and added some additional information to make the related descriptions more informative.

src/java.base/share/classes/java/math/MathContext.java line 106:

> 104:      * rounding mode of {@link RoundingMode#HALF_EVEN HALF_EVEN}.
> 105:      * Note the exponent range of decimal128 (min exponent of -6143,
> 106:      * max exponent of 6144) is <em>not</em> used for rounding.

The exponent ranges are all correct, but... why mention them in the first place if they are not used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18587#discussion_r1549913966

From rgiulietti at openjdk.org  Wed Apr  3 15:01:10 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 3 Apr 2024 15:01:10 GMT
Subject: RFR: JDK-8329557: Fix statement around MathContext.DECIMAL128
 rounding
In-Reply-To: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
References: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
Message-ID: <aQRMw-EMVe0qZiYI7F7cgVVsBBhG5bqB71LuxOPCmLI=.530ea791-6bbe-4ab3-996d-4da31c636b80@github.com>

On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Happened to notice a semantic typo in the description of MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, and added some additional information to make the related descriptions more informative.

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18587#pullrequestreview-1977103640

From jpai at openjdk.org  Wed Apr  3 15:05:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Apr 2024 15:05:11 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <epFdOXeyudAthLSGQdzYTk-nl1laagxbQ3mJZAIi9xA=.197bb0f4-6a2e-4cd3-92b2-940db7c9cbdb@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
 <AIBNzoCFTcp5VlHJfjL9qmpeR-VdNdF-tFwSZqJ-ozg=.7bc2aa08-3622-4de2-8c01-cd1a8782c0e8@github.com>
 <aoNPqBbY1b4GtdkNLRDqG4WRjfuEg9BS_4f5Rh1l7Ug=.ef68803c-14de-40f5-9296-c9613db29842@github.com>
 <epFdOXeyudAthLSGQdzYTk-nl1laagxbQ3mJZAIi9xA=.197bb0f4-6a2e-4cd3-92b2-940db7c9cbdb@github.com>
Message-ID: <W8Be7L4ZbOedmNTrJoB8PuWPy8YYkOQSuEGxnAh-AR8=.7f055416-3b43-4620-9bc2-9398577fc72f@github.com>

On Wed, 3 Apr 2024 07:35:46 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Hello @suchismith1993,
>> 
>>> > I adjust the comments which also answer your question. Please add an AIX-only test to verify this behavior.
>>> 
>>> By test you mean provide the use case for pure .a files ?
>> 
>> In the JDK repo, changes like these are backed by jtreg tests https://openjdk.org/guide/#jtreg. So for this change, you would need to add a jtreg test which only runs on AIX (the jtreg documentation explains how to do that) and will exercise the `System.loadLibrary` call for a AIX specific library and verify that the library can be loaded as per the expectations that are set in the changes proposed and finalized in this PR.
>> 
>> For example, the test should verify that, after the changes proposed in this PR, calling `System.loadLibrary(<libname>)` on AIX will load from `<libname>.a` if `<libname>.so` is absent.
>> 
>> For reference, you can take a look at the existing tests for loadLibrary in the `test/jdk/java/lang/RuntimeTests/loadLibrary` directory.
>
>> test/jdk/java/lang/RuntimeTests/loadLibrary
> 
> I see. Thank you. Got to check some test cases files and how they are structured. 
> For this case, i feel the use case would be to have a pure .a file. Usually there is not such pure .a files that comes packaged with the OS. They are provided by some applications. So i am not sure how i can make the tests consistent for such cases. 
> Do you have any suggestions here ?  We are anyways passing it down to the hotspot code , which is taking care of it.

Hello @suchismith1993,

> Usually there is not such pure .a files that comes packaged with the OS. They are provided by some applications. So i am not sure how i can make the tests consistent for such cases.
> Do you have any suggestions here ? 

Within the JDK repo, some tests require test specific native libraries (like in your case here). It appears that the JDK build infrastructure has ability to compile native code (`foo.c` for example) into a native library. However that build infrastructure doesn't appear to be flexible enough to support the case where you would have to run AIX specific commands to generate a `.a` file. So the approach of generating a test specific `.a` file doesn't look promising right now (it could still be possible, but I don't know how big a build change that would require).

So taking a step back - I see that https://bugs.openjdk.org/browse/JDK-8313616 introduced the ability to dealing with `.a` files on AIX from within the hotspot area. In that commit https://github.com/openjdk/jdk/pull/15204/files I see that there are references to a couple of `.a` files - for example `libodm.a` and `libperfstat.a`. Are those `.a` expected to be present on certain AIX systems? Perhaps your new test could use either of those in the test? There was also a mention of `libclang.a` on AIX, previously in this discussion. Maybe that could be used in the test?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2034865328

From rriggs at openjdk.org  Wed Apr  3 15:12:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 Apr 2024 15:12:09 GMT
Subject: RFR: JDK-8329089: Empty immutable list throws the wrong exception
 type for remove(first | last) operations
In-Reply-To: <VqsB3uxDN8_H2wgkRz56gdTz5Ot1i5zOD3KlgjtR8FA=.74bfc834-647c-4cf7-bd60-5b846f780f06@github.com>
References: <VqsB3uxDN8_H2wgkRz56gdTz5Ot1i5zOD3KlgjtR8FA=.74bfc834-647c-4cf7-bd60-5b846f780f06@github.com>
Message-ID: <869n3vXcteD6NYfgKIGQMlOYbMhP7AlgUKZvEdEBjHY=.8d23995e-613f-455e-ac85-47e10d4a63c5@github.com>

On Tue, 2 Apr 2024 10:37:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to make empty immutable lists always throw UOE on `removeFirst` and `removeLast`.

test/jdk/java/util/Collection/MOAT.java line 573:

> 571:                 c::removeLast);
> 572:     }
> 573: 

Would this test better if inserted in `testImmutableCollection(final Collection<T> c, T t)`, Line 477'ish.
Or in `testImmutableList(final List<Integer> c)`, line 519.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18581#discussion_r1549940454

From sgibbons at openjdk.org  Wed Apr  3 15:15:24 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 3 Apr 2024 15:15:24 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v4]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <zaaY3TupJSFFwIkLPI9GHQvPnT1-rev4AuP2_rqO3aM=.8ba12ab3-b288-4558-b1b9-ade436f8e896@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Fix Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/3aa60a48..8bed1561

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=02-03

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From darcy at openjdk.org  Wed Apr  3 15:34:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 15:34:09 GMT
Subject: RFR: JDK-8329557: Fix statement around MathContext.DECIMAL128
 rounding
In-Reply-To: <VA8rIE30yeNJwF2FiaRA_J_QyT4Mxhj6qmJnmn6Zm20=.1a06f927-ad81-4d4e-9970-0d002d5a82e4@github.com>
References: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
 <VA8rIE30yeNJwF2FiaRA_J_QyT4Mxhj6qmJnmn6Zm20=.1a06f927-ad81-4d4e-9970-0d002d5a82e4@github.com>
Message-ID: <zExVrl5zD3qc5bp4mlr4uV2GMnNdqEIKCzXn2Hn_QQ8=.43b2abb5-9a66-477b-abc4-d5e55b923ec1@github.com>

On Wed, 3 Apr 2024 14:55:07 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Happened to notice a semantic typo in the description of MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, and added some additional information to make the related descriptions more informative.
>
> src/java.base/share/classes/java/math/MathContext.java line 106:
> 
>> 104:      * rounding mode of {@link RoundingMode#HALF_EVEN HALF_EVEN}.
>> 105:      * Note the exponent range of decimal128 (min exponent of -6143,
>> 106:      * max exponent of 6144) is <em>not</em> used for rounding.
> 
> The exponent ranges are all correct, but... why mention them in the first place if they are not used?

My thinking was to mention the ranges to show how different than are from the approx. +/- MAX_INT range of BigDecimal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18587#discussion_r1549980224

From dnsimon at openjdk.org  Wed Apr  3 15:39:59 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 3 Apr 2024 15:39:59 GMT
Subject: RFR: JDK-8329564: [JVMCI]
 TranslatedException::debugPrintStackTrace does not work in the libjvmci
 compiler. [v2]
In-Reply-To: <ee8bSNTaqMy8UkM8ddzIDCkj3UygLQh0yPrBHSg0WEc=.506074b6-d333-48bc-ad9b-0ba6e69853be@github.com>
References: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>
 <ee8bSNTaqMy8UkM8ddzIDCkj3UygLQh0yPrBHSg0WEc=.506074b6-d333-48bc-ad9b-0ba6e69853be@github.com>
Message-ID: <JZr5etGTCGY9pBLb2nDfuEKBTFPdl1THG2P2rr8t5Ms=.780a47ee-4e79-46c8-b2a4-e499f7671439@github.com>

On Wed, 3 Apr 2024 13:58:23 GMT, Tom?? Zezula <duke at openjdk.org> wrote:

>> Problem:
>> The debugging stack traces in `jdk.internal.vm.TranslatedException` do not work in libjvmci because they are enabled via the `jdk.internal.vm.TranslatedException.debug` system property. However, HotSpot system properties are not accessible via `System.getProperty()` in libjvmci.
>> 
>> Fix:
>> The value of `jdk.internal.vm.TranslatedException.debug` is passed from the VM via a boolean flag to `VMSupport::decodeAndThrowThrowable()`.
>
> Tom?? Zezula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8329564: Fixed TestTranslatedException tests.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18591#pullrequestreview-1977216173

From mchung at openjdk.org  Wed Apr  3 16:14:11 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 3 Apr 2024 16:14:11 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v9]
In-Reply-To: <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>
Message-ID: <qWjb044vLNUWkXE6mpv8wYKpX-sKluyD41uX58aE-04=.2d53c32a-bc5f-4a7c-b333-5859a4769385@github.com>

On Wed, 3 Apr 2024 12:32:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coding style

libsysteminfo.a is another option.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2035024141

From duke at openjdk.org  Wed Apr  3 16:29:16 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 3 Apr 2024 16:29:16 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v3]
In-Reply-To: <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@github.com>
Message-ID: <XqLJ4xChgeGDY5zK_NrenDYn0Bmx2PUcfeZ_xoKAzpg=.02b77bdc-70b6-4ece-81c8-6e33cdda3c97@github.com>

On Mon, 29 May 2023 07:25:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
>> 
>> switch (obj) {
>>     case String s when s.isEmpty() -> {}
>>     case String s -> {}
>>     case CharSequence cs -> {}
>>     ...
>> }
>> 
>> 
>> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
>> 
>> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
>> 
>> obj == null ? -1
>>                   : switch (restartIndex) {
>>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>>                         ...
>>                         default -> <labels-count>;
>>                     }
>> 
>> 
>> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
>> 
>> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
>> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
>> 
>> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
>> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
>> 
>> 
>> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291966
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 340:

> 338:                                                                             createRepeatIndexSwitch(lookup, labels),
> 339:                                                                             MethodHandles.insertArguments(MAPPED_ENUM_LOOKUP, 1, lookup, enumClass, labels, new EnumMap())));
> 340:             target = MethodHandles.permuteArguments(body, MethodType.methodType(int.class, Object.class, int.class), 1, 0);

This?`guardWithTest` does?the?opposite to?what?s?described in?the?above?comment.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 389:

> 387:             }
> 388:         }
> 389:         return enumMap.map[value.ordinal()];

`enumMap.map` never?gets?set before?this?line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1550058760
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1550057327

From darcy at openjdk.org  Wed Apr  3 16:32:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 16:32:08 GMT
Subject: Integrated: JDK-8329557: Fix statement around MathContext.DECIMAL128
 rounding
In-Reply-To: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
References: <oHY_G2wlVWQiwA7ZDMxHAWy5pG5KP-eESctfbvYLLPI=.4660c98b-5ade-4c11-b90b-b00c8880ae8d@github.com>
Message-ID: <Kqi1X_H4lHsopBDaX-E9SN3Xy3UhOWfA8F4A1P_0Ma8=.deab6369-4da8-4bfa-9650-e980dc0138d0@github.com>

On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Happened to notice a semantic typo in the description of MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, and added some additional information to make the related descriptions more informative.

This pull request has now been integrated.

Changeset: 233619b3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/233619b3fb2916ca6216f9d16f70fedf35837a43
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8329557: Fix statement around MathContext.DECIMAL128 rounding

Reviewed-by: bpb, iris, rgiulietti

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

PR: https://git.openjdk.org/jdk/pull/18587

From bhuang at openjdk.org  Wed Apr  3 17:07:12 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 3 Apr 2024 17:07:12 GMT
Subject: Integrated: JDK-8327474 Review use of java.io.tmpdir in jdk tests
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <4fPL8biQ1uu8AMKMNmt3x0yLRKa01iDp6OL5MXQgasM=.bc20a303-65dc-48b2-80eb-b9ef6cd15b00@github.com>

On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

This pull request has now been integrated.

Changeset: 375bfac8
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/375bfac8e7ff3f871e2d986876f91a5fba200c83
Stats:     193 lines in 11 files changed: 66 ins; 13 del; 114 mod

8327474: Review use of java.io.tmpdir in jdk tests

Reviewed-by: michaelm, jpai

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

PR: https://git.openjdk.org/jdk/pull/18352

From bpb at openjdk.org  Wed Apr  3 19:06:26 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Apr 2024 19:06:26 GMT
Subject: RFR: 8328183: Minor mistakes in docs of PrintStream.append()
Message-ID: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>

Clarify the behavior of `append` for a `null` `CharSequence` parameter and clean up a couple of other typos.

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

Commit messages:
 - 8328183: Minor mistakes in docs of PrintStream.append()

Changes: https://git.openjdk.org/jdk/pull/18607/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328183
  Stats: 17 lines in 5 files changed: 5 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/18607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18607/head:pull/18607

PR: https://git.openjdk.org/jdk/pull/18607

From bpb at openjdk.org  Wed Apr  3 19:06:26 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Apr 2024 19:06:26 GMT
Subject: RFR: 8328183: Minor mistakes in docs of PrintStream.append()
In-Reply-To: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>
References: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>
Message-ID: <05ewW6qRx50EAQ8erWEKNxwrn2Plheu3uBUPoUfOxy4=.0431a8b1-c65a-4e81-abbb-e41a75dcfe3b@github.com>

On Wed, 3 Apr 2024 19:01:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `append` for a `null` `CharSequence` parameter and clean up a couple of other typos.

Item 4 in [this comment](https://bugs.openjdk.org/browse/JDK-8328183?focusedId=14657943&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14657943) is not addressed as this would be a change to very longstanding behavior and might cause unexpected results.

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

PR Comment: https://git.openjdk.org/jdk/pull/18607#issuecomment-2035372741

From iris at openjdk.org  Wed Apr  3 19:36:09 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 3 Apr 2024 19:36:09 GMT
Subject: RFR: 8328183: Minor mistakes in docs of PrintStream.append()
In-Reply-To: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>
References: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>
Message-ID: <hz0rngwRJHoCy6eh5upHVQeVZj16EJD8gPAhqx5u18Q=.a714767d-4a23-400f-9412-588bc4a246c4@github.com>

On Wed, 3 Apr 2024 19:01:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `append` for a `null` `CharSequence` parameter and clean up a couple of other typos.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18607#pullrequestreview-1977785394

From duke at openjdk.org  Wed Apr  3 19:57:21 2024
From: duke at openjdk.org (=?UTF-8?B?VG9tw6HFoQ==?= Zezula)
Date: Wed, 3 Apr 2024 19:57:21 GMT
Subject: RFR: JDK-8329564: [JVMCI]
 TranslatedException::debugPrintStackTrace does not work in the libjvmci
 compiler. [v3]
In-Reply-To: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>
References: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>
Message-ID: <UshnCqh4njpyuh7KxwQxOgXVGm6ZzRu_eGRvTr-h48U=.99e97824-bd60-4507-b87c-934c245709b0@github.com>

> Problem:
> The debugging stack traces in `jdk.internal.vm.TranslatedException` do not work in libjvmci because they are enabled via the `jdk.internal.vm.TranslatedException.debug` system property. However, HotSpot system properties are not accessible via `System.getProperty()` in libjvmci.
> 
> Fix:
> The value of `jdk.internal.vm.TranslatedException.debug` is passed from the VM via a boolean flag to `VMSupport::decodeAndThrowThrowable()`.

Tom?? Zezula has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8329564: Fixed vmSymbols.hpp formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18591/files
  - new: https://git.openjdk.org/jdk/pull/18591/files/3a34ce27..de30637b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18591&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18591&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/18591

From naoto at openjdk.org  Wed Apr  3 19:59:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Apr 2024 19:59:01 GMT
Subject: RFR: 8328183: Minor mistakes in docs of PrintStream.append()
In-Reply-To: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>
References: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>
Message-ID: <oiDr_K2UGD1hF4jJZ6rIb-chqMHad4tRBf-EvrUAQa4=.e7390d87-b26d-48fb-8857-6ed557279318@github.com>

On Wed, 3 Apr 2024 19:01:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `append` for a `null` `CharSequence` parameter and clean up a couple of other typos.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18607#pullrequestreview-1977836146

From dnsimon at openjdk.org  Wed Apr  3 20:07:59 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 3 Apr 2024 20:07:59 GMT
Subject: RFR: JDK-8329564: [JVMCI]
 TranslatedException::debugPrintStackTrace does not work in the libjvmci
 compiler. [v3]
In-Reply-To: <UshnCqh4njpyuh7KxwQxOgXVGm6ZzRu_eGRvTr-h48U=.99e97824-bd60-4507-b87c-934c245709b0@github.com>
References: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>
 <UshnCqh4njpyuh7KxwQxOgXVGm6ZzRu_eGRvTr-h48U=.99e97824-bd60-4507-b87c-934c245709b0@github.com>
Message-ID: <1H-n6VsDZdR3-2Yhs4jnZPys7_pf-5NfqprTtAWfpGk=.7cc71477-2d6c-4369-969d-a517ca4481c1@github.com>

On Wed, 3 Apr 2024 19:57:21 GMT, Tom?? Zezula <duke at openjdk.org> wrote:

>> Problem:
>> The debugging stack traces in `jdk.internal.vm.TranslatedException` do not work in libjvmci because they are enabled via the `jdk.internal.vm.TranslatedException.debug` system property. However, HotSpot system properties are not accessible via `System.getProperty()` in libjvmci.
>> 
>> Fix:
>> The value of `jdk.internal.vm.TranslatedException.debug` is passed from the VM via a boolean flag to `VMSupport::decodeAndThrowThrowable()`.
>
> Tom?? Zezula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8329564: Fixed vmSymbols.hpp formatting.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18591#pullrequestreview-1977858058

From naoto at openjdk.org  Wed Apr  3 20:12:11 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Apr 2024 20:12:11 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags
In-Reply-To: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
Message-ID: <r1DEQ_j7jXBsCnrkNhKiX1jWMNobGLPkE_srpEODhOM=.e1dc7d43-28f3-4ff6-995e-ba3f3e2b30a4@github.com>

On Wed, 3 Apr 2024 11:47:45 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Updated following tests to use ProcessTools methods:
>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>  test/jdk/javax/naming/spi/providers/InitialContextTest.java

Changes in `HijrahConfigTest.java` look good

test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java line 71:

> 69:         // Run tests
> 70:         Path launcher = outputPath.resolve("bin").resolve("java");
> 71:         OutputAnalyzer analyzer =  ProcessTools.executeCommand(launcher.toAbsolutePath().toString(),"-ea", "-esa", "HijrahConfigCheck");

Nit: need a space before `"-ea"`

test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java line 72:

> 70:         Path launcher = outputPath.resolve("bin").resolve("java");
> 71:         OutputAnalyzer analyzer =  ProcessTools.executeCommand(launcher.toAbsolutePath().toString(),"-ea", "-esa", "HijrahConfigCheck");
> 72:         analyzer.shouldHaveExitValue(0);

The variable `analyzer` may not be needed

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

PR Review: https://git.openjdk.org/jdk/pull/18602#pullrequestreview-1977861951
PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1550389295
PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1550389971

From duke at openjdk.org  Wed Apr  3 20:14:11 2024
From: duke at openjdk.org (=?UTF-8?B?VG9tw6HFoQ==?= Zezula)
Date: Wed, 3 Apr 2024 20:14:11 GMT
Subject: Integrated: JDK-8329564: [JVMCI]
 TranslatedException::debugPrintStackTrace does not work in the libjvmci
 compiler.
In-Reply-To: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>
References: <wketWjOfS8lz1-UNe95ll1UUUMX1iuJ2X79qqXb7wy0=.7f25966d-1258-4771-a9d2-ec0834794b2c@github.com>
Message-ID: <icQc5qq9wlGUUGYELsgC50foj0jQXqLcyBiId1TcAfk=.853dd370-b596-4f04-a98c-b2259d2b3d31@github.com>

On Wed, 3 Apr 2024 07:02:31 GMT, Tom?? Zezula <duke at openjdk.org> wrote:

> Problem:
> The debugging stack traces in `jdk.internal.vm.TranslatedException` do not work in libjvmci because they are enabled via the `jdk.internal.vm.TranslatedException.debug` system property. However, HotSpot system properties are not accessible via `System.getProperty()` in libjvmci.
> 
> Fix:
> The value of `jdk.internal.vm.TranslatedException.debug` is passed from the VM via a boolean flag to `VMSupport::decodeAndThrowThrowable()`.

This pull request has now been integrated.

Changeset: 8267d656
Author:    Tomas Zezula <tzezula at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8267d6565d17c8db8f5b50a37482610ffe0a8a5c
Stats:     32 lines in 5 files changed: 8 ins; 1 del; 23 mod

8329564: [JVMCI] TranslatedException::debugPrintStackTrace does not work in the libjvmci compiler.

Reviewed-by: dnsimon

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

PR: https://git.openjdk.org/jdk/pull/18591

From darcy at openjdk.org  Wed Apr  3 20:23:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 20:23:53 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
Message-ID: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>

When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.

The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.

To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

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

Commit messages:
 - Remove accidentally added file.
 - JDK-8329624: Add visitors for preview language features

Changes: https://git.openjdk.org/jdk/pull/18609/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329624
  Stats: 724 lines in 11 files changed: 715 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18609/head:pull/18609

PR: https://git.openjdk.org/jdk/pull/18609

From darcy at openjdk.org  Wed Apr  3 20:32:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 20:32:08 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <wr5jlKvUcAM_oVcnoUABHesCpi7U8WwKHvWImcw9DEk=.cea6f91a-6e00-4a95-a0db-c2060ecf6a10@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as #18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

When one of the preview visitors is subclassed, javac emits a warning like:


javac VisitorTest.java 
VisitorTest.java:2: warning: [preview] ElementKindVisitorPreview is a reflective preview API and may be removed in a future release.
public class VisitorTest extends javax.lang.model.util.ElementKindVisitorPreview {
                                                      ^
1 warning


Once these preview visitors are present, the particular API to support language change P can be added and reviewed without being dwarfed in the overall scaffolding. The anticipated usage would be:

Methods particular to supporting preview feature P can be annotated accordingly to indicate that usage.
When P goes to a final feature, a new set of JDK $N visitors would be inserted between to latest numbered set of visitors and the preview visitors. Methods particular to P would be moved up into the new JDK $N visitors.

For example, if feature P when final in JDK 25, there would be a new set of JDK 25 concrete visitors extended the existing JDK 14 visitors and superclass of the preview visitors would be changed from the JDK 14 visitor to the corresponding JDK 25 visitor. Methods associated with feature P would be moved up from the preview visitors into the JDK 25 visitors.

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

PR Comment: https://git.openjdk.org/jdk/pull/18609#issuecomment-2035521547

From vromero at openjdk.org  Wed Apr  3 21:36:00 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Apr 2024 21:36:00 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <nGUN4Wc51exZPWebfpBm2TmW8xLIJSotYJtcASZ1Yuo=.03bf5332-2eea-437d-9b4f-4c7e441cf5d3@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

looks good

src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2024, Oracle and/or its affiliates. All rights reserved.

general, please check the copyright years

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18609#pullrequestreview-1978047611
PR Review Comment: https://git.openjdk.org/jdk/pull/18609#discussion_r1550497836

From darcy at openjdk.org  Wed Apr  3 21:41:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 21:41:09 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <nGUN4Wc51exZPWebfpBm2TmW8xLIJSotYJtcASZ1Yuo=.03bf5332-2eea-437d-9b4f-4c7e441cf5d3@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
 <nGUN4Wc51exZPWebfpBm2TmW8xLIJSotYJtcASZ1Yuo=.03bf5332-2eea-437d-9b4f-4c7e441cf5d3@github.com>
Message-ID: <S7CI2vfGV7MKjgctDNmZ5V02VPiICf0nLsVNmNwVjMA=.489b5516-89a3-4756-ae5a-7b4d4232797f@github.com>

On Wed, 3 Apr 2024 21:05:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
>> 
>> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
>> 
>> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.
>
> src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> general, please check the copyright years

Starting with 2019 was intentional as I copied the corresponding FooVisitor14 file into FooVisitorPreview and then began editing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18609#discussion_r1550538694

From vromero at openjdk.org  Wed Apr  3 21:46:10 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Apr 2024 21:46:10 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <S7CI2vfGV7MKjgctDNmZ5V02VPiICf0nLsVNmNwVjMA=.489b5516-89a3-4756-ae5a-7b4d4232797f@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
 <nGUN4Wc51exZPWebfpBm2TmW8xLIJSotYJtcASZ1Yuo=.03bf5332-2eea-437d-9b4f-4c7e441cf5d3@github.com>
 <S7CI2vfGV7MKjgctDNmZ5V02VPiICf0nLsVNmNwVjMA=.489b5516-89a3-4756-ae5a-7b4d4232797f@github.com>
Message-ID: <NfA1ahYApo0VlcqPIRys0Nbx95LwLpU48ak2wtfLzxw=.3a66cd42-da9f-45bc-812e-9d9c6f17c3ec@github.com>

On Wed, 3 Apr 2024 21:38:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2019, 2024, Oracle and/or its affiliates. All rights reserved.
>> 
>> general, please check the copyright years
>
> Starting with 2019 was intentional as I copied the corresponding FooVisitor14 file into FooVisitorPreview and then began editing.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18609#discussion_r1550548814

From mchung at openjdk.org  Wed Apr  3 22:34:14 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 3 Apr 2024 22:34:14 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
Message-ID: <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>

On Tue, 19 Mar 2024 16:55:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move CreateLinkableRuntimePlugin to build folder
>   
>   Keep runtime link supporting classes in package
>   jdk.tools.jlink.internal.runtimelink

Thanks for the investigation w.r.t. extending jimage.  It does not seem worth the effort in pursuing the support of adding resources to an existing jimage file.   To me, putting the diff data under `lib` directory as a private file is a simpler and acceptable solution.   It allows the second jlink invocation to avoid the plugin pipeline if the per-module metadata is generated in normal jlink invocation.

(An observation: The current implementation requires the diffs to be generated as a plugin.  For this approach, it may be possible to implement with a separate main class that calls JLink API and generates the diffs.)

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2035719255

From alanb at openjdk.org  Thu Apr  4 05:51:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Apr 2024 05:51:11 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <BLnqfgrphEYISv8H_K1eVX78rzAX5HfgdrKSa-vp9l4=.b6ba350a-a99e-466a-a7a8-29accda21350@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

The visitor classes are themselves preview APIs. Is this the first time that preview APIs have been proposed without a JEP? Just wondering how much visibility this preview API will get.

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

PR Comment: https://git.openjdk.org/jdk/pull/18609#issuecomment-2036238254

From darcy at openjdk.org  Thu Apr  4 06:40:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 Apr 2024 06:40:11 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <BLnqfgrphEYISv8H_K1eVX78rzAX5HfgdrKSa-vp9l4=.b6ba350a-a99e-466a-a7a8-29accda21350@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
 <BLnqfgrphEYISv8H_K1eVX78rzAX5HfgdrKSa-vp9l4=.b6ba350a-a99e-466a-a7a8-29accda21350@github.com>
Message-ID: <3sSjWLu9scH-sWzCLWHKnXWOjuvpc5bT_KJ2O3qD8do=.07fd8fa1-94ea-484b-a910-d258d2103e09@github.com>

On Thu, 4 Apr 2024 05:48:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The visitor classes are themselves preview APIs. Is this the first time that preview APIs have been proposed without a JEP? Just wondering how much visibility this preview API will get.

To clarify the intention, the visitor classes are meant to be persistent preview APIs to help host specific preview APIs associated with modeling upcoming new language features. In particular, these visitor classes are expected to get small updates as part of the work being done in

https://github.com/openjdk/jdk/pull/18509

The preview visitor classes as such don't need much visibility as their use will be through various previewing language features.

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

PR Comment: https://git.openjdk.org/jdk/pull/18609#issuecomment-2036304517

From jlahoda at openjdk.org  Thu Apr  4 06:48:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 06:48:10 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <AzanYeupkPjTDSJ8a-pMZtvk48VYlqMaCoYetzyNRMM=.2284e4f0-4383-4271-9d7b-2cb84b732f40@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18609#pullrequestreview-1978870962

From jlahoda at openjdk.org  Thu Apr  4 07:35:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 07:35:33 GMT
Subject: RFR: 8328935: Implement Module Imports.
Message-ID: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>

This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
https://bugs.openjdk.org/browse/JDK-8315129

It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
There is a few notable aspects, however:
- the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
- JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

Commit messages:
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - More correct handling of requires transitive.
 - Merge branch 'module-imports' of github.com:lahodaj/jdk into module-imports
 - ... and 5 more: https://git.openjdk.org/jdk/compare/f26e4308...9cab0ae8

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328935
  Stats: 1065 lines in 28 files changed: 989 ins; 11 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From pminborg at openjdk.org  Thu Apr  4 07:39:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 4 Apr 2024 07:39:09 GMT
Subject: RFR: JDK-8329089: Empty immutable list throws the wrong exception
 type for remove(first | last) operations
In-Reply-To: <869n3vXcteD6NYfgKIGQMlOYbMhP7AlgUKZvEdEBjHY=.8d23995e-613f-455e-ac85-47e10d4a63c5@github.com>
References: <VqsB3uxDN8_H2wgkRz56gdTz5Ot1i5zOD3KlgjtR8FA=.74bfc834-647c-4cf7-bd60-5b846f780f06@github.com>
 <869n3vXcteD6NYfgKIGQMlOYbMhP7AlgUKZvEdEBjHY=.8d23995e-613f-455e-ac85-47e10d4a63c5@github.com>
Message-ID: <bbI9QMaWhLey3mtCMVz8GpwhkGomqJfMAnDrhZnxc2Y=.7fd3a4e7-3ed3-4764-a8f0-d90c507efddb@github.com>

On Wed, 3 Apr 2024 15:09:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR proposes to make empty immutable lists always throw UOE on `removeFirst` and `removeLast`.
>
> test/jdk/java/util/Collection/MOAT.java line 573:
> 
>> 571:                 c::removeLast);
>> 572:     }
>> 573: 
> 
> Would this test better if inserted in `testImmutableCollection(final Collection<T> c, T t)`, Line 477'ish.
> Or in `testImmutableList(final List<Integer> c)`, line 519.

Unfortunately, the `remove(F|L)` methods are not available for general collections. `testImmutableList()` is also applied for unmodifiable lists (like `Collections.emptyList()` and `Collections.nCopies(0, ...)`) that seem to behave differently (they throw NSEE). The latter have different specifications compared to an immutable list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18581#discussion_r1551086873

From sgehwolf at openjdk.org  Thu Apr  4 07:49:19 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 07:49:19 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
Message-ID: <q22qbuNBm3KFYBWcLw_stauZvjoBBfqMdFm6c_LU7mM=.8c792b85-a940-4dc0-871c-99462ca52aef@github.com>

On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Thanks for the investigation w.r.t. extending jimage. It does not seem worth the effort in pursuing the support of adding resources to an existing jimage file. To me, putting the diff data under `lib` directory as a private file is a simpler and acceptable solution. It allows the second jlink invocation to avoid the plugin pipeline if the per-module metadata is generated in normal jlink invocation.

Agreed. I'm pushing an update of the patch later today which does this. There is only one jlink call producing the final `jdk` image. That image is then amended to add the delta file under `lib`. The file is generated as a build step.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2036428963

From asotona at openjdk.org  Thu Apr  4 09:20:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 Apr 2024 09:20:39 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v5]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <pYTdp794pxHiv-RrNVd2EukvPltYiFBCiAY0Y92WOt4=.7016d790-c6f4-4326-9669-4f4b6ba19925@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> 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 10 additional commits since the last revision:

 - Reversion of ClassBuilder changes
 - Merge branch 'master' into JDK-8294960-invoke
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - added missing comment
 - fixed InnerClassLambdaMetafactory for hidden caller classes
 - performance improvements
 - consolidation of descriptors handling
 - InvokerBytecodeGenerator::emit... improvements
 - 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handlers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/098df109..500bb8f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=03-04

  Stats: 598651 lines in 7745 files changed: 108259 ins; 133327 del; 357065 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From mdoerr at openjdk.org  Thu Apr  4 09:40:11 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 4 Apr 2024 09:40:11 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v9]
In-Reply-To: <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>
Message-ID: <vOx-r_gLfHtkvxTdkDYePG2JOQHfp-ivM1q0bo254no=.9ee54d20-cf4a-4cdf-bac0-af8f48614173@github.com>

On Wed, 3 Apr 2024 12:32:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coding style

AFAICS, all .a libraries which are part of the AIX installation require a member specification in braces like `libodm.a(shr_64.o)` and can hence not be loaded by `System.loadLibrary`.
"libsysteminfo.a" is not available on typical AIX machines.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036686867

From sroy at openjdk.org  Thu Apr  4 09:44:11 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 4 Apr 2024 09:44:11 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <epFdOXeyudAthLSGQdzYTk-nl1laagxbQ3mJZAIi9xA=.197bb0f4-6a2e-4cd3-92b2-940db7c9cbdb@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
 <AIBNzoCFTcp5VlHJfjL9qmpeR-VdNdF-tFwSZqJ-ozg=.7bc2aa08-3622-4de2-8c01-cd1a8782c0e8@github.com>
 <aoNPqBbY1b4GtdkNLRDqG4WRjfuEg9BS_4f5Rh1l7Ug=.ef68803c-14de-40f5-9296-c9613db29842@github.com>
 <epFdOXeyudAthLSGQdzYTk-nl1laagxbQ3mJZAIi9xA=.197bb0f4-6a2e-4cd3-92b2-940db7c9cbdb@github.com>
Message-ID: <58-oFHQrFe66aGJP2FZhDs3JvDQs93-hxpdnGuZZoCI=.62b4ea2f-483d-4e49-af10-3db13f3c9edc@github.com>

On Wed, 3 Apr 2024 07:35:46 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Hello @suchismith1993,
>> 
>>> > I adjust the comments which also answer your question. Please add an AIX-only test to verify this behavior.
>>> 
>>> By test you mean provide the use case for pure .a files ?
>> 
>> In the JDK repo, changes like these are backed by jtreg tests https://openjdk.org/guide/#jtreg. So for this change, you would need to add a jtreg test which only runs on AIX (the jtreg documentation explains how to do that) and will exercise the `System.loadLibrary` call for a AIX specific library and verify that the library can be loaded as per the expectations that are set in the changes proposed and finalized in this PR.
>> 
>> For example, the test should verify that, after the changes proposed in this PR, calling `System.loadLibrary(<libname>)` on AIX will load from `<libname>.a` if `<libname>.so` is absent.
>> 
>> For reference, you can take a look at the existing tests for loadLibrary in the `test/jdk/java/lang/RuntimeTests/loadLibrary` directory.
>
>> test/jdk/java/lang/RuntimeTests/loadLibrary
> 
> I see. Thank you. Got to check some test cases files and how they are structured. 
> For this case, i feel the use case would be to have a pure .a file. Usually there is not such pure .a files that comes packaged with the OS. They are provided by some applications. So i am not sure how i can make the tests consistent for such cases. 
> Do you have any suggestions here ?  We are anyways passing it down to the hotspot code , which is taking care of it.

> Hello @suchismith1993,
> 
> > Usually there is not such pure .a files that comes packaged with the OS. They are provided by some applications. So i am not sure how i can make the tests consistent for such cases.
> > Do you have any suggestions here ?
> 
> Within the JDK repo, some tests require test specific native libraries (like in your case here). It appears that the JDK build infrastructure has ability to compile native code (`foo.c` for example) into a native library. However that build infrastructure doesn't appear to be flexible enough to support the case where you would have to run AIX specific commands to generate a `.a` file. So the approach of generating a test specific `.a` file doesn't look promising right now (it could still be possible, but I don't know how big a build change that would require).
> 
> So taking a step back - I see that https://bugs.openjdk.org/browse/JDK-8313616 introduced the ability to dealing with `.a` files on AIX from within the hotspot area. In that commit https://github.com/openjdk/jdk/pull/15204/files I see that there are references to a couple of `.a` files - for example `libodm.a` and `libperfstat.a`. Are those `.a` expected to be present on certain AIX systems? Perhaps your new test could use either of those in the test? There was also a mention of `libclang.a` on AIX, previously in this discussion. Maybe that could be used in the test?

I found libperfstat as the only example that is purely an archive files as part of AIX, after trying out multiple archives under /usr/lib. 
I am facing an issue to run the test ,but unable to set the library path to /usr/lib. I see the existing test case has libawt as part of jdk itself . Can i set -Djava.library.path while running jtreg test case ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036696638

From jpai at openjdk.org  Thu Apr  4 09:45:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 Apr 2024 09:45:10 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v5]
In-Reply-To: <JWx7o66uJrnstfhnilMY2CHfaxdkBGv2dIJ6hCMGW2k=.a60250fe-fb7b-49b3-97f6-2975fea94e89@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <JWx7o66uJrnstfhnilMY2CHfaxdkBGv2dIJ6hCMGW2k=.a60250fe-fb7b-49b3-97f6-2975fea94e89@github.com>
Message-ID: <XtkY48fSzgbHz0mc6Tupd569_YIpnaGx-DxpsWzoMDs=.134b5d9b-750a-4424-9fa2-c236a10ddfa2@github.com>

On Mon, 1 Apr 2024 22:22:19 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some more comments

test/jdk/java/util/zip/Zip64Offsets.java line 1:

> 1: /*

Hello Liam, given that this PR is addressing an issue in the `java` launcher, I think this test should reside in `test/jdk/tools/launcher/` directory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1551347422

From sroy at openjdk.org  Thu Apr  4 10:00:01 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 4 Apr 2024 10:00:01 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v8]
In-Reply-To: <58-oFHQrFe66aGJP2FZhDs3JvDQs93-hxpdnGuZZoCI=.62b4ea2f-483d-4e49-af10-3db13f3c9edc@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <BwXfsqWv0zM09mc4ljKvLlP_mHDFX7FbG5jEjXC1WaE=.d4ea6f1f-90f5-41e3-8cf2-04824d430370@github.com>
 <nXzmM13eKuBoJIJHBCjWrjlXjX3fJ_vGX7q1Yh4sjAU=.d13dad29-62ec-42c1-8d2e-c7386e0da34a@github.com>
 <AIBNzoCFTcp5VlHJfjL9qmpeR-VdNdF-tFwSZqJ-ozg=.7bc2aa08-3622-4de2-8c01-cd1a8782c0e8@github.com>
 <aoNPqBbY1b4GtdkNLRDqG4WRjfuEg9BS_4f5Rh1l7Ug=.ef68803c-14de-40f5-9296-c9613db29842@github.com>
 <epFdOXeyudAthLSGQdzYTk-nl1laagxbQ3mJZAIi9xA=.197bb0f4-6a2e-4cd3-92b2-940db7c9cbdb@github.com>
 <58-oFHQrFe66aGJP2FZhDs3JvDQs93-hxpdnGuZZoCI=.62b4ea2f-483d-4e49-af10-3db13f3c9edc@github.com>
Message-ID: <I0dAFcq7hKu6sGzf-J49KRVgHO2LdTQW2xk8mkjf-34=.634955b0-f8d5-43cb-a64b-36285461a84a@github.com>

On Thu, 4 Apr 2024 09:41:50 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > Hello @suchismith1993,
> > > Usually there is not such pure .a files that comes packaged with the OS. They are provided by some applications. So i am not sure how i can make the tests consistent for such cases.
> > > Do you have any suggestions here ?
> > 
> > 
> > Within the JDK repo, some tests require test specific native libraries (like in your case here). It appears that the JDK build infrastructure has ability to compile native code (`foo.c` for example) into a native library. However that build infrastructure doesn't appear to be flexible enough to support the case where you would have to run AIX specific commands to generate a `.a` file. So the approach of generating a test specific `.a` file doesn't look promising right now (it could still be possible, but I don't know how big a build change that would require).
> > So taking a step back - I see that https://bugs.openjdk.org/browse/JDK-8313616 introduced the ability to dealing with `.a` files on AIX from within the hotspot area. In that commit https://github.com/openjdk/jdk/pull/15204/files I see that there are references to a couple of `.a` files - for example `libodm.a` and `libperfstat.a`. Are those `.a` expected to be present on certain AIX systems? Perhaps your new test could use either of those in the test? There was also a mention of `libclang.a` on AIX, previously in this discussion. Maybe that could be used in the test?
> 
> I found libperfstat as the only example that is purely an archive files as part of AIX, after trying out multiple archives under /usr/lib. I am facing an issue to run the test ,but unable to set the library path to /usr/lib. I see the existing test case has libawt as part of jdk itself . Can i set -Djava.library.path while running jtreg test case ?

-Djava.library.path=/home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/images/test/jdk/jtreg/native  
I see from logs, this is the path being set to, Which is not the intended path. Not sure how the other test is working.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036730865

From alanb at openjdk.org  Thu Apr  4 10:08:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Apr 2024 10:08:21 GMT
Subject: RFR: 8329596: Add test for virtual threads invoking synchronized
 native methods
Message-ID: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>

This is a test-only addition to add a test for virtual threads invoking a synchronized native method and invoking a native method that enter/exits a monitor with JNI MonitorEnter/MonitorExit. The test has been in the loom repo for some time, it can move to the main line in advance of changes to the object monitor implementation.

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

Commit messages:
 - Fix typo in comments
 - Initial commit

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

PR: https://git.openjdk.org/jdk/pull/18600

From alanb at openjdk.org  Thu Apr  4 10:14:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Apr 2024 10:14:29 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
Message-ID: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>

This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.

In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.

The changes have been baking in the loom repo for several months.

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

Commit messages:
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/18598/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18598&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329593
  Stats: 1069 lines in 28 files changed: 221 ins; 623 del; 225 mod
  Patch: https://git.openjdk.org/jdk/pull/18598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18598/head:pull/18598

PR: https://git.openjdk.org/jdk/pull/18598

From mdoerr at openjdk.org  Thu Apr  4 10:33:14 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 4 Apr 2024 10:33:14 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v9]
In-Reply-To: <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>
Message-ID: <aCeoM9w1lL9_Ao8u0pBFTjvoGgo5dW-vN8qArTPGa9Q=.481931ef-e6a9-4788-ac04-bd74937555b9@github.com>

On Wed, 3 Apr 2024 12:32:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coding style

Hotspot loads it like this: https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/hotspot/os/aix/libperfstat_aix.cpp#L76
Are you sure it is supposed to be loaded without member specification?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036796686

From sroy at openjdk.org  Thu Apr  4 10:46:11 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 4 Apr 2024 10:46:11 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v9]
In-Reply-To: <aCeoM9w1lL9_Ao8u0pBFTjvoGgo5dW-vN8qArTPGa9Q=.481931ef-e6a9-4788-ac04-bd74937555b9@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>
 <aCeoM9w1lL9_Ao8u0pBFTjvoGgo5dW-vN8qArTPGa9Q=.481931ef-e6a9-4788-ac04-bd74937555b9@github.com>
Message-ID: <sXZ_bTCj7dfTisw1Y_cvx7y66eiD8uuDCXFew2WLtRU=.1b69d5ea-5ad3-4e98-857a-f329c20aaf47@github.com>

On Thu, 4 Apr 2024 10:30:08 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Hotspot loads it like this:
> 
> https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/hotspot/os/aix/libperfstat_aix.cpp#L76
> 
> 
> Are you sure it is supposed to be loaded without member specification?

Yes i was able to do it without mentioning the shared object. libodm was failing though.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036822196

From sgehwolf at openjdk.org  Thu Apr  4 11:12:43 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 11:12:43 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:

 - Fix coment
 - Fix comment
 - Fix typo
 - Revert some now unneded build changes
 - Follow build tools naming convention
 - Update to new build-time approach with delta in lib
 - Make generation of fs_$module_files unconditional
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Fix copyright year
 - Move CreateLinkableRuntimePlugin to build folder
   
   Keep runtime link supporting classes in package
   jdk.tools.jlink.internal.runtimelink
 - ... and 90 more: https://git.openjdk.org/jdk/compare/6ae1cf12...ce04f42a

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

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=23
  Stats: 3384 lines in 36 files changed: 3247 ins; 106 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From sroy at openjdk.org  Thu Apr  4 11:13:43 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 4 Apr 2024 11:13:43 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v10]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  Add jtreg test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/c6ec69a9..0f6641fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=08-09

  Stats: 40 lines in 1 file changed: 40 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Thu Apr  4 11:18:12 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 4 Apr 2024 11:18:12 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v9]
In-Reply-To: <sXZ_bTCj7dfTisw1Y_cvx7y66eiD8uuDCXFew2WLtRU=.1b69d5ea-5ad3-4e98-857a-f329c20aaf47@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <tf-hy_O6Ba8W3fY33cBaP4Eb9P08yOao9iupQnnKoFk=.c43cb737-a1b5-46fe-978c-30a05549ef0a@github.com>
 <aCeoM9w1lL9_Ao8u0pBFTjvoGgo5dW-vN8qArTPGa9Q=.481931ef-e6a9-4788-ac04-bd74937555b9@github.com>
 <sXZ_bTCj7dfTisw1Y_cvx7y66eiD8uuDCXFew2WLtRU=.1b69d5ea-5ad3-4e98-857a-f329c20aaf47@github.com>
Message-ID: <vgGB2eM-IDta9w1KuUuodWOv1-weM1UfB2f02wwNEvY=.bab9c38d-0319-4ab6-86f8-1580538d0e45@github.com>

On Thu, 4 Apr 2024 10:43:35 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Hotspot loads it like this: https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/hotspot/os/aix/libperfstat_aix.cpp#L76
>> Are you sure it is supposed to be loaded without member specification?
>
>> Hotspot loads it like this:
>> 
>> https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/hotspot/os/aix/libperfstat_aix.cpp#L76
>> 
>> 
>> Are you sure it is supposed to be loaded without member specification?
> 
> Yes i was able to do it without mentioning the shared object. libodm was failing though.

> > > Hello @suchismith1993,
> > > > Usually there is not such pure .a files that comes packaged with the OS. They are provided by some applications. So i am not sure how i can make the tests consistent for such cases.
> > > > Do you have any suggestions here ?
> > > 
> > > 
> > > Within the JDK repo, some tests require test specific native libraries (like in your case here). It appears that the JDK build infrastructure has ability to compile native code (`foo.c` for example) into a native library. However that build infrastructure doesn't appear to be flexible enough to support the case where you would have to run AIX specific commands to generate a `.a` file. So the approach of generating a test specific `.a` file doesn't look promising right now (it could still be possible, but I don't know how big a build change that would require).
> > > So taking a step back - I see that https://bugs.openjdk.org/browse/JDK-8313616 introduced the ability to dealing with `.a` files on AIX from within the hotspot area. In that commit https://github.com/openjdk/jdk/pull/15204/files I see that there are references to a couple of `.a` files - for example `libodm.a` and `libperfstat.a`. Are those `.a` expected to be present on certain AIX systems? Perhaps your new test could use either of those in the test? There was also a mention of `libclang.a` on AIX, previously in this discussion. Maybe that could be used in the test?
> > 
> > 
> > I found libperfstat as the only example that is purely an archive files as part of AIX, after trying out multiple archives under /usr/lib. I am facing an issue to run the test ,but unable to set the library path to /usr/lib. I see the existing test case has libawt as part of jdk itself . Can i set -Djava.library.path while running jtreg test case ?
> 
> -Djava.library.path=/home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/images/test/jdk/jtreg/native I see from logs, this is the path being set to, Which is not the intended path. Not sure how the other test is working.

Ok i think i was able to resolve this. Need some guidance on where should i place the test file. Have made a very basic test to just load libperfstat.a

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036882540

From duke at openjdk.org  Thu Apr  4 11:46:10 2024
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 4 Apr 2024 11:46:10 GMT
Subject: RFR: 8328481: Implement Module Imports
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>

On Thu, 4 Apr 2024 07:30:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Should the pull request incorporate a modification to the JAVASE script file for JShell, specifically substituting it with `import module java.se`? (right now the imports are computed, not read from a file)

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

PR Comment: https://git.openjdk.org/jdk/pull/18614#issuecomment-2036941814

From jlahoda at openjdk.org  Thu Apr  4 11:52:59 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 11:52:59 GMT
Subject: RFR: 8328481: Implement Module Imports
In-Reply-To: <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>
Message-ID: <PkEjwtAGwGv4mLh5mGGtGVBIPSHTF0738uNTmcQryzw=.830b4b46-94ba-40b0-bb89-9a1b50c8833a@github.com>

On Thu, 4 Apr 2024 11:43:07 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

> Should the pull request incorporate a modification to the JAVASE script file for JShell, specifically substituting it with `import module java.se`? (right now the imports are computed, not read from a file)

Given we need to keep the existing code (as `import module java.se` would only work when preview is enabled), and given the outcomes for the user should be (I think, at least) the same, it does not seem necessary to me to complicate things by having two ways to achieve the same outcome.

When the feature goes final, then maybe we could consider replacing the hardcoded JAVASE with a script. But, even then, the user might use `-C--release=21`, and `import module java.se` would not work then, so it may be easier to keep the current code even then.

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

PR Comment: https://git.openjdk.org/jdk/pull/18614#issuecomment-2036957025

From sgehwolf at openjdk.org  Thu Apr  4 12:10:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 12:10:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <kUhJgtefWZUERJXOtv1HgUfgSbCQLMsfJig0W9sFj9w=.323f0ae3-07be-4963-93ee-655839a6ad86@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <kUhJgtefWZUERJXOtv1HgUfgSbCQLMsfJig0W9sFj9w=.323f0ae3-07be-4963-93ee-655839a6ad86@github.com>
Message-ID: <bsSkbEkZSyWzQ-unU0ifCAbda4LlqTXBbsMwKM8A_5o=.f467733c-b251-403d-94a5-a842304b992e@github.com>

On Thu, 14 Mar 2024 17:46:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in autoconf file
>
> make/Images.gmk line 126:
> 
>> 124:   RL_BUILD_MODULE_NAME := jdk.unsupported_jlink_runtime
>> 125:   RL_CREATE_PLUGIN_MOD_OUTPUT := $(SUPPORT_OUTPUTDIR)/$(RL_BUILD_MODULE_NAME)
>> 126:   JDK_RUN_TIME_IMAGE_SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/runtime-link-support
> 
> Suggestion:
> 
>   JDK_RUNTIME_IMAGE_SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/runtime-link-support
> 
> or just inline it as it's only used in one location.

Obsolete now.

> make/Images.gmk line 132:
> 
>> 130:   JLINK_RUNTIME_CREATE_ARG += -J--add-exports=java.base/jdk.internal.jimage=$(RL_BUILD_MODULE_NAME)
>> 131:   JLINK_RUNTIME_CREATE_ARG += -J--add-exports=jdk.jlink/jdk.tools.jlink.internal=$(RL_BUILD_MODULE_NAME)
>> 132:   JLINK_RUNTIME_CREATE_ARG += --create-linkable-runtime jimage=$(JDK_LINK_OUTPUT_DIR)/lib/modules:module-path=$(IMAGES_OUTPUTDIR)/jmods
> 
> I would suggest using recommendation 17 from the [style guideline](https://openjdk.org/groups/build/doc/code-conventions.html) here.
> Suggestion:
> 
>   JLINK_RUNTIME_CREATE_ARG := \
>         -J--module-path=$(RL_CREATE_PLUGIN_MOD_OUTPUT) \
>         -J--add-exports=java.base/jdk.internal.module=$(RL_BUILD_MODULE_NAME) \
>         -J--add-exports=java.base/jdk.internal.jimage=$(RL_BUILD_MODULE_NAME) \
>         -J--add-exports=jdk.jlink/jdk.tools.jlink.internal=$(RL_BUILD_MODULE_NAME) \
>         --create-linkable-runtime jimage=$(JDK_LINK_OUTPUT_DIR)/lib/modules:module-path=$(IMAGES_OUTPUTDIR)/jmods \
>         #
> 
> or just inline as it's only used in one location.

No longer applicable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551541291
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551542046

From sgehwolf at openjdk.org  Thu Apr  4 12:10:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 12:10:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <nPDJ7Lc3TWtM3A6hE5SEvHOGFD23WtBiHvTBuVwALLY=.8a444e4c-4fde-4046-be06-2d3fc7f09bfc@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <VxmGlRYbm6YgNfgGegfXfu-iHQjJkJs5B3zPCQfSYqE=.8515aa64-efd0-4aad-a4bc-5cd830491ead@github.com>
 <2vB9N80N5vzYIQiyt9yb2bufOR-l_mH4g5C4qZ9_Jm0=.57d0cc34-50b5-4965-8229-2c046014088d@github.com>
 <nPDJ7Lc3TWtM3A6hE5SEvHOGFD23WtBiHvTBuVwALLY=.8a444e4c-4fde-4046-be06-2d3fc7f09bfc@github.com>
Message-ID: <o3suGILRYN7CtL38wcetTDJxFknrq6gLRaw4eURi9Y8=.6d804b39-fb15-4f15-aa32-7320baad5f45@github.com>

On Thu, 21 Mar 2024 15:30:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks! This will also likely change. I'm thinking of just generating the diff file and putting it into `lib/` of the JDK image. That avoids needing to call this build-time only jlink plugin and this `FixPath` magic.
>
> I see. I'm sorry if I did not fully understand how the ongoing discussions affected build source changes. 
> 
> Maybe I should just put the build part review of this PR on the backburner, and then you can ping me when you think you have a solution that will stick, and I can check how it holds up from a build perspective?

I hope the latest version is where we're headed now. I'll ping you for a review once the dust settles. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551544078

From sgehwolf at openjdk.org  Thu Apr  4 12:10:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 12:10:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <2vB9N80N5vzYIQiyt9yb2bufOR-l_mH4g5C4qZ9_Jm0=.57d0cc34-50b5-4965-8229-2c046014088d@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <VxmGlRYbm6YgNfgGegfXfu-iHQjJkJs5B3zPCQfSYqE=.8515aa64-efd0-4aad-a4bc-5cd830491ead@github.com>
 <2vB9N80N5vzYIQiyt9yb2bufOR-l_mH4g5C4qZ9_Jm0=.57d0cc34-50b5-4965-8229-2c046014088d@github.com>
Message-ID: <wjf88OpbCOPyQZWIQh1A9OiAf7qpYg1NVOARyzvgj9o=.99ff81bd-049d-49bc-9a01-17eea1938313@github.com>

On Thu, 21 Mar 2024 15:29:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> make/Images.gmk line 145:
>> 
>>> 143:   $(eval $(call SetupJavaCompilation, BUILD_JDK_RUNLINK_CLASSES, \
>>> 144:       COMPILER := buildjdk, \
>>> 145:       DISABLED_WARNINGS := try, \
>> 
>> Why do we get warnings in the java code?
>
> That's not needed anymore. There are some `try` warnings in the `JmodsReader` and `JimageDiffGenerator` classes which used to get compiled with this. It'll probably change again...

No longer there.

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 40:
>> 
>>> 38: public class JimageDiffGenerator {
>>> 39: 
>>> 40:     private static final boolean DEBUG = false;
>> 
>> This seems like left-over debug code. If this should go into product code I suggest you either remove it, or alternatively make it possible to change at runtime, if the debug functionality will be needed.
>
> OK.

Removed in the latest version. The debug static in the build tools class can be enabled with a property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551544541
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551547273

From sgehwolf at openjdk.org  Thu Apr  4 12:10:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 12:10:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <vmuux88zamMVuqmXJ9MJFRoOuwTAzTSpx5rYTVS-SzI=.b3c15c0d-a926-468f-8ad4-e4d96d0e1ee1@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <VxmGlRYbm6YgNfgGegfXfu-iHQjJkJs5B3zPCQfSYqE=.8515aa64-efd0-4aad-a4bc-5cd830491ead@github.com>
 <2vB9N80N5vzYIQiyt9yb2bufOR-l_mH4g5C4qZ9_Jm0=.57d0cc34-50b5-4965-8229-2c046014088d@github.com>
 <nPDJ7Lc3TWtM3A6hE5SEvHOGFD23WtBiHvTBuVwALLY=.8a444e4c-4fde-4046-be06-2d3fc7f09bfc@github.com>
 <vmuux88zamMVuqmXJ9MJFRoOuwTAzTSpx5rYTVS-SzI=.b3c15c0d-a926-468f-8ad4-e4d96d0e1ee1@github.com>
Message-ID: <XdchgoaQexBjSMBscS3534bbPo069HHtkE2C7ibeaWc=.003f4590-da31-40cf-aa96-da8c69d3fef5@github.com>

On Thu, 21 Mar 2024 15:35:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Ok, fine. Will the new solution still include a build-time only tool?
>
> Yes, but I'll likely go with the interim solution and that would only require the a single "driver" class in the build tree with a `main` method.

Now it's no longer a module, since no jlink plugin is being used any more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551545310

From erikj at openjdk.org  Thu Apr  4 13:13:18 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 4 Apr 2024 13:13:18 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
Message-ID: <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>

On Thu, 4 Apr 2024 11:12:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:
> 
>  - Fix coment
>  - Fix comment
>  - Fix typo
>  - Revert some now unneded build changes
>  - Follow build tools naming convention
>  - Update to new build-time approach with delta in lib
>  - Make generation of fs_$module_files unconditional
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Fix copyright year
>  - Move CreateLinkableRuntimePlugin to build folder
>    
>    Keep runtime link supporting classes in package
>    jdk.tools.jlink.internal.runtimelink
>  - ... and 90 more: https://git.openjdk.org/jdk/compare/6ae1cf12...ce04f42a

The new approach certainly makes the build part simpler, which I appreciate. Left some polishing comments. You don't need to address them until the general approach is accepted.

make/CompileToolsJdk.gmk line 50:

> 48:     EXCLUDES := \
> 49:         build/tools/classlist \
> 50:         build/tools/runtimeimagelinkdeltaproducer \

This directory name is comically long. I guess that's not really a problem, but perhaps "linkdelta" would be descriptive enough given that the class has the full name anyway?

make/Images.gmk line 114:

> 112: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
> 113:   RL_BUILD_CLASSES := runtimeimagelinkdeltaproducer-classes
> 114:   RL_DELTA_GEN_CLASSES := $(BUILDTOOLS_OUTPUTDIR)/$(RL_BUILD_CLASSES)

With a shorter name, this could be just one line.

make/Images.gmk line 119:

> 117:   RL_DIFFS_OUTPUT_FILE_ARG := $(JDK_IMAGE_DIR)/lib/runtime-image-link.delta
> 118:   RL_MOD_PATH_ARG := $(IMAGES_OUTPUTDIR)/jmods
> 119:   TOOL_RUNTIME_IMAGE_LINK_DELTA_PRODUCER := $(BUILD_JAVA) --add-modules jdk.jlink \

All of these are only used once so should rather be inlined. I think that makes it easier to understand and read.

make/Images.gmk line 122:

> 120:       --add-exports=jdk.jlink/jdk.tools.jlink.internal.runtimelink=ALL-UNNAMED \
> 121:       --add-exports=java.base/jdk.internal.module=ALL-UNNAMED \
> 122:       --add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED \

These three are repeated in both compilation and runtime so could potentially be set in a variable to avoid the duplication.

make/Images.gmk line 208:

> 206:       WARN := Creating CDS$$($1_$2_DUMP_TYPE) archive for jdk image for $1, \
> 207:       INFO := Using CDS flags for $1: $$($1_$2_CDS_DUMP_FLAGS), \
> 208:       DEPS := $$(FINAL_JDK_JLINK), \

Does this actually interfere with the cds archive creation? I would assume they output to different files and they aren't even running `java` from the same image. If not, I would skip the whole `FINAL_JDK_JLINK` and just add `$(diff_runtime_jdk)` to `JDK_TARGETS`.

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

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-1979812209
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551631105
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551639403
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551648048
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551652030
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551636954

From sgehwolf at openjdk.org  Thu Apr  4 13:14:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 13:14:00 GMT
Subject: RFR: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
In-Reply-To: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
References: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
Message-ID: <FNfUoT7DMNfNRDHsIPl2i6YSPI5-oH5Xd8QOLN6hosA=.4f0be6b5-d926-4112-baf3-5d7e1cbf3f74@github.com>

On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is a draft PR with a potential solution to 8328366 without regressing 8327501.
> 
> @DougLea To avoid regressions in the future, where would regression tests for this ideally be located?

Is there any update on this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/18374#issuecomment-2037179136

From jlahoda at openjdk.org  Thu Apr  4 14:13:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 14:13:27 GMT
Subject: RFR: 8328481: Implement Module Imports [v2]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <JO0h7iNpNt6eGqBfRUboq8R6AKfKJ4yvAps-kGdKD8Y=.23754f67-5b3b-4505-8aaa-e19b10751f80@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda 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 16 additional commits since the last revision:

 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - More correct handling of requires transitive.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/c0c0131b...3f2deab9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/9cab0ae8..3f2deab9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=00-01

  Stats: 318 lines in 18 files changed: 46 ins; 198 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From rriggs at openjdk.org  Thu Apr  4 14:46:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 4 Apr 2024 14:46:09 GMT
Subject: RFR: JDK-8329089: Empty immutable list throws the wrong exception
 type for remove(first | last) operations
In-Reply-To: <VqsB3uxDN8_H2wgkRz56gdTz5Ot1i5zOD3KlgjtR8FA=.74bfc834-647c-4cf7-bd60-5b846f780f06@github.com>
References: <VqsB3uxDN8_H2wgkRz56gdTz5Ot1i5zOD3KlgjtR8FA=.74bfc834-647c-4cf7-bd60-5b846f780f06@github.com>
Message-ID: <ziJ4c8eDYxjUdEzwSPrcQrVzkjOGSN22_eFhwxJNgJw=.a7c638e2-fe4a-40de-a34f-9ed267ef7ed6@github.com>

On Tue, 2 Apr 2024 10:37:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to make empty immutable lists always throw UOE on `removeFirst` and `removeLast`.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18581#pullrequestreview-1980142511

From vklang at openjdk.org  Thu Apr  4 14:49:13 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 4 Apr 2024 14:49:13 GMT
Subject: RFR: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
In-Reply-To: <JOs0zlC7sN6d9F5q0VezSJL9Jtt8ZJn4mxbyGNy6i5c=.e91745c0-4568-43cd-9dd8-bab71fc1b804@github.com>
References: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
 <JOs0zlC7sN6d9F5q0VezSJL9Jtt8ZJn4mxbyGNy6i5c=.e91745c0-4568-43cd-9dd8-bab71fc1b804@github.com>
Message-ID: <bCUB4VdSk-pAgO0LshCeqC1k8NQLz-A3xuOqOJct3gY=.61b325ba-efc8-4c3a-8ae0-926fd0621043@github.com>

On Wed, 20 Mar 2024 17:15:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This is a draft PR with a potential solution to 8328366 without regressing 8327501.
>> 
>> @DougLea To avoid regressions in the future, where would regression tests for this ideally be located?
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1143:
> 
>> 1141:             @SuppressWarnings("removal")
>> 1142:             SecurityManager sm = System.getSecurityManager();
>> 1143:             if (sm != null && isCommon)
> 
> For common thread pool, if SM is not enabled, it will create `ForkJoinWorkerThread` that does not clear thread locals which is different than JDK 18 behavior.  Is this intentional?

@mlchung I think we should proceed with merging this as-is and look to address the ThreadLocal situation (or not at all, based on @DougLea's input). Are you OK with reviewing this as-is?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18374#discussion_r1551827957

From simonis at openjdk.org  Thu Apr  4 15:15:16 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 4 Apr 2024 15:15:16 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v6]
In-Reply-To: <OawnS0uxsJYWlbNcXWteJTVR0H5NCXoU4o4MJwSglIQ=.b91bd0d4-f84d-4b00-85e3-ab84f9d2ceef@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <OawnS0uxsJYWlbNcXWteJTVR0H5NCXoU4o4MJwSglIQ=.b91bd0d4-f84d-4b00-85e3-ab84f9d2ceef@github.com>
Message-ID: <AZOh5X_HxjZ2ecc4a7hINvkdlCZQwvSuM2ID8VQD07c=.50f3a1d9-38d2-4b7a-b062-3d67f3199651@github.com>

On Wed, 3 Apr 2024 01:37:37 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> Add notes for `HashMap::putAll()` conservative resizing.
>> 
>> Note: everything below this line is from the original change. After discussion, we decided to keep the conservative resizing, but we should add an `@implNote` for the decision.
>> 
>> ---
>> 
>> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
>> 
>> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
>> 
>> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
>> 
>> 
>> Before change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
>> 
>> 
>> After change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
>> 
>> 
>> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
>> 
>> ---
>> 
>> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
>> 
>> Before change:
>> 
>> 
>> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
>> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
>> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
>> HashM...
>
> Joshua Cao 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:
> 
>  - Update implNotes to explain conservative resizing decisions and suggest
>    options to avoid expensive resizing
>  - Merge branch 'master' into hashmap
>  - Add note about conservative resizing
>  - Merge branch 'master' into hashmap
>  - extract msize variable
>  - Use max of both sizes and other maps size in case of overflow
>  - Add benchmark with all duplicate keys
>  - 8324573: HashMap::putAll should resize to sum of both map sizes

The new comment looks good, but as I wrote, ` {@code HashMap(int initialCapacity)}` and `{@code newHashMap(int numMappings)}` should be change to ``@link` tags.  I don't now the exact syntax, but there are other examples in that file.

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-2037483552

From sgehwolf at openjdk.org  Thu Apr  4 15:24:22 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 15:24:22 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
 <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
Message-ID: <UC-vZA6XdT36rRC7KehIdQ7tv6a8qY1beB8Jf6vKM_8=.c0d7d19e-13c0-486c-ab0d-fda31bfe07f0@github.com>

On Thu, 4 Apr 2024 13:00:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:
>> 
>>  - Fix coment
>>  - Fix comment
>>  - Fix typo
>>  - Revert some now unneded build changes
>>  - Follow build tools naming convention
>>  - Update to new build-time approach with delta in lib
>>  - Make generation of fs_$module_files unconditional
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Fix copyright year
>>  - Move CreateLinkableRuntimePlugin to build folder
>>    
>>    Keep runtime link supporting classes in package
>>    jdk.tools.jlink.internal.runtimelink
>>  - ... and 90 more: https://git.openjdk.org/jdk/compare/6ae1cf12...ce04f42a
>
> make/Images.gmk line 208:
> 
>> 206:       WARN := Creating CDS$$($1_$2_DUMP_TYPE) archive for jdk image for $1, \
>> 207:       INFO := Using CDS flags for $1: $$($1_$2_CDS_DUMP_FLAGS), \
>> 208:       DEPS := $$(FINAL_JDK_JLINK), \
> 
> Does this actually interfere with the cds archive creation? I would assume they output to different files and they aren't even running `java` from the same image. If not, I would skip the whole `FINAL_JDK_JLINK` and just add `$(diff_runtime_jdk)` to `JDK_TARGETS`.

You are right. It no longer does (the old approach did, though). I'll clean it up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551898463

From sgehwolf at openjdk.org  Thu Apr  4 15:27:24 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 15:27:24 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
 <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
Message-ID: <T-Myy48CM4UbBFHTmzCt8d-SPgFmyX_R3ZV9NYorgDg=.0b8b4d06-930f-417f-9e3e-0dd789d57dca@github.com>

On Thu, 4 Apr 2024 12:56:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:
>> 
>>  - Fix coment
>>  - Fix comment
>>  - Fix typo
>>  - Revert some now unneded build changes
>>  - Follow build tools naming convention
>>  - Update to new build-time approach with delta in lib
>>  - Make generation of fs_$module_files unconditional
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Fix copyright year
>>  - Move CreateLinkableRuntimePlugin to build folder
>>    
>>    Keep runtime link supporting classes in package
>>    jdk.tools.jlink.internal.runtimelink
>>  - ... and 90 more: https://git.openjdk.org/jdk/compare/6ae1cf12...ce04f42a
>
> make/CompileToolsJdk.gmk line 50:
> 
>> 48:     EXCLUDES := \
>> 49:         build/tools/classlist \
>> 50:         build/tools/runtimeimagelinkdeltaproducer \
> 
> This directory name is comically long. I guess that's not really a problem, but perhaps "linkdelta" would be descriptive enough given that the class has the full name anyway?

FYI: This was trying to address a comment from @magicus https://github.com/openjdk/jdk/pull/14787#discussion_r1514894494 Happy to not follow that convention and/or rename the tool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551909878

From erikj at openjdk.org  Thu Apr  4 15:41:17 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 4 Apr 2024 15:41:17 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <T-Myy48CM4UbBFHTmzCt8d-SPgFmyX_R3ZV9NYorgDg=.0b8b4d06-930f-417f-9e3e-0dd789d57dca@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
 <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
 <T-Myy48CM4UbBFHTmzCt8d-SPgFmyX_R3ZV9NYorgDg=.0b8b4d06-930f-417f-9e3e-0dd789d57dca@github.com>
Message-ID: <4NcIbddx8UZky7IIR9XW0yRFXAARqA1HQyeH1eejk20=.e60906ea-8a4b-4932-99f9-0fb9e4ca0ca7@github.com>

On Thu, 4 Apr 2024 15:24:53 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> make/CompileToolsJdk.gmk line 50:
>> 
>>> 48:     EXCLUDES := \
>>> 49:         build/tools/classlist \
>>> 50:         build/tools/runtimeimagelinkdeltaproducer \
>> 
>> This directory name is comically long. I guess that's not really a problem, but perhaps "linkdelta" would be descriptive enough given that the class has the full name anyway?
>
> FYI: This was trying to address a comment from @magicus https://github.com/openjdk/jdk/pull/14787#discussion_r1514894494 Happy to not follow that convention and/or rename the tool.

I was not aware of such a convention and I can't say I agree with it. It just seems redundant and unnecessary, but I suppose we should wait for Magnus to respond.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1551940327

From mchung at openjdk.org  Thu Apr  4 16:18:11 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 4 Apr 2024 16:18:11 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v10]
In-Reply-To: <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
Message-ID: <a2ckNEMR9cpreb2C8c-du5w5tspTHdMdbXzcCUESoko=.eb236543-82dd-48b8-8947-579319c5e067@github.com>

On Thu, 4 Apr 2024 11:13:43 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add jtreg test case

Under `test/jdk/java/lang/RuntimeTests/loadLibrary` directory or a subdirectory under it would work

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2037641298

From mchung at openjdk.org  Thu Apr  4 16:21:10 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 4 Apr 2024 16:21:10 GMT
Subject: RFR: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
In-Reply-To: <bCUB4VdSk-pAgO0LshCeqC1k8NQLz-A3xuOqOJct3gY=.61b325ba-efc8-4c3a-8ae0-926fd0621043@github.com>
References: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
 <JOs0zlC7sN6d9F5q0VezSJL9Jtt8ZJn4mxbyGNy6i5c=.e91745c0-4568-43cd-9dd8-bab71fc1b804@github.com>
 <bCUB4VdSk-pAgO0LshCeqC1k8NQLz-A3xuOqOJct3gY=.61b325ba-efc8-4c3a-8ae0-926fd0621043@github.com>
Message-ID: <E4lRMPf-4rreYBErEeDZ6kgDxtkxxQTEJbPhQhWz5Ao=.3669979d-011f-4374-a010-2266e3d45620@github.com>

On Thu, 4 Apr 2024 14:46:11 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1143:
>> 
>>> 1141:             @SuppressWarnings("removal")
>>> 1142:             SecurityManager sm = System.getSecurityManager();
>>> 1143:             if (sm != null && isCommon)
>> 
>> For common thread pool, if SM is not enabled, it will create `ForkJoinWorkerThread` that does not clear thread locals which is different than JDK 18 behavior.  Is this intentional?
>
> @mlchung I think we should proceed with merging this as-is and look to address the ThreadLocal situation (or not at all, based on @DougLea's input). Are you OK with reviewing this as-is?

Yes it's fine to separate it as a follow up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18374#discussion_r1552027346

From mchung at openjdk.org  Thu Apr  4 16:21:09 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 4 Apr 2024 16:21:09 GMT
Subject: RFR: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
In-Reply-To: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
References: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
Message-ID: <Ull-LWX0PVr50rUGA8PikUBTevryQv75RWyNWMyl-Vs=.feaedb01-b8dc-4fcf-92a4-40a12052c280@github.com>

On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is a draft PR with a potential solution to 8328366 without regressing 8327501.
> 
> @DougLea To avoid regressions in the future, where would regression tests for this ideally be located?

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18374#pullrequestreview-1980469001

From darcy at openjdk.org  Thu Apr  4 16:34:50 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 Apr 2024 16:34:50 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features [v2]
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <TihoImdTm2OP4-JkhnrBjoEMjEv-ADSkLp1F1B9-KBg=.74865fda-4d9a-43e0-a60c-c8a03b59b78e@github.com>

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

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

  Add informative links.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18609/files
  - new: https://git.openjdk.org/jdk/pull/18609/files/45bbc292..5fc414bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18609&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18609&range=00-01

  Stats: 36 lines in 10 files changed: 22 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18609/head:pull/18609

PR: https://git.openjdk.org/jdk/pull/18609

From sgehwolf at openjdk.org  Thu Apr  4 16:46:32 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 16:46:32 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

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

 - Use shorter name for the build tool
 - Review feedback from Erik J.
 - Remove dependency on CDS which isn't needed anymore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/ce04f42a..84d4feff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=23-24

  Stats: 32 lines in 3 files changed: 3 ins; 16 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From sroy at openjdk.org  Thu Apr  4 16:53:04 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 4 Apr 2024 16:53:04 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v10]
In-Reply-To: <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
Message-ID: <TVsB92f4jydhJLU3ElNS0Bu1OEuXPazYOhNnCyVcprA=.10326443-2eb8-4168-9efe-7cb8ea857b96@github.com>

On Thu, 4 Apr 2024 11:13:43 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add jtreg test case

Is the current name of file accurate ?
Shall i just make a directory named aix and keep the name of file as
loadLibraryTest.
Just trying to get familiar with the best practices.

On Thu, Apr 4, 2024, 21:45 Mandy Chung ***@***.***> wrote:

> Under test/jdk/java/lang/RuntimeTests/loadLibrary directory or a
> subdirectory under it would work
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/17945#issuecomment-2037641298>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AESW3BDXY2NTWOZO2OTRQRTY3V4DLAVCNFSM6AAAAABDS326YOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGY2DCMRZHA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2037708525

From cushon at openjdk.org  Thu Apr  4 16:57:40 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 4 Apr 2024 16:57:40 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v6]
In-Reply-To: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
Message-ID: <mFJD586uS9BKVdghAP0y8c1qkULzQbEgypPZwkd2YDI=.4c643822-c8b2-41ad-955a-2420c7e0af5e@github.com>

> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Move test to test/jdk/tools/launcher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18479/files
  - new: https://git.openjdk.org/jdk/pull/18479/files/c2e16e12..140e13b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/18479

From cushon at openjdk.org  Thu Apr  4 16:57:40 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 4 Apr 2024 16:57:40 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v5]
In-Reply-To: <XtkY48fSzgbHz0mc6Tupd569_YIpnaGx-DxpsWzoMDs=.134b5d9b-750a-4424-9fa2-c236a10ddfa2@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <JWx7o66uJrnstfhnilMY2CHfaxdkBGv2dIJ6hCMGW2k=.a60250fe-fb7b-49b3-97f6-2975fea94e89@github.com>
 <XtkY48fSzgbHz0mc6Tupd569_YIpnaGx-DxpsWzoMDs=.134b5d9b-750a-4424-9fa2-c236a10ddfa2@github.com>
Message-ID: <ks4HKBIcJYANIr8GKLB-gneRUQKM5kNyvaj_oV_BdF0=.ceb5f41a-4c3e-4829-aa58-8f857b95c455@github.com>

On Thu, 4 Apr 2024 09:42:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add some more comments
>
> test/jdk/java/util/zip/Zip64Offsets.java line 1:
> 
>> 1: /*
> 
> Hello Liam, given that this PR is addressing an issue in the `java` launcher, I think this test should reside in `test/jdk/tools/launcher/` directory.

I moved it to `test/jdk/tools/launcher/`, thanks!

(I modeled this after some other zip64 tests, which I now realize were originally added as tests for `java.util.zip`.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1552080095

From vromero at openjdk.org  Thu Apr  4 17:05:05 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Apr 2024 17:05:05 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
Message-ID: <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>

On Thu, 28 Mar 2024 14:08:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 133:

> 131:      */
> 132:     @PreviewFeature(feature=PreviewFeature.Feature.DERIVED_RECORD_CREATION, reflective=true)
> 133:     COMPONENT_LOCAL_VARIABLE;

I wonder if we can't just use: LOCAL_VARIABLE

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2235:

> 2233:             }
> 2234:             sym.adr = nextadr;
> 2235:             vars[nextadr] = sym;

could we use a record here? these two arrays seem to be in sync

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 1364:

> 1362: 
> 1363:     @Override
> 1364:     public void visitDerivedInstance(JCDerivedInstance tree) {

I was expecting this code to belong to Lower, not saying that it is wrong here though but probably more naturally in Lower I think

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1574:

> 1572:             @Override
> 1573:             public void visitDerivedInstance(JCDerivedInstance tree) {
> 1574:                 hasPatterns |= true;

it could be thought as a pattern but it is not a pattern nor it is internally converted to a pattern, unless I'm missing something

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1550678834
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1552065329
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1552076515
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1552088772

From mchhipa at openjdk.org  Thu Apr  4 17:16:22 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 4 Apr 2024 17:16:22 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags [v2]
In-Reply-To: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
Message-ID: <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>

> Updated following tests to use ProcessTools methods:
>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>  test/jdk/javax/naming/spi/providers/InitialContextTest.java

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

  Implemented review comments.
  Updated EscapePath test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18602/files
  - new: https://git.openjdk.org/jdk/pull/18602/files/95605aaf..04a35331

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18602&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18602&range=00-01

  Stats: 31 lines in 2 files changed: 19 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18602.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18602/head:pull/18602

PR: https://git.openjdk.org/jdk/pull/18602

From mchhipa at openjdk.org  Thu Apr  4 17:16:22 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 4 Apr 2024 17:16:22 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags [v2]
In-Reply-To: <r1DEQ_j7jXBsCnrkNhKiX1jWMNobGLPkE_srpEODhOM=.e1dc7d43-28f3-4ff6-995e-ba3f3e2b30a4@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <r1DEQ_j7jXBsCnrkNhKiX1jWMNobGLPkE_srpEODhOM=.e1dc7d43-28f3-4ff6-995e-ba3f3e2b30a4@github.com>
Message-ID: <7hOchtLADHc-kCrKUh3bUEE5NpD-BoNdqooHC-qZ6EU=.fccce0ea-c9b8-42e7-a199-3d1a4d2cb74c@github.com>

On Wed, 3 Apr 2024 20:08:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>>   Updated EscapePath test.
>
> test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java line 71:
> 
>> 69:         // Run tests
>> 70:         Path launcher = outputPath.resolve("bin").resolve("java");
>> 71:         OutputAnalyzer analyzer =  ProcessTools.executeCommand(launcher.toAbsolutePath().toString(),"-ea", "-esa", "HijrahConfigCheck");
> 
> Nit: need a space before `"-ea"`

Thanks, updated in next commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1552108497

From mchhipa at openjdk.org  Thu Apr  4 17:20:00 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 4 Apr 2024 17:20:00 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags [v2]
In-Reply-To: <r1DEQ_j7jXBsCnrkNhKiX1jWMNobGLPkE_srpEODhOM=.e1dc7d43-28f3-4ff6-995e-ba3f3e2b30a4@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <r1DEQ_j7jXBsCnrkNhKiX1jWMNobGLPkE_srpEODhOM=.e1dc7d43-28f3-4ff6-995e-ba3f3e2b30a4@github.com>
Message-ID: <q114jUPkKwgYDVGgTlLMlbPSQwuiURjTItHfnwxNViw=.728f4a81-be89-4b1f-bde1-82e768199881@github.com>

On Wed, 3 Apr 2024 20:08:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>>   Updated EscapePath test.
>
> test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java line 72:
> 
>> 70:         Path launcher = outputPath.resolve("bin").resolve("java");
>> 71:         OutputAnalyzer analyzer =  ProcessTools.executeCommand(launcher.toAbsolutePath().toString(),"-ea", "-esa", "HijrahConfigCheck");
>> 72:         analyzer.shouldHaveExitValue(0);
> 
> The variable `analyzer` may not be needed

Yes, I left it to improve readability.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1552113345

From sgehwolf at openjdk.org  Thu Apr  4 17:21:03 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Apr 2024 17:21:03 GMT
Subject: RFR: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
In-Reply-To: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
References: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
Message-ID: <3gyWNGg79z-yC-qhPUTNpAE-EtMOQh15mzdSDe_CLQ4=.2c81699b-bc78-4825-96f1-66584332af18@github.com>

On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is a draft PR with a potential solution to 8328366 without regressing 8327501.
> 
> @DougLea To avoid regressions in the future, where would regression tests for this ideally be located?

FWIW, I've tested this with the quarkus reproducer and a reproducer for the class load leak. They seem both to work with this patch.

Please be sure to mention the bug for the ThreadLocal follow-up. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18374#issuecomment-2037767866

From mchung at openjdk.org  Thu Apr  4 17:51:14 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 4 Apr 2024 17:51:14 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v10]
In-Reply-To: <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
Message-ID: <nlBPAVHRz8Mnu_bYSqasASiITBYCwHN2FCoDQDd74bw=.55b92878-f3b5-473e-8f0a-f4cfc8894c49@github.com>

On Thu, 4 Apr 2024 11:13:43 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add jtreg test case

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 47:

> 45:     * If loading of the given library name with ".so" suffix fails, it will attempt to load the library of
> 46:     * the same name with ".a" suffix as the alternate name.
> 47:     * This method simply returns null.  It could implement the alternate name converting ".so" with ".a" suffix but redundant.

Formatting nit: please wrap the comment with approx same width (~80 column).  Same for line 37-39.

test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java line 28:

> 26:  * @bug 8319516
> 27:  * @requires os.family == "aix"
> 28:  * @run  main/native/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX

Suggestion:

 * @run  main/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX


This test does not build native library.  I think it does not need "main/native"

test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java line 31:

> 29:  */
> 30: 
> 31: public class LoadLibraryTestAIX {

what about `LoadAIXLibraryFromArchiveObject`?

test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java line 33:

> 31: public class LoadLibraryTestAIX {
> 32:     public static void main(String[] args) throws Exception {
> 33:         String libraryName="perfstat";

Suggestion:

        String libraryName = "perfstat";

test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java line 38:

> 36:         } catch (Exception e) {
> 37:             throw new RuntimeException("LoadLibraryTestAIX : could not load libperfstat.a"+e);
> 38:         }

Nit: the catch clause is not strictly needed.   `UnsatisfiedLinkError` is an unchecked exception.   The test should fail if you run it with JDK without this fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1552158568
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1552146115
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1552145197
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1552135081
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1552137303

From mchung at openjdk.org  Thu Apr  4 17:51:14 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 4 Apr 2024 17:51:14 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v10]
In-Reply-To: <nlBPAVHRz8Mnu_bYSqasASiITBYCwHN2FCoDQDd74bw=.55b92878-f3b5-473e-8f0a-f4cfc8894c49@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
 <nlBPAVHRz8Mnu_bYSqasASiITBYCwHN2FCoDQDd74bw=.55b92878-f3b5-473e-8f0a-f4cfc8894c49@github.com>
Message-ID: <PMsuXLAuHBDn0pZae8GVRM-_gfj9czqpKA-lGLEzZ1c=.fc747644-bd5e-496d-bc78-615dd3a8db4b@github.com>

On Thu, 4 Apr 2024 17:35:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add jtreg test case
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java line 38:
> 
>> 36:         } catch (Exception e) {
>> 37:             throw new RuntimeException("LoadLibraryTestAIX : could not load libperfstat.a"+e);
>> 38:         }
> 
> Nit: the catch clause is not strictly needed.   `UnsatisfiedLinkError` is an unchecked exception.   The test should fail if you run it with JDK without this fix.

The test should verify if `/usr/lib/libperstat.a` is present and also `/usr/lib/libperfstat.so` is not present.

Do you expect all AIX machines do not have `/usr/lib/libperfstat.so`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1552140344

From alanb at openjdk.org  Thu Apr  4 18:10:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Apr 2024 18:10:09 GMT
Subject: RFR: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
In-Reply-To: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
References: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
Message-ID: <Crr1WCgE1Ve5lcEADao88zlvng5NzcvwSaboyst9qn0=.bfdf544d-c49e-45fc-b7d5-4bc82cb2c581@github.com>

On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is a draft PR with a potential solution to 8328366 without regressing 8327501.
> 
> @DougLea To avoid regressions in the future, where would regression tests for this ideally be located?

The change looks okay. It's unfortunate we didn't catch this but you've added a test. As a general point, I hope these tasks that are running in the common pool (or any thread pool for that matter) are resetting the TCCL before they complete.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18374#pullrequestreview-1980782195

From vklang at openjdk.org  Thu Apr  4 18:31:10 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 4 Apr 2024 18:31:10 GMT
Subject: RFR: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
In-Reply-To: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
References: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
Message-ID: <V16X2IPOzw_dfPQNwhKHgRJD5NvH4XV_WN0ptq6fChY=.e9dfbe07-c624-4f14-9d60-4e066a3e2c2b@github.com>

On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is a draft PR with a potential solution to 8328366 without regressing 8327501.
> 
> @DougLea To avoid regressions in the future, where would regression tests for this ideally be located?

Follow-up issue regarding the clearing of the Thread Locals here: https://bugs.openjdk.org/browse/JDK-8329701

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

PR Comment: https://git.openjdk.org/jdk/pull/18374#issuecomment-2037904241

From vklang at openjdk.org  Thu Apr  4 18:36:12 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 4 Apr 2024 18:36:12 GMT
Subject: Integrated: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
In-Reply-To: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
References: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>
Message-ID: <1dC9nZHeyQkVqwMOwSf1wBqCgLOElv_jrZnGSM9u8LQ=.ee80fcac-6000-4f95-af3a-cdf4f7e2586d@github.com>

On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is a draft PR with a potential solution to 8328366 without regressing 8327501.
> 
> @DougLea To avoid regressions in the future, where would regression tests for this ideally be located?

This pull request has now been integrated.

Changeset: 28216aa9
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28216aa971ea65938117107542152abd532a5384
Stats:     14 lines in 2 files changed: 8 ins; 5 del; 1 mod

8328366: Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501

Reviewed-by: mchung, alanb

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

PR: https://git.openjdk.org/jdk/pull/18374

From sgibbons at openjdk.org  Thu Apr  4 19:06:10 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 4 Apr 2024 19:06:10 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <4ECS4yQ0YXQVSt352CQhkQ4dax4VBYv6ZXzK9eBIio0=.baabfef1-2b9e-4b2f-ba0f-e358f6a83af1@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
 <4ECS4yQ0YXQVSt352CQhkQ4dax4VBYv6ZXzK9eBIio0=.baabfef1-2b9e-4b2f-ba0f-e358f6a83af1@github.com>
Message-ID: <qwKqHrvc3B1_WhXjqku-Mne11dpqxh5TXLNyASekO44=.c9193513-cebc-4048-9646-1584d41e9353@github.com>

On Tue, 2 Apr 2024 08:09:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Wouldn't it be better to do this intrinsification directly in the JIT without calling out to a stub?

I believe the code size is too large for a direct JIT intrinsic.  A lot of registers are also used, which may be an issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2037992868

From sgibbons at openjdk.org  Thu Apr  4 19:06:11 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 4 Apr 2024 19:06:11 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <MFXU-XkLXbcoiQBKpOe01HTfNH_5mW471a6VENQKBxA=.02f372cb-6c09-483a-bf44-772dcbdd2047@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
 <MFXU-XkLXbcoiQBKpOe01HTfNH_5mW471a6VENQKBxA=.02f372cb-6c09-483a-bf44-772dcbdd2047@github.com>
Message-ID: <fY7iQHcNjrIiAwTBRLPBUAyCM0hFUEvHHW1pl329wsE=.64b51f03-fe40-4210-9881-05a52b9064fd@github.com>

On Tue, 2 Apr 2024 02:16:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use non-sse fill (old left in)
>
> This looks like it is still a Draft/work-in-progress. There is only code for x64 and it doesn't appear it will build on other platforms. Also there are still a bunch of `if 0` in the code that should not be there.

@dholmes-ora Sorry for the dead code left in.  It is gone now.  Plus, this was only requested for x86, thus no implementation for other platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2037994898

From bchristi at openjdk.org  Thu Apr  4 19:29:38 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 4 Apr 2024 19:29:38 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v21]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <n36HU1-dhs9iC5aedbTW2eym18qOOCDeg04zuE2mDNA=.ee9790cc-0f36-40fc-9eb5-c846f8d5dd80@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

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

  small reformat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/170c9814..bdac5cce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=19-20

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

PR: https://git.openjdk.org/jdk/pull/16644

From naoto at openjdk.org  Thu Apr  4 19:43:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Apr 2024 19:43:09 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags [v2]
In-Reply-To: <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
Message-ID: <I9dmFRDQLigy9Yo53DYOi_ISvdzwXPkow_7zjGNxfs4=.be029e27-2725-4043-aa64-819e515f02ec@github.com>

On Thu, 4 Apr 2024 17:16:22 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Updated following tests to use ProcessTools methods:
>>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>>  test/jdk/javax/naming/spi/providers/InitialContextTest.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.
>   Updated EscapePath test.

Looks good. Please have reviews from other areas.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18602#pullrequestreview-1980982474

From ruppel.julian at gmail.com  Thu Apr  4 20:29:11 2024
From: ruppel.julian at gmail.com (Julian Ruppel)
Date: Thu, 4 Apr 2024 22:29:11 +0200
Subject: Method references in annotations
In-Reply-To: <856EB4DE-2868-4E0E-851F-D0F4F3740EBF@oracle.com>
References: <CAKf0hViPE71HvbEk73Hojyf_CoaCy-6Dpf6AUR63w4xBrVghCw@mail.gmail.com>
 <856EB4DE-2868-4E0E-851F-D0F4F3740EBF@oracle.com>
Message-ID: <CAKf0hVjorwzmpk0No0UiCWmooh04g4pBbHg7GLnY-jjHafv7UQ@mail.gmail.com>

I want to kindly check if there are some news regarding the cost/benefit
ratio and prioritization. Any updates that I missed?

Best
Julian

Am Di., 13. Nov. 2018 um 15:26 Uhr schrieb Brian Goetz <
brian.goetz at oracle.com>:

> The story here is: we?ve completed our analysis on the feature, and
> concluded that the feature is sound (many such features don?t survive this
> cut.)  But, there is actually quite a bit of work needed in the underlying
> infrastructure to implement it, largely having to do with annotation
> processing in the VM, and reflection.  As a result, the amount of work went
> up, which pushed its cost/benefit ratio down.  It is still on the list, but
> hasn?t been prioritized.
>
> If someone with VM and reflection skills wanted to step up and help
> implement it, that might move the balance back in the other direction.
>
> > On Nov 7, 2018, at 8:17 PM, Julian Ruppel <ruppel.julian at gmail.com>
> wrote:
> >
> > Hi,
> >
> > being aware that there has been a discussion quite some time ago (
> >
> http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003768.html)
> > I wanted to come up again with this topic as this feature would be
> > beneficial especially for framework developers who wants to appoint
> > behaviour to annotations.
> >
> > The following snippet shows what I want to vote for.
> >
> > @MyAnnotation(method = MyClass::myMethod)private String myVariable;
> >
> > This would be far more type-safe compared to using string literals to
> find
> > the method via reflection.
> >
> >
> > - Julian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240404/0826e064/attachment.htm>

From jlahoda at openjdk.org  Thu Apr  4 20:30:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 20:30:00 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
Message-ID: <o7ijrPPLmzq7LdxFWnecxPa-uJIB-9K-3FRTM3qGl2Q=.12a9d5ec-64e6-40e3-b518-632c68e84dc8@github.com>

On Thu, 4 Apr 2024 00:37:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 133:
> 
>> 131:      */
>> 132:     @PreviewFeature(feature=PreviewFeature.Feature.DERIVED_RECORD_CREATION, reflective=true)
>> 133:     COMPONENT_LOCAL_VARIABLE;
> 
> I wonder if we can't just use: LOCAL_VARIABLE

We could, and I was thinking of that. But, then I decided to go with a new kind, as I think it matches better the overall design of the Elements/Kinds. E.g. we have existing `EXCEPTION_PARAMETER` (used in `catch`) or `BINDING_VARIABLE`, rather than using `LOCAL_VARIABLE` for them.

(Also, many of these variable kinds have some small, but significant differences in semantics from `LOCAL_VARIABLE` - e.g. some are never blank/are always definitely assigned.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1552385305

From ihse at openjdk.org  Thu Apr  4 20:59:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 4 Apr 2024 20:59:09 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
Message-ID: <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>

On Thu, 4 Apr 2024 16:46:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shorter name for the build tool
>  - Review feedback from Erik J.
>  - Remove dependency on CDS which isn't needed anymore

Overall, I think the build system changes in the current revision of the patch look good, but please let me know for a deeper review when things have stabilized.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 165:

> 163: 
> 164: runtime.link.info=Linking based on the current run-time image.
> 165: runtime.link.jprt.path.extra=(run-time image)

Missing newline at last line.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2038205036
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1552425957

From ihse at openjdk.org  Thu Apr  4 20:59:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 4 Apr 2024 20:59:10 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <4NcIbddx8UZky7IIR9XW0yRFXAARqA1HQyeH1eejk20=.e60906ea-8a4b-4932-99f9-0fb9e4ca0ca7@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
 <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
 <T-Myy48CM4UbBFHTmzCt8d-SPgFmyX_R3ZV9NYorgDg=.0b8b4d06-930f-417f-9e3e-0dd789d57dca@github.com>
 <4NcIbddx8UZky7IIR9XW0yRFXAARqA1HQyeH1eejk20=.e60906ea-8a4b-4932-99f9-0fb9e4ca0ca7@github.com>
Message-ID: <BvaS42vvrMTpIda6eWgRnemKpHwYGDMp3ui5t176XKw=.b7d676b6-6694-42d5-9f48-39867ff219da@github.com>

On Thu, 4 Apr 2024 15:38:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> FYI: This was trying to address a comment from @magicus https://github.com/openjdk/jdk/pull/14787#discussion_r1514894494 Happy to not follow that convention and/or rename the tool.
>
> I was not aware of such a convention and I can't say I agree with it. It just seems redundant and unnecessary, but I suppose we should wait for Magnus to respond.

Just to clarify: I did not say the name needed to be long, just that many (if not all) tools has used the convention of using the package name `build.tools.<toolname>` and the class name `<ToolName>.java`. 

I think the new name sounds ? .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1552430689

From duke at openjdk.org  Thu Apr  4 22:17:33 2024
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 4 Apr 2024 22:17:33 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v7]
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <gmI4eExOapsFiXpbevIZd_b8MrqyH-eKs2m1dqXg93w=.06e8abe9-32c0-44be-9762-35fd1476a88b@github.com>

> Add notes for `HashMap::putAll()` conservative resizing.
> 
> Note: everything below this line is from the original change. After discussion, we decided to keep the conservative resizing, but we should add an `@implNote` for the decision.
> 
> ---
> 
> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
> 
> ---
> 
> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
> 
> Before change:
> 
> 
> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       87...

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

  Use @link for javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17544/files
  - new: https://git.openjdk.org/jdk/pull/17544/files/030f7d50..8db9e125

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/17544

From duke at openjdk.org  Thu Apr  4 22:21:09 2024
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 4 Apr 2024 22:21:09 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v7]
In-Reply-To: <gmI4eExOapsFiXpbevIZd_b8MrqyH-eKs2m1dqXg93w=.06e8abe9-32c0-44be-9762-35fd1476a88b@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <gmI4eExOapsFiXpbevIZd_b8MrqyH-eKs2m1dqXg93w=.06e8abe9-32c0-44be-9762-35fd1476a88b@github.com>
Message-ID: <aFMQBLyS9_PFhMZS2T6GxvLK0wtM15-ICqZaehliQiw=.62e8cfd3-d8cd-4755-a853-9d1792fdd757@github.com>

On Thu, 4 Apr 2024 22:17:33 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> Add notes for `HashMap::putAll()` conservative resizing.
>> 
>> Note: everything below this line is from the original change. After discussion, we decided to keep the conservative resizing, but we should add an `@implNote` for the decision.
>> 
>> ---
>> 
>> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
>> 
>> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
>> 
>> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
>> 
>> 
>> Before change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
>> 
>> 
>> After change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
>> 
>> 
>> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
>> 
>> ---
>> 
>> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
>> 
>> Before change:
>> 
>> 
>> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
>> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
>> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
>> HashM...
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use @link for javadoc

I tried looking at the docs with `make docs-image`, but I can't test that the syntax/links are actually correct because `@implNote` does not actually show up in the web pages. As I understand from [the original proposal](https://mail.openjdk.org/pipermail/lambda-libs-spec-experts/2013-January/001211.html), `@implNote` is there to help to developer understand implementation, and is not intended to be exposed in the web docs.

This seems like information that would be useful to the consumer. So maybe we can consider moving this into the main comment block?

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-2038341734

From dholmes at openjdk.org  Fri Apr  5 01:14:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Apr 2024 01:14:15 GMT
Subject: RFR: 8329596: Add test for virtual threads invoking synchronized
 native methods
In-Reply-To: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
References: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
Message-ID: <zhB-GMfI0v_a8ibVDJ2SG5yYGIuJLqZBPXxli3W7DZc=.0d226268-b847-4a6d-8342-75e362631682@github.com>

On Wed, 3 Apr 2024 10:52:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only addition to add a test for virtual threads invoking a synchronized native method and invoking a native method that enter/exits a monitor with JNI MonitorEnter/MonitorExit. The test has been in the loom repo for some time, it can move to the main line in advance of changes to the object monitor implementation.

test/jdk/java/lang/Thread/virtual/libSynchronizedNative.c line 29:

> 27: Java_SynchronizedNative_runWithSynchronizedNative(JNIEnv *env, jobject obj, jobject task) {
> 28:     jclass clazz = (*env)->GetObjectClass(env, obj);
> 29:     jmethodID mid = (*env)->GetMethodID(env, clazz, "run", "(Ljava/lang/Runnable;)V");

Does this generate a warning with `-Xcheck:jni` due to exceptions not being checked for?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18600#discussion_r1552648444

From dlong at openjdk.org  Fri Apr  5 02:43:04 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 5 Apr 2024 02:43:04 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v4]
In-Reply-To: <zaaY3TupJSFFwIkLPI9GHQvPnT1-rev4AuP2_rqO3aM=.8ba12ab3-b288-4558-b1b9-ade436f8e896@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <zaaY3TupJSFFwIkLPI9GHQvPnT1-rev4AuP2_rqO3aM=.8ba12ab3-b288-4558-b1b9-ade436f8e896@github.com>
Message-ID: <tBmcxcgnfC4Pq_GP93yFAe6W4bsI72i-IPK8htuIoG0=.cd3b62a0-fdcb-49dc-a103-ce217075428b@github.com>

On Wed, 3 Apr 2024 15:15:24 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Windows

I think the right approach is to turn it into a loop in the IR, which I think is what Doug was implying.  That way C2 can do all its usual optimizations, like unrolling, vectorization, and redundant store elimination (if it is an on-heap primitive array that was just allocated, then there is no need to zero the parts that are being "set").

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

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-1981533209

From duke at openjdk.org  Fri Apr  5 04:02:13 2024
From: duke at openjdk.org (mjustin)
Date: Fri, 5 Apr 2024 04:02:13 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false
In-Reply-To: <hXZ-RGqpw_V3OHnQ_CMkxhJzJqxYzCBdDLWhHxf2cpU=.cc5f1ba4-91ed-4bff-a0a9-2b3c2eb096ee@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
 <hXZ-RGqpw_V3OHnQ_CMkxhJzJqxYzCBdDLWhHxf2cpU=.cc5f1ba4-91ed-4bff-a0a9-2b3c2eb096ee@github.com>
Message-ID: <BGyuLE1V1vdvbr71ltkrtjY0VTjtvEhQtS1Tb6Yy51E=.e200dbfb-9d5b-4b53-a037-6362e1c1d70b@github.com>

On Mon, 18 Mar 2024 16:27:58 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Just a note to self, consider if this should get backported to 22 or not.

Have you decided whether this will be backported to 22?

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

PR Comment: https://git.openjdk.org/jdk/pull/18351#issuecomment-2030716799

From dholmes at openjdk.org  Fri Apr  5 05:04:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Apr 2024 05:04:03 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]
In-Reply-To: <MFXU-XkLXbcoiQBKpOe01HTfNH_5mW471a6VENQKBxA=.02f372cb-6c09-483a-bf44-772dcbdd2047@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <MZQImkt1i6H7vowSu_AZJ35iLJDjx4W76IjTitFGpws=.f018cfdb-2930-47ef-9e5c-f23d32bf2eb2@github.com>
 <MFXU-XkLXbcoiQBKpOe01HTfNH_5mW471a6VENQKBxA=.02f372cb-6c09-483a-bf44-772dcbdd2047@github.com>
Message-ID: <NkN7ckZ3ttBwGFKBBsBpJlzmKjnbiR7CpSY8nbYfK3U=.711e9871-cf1a-45cb-8b19-4b8a4f6c51ce@github.com>

On Tue, 2 Apr 2024 02:16:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use non-sse fill (old left in)
>
> This looks like it is still a Draft/work-in-progress. There is only code for x64 and it doesn't appear it will build on other platforms. Also there are still a bunch of `if 0` in the code that should not be there.

> @dholmes-ora Sorry for the dead code left in. It is gone now. Plus, this was only requested for x86, thus no implementation for other platforms.

Only requested by whom? The JBS issue says nothing about that.

I'm not even sure how this avoids the  `CheckIntrinsics` check for missing intrinsics ... I guess it must only look for some kind of declaration not an actual implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2038941462

From darcy at openjdk.org  Fri Apr  5 05:08:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 05:08:15 GMT
Subject: Integrated: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <QQr-PzBcisQrDf876CQaOZ04DlvtNKbKqZK9Pqo4wJA=.7e93e411-3414-48e8-bcc1-b277575e4461@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

This pull request has now been integrated.

Changeset: 5860a48c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5860a48c71e324f77a7ecc613c063cbb81580011
Stats:     745 lines in 12 files changed: 735 ins; 0 del; 10 mod

8329624: Add visitors for preview language features

Reviewed-by: vromero, jlahoda

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

PR: https://git.openjdk.org/jdk/pull/18609

From alanb at openjdk.org  Fri Apr  5 05:20:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Apr 2024 05:20:09 GMT
Subject: RFR: 8329596: Add test for virtual threads invoking synchronized
 native methods
In-Reply-To: <zhB-GMfI0v_a8ibVDJ2SG5yYGIuJLqZBPXxli3W7DZc=.0d226268-b847-4a6d-8342-75e362631682@github.com>
References: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
 <zhB-GMfI0v_a8ibVDJ2SG5yYGIuJLqZBPXxli3W7DZc=.0d226268-b847-4a6d-8342-75e362631682@github.com>
Message-ID: <w-KPNtE0eFUHfDVMRKXVge57HL98cRU194TYQZ2Jsy8=.990c436c-51f5-46c5-a509-ca586ef10f58@github.com>

On Fri, 5 Apr 2024 01:11:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Does this generate a warning with `-Xcheck:jni` due to exceptions not being checked for?

I run with`TEST_OPTS_JAVA_OPTIONS=-Xcheck:jni` and don't see any warnings. Are you asking about the usage of GetObjectClass (which is not documented to throw) or GetMethodID (the check for the jmethodID of NULL is at L30). Or maybe you are saying that GetMethodID can return a jmethodID with a pending exception?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18600#discussion_r1552938067

From dholmes at openjdk.org  Fri Apr  5 05:43:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Apr 2024 05:43:08 GMT
Subject: RFR: 8329596: Add test for virtual threads invoking synchronized
 native methods
In-Reply-To: <w-KPNtE0eFUHfDVMRKXVge57HL98cRU194TYQZ2Jsy8=.990c436c-51f5-46c5-a509-ca586ef10f58@github.com>
References: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
 <zhB-GMfI0v_a8ibVDJ2SG5yYGIuJLqZBPXxli3W7DZc=.0d226268-b847-4a6d-8342-75e362631682@github.com>
 <w-KPNtE0eFUHfDVMRKXVge57HL98cRU194TYQZ2Jsy8=.990c436c-51f5-46c5-a509-ca586ef10f58@github.com>
Message-ID: <5m9oxnDwOtM45S7Z_msb1fL68EqHLHzqWTioDRo0L88=.5c35062f-7473-455b-ba28-b2e37e1edeb8@github.com>

On Fri, 5 Apr 2024 05:17:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/libSynchronizedNative.c line 29:
>> 
>>> 27: Java_SynchronizedNative_runWithSynchronizedNative(JNIEnv *env, jobject obj, jobject task) {
>>> 28:     jclass clazz = (*env)->GetObjectClass(env, obj);
>>> 29:     jmethodID mid = (*env)->GetMethodID(env, clazz, "run", "(Ljava/lang/Runnable;)V");
>> 
>> Does this generate a warning with `-Xcheck:jni` due to exceptions not being checked for?
>
>> Does this generate a warning with `-Xcheck:jni` due to exceptions not being checked for?
> 
> I run with`TEST_OPTS_JAVA_OPTIONS=-Xcheck:jni` and don't see any warnings. Are you asking about the usage of GetObjectClass (which is not documented to throw) or GetMethodID (the check for the jmethodID of NULL is at L30). Or maybe you are saying that GetMethodID can return a jmethodID with a pending exception?

Sorry I was thinking `GetObjectClass` could throw, but it can't.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18600#discussion_r1552955426

From dlong at openjdk.org  Fri Apr  5 05:49:10 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 5 Apr 2024 05:49:10 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v4]
In-Reply-To: <zaaY3TupJSFFwIkLPI9GHQvPnT1-rev4AuP2_rqO3aM=.8ba12ab3-b288-4558-b1b9-ade436f8e896@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <zaaY3TupJSFFwIkLPI9GHQvPnT1-rev4AuP2_rqO3aM=.8ba12ab3-b288-4558-b1b9-ade436f8e896@github.com>
Message-ID: <r2t6ghBKI0T45seZ_al1-fc4ETql1PpG_y_bnwktMVo=.363a64b8-a363-4980-b85e-bfdf3c0ffab3@github.com>

On Wed, 3 Apr 2024 15:15:24 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Windows

As an experiment, couldn't you have the C2 intrinsic redirect to a Java helper that calls putByte() in a loop?

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2038994043

From pminborg at openjdk.org  Fri Apr  5 07:41:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 5 Apr 2024 07:41:13 GMT
Subject: Integrated: JDK-8329089: Empty immutable list throws the wrong
 exception type for remove(first | last) operations
In-Reply-To: <VqsB3uxDN8_H2wgkRz56gdTz5Ot1i5zOD3KlgjtR8FA=.74bfc834-647c-4cf7-bd60-5b846f780f06@github.com>
References: <VqsB3uxDN8_H2wgkRz56gdTz5Ot1i5zOD3KlgjtR8FA=.74bfc834-647c-4cf7-bd60-5b846f780f06@github.com>
Message-ID: <PmyBo43l4wZVBMjW-Lv46BaoRVvT9ztaMb3Ks6gW2ww=.c11c59d1-5331-4775-a64e-29c9694aec0d@github.com>

On Tue, 2 Apr 2024 10:37:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to make empty immutable lists always throw UOE on `removeFirst` and `removeLast`.

This pull request has now been integrated.

Changeset: b71acc70
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b71acc704a13b816621b9db65b4c5107f2ae032f
Stats:     9 lines in 2 files changed: 9 ins; 0 del; 0 mod

8329089: Empty immutable list throws the wrong exception type for remove(first | last) operations

Reviewed-by: rriggs

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

PR: https://git.openjdk.org/jdk/pull/18581

From sroy at openjdk.org  Fri Apr  5 08:11:04 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 5 Apr 2024 08:11:04 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v10]
In-Reply-To: <PMsuXLAuHBDn0pZae8GVRM-_gfj9czqpKA-lGLEzZ1c=.fc747644-bd5e-496d-bc78-615dd3a8db4b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
 <nlBPAVHRz8Mnu_bYSqasASiITBYCwHN2FCoDQDd74bw=.55b92878-f3b5-473e-8f0a-f4cfc8894c49@github.com>
 <PMsuXLAuHBDn0pZae8GVRM-_gfj9czqpKA-lGLEzZ1c=.fc747644-bd5e-496d-bc78-615dd3a8db4b@github.com>
Message-ID: <i9S2EIS6Y5PW2OqbgYry8tcq-dzNrH4sdclX6BiNA7I=.175c2aaa-9e21-46c5-92e8-097c3838cd44@github.com>

On Thu, 4 Apr 2024 17:38:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java line 38:
>> 
>>> 36:         } catch (Exception e) {
>>> 37:             throw new RuntimeException("LoadLibraryTestAIX : could not load libperfstat.a"+e);
>>> 38:         }
>> 
>> Nit: the catch clause is not strictly needed.   `UnsatisfiedLinkError` is an unchecked exception.   The test should fail if you run it with JDK without this fix.
>
> The test should verify if `/usr/lib/libperstat.a` is present and also `/usr/lib/libperfstat.so` is not present.
> 
> Do you expect all AIX machines do not have `/usr/lib/libperfstat.so`?

Yes it is expected.  the hotspot code has harcoded it to .a file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1553156812

From sgehwolf at openjdk.org  Fri Apr  5 08:58:16 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 5 Apr 2024 08:58:16 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <BvaS42vvrMTpIda6eWgRnemKpHwYGDMp3ui5t176XKw=.b7d676b6-6694-42d5-9f48-39867ff219da@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
 <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
 <T-Myy48CM4UbBFHTmzCt8d-SPgFmyX_R3ZV9NYorgDg=.0b8b4d06-930f-417f-9e3e-0dd789d57dca@github.com>
 <4NcIbddx8UZky7IIR9XW0yRFXAARqA1HQyeH1eejk20=.e60906ea-8a4b-4932-99f9-0fb9e4ca0ca7@github.com>
 <BvaS42vvrMTpIda6eWgRnemKpHwYGDMp3ui5t176XKw=.b7d676b6-6694-42d5-9f48-39867ff219da@github.com>
Message-ID: <0c6Kwv_iDi97U1H1jtBktZjgo2a6lC-WCT17TFBQm1g=.da11a706-3c9f-4e55-bf6f-b9afa3d28952@github.com>

On Thu, 4 Apr 2024 20:56:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I was not aware of such a convention and I can't say I agree with it. It just seems redundant and unnecessary, but I suppose we should wait for Magnus to respond.
>
> Just to clarify: I did not say the name needed to be long, just that many (if not all) tools has used the convention of using the package name `build.tools.<toolname>` and the class name `<ToolName>.java`. 
> 
> I think the new name sounds ? .

Thanks. Yes, the long name was my doing. Sorry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1553173105

From sroy at openjdk.org  Fri Apr  5 08:58:34 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 5 Apr 2024 08:58:34 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v11]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <QkrtkjA1tvz6BmnX9mnfD76YKE5EfzQtxEKUYLjsy6k=.ff1ed2b7-5786-4a2c-9e93-c797acc12aec@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 - spaces
 - nits and move file to aix directory

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/0f6641fb..5f05e278

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=09-10

  Stats: 82 lines in 3 files changed: 38 ins; 40 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From jbhateja at openjdk.org  Fri Apr  5 09:20:10 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 5 Apr 2024 09:20:10 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
Message-ID: <YwzqZOEDfuKsay4D10uJVN77llZhRvIZxRApbPiAHz8=.a9e83ea8-7e18-437b-bc2d-3e2759558a25@github.com>

On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove use of jdk.crypto.ec

Few early comments.

Please update the copyright year of all the modified files.

You can even consider splitting this into two patches, Java side changes in one and  x86 optimized intrinsic in next one.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 39:

> 37: };
> 38: static address modulus_p256() {
> 39:   return (address)MODULUS_P256;

Long constants should have UL suffix.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 386:

> 384:   __ jcc(Assembler::equal, L_Length19);
> 385: 
> 386:   // Default copy loop

Please add appropriate loop entry alignment.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 394:

> 392:   __ lea(aLimbs, Address(aLimbs,8));
> 393:   __ lea(bLimbs, Address(bLimbs,8));
> 394:   __ jmp(L_DefaultLoop);

Both sub and cmp are flag affecting instructions and are macro-fusible. 
By doing a loop rotation i.e. moving the length <= 0 check outside the loop and pushing the loop exit check at bottom you can save additional compare checks.

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

PR Review: https://git.openjdk.org/jdk/pull/18583#pullrequestreview-1981555803
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1553056633
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1552710600
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1553110376

From ihse at openjdk.org  Fri Apr  5 09:34:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Apr 2024 09:34:19 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <0c6Kwv_iDi97U1H1jtBktZjgo2a6lC-WCT17TFBQm1g=.da11a706-3c9f-4e55-bf6f-b9afa3d28952@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
 <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
 <T-Myy48CM4UbBFHTmzCt8d-SPgFmyX_R3ZV9NYorgDg=.0b8b4d06-930f-417f-9e3e-0dd789d57dca@github.com>
 <4NcIbddx8UZky7IIR9XW0yRFXAARqA1HQyeH1eejk20=.e60906ea-8a4b-4932-99f9-0fb9e4ca0ca7@github.com>
 <BvaS42vvrMTpIda6eWgRnemKpHwYGDMp3ui5t176XKw=.b7d676b6-6694-42d5-9f48-39867ff219da@github.com>
 <0c6Kwv_iDi97U1H1jtBktZjgo2a6lC-WCT17TFBQm1g=.da11a706-3c9f-4e55-bf6f-b9afa3d28952@github.com>
Message-ID: <GoYs3jeYG9mMBwSoRe0KvphscDkEZw-7TEW0dUQ0NrY=.626506bf-3fe5-4624-ab68-c5decc171c6a@github.com>

On Fri, 5 Apr 2024 08:21:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Just to clarify: I did not say the name needed to be long, just that many (if not all) tools has used the convention of using the package name `build.tools.<toolname>` and the class name `<ToolName>.java`. 
>> 
>> I think the new name sounds ? .
>
> Thanks. Yes, the long name was my doing. Sorry.

Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapit?n" prejudice of German. ;-) 



(In Sweden, we have "flaggst?ngsknoppsf?rgyllare" so you are not alone)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1553253017

From sgehwolf at openjdk.org  Fri Apr  5 09:34:20 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 5 Apr 2024 09:34:20 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <GoYs3jeYG9mMBwSoRe0KvphscDkEZw-7TEW0dUQ0NrY=.626506bf-3fe5-4624-ab68-c5decc171c6a@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
 <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
 <T-Myy48CM4UbBFHTmzCt8d-SPgFmyX_R3ZV9NYorgDg=.0b8b4d06-930f-417f-9e3e-0dd789d57dca@github.com>
 <4NcIbddx8UZky7IIR9XW0yRFXAARqA1HQyeH1eejk20=.e60906ea-8a4b-4932-99f9-0fb9e4ca0ca7@github.com>
 <BvaS42vvrMTpIda6eWgRnemKpHwYGDMp3ui5t176XKw=.b7d676b6-6694-42d5-9f48-39867ff219da@github.com>
 <0c6Kwv_iDi97U1H1jtBktZjgo2a6lC-WCT17TFBQm1g=.da11a706-3c9f-4e55-bf6f-b9afa3d28952@github.com>
 <GoYs3jeYG9mMBwSoRe0KvphscDkEZw-7TEW0dUQ0NrY=.626506bf-3fe5-4624-ab68-c5decc171c6a@github.com>
Message-ID: <8tI50-YtIdOPXzFlbhjmFNGkdK8-Tb6cSRwBmdAypqM=.270ddf3b-8acb-44c1-af71-d1274b29c3b3@github.com>

On Fri, 5 Apr 2024 09:25:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks. Yes, the long name was my doing. Sorry.
>
> Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapit?n" prejudice of German. ;-) 
> 
> 
> 
> (In Sweden, we have "flaggst?ngsknoppsf?rgyllare" so you are not alone)

Hah! My kids just recently informed me about "Donaudampfschiffahrtsgesellschaftskapit?nsm?tzenproductionsst?tte"... or whatever else you can come up with :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1553260930

From adinn at openjdk.org  Fri Apr  5 11:18:16 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Fri, 5 Apr 2024 11:18:16 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v24]
In-Reply-To: <8tI50-YtIdOPXzFlbhjmFNGkdK8-Tb6cSRwBmdAypqM=.270ddf3b-8acb-44c1-af71-d1274b29c3b3@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <oaQO1sn3IF-Z9opitK8rsdM7PQj_uWDR8vPFycQNWl0=.2fa8c794-9fe5-480b-b368-84d5a891f3c0@github.com>
 <14SkXHYJBCXlLvZoRJjvyg3uronlFaxUbM-tsCQURMQ=.8a5bf8d3-7774-4fec-af1a-049f8fc004ab@github.com>
 <T-Myy48CM4UbBFHTmzCt8d-SPgFmyX_R3ZV9NYorgDg=.0b8b4d06-930f-417f-9e3e-0dd789d57dca@github.com>
 <4NcIbddx8UZky7IIR9XW0yRFXAARqA1HQyeH1eejk20=.e60906ea-8a4b-4932-99f9-0fb9e4ca0ca7@github.com>
 <BvaS42vvrMTpIda6eWgRnemKpHwYGDMp3ui5t176XKw=.b7d676b6-6694-42d5-9f48-39867ff219da@github.com>
 <0c6Kwv_iDi97U1H1jtBktZjgo2a6lC-WCT17TFBQm1g=.da11a706-3c9f-4e55-bf6f-b9afa3d28952@github.com>
 <GoYs3jeYG9mMBwSoRe0KvphscDkEZw-7TEW0dUQ0NrY=.626506bf-3fe5-4624-ab68-c5decc171c6a@github.com>
 <8tI50-YtIdOPXzFlbhjmFNGkdK8-Tb6cSRwBmdAypqM=.270ddf3b-8acb-44c1-af71-d1274b29c3b3@github.com>
Message-ID: <71UPW7nwAv56c-Kxn6IAeeDgdktknQbpSWs14sJ9nxM=.260aeb98-eba9-4e79-9729-e65acadc1359@github.com>

On Fri, 5 Apr 2024 09:31:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapit?n" prejudice of German. ;-) 
>> 
>> 
>> 
>> (In Sweden, we have "flaggst?ngsknoppsf?rgyllare" so you are not alone)
>
> Hah! My kids just recently informed me about "Donaudampfschiffahrtsgesellschaftskapit?nsm?tzenproductionsst?tte"... or whatever else you can come up with :)

Hmm, that's nothing. Look up Rhabarberbarbara on YouTube.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1553444805

From jlahoda at openjdk.org  Fri Apr  5 12:35:26 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 12:35:26 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v6]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <czrY9ETJy2yEFJewX4s1zn2IJbHb-YpBnmLExRTgLLg=.b5174e96-5461-4216-96d5-512c9666034f@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

 - Improving the javax.lang.model for component local variables, by darcy.
 - Reflecting review feedback.
 - Merge branch 'master' into wthexp
 - Fixing tests.
 - Adding tests.
 - The var declaration can be any JCTree.
 - Renaming visitReconstruction to visitDerivedInstance as suggested.
 - Fixing support for derived record creation expression in JShell.
 - Removing whitespace
 - Cleanup.
 - ... and 19 more: https://git.openjdk.org/jdk/compare/18c925cd...f9b6c403

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

Changes: https://git.openjdk.org/jdk/pull/18509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=05
  Stats: 1772 lines in 50 files changed: 1687 ins; 20 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

PR: https://git.openjdk.org/jdk/pull/18509

From jlahoda at openjdk.org  Fri Apr  5 12:35:26 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 12:35:26 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
Message-ID: <-5qPp90Gs9kig6Urog31yB80MJ0K9phxs80m4UIB468=.7a67fd90-04f3-42f3-856a-5b3c7795453f@github.com>

On Thu, 4 Apr 2024 16:47:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2235:
> 
>> 2233:             }
>> 2234:             sym.adr = nextadr;
>> 2235:             vars[nextadr] = sym;
> 
> could we use a record here? these two arrays seem to be in sync

Sure, done. Thanks for the comment!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 1364:
> 
>> 1362: 
>> 1363:     @Override
>> 1364:     public void visitDerivedInstance(JCDerivedInstance tree) {
> 
> I was expecting this code to belong to Lower, not saying that it is wrong here though but probably more naturally in Lower I think

Moved to `Lower`. Thanks for the comment!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553545686
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553546716

From jlahoda at openjdk.org  Fri Apr  5 12:40:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 12:40:22 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

  JavaCompiler cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/f9b6c403..c91e87fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/18509

From jlahoda at openjdk.org  Fri Apr  5 12:40:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 12:40:23 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
Message-ID: <VW-FkuTbQzX-wk20ohdHMO1yixVEkUJPYSD2E5K0nUU=.b202e2d0-92c1-46c3-946a-a192b62782b8@github.com>

On Thu, 4 Apr 2024 17:00:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1574:
> 
>> 1572:             @Override
>> 1573:             public void visitDerivedInstance(JCDerivedInstance tree) {
>> 1574:                 hasPatterns |= true;
> 
> it could be thought as a pattern but it is not a pattern nor it is internally converted to a pattern, unless I'm missing something

The main point here is to make not run `TransPatterns` in case the visitor is not performing any work (because loading the class causes some perf tests to regress - we do the same for `LambdaToMethod`). But, as the desugaring was moved to `Lower`, we no longer need to do anything in `JavaCompiler`. Thanks for the comment!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553555861

From mcimadamore at openjdk.org  Fri Apr  5 12:58:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Apr 2024 12:58:10 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <o7ijrPPLmzq7LdxFWnecxPa-uJIB-9K-3FRTM3qGl2Q=.12a9d5ec-64e6-40e3-b518-632c68e84dc8@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
 <o7ijrPPLmzq7LdxFWnecxPa-uJIB-9K-3FRTM3qGl2Q=.12a9d5ec-64e6-40e3-b518-632c68e84dc8@github.com>
Message-ID: <4sL69UCPpTH3iACJsM6NfwJKGkJ7Elc8vMKeGQkjkcI=.24ea7f83-bb52-415c-be43-8a245af29347@github.com>

On Thu, 4 Apr 2024 20:27:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 133:
>> 
>>> 131:      */
>>> 132:     @PreviewFeature(feature=PreviewFeature.Feature.DERIVED_RECORD_CREATION, reflective=true)
>>> 133:     COMPONENT_LOCAL_VARIABLE;
>> 
>> I wonder if we can't just use: LOCAL_VARIABLE
>
> We could, and I was thinking of that. But, then I decided to go with a new kind, as I think it matches better the overall design of the Elements/Kinds. E.g. we have existing `EXCEPTION_PARAMETER` (used in `catch`) or `BINDING_VARIABLE`, rather than using `LOCAL_VARIABLE` for them.
> 
> (Also, many of these variable kinds have some small, but significant differences in semantics from `LOCAL_VARIABLE` - e.g. some are never blank/are always definitely assigned.)

Given the JLS defines "component local variable" I think it makes sense to have a separate kind

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553580520

From mcimadamore at openjdk.org  Fri Apr  5 13:05:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Apr 2024 13:05:10 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
Message-ID: <BSC2pDkRc8mjv_BguuoooIXehNeFdVeTebvAcqVvsmg=.6d25e545-8137-4e86-bde1-56faf4b29a19@github.com>

On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JavaCompiler cleanup

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4913:

> 4911: 
> 4912:     void checkDerivedInstanceBlockStructure(JCDerivedInstance instance) {
> 4913:         new TreeScanner() {

I note that here we don't care about leaving locals declared inside a block in the `seenVariables` after the block ends (e.g. I see no visitBlock). I think that's probably ok, given that every variable has a fresh symbol, so checking against the `seenVariables` set will fail anyway for two variables that have same name, but different scopes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553596699

From mcimadamore at openjdk.org  Fri Apr  5 13:13:03 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Apr 2024 13:13:03 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
Message-ID: <N88cWm47DXisDS82xRXJgAxx7_tLtunbiU-DTOtiJVk=.c5ddae1e-2402-4215-aa2a-092494b348c5@github.com>

On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JavaCompiler cleanup

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2117:

> 2115:          *  position.
> 2116:          */
> 2117:         protected VarAndDeclarationTree[] vars;

So... normally, a `JCVariableDecl` would have a symbol attached, which is how the old code used to work. Is it correct that this change is needed because the `componentLocalVariables` list is a list of symbols and not of JCVariableDecl? Would it be too complex to create a declaration in Attr and save those in the derived creation tree?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4443:

> 4441:     }
> 4442: 
> 4443:     @Override

As usual, I suggest to add some brief comment with the shape of the generated code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553607860
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553608813

From mcimadamore at openjdk.org  Fri Apr  5 13:36:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Apr 2024 13:36:00 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
Message-ID: <dmK3tjutF5mm6goWcidZTFbSYf3oYrkWF4UO3FcRPsQ=.7253bc31-fef4-4a97-baee-fbfd830be56b@github.com>

On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JavaCompiler cleanup

Good job!

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

PR Review: https://git.openjdk.org/jdk/pull/18509#pullrequestreview-1983199416

From simonis at openjdk.org  Fri Apr  5 16:00:11 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 5 Apr 2024 16:00:11 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v7]
In-Reply-To: <aFMQBLyS9_PFhMZS2T6GxvLK0wtM15-ICqZaehliQiw=.62e8cfd3-d8cd-4755-a853-9d1792fdd757@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <gmI4eExOapsFiXpbevIZd_b8MrqyH-eKs2m1dqXg93w=.06e8abe9-32c0-44be-9762-35fd1476a88b@github.com>
 <aFMQBLyS9_PFhMZS2T6GxvLK0wtM15-ICqZaehliQiw=.62e8cfd3-d8cd-4755-a853-9d1792fdd757@github.com>
Message-ID: <9pFkX6iZWYDM9cBUh53VHch45MaKZnmpLkpZxWTDSnk=.4560f9b1-3099-42ef-8357-6e8a5ac35c9d@github.com>

On Thu, 4 Apr 2024 22:18:16 GMT, Joshua Cao <duke at openjdk.org> wrote:

> I tried looking at the docs with `make docs-image`, but I can't test that the syntax/links are actually correct because `@implNote` does not actually show up in the web pages. As I understand from [the original proposal](https://mail.openjdk.org/pipermail/lambda-libs-spec-experts/2013-January/001211.html), `@implNote` is there to help to developer understand implementation, and is not intended to be exposed in the web docs.
> 
> This seems like information that would be useful to the consumer. So maybe we can consider moving this into the main comment block?

@caojoshua the `@implNote` should definitely appear in the public API documentation, if not something is wrong. See for example: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#method-detail

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-2040160049

From mark.reinhold at oracle.com  Fri Apr  5 16:09:11 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Fri, 5 Apr 2024 16:09:11 +0000
Subject: New candidate JEP: 473: Stream Gatherers (Second Preview)
Message-ID: <20240405160741.54C686C6B12@eggemoggin.niobe.net>

https://openjdk.org/jeps/473

  Summary: Enhance the Stream API to support custom intermediate
  operations. This will allow stream pipelines to transform data in ways
  that are not easily achievable with the existing built-in intermediate
  operations. This is a preview API.

- Mark

From bpb at openjdk.org  Fri Apr  5 16:11:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Apr 2024 16:11:12 GMT
Subject: Integrated: 8328183: Minor mistakes in docs of PrintStream.append()
In-Reply-To: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>
References: <1F3rk3B457wKP4A0hIQfDXkrPz9L4AgTp4xIcf9vTWA=.4236afe8-aa60-43ac-b8f1-396961d9b55d@github.com>
Message-ID: <tDnLJJb5X7NHcMsbg8pryU0SXHAjh9IDILsY6kPrzQ4=.70961a64-44d9-45a4-9c3d-ce6a8b4759a3@github.com>

On Wed, 3 Apr 2024 19:01:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `append` for a `null` `CharSequence` parameter and clean up a couple of other typos.

This pull request has now been integrated.

Changeset: 040c9356
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/040c93565c0dff6270911eb9e58d78aa01bbb925
Stats:     17 lines in 5 files changed: 5 ins; 1 del; 11 mod

8328183: Minor mistakes in docs of PrintStream.append()

Reviewed-by: iris, naoto

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

PR: https://git.openjdk.org/jdk/pull/18607

From mchung at openjdk.org  Fri Apr  5 16:21:11 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 16:21:11 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v10]
In-Reply-To: <i9S2EIS6Y5PW2OqbgYry8tcq-dzNrH4sdclX6BiNA7I=.175c2aaa-9e21-46c5-92e8-097c3838cd44@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <aFNuoIA9GTgBjuovS2qNBy915yxN2-AEqIUYZgK8l-I=.28145b6b-3954-46e7-bce4-ac3bcf8505d7@github.com>
 <nlBPAVHRz8Mnu_bYSqasASiITBYCwHN2FCoDQDd74bw=.55b92878-f3b5-473e-8f0a-f4cfc8894c49@github.com>
 <PMsuXLAuHBDn0pZae8GVRM-_gfj9czqpKA-lGLEzZ1c=.fc747644-bd5e-496d-bc78-615dd3a8db4b@github.com>
 <i9S2EIS6Y5PW2OqbgYry8tcq-dzNrH4sdclX6BiNA7I=.175c2aaa-9e21-46c5-92e8-097c3838cd44@github.com>
Message-ID: <9fyKsld7Cwj0HjqHLy_vk61ZBBDPOJC00-UWQyXCb5g=.aee3ebcf-fe80-43e5-958f-e08e363d1338@github.com>

On Fri, 5 Apr 2024 08:08:27 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> The test should verify if `/usr/lib/libperstat.a` is present and also `/usr/lib/libperfstat.so` is not present.
>> 
>> Do you expect all AIX machines do not have `/usr/lib/libperfstat.so`?
>
> Yes it is expected.  the hotspot code has harcoded it to .a file.

In this case, the test can verify if `/usr/lib/libperstat.a` is present and `/usr/lib/libperfstat.so` is not present; otherwise, the test should throw `RuntimeException`.   This also serves a good documentation purpose showing what this test expects.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1553961921

From mchung at openjdk.org  Fri Apr  5 16:21:12 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 16:21:12 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v11]
In-Reply-To: <QkrtkjA1tvz6BmnX9mnfD76YKE5EfzQtxEKUYLjsy6k=.ff1ed2b7-5786-4a2c-9e93-c797acc12aec@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <QkrtkjA1tvz6BmnX9mnfD76YKE5EfzQtxEKUYLjsy6k=.ff1ed2b7-5786-4a2c-9e93-c797acc12aec@github.com>
Message-ID: <l8nBdmH-bLk7WJEIA62GklxgJR5rodQ6fPY0Y59YGbM=.b51f7169-8274-441a-a7a9-be956f9fefb3@github.com>

On Fri, 5 Apr 2024 08:58:34 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - spaces
>  - nits and move file to aix directory

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 28:

> 26:  * @bug 8319516
> 27:  * @requires os.family == "aix"
> 28:  * @run  main/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX

Suggestion:

 * @run main/othervm -Djava.library.path=/usr/lib LoadAIXLibraryFromArchiveObject

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 33:

> 31: public class LoadAIXLibraryFromArchiveObject {
> 32:     public static void main(String[] args) throws Exception {
> 33:         String libraryName = "perfstat";

I suggest to check if `/usr/lib/libperstat.a` is present and `/usr/lib/libperfstat.so` is not present; otherwise, the test should throw RuntimeException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1553959163
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1553962707

From sroy at openjdk.org  Fri Apr  5 17:09:14 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 5 Apr 2024 17:09:14 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v11]
In-Reply-To: <QkrtkjA1tvz6BmnX9mnfD76YKE5EfzQtxEKUYLjsy6k=.ff1ed2b7-5786-4a2c-9e93-c797acc12aec@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <QkrtkjA1tvz6BmnX9mnfD76YKE5EfzQtxEKUYLjsy6k=.ff1ed2b7-5786-4a2c-9e93-c797acc12aec@github.com>
Message-ID: <zp--gxIrQdBTjP4gX1vfGPCE4BNHZVYRDYk8H0FAmKw=.153b7589-d663-4182-a0fb-0fa4fb049d29@github.com>

On Fri, 5 Apr 2024 08:58:34 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - spaces
>  - nits and move file to aix directory

Wouldn't hotspot anyways give a failure which will lead to an exception if
.a is not present ?

On Fri, Apr 5, 2024, 21:48 Mandy Chung ***@***.***> wrote:

> ***@***.**** commented on this pull request.
> ------------------------------
>
> In
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
> <https://github.com/openjdk/jdk/pull/17945#discussion_r1553959163>:
>
> > + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +
> +/**
> + * @test
> + * @bug 8319516
> + * @requires os.family == "aix"
> + * @run  main/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX
>
> ?? Suggested change
>
> - * @run  main/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX
> + * @run main/othervm -Djava.library.path=/usr/lib LoadAIXLibraryFromArchiveObject
>
> ------------------------------
>
> In
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
> <https://github.com/openjdk/jdk/pull/17945#discussion_r1553962707>:
>
> > + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +
> +/**
> + * @test
> + * @bug 8319516
> + * @requires os.family == "aix"
> + * @run  main/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX
> + */
> +
> +public class LoadAIXLibraryFromArchiveObject {
> +    public static void main(String[] args) throws Exception {
> +        String libraryName = "perfstat";
>
> I suggest to check if /usr/lib/libperstat.a is present and
> /usr/lib/libperfstat.so is not present; otherwise, the test should throw
> RuntimeException.
> ------------------------------
>
> In test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java
> <https://github.com/openjdk/jdk/pull/17945#discussion_r1553961921>:
>
> > +        } catch (Exception e) {
> +            throw new RuntimeException("LoadLibraryTestAIX : could not load libperfstat.a"+e);
> +        }
>
> In this case, the test can verify if /usr/lib/libperstat.a is present and
> /usr/lib/libperfstat.so is not present; otherwise, the test should throw
> RuntimeException. This also serves a good documentation purpose showing
> what this test expects.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/17945#pullrequestreview-1983652464>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AESW3BGWJOY5EQDRKPNMKEDY33FGFAVCNFSM6AAAAABDS326YOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSOBTGY2TENBWGQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2040275014

From naoto at openjdk.org  Fri Apr  5 17:27:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 5 Apr 2024 17:27:24 GMT
Subject: RFR: 8329787: Fix typo in CLDRConverter
Message-ID: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>

Fix a file/class name in the `CLDRConverter` build tool, with some clean-up for a switch statement.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/18662/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18662&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329787
  Stats: 393 lines in 4 files changed: 186 ins; 203 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18662/head:pull/18662

PR: https://git.openjdk.org/jdk/pull/18662

From darcy at openjdk.org  Fri Apr  5 17:41:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 17:41:13 GMT
Subject: RFR: JDK-8329556: javax.lang.model suppor for Derived Record
 Creation (Preview)
In-Reply-To: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
References: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
Message-ID: <oxGgm-e1ERf84KUzrd4CNGYKE8uw1JVPyS5XnYAxqOk=.f277b54e-4f47-45ff-9c51-94d1d5be5282@github.com>

On Wed, 3 Apr 2024 05:56:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

The changes in this PR are being incorporated into the larger PR for derived record creation.

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

PR Comment: https://git.openjdk.org/jdk/pull/18590#issuecomment-2040316977

From darcy at openjdk.org  Fri Apr  5 17:41:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 17:41:13 GMT
Subject: Withdrawn: JDK-8329556: javax.lang.model suppor for Derived Record
 Creation (Preview)
In-Reply-To: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
References: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
Message-ID: <hgxJOeKQkdCfyi7oJ4s3lbCyeg9k2_oE_vcUUJR13ko=.e7b82340-1d47-4720-9608-b6e7b67527aa@github.com>

On Wed, 3 Apr 2024 05:56:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/18590

From sroy at openjdk.org  Fri Apr  5 17:44:22 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 5 Apr 2024 17:44:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v12]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <Y9P3mQNgCuh4ff2yTttQHviNmyyDN1c60StnOiMnKCs=.90e26a3d-f89d-4307-a144-01e7e21d85d3@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 - update tests
 - update tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/5f05e278..68eb14e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=10-11

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From mchung at openjdk.org  Fri Apr  5 17:44:22 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 17:44:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v11]
In-Reply-To: <QkrtkjA1tvz6BmnX9mnfD76YKE5EfzQtxEKUYLjsy6k=.ff1ed2b7-5786-4a2c-9e93-c797acc12aec@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <QkrtkjA1tvz6BmnX9mnfD76YKE5EfzQtxEKUYLjsy6k=.ff1ed2b7-5786-4a2c-9e93-c797acc12aec@github.com>
Message-ID: <pRpxHYn3gyzvMxCt4dpXdGHSO0wHvFenzsJnN7oVlB0=.6dd55c9b-b548-4730-bcad-f7de15626faa@github.com>

On Fri, 5 Apr 2024 08:58:34 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - spaces
>  - nits and move file to aix directory

Yes while it's just sanity test and documents what this test expects and validates this specific code path.   Ideally the test should generate its own ".so" and ".a" to validate the code paths so that it does not depend on a system library.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2040313136

From sroy at openjdk.org  Fri Apr  5 17:44:22 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 5 Apr 2024 17:44:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v11]
In-Reply-To: <l8nBdmH-bLk7WJEIA62GklxgJR5rodQ6fPY0Y59YGbM=.b51f7169-8274-441a-a7a9-be956f9fefb3@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <QkrtkjA1tvz6BmnX9mnfD76YKE5EfzQtxEKUYLjsy6k=.ff1ed2b7-5786-4a2c-9e93-c797acc12aec@github.com>
 <l8nBdmH-bLk7WJEIA62GklxgJR5rodQ6fPY0Y59YGbM=.b51f7169-8274-441a-a7a9-be956f9fefb3@github.com>
Message-ID: <TaldThQVbZQkBHvVXPAI2Ml5qGj4Hx_i_PAiNTqD0ac=.17ae491a-8fd8-4b8e-9daa-a97b1242f3e1@github.com>

On Fri, 5 Apr 2024 16:18:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - spaces
>>  - nits and move file to aix directory
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 33:
> 
>> 31: public class LoadAIXLibraryFromArchiveObject {
>> 32:     public static void main(String[] args) throws Exception {
>> 33:         String libraryName = "perfstat";
> 
> I suggest to check if `/usr/lib/libperstat.a` is present and `/usr/lib/libperfstat.so` is not present; otherwise, the test should throw RuntimeException.

I understand. But isn't the presence of .so also a legit test case ? I mean loadLibrary is not expected to fail if that happens. The failure is expected when .so is not present and .a is also not present . Shouldn't we check for non existence of both ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1554048115

From mchung at openjdk.org  Fri Apr  5 17:44:22 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 17:44:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v12]
In-Reply-To: <Y9P3mQNgCuh4ff2yTttQHviNmyyDN1c60StnOiMnKCs=.90e26a3d-f89d-4307-a144-01e7e21d85d3@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <Y9P3mQNgCuh4ff2yTttQHviNmyyDN1c60StnOiMnKCs=.90e26a3d-f89d-4307-a144-01e7e21d85d3@github.com>
Message-ID: <sQ_-iinJlk1WvaJrzoSVnvBSL6eofN91B4qsAU1Y-pU=.16d25ba2-f5cb-48bc-8caf-e5afe4fb0310@github.com>

On Fri, 5 Apr 2024 17:41:36 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update tests
>  - update tests

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 37:

> 35:         File perfstatSharedObjectPath = new File("/usr/lib/libperfstat.so");
> 36:         // If .a file is not present and .so file is present.
> 37:         if (!perfstatPath.exists() || !perfstatSharedObjectPath.exists())

This test does not compile.  Please run it before and after the fix to validate the fix.

Suggestion:

        if (!perfstatArchivePath.exists() || !perfstatSharedObjectPath.exists())

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1554046285

From sroy at openjdk.org  Fri Apr  5 17:44:22 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 5 Apr 2024 17:44:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v12]
In-Reply-To: <sQ_-iinJlk1WvaJrzoSVnvBSL6eofN91B4qsAU1Y-pU=.16d25ba2-f5cb-48bc-8caf-e5afe4fb0310@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <Y9P3mQNgCuh4ff2yTttQHviNmyyDN1c60StnOiMnKCs=.90e26a3d-f89d-4307-a144-01e7e21d85d3@github.com>
 <sQ_-iinJlk1WvaJrzoSVnvBSL6eofN91B4qsAU1Y-pU=.16d25ba2-f5cb-48bc-8caf-e5afe4fb0310@github.com>
Message-ID: <QUx2CXXMjAyDRfup9pM3roX4lq1cDGsBYEqQn-D-des=.6cc6b644-2931-4630-8833-e86230701b38@github.com>

On Fri, 5 Apr 2024 17:38:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update tests
>>  - update tests
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 37:
> 
>> 35:         File perfstatSharedObjectPath = new File("/usr/lib/libperfstat.so");
>> 36:         // If .a file is not present and .so file is present.
>> 37:         if (!perfstatPath.exists() || !perfstatSharedObjectPath.exists())
> 
> This test does not compile.  Please run it before and after the fix to validate the fix.
> 
> Suggestion:
> 
>         if (!perfstatArchivePath.exists() || !perfstatSharedObjectPath.exists())

Yes, sorry it was the autocomplete command that ran through.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1554048830

From duke at openjdk.org  Fri Apr  5 17:47:03 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 5 Apr 2024 17:47:03 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
Message-ID: <zTeEE0xynGMh3LgAjxA99YyYwKfTIi5hAs3tFj5Y838=.b0f52ea7-9b57-4e0d-bdd7-d04d2e806e4c@github.com>

On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove use of jdk.crypto.ec

@ascarpino Hi Tony, this is the ECC P256 PR we talked about last year, would appreciate your feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2040325424

From mchung at openjdk.org  Fri Apr  5 17:48:02 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 17:48:02 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v12]
In-Reply-To: <Y9P3mQNgCuh4ff2yTttQHviNmyyDN1c60StnOiMnKCs=.90e26a3d-f89d-4307-a144-01e7e21d85d3@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <Y9P3mQNgCuh4ff2yTttQHviNmyyDN1c60StnOiMnKCs=.90e26a3d-f89d-4307-a144-01e7e21d85d3@github.com>
Message-ID: <uDCrt6r3FHBCF7jMjHfrR6rX0G5wKhAVEusq5hNOCSA=.2444574f-fea4-40b5-a7e0-bee94f2bb183@github.com>

On Fri, 5 Apr 2024 17:44:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update tests
>  - update tests

If it turns out that "libperfstat.so" exists on some system, we can update the test to allow that scenario.   It's good to confirm before we allow that.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2040326628

From rriggs at openjdk.org  Fri Apr  5 17:49:20 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Apr 2024 17:49:20 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
Message-ID: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>

When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) computation of the buffer size may exceed the range of a positive 32-bit Integer.
If the estimated size for the result byte array is too large, pre-compute the exact buffer size. 
If that exceeds the range, then throw OutOfMemoryError.

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

Commit messages:
 - 8329623: NegativeArraySizeException encoding large String to UTF-8

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

PR: https://git.openjdk.org/jdk/pull/18663

From jlu at openjdk.org  Fri Apr  5 17:59:58 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 5 Apr 2024 17:59:58 GMT
Subject: RFR: 8329787: Fix typo in CLDRConverter
In-Reply-To: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
References: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
Message-ID: <hZnHRAVu6NsnCIvYz0jTAv_WDtHHvNA2tPQRWYSpT60=.ffa7cab7-7569-465f-8a7a-5029ec04dffa@github.com>

On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fix a file/class name in the `CLDRConverter` build tool, with some clean-up for a switch statement.

LGTM

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18662#pullrequestreview-1983814332

From iris at openjdk.org  Fri Apr  5 18:06:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 5 Apr 2024 18:06:08 GMT
Subject: RFR: 8329787: Fix typo in CLDRConverter
In-Reply-To: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
References: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
Message-ID: <aYb5I7kJiINU0daQggaWF4n-Rd9XJL_57yZqdw-JPFA=.50846e37-9d0f-45df-adee-ea22a1bbefbe@github.com>

On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fix a file/class name in the `CLDRConverter` build tool, with some clean-up for a switch statement.

I like the new switch!

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18662#pullrequestreview-1983822529

From sroy at openjdk.org  Fri Apr  5 18:14:36 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 5 Apr 2024 18:14:36 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v13]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

 - update tests
 - update tests
 - update tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/68eb14e6..89b8da39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/17945

From lancea at openjdk.org  Fri Apr  5 18:25:59 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 5 Apr 2024 18:25:59 GMT
Subject: RFR: 8329787: Fix typo in CLDRConverter
In-Reply-To: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
References: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
Message-ID: <0z7R8S2VWVaW8NIOgu7UeOH2VYKB12CJ9Zn7Aoe4tzA=.9ec621b5-2cbc-4ae3-8215-0adfe397e3b2@github.com>

On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fix a file/class name in the `CLDRConverter` build tool, with some clean-up for a switch statement.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18662#pullrequestreview-1983860994

From jlahoda at openjdk.org  Fri Apr  5 18:35:37 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 18:35:37 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v8]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <0k62PoyjaMG_YZw-xV9T1H2q7W9JYCeoCx6VOcZoVRQ=.2089eb99-3979-4b48-af9d-9dff89a4068a@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

  Reflecting review feedback:
  - pre-generating the JCVarDecls in Attr, to aid Flow
  - adding a note on how the desugared code looks like

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/c91e87fd..14651358

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=06-07

  Stats: 75 lines in 6 files changed: 30 ins; 11 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

PR: https://git.openjdk.org/jdk/pull/18509

From darcy at openjdk.org  Fri Apr  5 18:35:38 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 18:35:38 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v8]
In-Reply-To: <0k62PoyjaMG_YZw-xV9T1H2q7W9JYCeoCx6VOcZoVRQ=.2089eb99-3979-4b48-af9d-9dff89a4068a@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <0k62PoyjaMG_YZw-xV9T1H2q7W9JYCeoCx6VOcZoVRQ=.2089eb99-3979-4b48-af9d-9dff89a4068a@github.com>
Message-ID: <B36ahBT-Byi3Z52KLTRFFkYRH50jSeZGL7PW64WBE60=.4f62075d-1bc6-48f1-bbee-f3b76d1ecec3@github.com>

On Fri, 5 Apr 2024 18:32:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback:
>   - pre-generating the JCVarDecls in Attr, to aid Flow
>   - adding a note on how the desugared code looks like

src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 135:

> 133:     COMPONENT_LOCAL_VARIABLE;
> 134: 
> 135:     // Maintenance note: check if the default implementation of

>From a quick look, I don't think Elements.getOutermostTypeElement needs updating for COMPONENT_LOCAL_VARIABLE, but it would be good to add a test case.

src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java line 91:

> 89: 
> 90:     /**
> 91:      * {@inheritDoc ElementKindVisitor6}

If possible, would be good to add some minimal testing/use of the element kind visitors on component local variables.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1554108944
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1554113169

From jlahoda at openjdk.org  Fri Apr  5 18:35:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 18:35:38 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <N88cWm47DXisDS82xRXJgAxx7_tLtunbiU-DTOtiJVk=.c5ddae1e-2402-4215-aa2a-092494b348c5@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
 <N88cWm47DXisDS82xRXJgAxx7_tLtunbiU-DTOtiJVk=.c5ddae1e-2402-4215-aa2a-092494b348c5@github.com>
Message-ID: <zkm6nuZGWZ289iCgSfLwW45m_hUFxDrIZI4Ewgd9hUo=.33daff82-08d8-41d8-9339-9e0d3e206278@github.com>

On Fri, 5 Apr 2024 13:09:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JavaCompiler cleanup
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2117:
> 
>> 2115:          *  position.
>> 2116:          */
>> 2117:         protected VarAndDeclarationTree[] vars;
> 
> So... normally, a `JCVariableDecl` would have a symbol attached, which is how the old code used to work. Is it correct that this change is needed because the `componentLocalVariables` list is a list of symbols and not of JCVariableDecl? Would it be too complex to create a declaration in Attr and save those in the derived creation tree?

Generating the `JCVariableDecl`s in Attr in https://github.com/openjdk/jdk/pull/18509/commits/146513580f96abd5feb7886bd1191805cc93403b.
Thanks for the comment!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4443:
> 
>> 4441:     }
>> 4442: 
>> 4443:     @Override
> 
> As usual, I suggest to add some brief comment with the shape of the generated code.

Done here:
https://github.com/openjdk/jdk/pull/18509/commits/146513580f96abd5feb7886bd1191805cc93403b#diff-bc0df6dce7f74078bfca1e90bec75d7bb3d8b338933be725da78f0a8a7a0c78dR4445

Please let me know if that needs some tweaks.

Thanks for the comment!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1554103472
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1554104437

From bpb at openjdk.org  Fri Apr  5 19:11:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Apr 2024 19:11:10 GMT
Subject: RFR: 8329787: Fix typo in CLDRConverter
In-Reply-To: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
References: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
Message-ID: <V_1SDC-Zx7066Njrnd0SGKevkdDipPzPwoNRU1SLBAE=.e59628ae-348b-4585-9e7d-75916115a7bd@github.com>

On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fix a file/class name in the `CLDRConverter` build tool, with some clean-up for a switch statement.

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18662#pullrequestreview-1984005299

From mchung at openjdk.org  Fri Apr  5 19:21:02 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 19:21:02 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v13]
In-Reply-To: <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
Message-ID: <zyfQWQCZTDH__DJyAGGp7StKJRApptQbgHhs7bsdkaI=.b1614360-acbe-4d07-817a-0ce64ed1b954@github.com>

On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update tests
>  - update tests
>  - update tests

Thanks for the update.  Looks good. 

I updated the synopsis of the JBS issue for better description.  Please update the title to match it.

It's good to get another reviewer who can validate this on AIX to sponsor this change.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-1984018341

From naoto at openjdk.org  Fri Apr  5 20:20:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 5 Apr 2024 20:20:08 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
In-Reply-To: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
Message-ID: <yOFNzw_lpzXMb4cm0wbgrZABPWkwgLKkabqMLhb6d5k=.d3465662-a062-4ab3-ae72-a001f97dec40@github.com>

On Fri, 5 Apr 2024 17:44:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) computation of the buffer size may exceed the range of a positive 32-bit Integer.
> If the estimated size for the result byte array is too large, pre-compute the exact buffer size. 
> If that exceeds the range, then throw OutOfMemoryError.

LGTM. The test case could be more thorough if it tests strings with supplementary codepoints, as the new method computes them exclusively.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18663#pullrequestreview-1984117426

From sgibbons at openjdk.org  Fri Apr  5 21:53:50 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 5 Apr 2024 21:53:50 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v5]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <uFn14ktpk_5hPeQc1cQ81zm7bWf2ql86-RR7JejXfmI=.a698860b-f2c9-4249-a3f8-3b2289899f5e@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Fixed generate_fill when count > 0x80000000

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/8bed1561..b025318f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=03-04

  Stats: 13 lines in 2 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From rriggs at openjdk.org  Fri Apr  5 22:00:05 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Apr 2024 22:00:05 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
In-Reply-To: <yOFNzw_lpzXMb4cm0wbgrZABPWkwgLKkabqMLhb6d5k=.d3465662-a062-4ab3-ae72-a001f97dec40@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
 <yOFNzw_lpzXMb4cm0wbgrZABPWkwgLKkabqMLhb6d5k=.d3465662-a062-4ab3-ae72-a001f97dec40@github.com>
Message-ID: <WhtRpEjqphm-yON48dXSUJVIabi98WeVE_M0lWWbmK8=.fe4a23bc-6acb-4999-a29a-6627ad3847d0@github.com>

On Fri, 5 Apr 2024 20:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> LGTM. The test case could be more thorough if it tests strings with supplementary codepoints, as the new method computes them exclusively.

I considered that, but the worst case is the x3 expansion. 
A 2 character high/low surrogate pair would result in 4 bytes of UTF-8, less than the 6 bytes needed for a 2 16 bit characters. The test doesn't run quickly already due to the large chunks of memory used.

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

PR Comment: https://git.openjdk.org/jdk/pull/18663#issuecomment-2040681452

From sgibbons at openjdk.org  Fri Apr  5 22:07:23 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 5 Apr 2024 22:07:23 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v5]
In-Reply-To: <uFn14ktpk_5hPeQc1cQ81zm7bWf2ql86-RR7JejXfmI=.a698860b-f2c9-4249-a3f8-3b2289899f5e@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <uFn14ktpk_5hPeQc1cQ81zm7bWf2ql86-RR7JejXfmI=.a698860b-f2c9-4249-a3f8-3b2289899f5e@github.com>
Message-ID: <epioDyNzIT8vtl2UzGsqznUHEp1tyj67Bh5_KV3UKPA=.5e6f6f89-4a88-406e-a647-8cd36f8a719a@github.com>

On Fri, 5 Apr 2024 21:53:50 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed generate_fill when count > 0x80000000

Thanks for all your thoughtful feedback.  I would very much like to take "the right approach"(tm) but I don't have the skill to write IR, especially given that this is an Unsafe block, which is restricted by atomicity and alignment.  I would not know how to prevent the C2 optimizer from vectorizing, or indeed replacing my code with a call to memset().  I'm not sure it would go this far, but in order to remain compliant with the spec I have to prevent it in the future.

This was modeled after the existing implementation of copyMemory, gives good performance (3-5x), and can serve as a template for other platform developers to follow.  They have the expertise for their specific platform(s) which I do not have.

Again, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2040688225

From naoto at openjdk.org  Fri Apr  5 22:26:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 5 Apr 2024 22:26:13 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
In-Reply-To: <WhtRpEjqphm-yON48dXSUJVIabi98WeVE_M0lWWbmK8=.fe4a23bc-6acb-4999-a29a-6627ad3847d0@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
 <yOFNzw_lpzXMb4cm0wbgrZABPWkwgLKkabqMLhb6d5k=.d3465662-a062-4ab3-ae72-a001f97dec40@github.com>
 <WhtRpEjqphm-yON48dXSUJVIabi98WeVE_M0lWWbmK8=.fe4a23bc-6acb-4999-a29a-6627ad3847d0@github.com>
Message-ID: <TibySOxJvpWMqOJZ8dQ-GCvG7vObkv67S08vs0lw5Q4=.20f6c042-b6b6-4a76-9e9d-1fc6d56238b0@github.com>

On Fri, 5 Apr 2024 21:57:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test doesn't run quickly already due to the large chunks of memory used.

OK, never mind then, if it would take considerable time.

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

PR Comment: https://git.openjdk.org/jdk/pull/18663#issuecomment-2040706486

From bchristi at openjdk.org  Fri Apr  5 23:13:39 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 5 Apr 2024 23:13:39 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v22]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

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

  Another update to reachabilityFence() @apiNote

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/bdac5cce..91d4db48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=20-21

  Stats: 19 lines in 1 file changed: 0 ins; 5 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From sgibbons at openjdk.org  Sat Apr  6 00:13:26 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 6 Apr 2024 00:13:26 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <9BH6kkaQU5kSjlJUnNenUeWBK2EdahCuks8qEUjDlv0=.b8979589-32df-4fa3-b5a6-f56dad76c58d@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Oops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/b025318f..fd6f04f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=04-05

  Stats: 18 lines in 2 files changed: 2 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From dlong at openjdk.org  Sun Apr  7 01:52:14 2024
From: dlong at openjdk.org (Dean Long)
Date: Sun, 7 Apr 2024 01:52:14 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <9BH6kkaQU5kSjlJUnNenUeWBK2EdahCuks8qEUjDlv0=.b8979589-32df-4fa3-b5a6-f56dad76c58d@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <9BH6kkaQU5kSjlJUnNenUeWBK2EdahCuks8qEUjDlv0=.b8979589-32df-4fa3-b5a6-f56dad76c58d@github.com>
Message-ID: <lHOUGJcmoxK_FDm_gP5yj6BU6ccDCujHCGTB_FMNHYg=.69287fa4-dc59-4cc5-98c6-f91c070662da@github.com>

On Sat, 6 Apr 2024 00:13:26 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Oops

I went ahead and tried a pure-Java implementation, and it is faster for small sizes (up to 8) and only about 1.5x slower for larger sizes, so that might make for an interesting fallback if there is no customized assembler implementation available or if the size is known to me small.

Ideally, I think we would want C2 to be more aware of setMemory stores, so that it can remove redundant stores, like it does with InitializeNode.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2041271472

From duke at openjdk.org  Sun Apr  7 05:18:08 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Sun, 7 Apr 2024 05:18:08 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <lHOUGJcmoxK_FDm_gP5yj6BU6ccDCujHCGTB_FMNHYg=.69287fa4-dc59-4cc5-98c6-f91c070662da@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <9BH6kkaQU5kSjlJUnNenUeWBK2EdahCuks8qEUjDlv0=.b8979589-32df-4fa3-b5a6-f56dad76c58d@github.com>
 <lHOUGJcmoxK_FDm_gP5yj6BU6ccDCujHCGTB_FMNHYg=.69287fa4-dc59-4cc5-98c6-f91c070662da@github.com>
Message-ID: <2X2qG_TCmbIfhM4CCepi7PHttQGFuMXlLgea1Yq15uc=.3d4bdee1-2eed-4df9-bcb4-f08bf8060119@github.com>

On Sun, 7 Apr 2024 01:49:01 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Oops
>
> I went ahead and tried a pure-Java implementation, and it is faster for small sizes (up to 8) and only about 1.5x slower for larger sizes, so that might make for an interesting fallback if there is no customized assembler implementation available or if the size is known to me small.
> 
> Ideally, I think we would want C2 to be more aware of setMemory stores, so that it can remove redundant stores, like it does with InitializeNode.

@dean-long in my old PR I have done the same, choosing a (not yet) configurable cutoff value. 

See https://github.com/openjdk/jdk/pull/16760

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2041314429

From errael at raelity.com  Sun Apr  7 16:06:13 2024
From: errael at raelity.com (Ernie Rael)
Date: Sun, 7 Apr 2024 09:06:13 -0700
Subject: JEP 473: Stream Gatherers (Second Preview)
Message-ID: <8d9a2edb-505a-4253-bfa2-054d092f0db2@raelity.com>

This is about what might be a minor doc issue.

In https://openjdk.org/jeps/473 it says

> As another example, |Stream::filter| takes a predicate that determines 
> whether an input element should be passed downstream; this is simply a 
> stateless one-to-many gatherer.
Shouldn't this be "many-to-one"?

-ernie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240407/24068fce/attachment.htm>

From viktor.klang at oracle.com  Sun Apr  7 16:11:11 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Sun, 7 Apr 2024 16:11:11 +0000
Subject: JEP 473: Stream Gatherers (Second Preview)
In-Reply-To: <8d9a2edb-505a-4253-bfa2-054d092f0db2@raelity.com>
References: <8d9a2edb-505a-4253-bfa2-054d092f0db2@raelity.com>
Message-ID: <MW4PR10MB5774C9305240C4692DACCFB0FF012@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Ernie,

"Many" in this case refers to "N", which is "0 ... N", so I'd say while it is techincally correct as-is, perhaps more precise would be to say "1-to-0..1" gatherer, since for every element in, there is 0 or 1 element out.

Many-to-one would be 0..N -> 1, which means that an empty input would yield a single output.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Ernie Rael <errael at raelity.com>
Sent: Sunday, 7 April 2024 18:06
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: JEP 473: Stream Gatherers (Second Preview)


This is about what might be a minor doc issue.

In https://openjdk.org/jeps/473 it says

As another example, Stream::filter takes a predicate that determines whether an input element should be passed downstream; this is simply a stateless one-to-many gatherer.
Shouldn't this be "many-to-one"?

-ernie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240407/d557e14d/attachment-0001.htm>

From errael at raelity.com  Sun Apr  7 16:31:04 2024
From: errael at raelity.com (Ernie Rael)
Date: Sun, 7 Apr 2024 09:31:04 -0700
Subject: JEP 473: Stream Gatherers (Second Preview)
In-Reply-To: <MW4PR10MB5774C9305240C4692DACCFB0FF012@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <8d9a2edb-505a-4253-bfa2-054d092f0db2@raelity.com>
 <MW4PR10MB5774C9305240C4692DACCFB0FF012@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <33a36ca1-b4db-4344-a868-f9993ce534ad@raelity.com>

On 24/04/07 9:11 AM, Viktor Klang wrote:
> Hi Ernie,
>
> "Many" in this case refers to "N", which is "0 ... N",
OK, I was wondering about "many" including "0".
> so I'd say while it is techincally correct as-is, perhaps more precise 
> would be to say "1-to-0..1" gatherer, since for every element in, 
> there is 0 or 1 element out.
I see.
>
> Many-to-one would be 0..N -> 1, which means that an empty input would
"could" not "would"?
> yield a single output.

Out of curiosity, is either correct technically?


Other than at? initialization or finish, is it possible to have an 
"empty" input?


-ernie

>
> Cheers,
> ?
>
> *
> *
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of 
> Ernie Rael <errael at raelity.com>
> *Sent:* Sunday, 7 April 2024 18:06
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* JEP 473: Stream Gatherers (Second Preview)
>
> This is about what might be a minor doc issue.
>
> In https://openjdk.org/jeps/473 <https://openjdk.org/jeps/473> it says
>
>> As another example, |Stream::filter| takes a predicate that 
>> determines whether an input element should be passed downstream; this 
>> is simply a stateless one-to-many gatherer.
> Shouldn't this be "many-to-one"?
>
> -ernie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240407/26f76b81/attachment.htm>

From holo3146 at gmail.com  Sun Apr  7 18:24:13 2024
From: holo3146 at gmail.com (Holo The Sage Wolf)
Date: Sun, 7 Apr 2024 21:24:13 +0300
Subject: JEP 473: Stream Gatherers (Second Preview)
In-Reply-To: <33a36ca1-b4db-4344-a868-f9993ce534ad@raelity.com>
References: <8d9a2edb-505a-4253-bfa2-054d092f0db2@raelity.com>
 <MW4PR10MB5774C9305240C4692DACCFB0FF012@MW4PR10MB5774.namprd10.prod.outlook.com>
 <33a36ca1-b4db-4344-a868-f9993ce534ad@raelity.com>
Message-ID: <CAKswmE59qfGcTHsd4DK2+jSXrXJ58UdsVrFhCr5c7Fh9b2S8tA@mail.gmail.com>

Think about `flatMap` (which filter is a special case of), this is
one-to-many function that can also return 1 or 0 elements for each input.
So it makes sense to include 0 as "many".

Filter isn't many-to-... At all, at no point it collapses a subsequence of
elements, it only works on one element at a time

On Sun, 7 Apr 2024, 19:31 Ernie Rael, <errael at raelity.com> wrote:

> On 24/04/07 9:11 AM, Viktor Klang wrote:
>
> Hi Ernie,
>
> "Many" in this case refers to "N", which is "0 ... N",
>
> OK, I was wondering about "many" including "0".
>
> so I'd say while it is techincally correct as-is, perhaps more precise
> would be to say "1-to-0..1" gatherer, since for every element in, there is
> 0 or 1 element out.
>
> I see.
>
>
> Many-to-one would be 0..N -> 1, which means that an empty input would
>
> "could" not "would"?
>
> yield a single output.
>
> Out of curiosity, is either correct technically?
>
>
> Other than at  initialization or finish, is it possible to have an "empty"
> input?
>
>
> -ernie
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org>
> <core-libs-dev-retn at openjdk.org> on behalf of Ernie Rael
> <errael at raelity.com> <errael at raelity.com>
> *Sent:* Sunday, 7 April 2024 18:06
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> <core-libs-dev at openjdk.org>
> *Subject:* JEP 473: Stream Gatherers (Second Preview)
>
>
> This is about what might be a minor doc issue.
>
> In https://openjdk.org/jeps/473 it says
>
> As another example, Stream::filter takes a predicate that determines
> whether an input element should be passed downstream; this is simply a
> stateless one-to-many gatherer.
>
> Shouldn't this be "many-to-one"?
>
> -ernie
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240407/3bfa6fe3/attachment.htm>

From duke at openjdk.org  Mon Apr  8 04:07:14 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 8 Apr 2024 04:07:14 GMT
Subject: RFR: 8329596: Add test for virtual threads invoking synchronized
 native methods
In-Reply-To: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
References: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
Message-ID: <UdnbKTlPVgvb6FcPZAG08HDBtGLtmD2lUpRzukBbKCI=.6a279191-acb0-416e-a896-f05bdab60a79@github.com>

On Wed, 3 Apr 2024 10:52:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only addition to add a test for virtual threads invoking a synchronized native method and invoking a native method that enter/exits a monitor with JNI MonitorEnter/MonitorExit. The test has been in the loom repo for some time, it can move to the main line in advance of changes to the object monitor implementation.

Nit, maybe?make all?re?entrancy comments match?each?other:

test/jdk/java/lang/Thread/virtual/SynchronizedNative.java line 94:

> 92:         VThreadRunner.run(() -> {
> 93: 
> 94:             // enter, reenter with a synchronized native method

Suggestion:

            // enter with synchronized statement, reenter with synchronized native method

test/jdk/java/lang/Thread/virtual/SynchronizedNative.java line 265:

> 263:         VThreadRunner.run(() -> {
> 264: 
> 265:             // enter, reenter with JNI MonitorEnter

Suggestion:

            // enter with synchronized statement, reenter with JNI MonitorEnter

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

PR Review: https://git.openjdk.org/jdk/pull/18600#pullrequestreview-1985402714
PR Review Comment: https://git.openjdk.org/jdk/pull/18600#discussion_r1555196757
PR Review Comment: https://git.openjdk.org/jdk/pull/18600#discussion_r1555196933

From rgiulietti at openjdk.org  Mon Apr  8 08:58:08 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 Apr 2024 08:58:08 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
In-Reply-To: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
Message-ID: <2Ofkv7CVfCj95CZ6Ltc5dJ8X5LQYnd8yf8YDnNoBU2g=.172251e8-45f7-4bd0-9e11-65810cdbf1bd@github.com>

On Fri, 5 Apr 2024 17:44:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) computation of the buffer size may exceed the range of a positive 32-bit Integer.
> If the estimated size for the result byte array is too large, pre-compute the exact buffer size. 
> If that exceeds the range, then throw OutOfMemoryError.

Code fix looks good, but see the comment in the test.

test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 143:

> 141:         // Strings of size min+1...min+2, throw OOME
> 142:         // The resulting byte array would exceed implementation limits
> 143:         for (int count = min + 1; count < max; count++) {

The case `min + 1` cannot lead to a `NegativeArraySizeException` in the current code, since `3 * (min + 1) <= MAX_VALUE`. In theory, it should succeed by returning the encoded `byte[]`, although It throws `OOME` for exceeding VM limits. That is, this case does not trigger the invocation of `computeSizeUTF8_UTF16()` in the proposed fix.

Only `min + 2` throws `NegativeArraySizeException` in the current code, and thus the invocation of `computeSizeUTF8_UTF16()` in the proposed fix.

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

PR Review: https://git.openjdk.org/jdk/pull/18663#pullrequestreview-1985830221
PR Review Comment: https://git.openjdk.org/jdk/pull/18663#discussion_r1555466467

From jpai at openjdk.org  Mon Apr  8 09:58:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Apr 2024 09:58:16 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match the
 range of Instant
Message-ID: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>

Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?

As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.

The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.

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

Commit messages:
 - 8212895: ChronoField.INSTANT_SECONDS's range doesn't match the range of Instant

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

PR: https://git.openjdk.org/jdk/pull/18674

From mdoerr at openjdk.org  Mon Apr  8 10:30:13 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 8 Apr 2024 10:30:13 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v13]
In-Reply-To: <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
Message-ID: <AJcRAHtgPJKk2-gCAtWH704Ud2oWdhQj61kY_stq_24=.75e6bb8d-598e-426c-8c9d-80fa0c3569a3@github.com>

On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update tests
>  - update tests
>  - update tests

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 40:

> 38:     * This method returns false so that loading of shared library continues if
> 39:     * libname.so is not present.
> 40:     */

The '*' should be in the same column. Please compare to ClassLoaderHelper.java for other OSs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1555591088

From mdoerr at openjdk.org  Mon Apr  8 10:43:11 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 8 Apr 2024 10:43:11 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v13]
In-Reply-To: <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
Message-ID: <wZph9jMyCm4TJ94dfyNs3mtet3P-Cnz9lnhC7E_4_W0=.c55fb00b-e65d-4cdf-9f3e-16a32bfe0ee8@github.com>

On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update tests
>  - update tests
>  - update tests

The fix itself looks good except minor nits.

I have looked at the test together with Joachim. The test is not valid. It only passes because https://github.com/openjdk/jdk/commit/b8ae4a8c0985d1763ac48ba78943d8b992d7be77 has a bug. The lib `/usr/lib/libperfstat.a(shr_64.o)` has already been loaded by hotspot and [JDK-8320890](https://bugs.openjdk.org/browse/JDK-8320890) prevents the loading attempt we are trying to test. This is a real problem because it breaks the ability to load several members of the same library.
@JoKern65: Please file a bug for this problem.

If you need a test for this PR, I suggest copying an existing ".so" library to e.g. "libdummyarchive.a" and use that. I think that it is possible to implement the copy step in Java and to write it to the test's temporary directory.

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 43:

> 41:     static boolean loadLibraryOnlyIfPresent() {
> 42:         return false;
> 43:     }

Please insert an empty line.

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

Changes requested by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-1986030389
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1555591905

From jpai at openjdk.org  Mon Apr  8 11:22:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 Apr 2024 11:22:08 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant
In-Reply-To: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
Message-ID: <JfAexdq2TGDgleUJ7I-HYRK6Jc6dQonz222yF6wSQG0=.6598a879-3dae-4cfa-81bc-b1f16f4246bf@github.com>

On Mon, 8 Apr 2024 09:52:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
> 
> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
> 
> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.

Given that this is a observable change through a public API, I think a csr will be needed for this. I'll draft one shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/18674#issuecomment-2042488119

From jkern at openjdk.org  Mon Apr  8 12:33:17 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 8 Apr 2024 12:33:17 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v13]
In-Reply-To: <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
Message-ID: <gT_LFbsUtvoNyHKMMfX0OtfJhm-jro8zp1IIy2Mx0ZE=.9d763da2-efa6-4694-9af0-a6b893ebb72f@github.com>

On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update tests
>  - update tests
>  - update tests

> The fix itself looks good except minor nits.
> 
> I have looked at the test together with Joachim. The test is not valid. It only passes because [b8ae4a8](https://github.com/openjdk/jdk/commit/b8ae4a8c0985d1763ac48ba78943d8b992d7be77) has a bug. The lib `/usr/lib/libperfstat.a(shr_64.o)` has already been loaded by hotspot and [JDK-8320890](https://bugs.openjdk.org/browse/JDK-8320890) prevents the loading attempt we are trying to test. This is a real problem because it breaks the ability to load several members of the same library. @JoKern65: Please file a bug for this problem.
> 
> Also note that `dlopen ("/usr/lib/libperfstat.a", RTLD_NOW);` fails with "Exec format error". The library really requires a member specification.
> 
> If you need a test for this PR, I suggest copying an existing ".so" library to e.g. "libdummyarchive.a" and use that. I think that it is possible to implement the copy step in Java and to write it to the test's temporary directory.

I Have created a PR (https://github.com/openjdk/jdk/pull/18676) to fix the mentioned problem. With this correction in place I can verify that your testcase does not properly work as is.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2042624487

From rriggs at openjdk.org  Mon Apr  8 13:42:10 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Apr 2024 13:42:10 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
In-Reply-To: <2Ofkv7CVfCj95CZ6Ltc5dJ8X5LQYnd8yf8YDnNoBU2g=.172251e8-45f7-4bd0-9e11-65810cdbf1bd@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
 <2Ofkv7CVfCj95CZ6Ltc5dJ8X5LQYnd8yf8YDnNoBU2g=.172251e8-45f7-4bd0-9e11-65810cdbf1bd@github.com>
Message-ID: <aW1Q6N3CCtnJShUdFk4K82WtEw7ot48I5JhMK6Iq79E=.2a89b157-8814-41e4-acee-2d275f5adef8@github.com>

On Mon, 8 Apr 2024 08:54:21 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) computation of the buffer size may exceed the range of a positive 32-bit Integer.
>> If the estimated size for the result byte array is too large, pre-compute the exact buffer size. 
>> If that exceeds the range, then throw OutOfMemoryError.
>
> test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 143:
> 
>> 141:         // Strings of size min+1...min+2, throw OOME
>> 142:         // The resulting byte array would exceed implementation limits
>> 143:         for (int count = min + 1; count < max; count++) {
> 
> The case `min + 1` cannot lead to a `NegativeArraySizeException` in the current code, since `3 * (min + 1) <= MAX_VALUE`. In theory, it should succeed by returning the encoded `byte[]`, although It throws `OOME` for exceeding VM limits. That is, this case does not trigger the invocation of `computeSizeUTF8_UTF16()` in the proposed fix.
> 
> Only `min + 2` throws `NegativeArraySizeException` in the current code, and thus the invocation of `computeSizeUTF8_UTF16()` in the proposed fix.

Indeed, different OOMEs are thrown in the two cases triggered by different limits, min +2 is due to integer overflow, while min +1  is due a VM limit on the size of byte[Integer.MAX_VALUE]. Different VM implementations may have different limits. on the max size of a byte array.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18663#discussion_r1555866610

From rriggs at openjdk.org  Mon Apr  8 13:49:11 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Apr 2024 13:49:11 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
In-Reply-To: <aW1Q6N3CCtnJShUdFk4K82WtEw7ot48I5JhMK6Iq79E=.2a89b157-8814-41e4-acee-2d275f5adef8@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
 <2Ofkv7CVfCj95CZ6Ltc5dJ8X5LQYnd8yf8YDnNoBU2g=.172251e8-45f7-4bd0-9e11-65810cdbf1bd@github.com>
 <aW1Q6N3CCtnJShUdFk4K82WtEw7ot48I5JhMK6Iq79E=.2a89b157-8814-41e4-acee-2d275f5adef8@github.com>
Message-ID: <Y6LvYzxCuh-LhYIh9QROeLOeP_MJfMlf_N3w79vTW5o=.41ff3d4a-657c-4fb1-a783-bfa487b8cd2f@github.com>

On Mon, 8 Apr 2024 13:39:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 143:
>> 
>>> 141:         // Strings of size min+1...min+2, throw OOME
>>> 142:         // The resulting byte array would exceed implementation limits
>>> 143:         for (int count = min + 1; count < max; count++) {
>> 
>> The case `min + 1` cannot lead to a `NegativeArraySizeException` in the current code, since `3 * (min + 1) <= MAX_VALUE`. In theory, it should succeed by returning the encoded `byte[]`, although It throws `OOME` for exceeding VM limits. That is, this case does not trigger the invocation of `computeSizeUTF8_UTF16()` in the proposed fix.
>> 
>> Only `min + 2` throws `NegativeArraySizeException` in the current code, and thus the invocation of `computeSizeUTF8_UTF16()` in the proposed fix.
>
> Indeed, different OOMEs are thrown in the two cases triggered by different limits, min +2 is due to integer overflow, while min +1  is due a VM limit on the size of byte[Integer.MAX_VALUE]. Different VM implementations may have different limits on the max size of a byte array.

There might be some merit in lowering the threshold at which an exact size computation is triggered.
The oversized allocation "wastes" quite a bit of memory and causes extra GC work and usually triggers a second copy of the final size.
However, some guess or heuristic would be needed to choose the threshold at which extra cpu work is needed to compute the exact size vs some metric as to the "cost" of wasted memory (and saving on the copy).
Most guesses would be somewhat arbitrary; bigger than 1Mb, 1GB, etc....? 
Choosing that number would be out of scope for the issue raised by this bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18663#discussion_r1555875973

From mcimadamore at openjdk.org  Mon Apr  8 14:06:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 Apr 2024 14:06:13 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <zkm6nuZGWZ289iCgSfLwW45m_hUFxDrIZI4Ewgd9hUo=.33daff82-08d8-41d8-9339-9e0d3e206278@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
 <N88cWm47DXisDS82xRXJgAxx7_tLtunbiU-DTOtiJVk=.c5ddae1e-2402-4215-aa2a-092494b348c5@github.com>
 <zkm6nuZGWZ289iCgSfLwW45m_hUFxDrIZI4Ewgd9hUo=.33daff82-08d8-41d8-9339-9e0d3e206278@github.com>
Message-ID: <uB-LY_NfCJ1KO_xK6Lk1xt15lWk4EdppIPqQ4Nn37RE=.3493a23c-fb45-4d88-8908-2f9072c61f15@github.com>

On Fri, 5 Apr 2024 18:28:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4443:
>> 
>>> 4441:     }
>>> 4442: 
>>> 4443:     @Override
>> 
>> As usual, I suggest to add some brief comment with the shape of the generated code.
>
> Done here:
> https://github.com/openjdk/jdk/pull/18509/commits/146513580f96abd5feb7886bd1191805cc93403b#diff-bc0df6dce7f74078bfca1e90bec75d7bb3d8b338933be725da78f0a8a7a0c78dR4445
> 
> Please let me know if that needs some tweaks.
> 
> Thanks for the comment!

Looks great!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1555902226

From rgiulietti at openjdk.org  Mon Apr  8 14:34:59 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 Apr 2024 14:34:59 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
In-Reply-To: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
Message-ID: <58_1NiJn2LyfP4hlS_EOtN9YOzeneBIAS6DB8-rwlMM=.e82aaf6a-778e-43ac-ac93-6b6cb6521959@github.com>

On Fri, 5 Apr 2024 17:44:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) computation of the buffer size may exceed the range of a positive 32-bit Integer.
> If the estimated size for the result byte array is too large, pre-compute the exact buffer size. 
> If that exceeds the range, then throw OutOfMemoryError.

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18663#pullrequestreview-1986623356

From rgiulietti at openjdk.org  Mon Apr  8 14:34:59 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 Apr 2024 14:34:59 GMT
Subject: RFR: 8329623: NegativeArraySizeException encoding large String to
 UTF-8
In-Reply-To: <Y6LvYzxCuh-LhYIh9QROeLOeP_MJfMlf_N3w79vTW5o=.41ff3d4a-657c-4fb1-a783-bfa487b8cd2f@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
 <2Ofkv7CVfCj95CZ6Ltc5dJ8X5LQYnd8yf8YDnNoBU2g=.172251e8-45f7-4bd0-9e11-65810cdbf1bd@github.com>
 <aW1Q6N3CCtnJShUdFk4K82WtEw7ot48I5JhMK6Iq79E=.2a89b157-8814-41e4-acee-2d275f5adef8@github.com>
 <Y6LvYzxCuh-LhYIh9QROeLOeP_MJfMlf_N3w79vTW5o=.41ff3d4a-657c-4fb1-a783-bfa487b8cd2f@github.com>
Message-ID: <uyIMNU6jMR7RtOR1nmTFLAeZbdzRgmv8VF4o7DtmZF0=.739eb49c-73c4-4984-8a62-ee6e2671a603@github.com>

On Mon, 8 Apr 2024 13:46:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Indeed, different OOMEs are thrown in the two cases triggered by different limits, min +2 is due to integer overflow, while min +1  is due a VM limit on the size of byte[Integer.MAX_VALUE]. Different VM implementations may have different limits on the max size of a byte array.
>
> There might be some merit in lowering the threshold at which an exact size computation is triggered.
> The oversized allocation "wastes" quite a bit of memory and causes extra GC work and usually triggers a second copy of the final size.
> However, some guess or heuristic would be needed to choose the threshold at which extra cpu work is needed to compute the exact size vs some metric as to the "cost" of wasted memory (and saving on the copy).
> Most guesses would be somewhat arbitrary; bigger than 1Mb, 1GB, etc....? 
> Choosing that number would be out of scope for the issue raised by this bug.

What I mean is that the VM limit might change and suddenly accept `MAX_VALUE` as an allowed array size (very unlikely, I guess). The test would then fail on `min + 1` because it expects a OOME which will not be thrown.

But that is very remote.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18663#discussion_r1555944305

From jlahoda at openjdk.org  Mon Apr  8 16:21:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 8 Apr 2024 16:21:19 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v9]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <HA2CicFGNm0tG_DC2OgKLFEtAg6Wv-kfAa3EAhUUd2o=.8e2abb3d-431b-4582-84f6-ef562054e49d@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

  Adding tests as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/14651358..e0930688

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=07-08

  Stats: 261 lines in 3 files changed: 257 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

PR: https://git.openjdk.org/jdk/pull/18509

From naoto at openjdk.org  Mon Apr  8 16:29:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Apr 2024 16:29:18 GMT
Subject: RFR: 8329787: Fix typo in CLDRConverter
In-Reply-To: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
References: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
Message-ID: <KwUw2HS8iFKtlAFhxACjzTfMGUd_SmSVudY-lE_XmuE=.3314a83b-ade2-41f6-83e7-9fb7621c8808@github.com>

On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fix a file/class name in the `CLDRConverter` build tool, with some clean-up for a switch statement.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/18662#issuecomment-2043177032

From naoto at openjdk.org  Mon Apr  8 16:29:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Apr 2024 16:29:18 GMT
Subject: Integrated: 8329787: Fix typo in CLDRConverter
In-Reply-To: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
References: <7laXYolMvTos_x5eHvEmVVPkDs7neoxGrEL59rmQZgQ=.128abc09-cc8b-480a-88a0-3a0b016a61f5@github.com>
Message-ID: <_fiYTFFx1ExC4RF8yq0TX4GOZaRDRrhOm0jU2yq9U8A=.131fd409-c313-4e1f-a1d6-8fd52b9d42d2@github.com>

On Fri, 5 Apr 2024 17:22:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fix a file/class name in the `CLDRConverter` build tool, with some clean-up for a switch statement.

This pull request has now been integrated.

Changeset: dd930c57
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd930c573b2822e7f55e9d1b9a945a023c3fdee6
Stats:     393 lines in 4 files changed: 186 ins; 203 del; 4 mod

8329787: Fix typo in CLDRConverter

Reviewed-by: jlu, iris, lancea, bpb

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

PR: https://git.openjdk.org/jdk/pull/18662

From errael at raelity.com  Mon Apr  8 16:42:11 2024
From: errael at raelity.com (Ernie Rael)
Date: Mon, 8 Apr 2024 09:42:11 -0700
Subject: JEP 473: Stream Gatherers (Second Preview)
In-Reply-To: <CAKswmE59qfGcTHsd4DK2+jSXrXJ58UdsVrFhCr5c7Fh9b2S8tA@mail.gmail.com>
References: <8d9a2edb-505a-4253-bfa2-054d092f0db2@raelity.com>
 <MW4PR10MB5774C9305240C4692DACCFB0FF012@MW4PR10MB5774.namprd10.prod.outlook.com>
 <33a36ca1-b4db-4344-a868-f9993ce534ad@raelity.com>
 <CAKswmE59qfGcTHsd4DK2+jSXrXJ58UdsVrFhCr5c7Fh9b2S8tA@mail.gmail.com>
Message-ID: <b1a09d5d-ed53-42fe-abd1-9f73b897b1d1@raelity.com>

> Filter isn't many-to-... At all, at no point it collapses a 
> subsequence of elements, it only works on one element at a time 
I was conflating the behavior of a specific intermediate operation with 
a black box view of an operation. Looking at an operation as a black box 
is useless (maybe mildly interesting at most). The description of filter 
as "one-to-many" threw me off balance (this is the first time I read the 
gatherer spec in detail, and I've only looked at streams on an as need 
basis, it took this long having brief exposures till I felt ready); but 
as was said, the precise description of filter is "1-to-0..1".

I'm still curious about the idea of an "empty" input?. Seems like "many" 
on the left side is never "0", in particular something like: 
"1..N-to-SomeRange"

Thanks to all,
-ernie

PS. Looking at flatMap (and mapMulti) was a good exercise.

On 24/04/07 11:24 AM, Holo The Sage Wolf wrote:
> Think about `flatMap` (which filter is a special case of), this is 
> one-to-many function that can also return 1 or 0 elements for each 
> input. So it makes sense to include 0 as "many".
>
> Filter isn't many-to-... At all, at no point it collapses a 
> subsequence of elements, it only works on one element at a time
>
> On Sun, 7 Apr 2024, 19:31 Ernie Rael, <errael at raelity.com> wrote:
>
>     On 24/04/07 9:11 AM, Viktor Klang wrote:
>>     Hi Ernie,
>>
>>     "Many" in this case refers to "N", which is "0 ... N",
>     OK, I was wondering about "many" including "0".
>>     so I'd say while it is techincally correct as-is, perhaps more
>>     precise would be to say "1-to-0..1" gatherer, since for every
>>     element in, there is 0 or 1 element out.
>     I see.
>>
>>     Many-to-one would be 0..N -> 1, which means that an empty input
>>     would
>     "could" not "would"?
>>     yield a single output.
>
>     Out of curiosity, is either correct technically?
>
>
>     Other than at? initialization or finish, is it possible to have an
>     "empty" input?
>
>
>     -ernie
>
>>
>>     Cheers,
>>     ?
>>
>>     *
>>     *
>>     *Viktor Klang*
>>     Software Architect, Java Platform Group
>>     Oracle
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org> on behalf of Ernie Rael
>>     <errael at raelity.com> <mailto:errael at raelity.com>
>>     *Sent:* Sunday, 7 April 2024 18:06
>>     *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>>     <mailto:core-libs-dev at openjdk.org>
>>     *Subject:* JEP 473: Stream Gatherers (Second Preview)
>>
>>     This is about what might be a minor doc issue.
>>
>>     In https://openjdk.org/jeps/473 it says
>>
>>>     As another example, |Stream::filter| takes a predicate that
>>>     determines whether an input element should be passed downstream;
>>>     this is simply a stateless one-to-many gatherer.
>>     Shouldn't this be "many-to-one"?
>>
>>     -ernie
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240408/a217d863/attachment-0001.htm>

From vromero at openjdk.org  Mon Apr  8 16:48:12 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 8 Apr 2024 16:48:12 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v9]
In-Reply-To: <HA2CicFGNm0tG_DC2OgKLFEtAg6Wv-kfAa3EAhUUd2o=.8e2abb3d-431b-4582-84f6-ef562054e49d@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <HA2CicFGNm0tG_DC2OgKLFEtAg6Wv-kfAa3EAhUUd2o=.8e2abb3d-431b-4582-84f6-ef562054e49d@github.com>
Message-ID: <sE8wdu-Ite3_AyTKaXFcr6b-GdJA8R5ZtGh08C4-Q-s=.f2c6b92b-2063-4c31-a181-643897110c8d@github.com>

On Mon, 8 Apr 2024 16:21:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests as suggested.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 101:

> 99: import com.sun.tools.javac.tree.JCTree.JCPattern;
> 100: import com.sun.tools.javac.tree.JCTree.JCPatternCaseLabel;
> 101: import com.sun.tools.javac.tree.JCTree.JCDerivedInstance;

changes to this file can be removed now

test/langtools/tools/javac/patterns/withers/Model.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

probably this test should be in another location not under `patterns`, same for other tests added inside `patterns` folder

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1556130188
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1556136586

From sroy at openjdk.org  Mon Apr  8 16:58:03 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 8 Apr 2024 16:58:03 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v13]
In-Reply-To: <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
Message-ID: <8h03M57RW_xzjqK6I-9sKxVq4fsnU8RNEQlVJHIn0fY=.dc3b78dd-b068-46f1-aa4a-72080b5bc1e2@github.com>

On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update tests
>  - update tests
>  - update tests

Ok. How can i get the path of an existing .so file and renamed it to .a ? 
Example we have libawt.so. In order to rename it i need to find its path. How can i do that using Java code ? 
Do i need to parse the java library path and search in it ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2043232272

From rriggs at openjdk.org  Mon Apr  8 18:01:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Apr 2024 18:01:12 GMT
Subject: Integrated: 8329623: NegativeArraySizeException encoding large String
 to UTF-8
In-Reply-To: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
References: <UV1sSObwH2m_lqxWlu4JzYAwhvD2biw6sFn8cNbeyTc=.b60b87ba-7440-49a8-ae15-2eee0211701b@github.com>
Message-ID: <SNnYWp91UFUCmdfPq4bURYUzvRwkC5rTzqLg_LE3d0E=.b0cb77df-8448-4b92-850f-76e02210af6c@github.com>

On Fri, 5 Apr 2024 17:44:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) computation of the buffer size may exceed the range of a positive 32-bit Integer.
> If the estimated size for the result byte array is too large, pre-compute the exact buffer size. 
> If that exceeds the range, then throw OutOfMemoryError.

This pull request has now been integrated.

Changeset: 212a2536
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/212a253697b1a5e722bb90ae1140c91175fc028b
Stats:     78 lines in 2 files changed: 76 ins; 0 del; 2 mod

8329623: NegativeArraySizeException encoding large String to UTF-8

Reviewed-by: naoto, rgiulietti

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

PR: https://git.openjdk.org/jdk/pull/18663

From naoto at openjdk.org  Mon Apr  8 18:03:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Apr 2024 18:03:10 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant
In-Reply-To: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
Message-ID: <WeknLfDNR-GL0nSULJqPMQ9cN6o0d12MMIAsYJzvAlE=.4aa50e78-33ea-4254-a9a7-f4f3b411e82d@github.com>

On Mon, 8 Apr 2024 09:52:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
> 
> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
> 
> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.

src/java.base/share/classes/java/time/temporal/ChronoField.java line 590:

> 588:      * This is necessary to ensure interoperation between calendars.
> 589:      */
> 590:     // ValueRange matches the min and max epoch second supported by java.time.Instant

Would we want to include this in the javadoc?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1556219119

From sroy at openjdk.org  Mon Apr  8 18:11:43 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 8 Apr 2024 18:11:43 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v14]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <LPW6-GoaXyxCY72us4mEJ0LXyZ8K_lzz6_R88MY1gBM=.94447b99-d364-464e-b4d7-09f009d1e311@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/89b8da39..1746f554

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=12-13

  Stats: 11 lines in 2 files changed: 1 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From rriggs at openjdk.org  Mon Apr  8 18:19:11 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Apr 2024 18:19:11 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant
In-Reply-To: <WeknLfDNR-GL0nSULJqPMQ9cN6o0d12MMIAsYJzvAlE=.4aa50e78-33ea-4254-a9a7-f4f3b411e82d@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <WeknLfDNR-GL0nSULJqPMQ9cN6o0d12MMIAsYJzvAlE=.4aa50e78-33ea-4254-a9a7-f4f3b411e82d@github.com>
Message-ID: <tfq0N5V-twZt_DE17cLQejKB4mo_x-_kSjfv9t8A80s=.6157a881-9ad5-4e08-b47d-f534626674a4@github.com>

On Mon, 8 Apr 2024 18:00:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> src/java.base/share/classes/java/time/temporal/ChronoField.java line 590:
> 
>> 588:      * This is necessary to ensure interoperation between calendars.
>> 589:      */
>> 590:     // ValueRange matches the min and max epoch second supported by java.time.Instant
> 
> Would we want to include this in the javadoc?

The code should reference the constants in Instant.java (though may need to make them package private.)

The javadoc can/should reference Instant.MIN and Instant.MAX (as the test does).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1556243941

From sroy at openjdk.org  Mon Apr  8 18:19:27 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 8 Apr 2024 18:19:27 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v15]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <fTZxVgG5PALllTeBzU_X6A-K2parvoAzkaFNV0gJ8ZU=.d3dd08cf-87e3-4458-bf55-97e69de55a82@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/1746f554..66dc630a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=13-14

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

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Mon Apr  8 18:26:37 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 8 Apr 2024 18:26:37 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v16]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <mxg38cozp-1oxkudW7qFi_YmchbE55kpK-Ka9vOoULI=.83330ec9-c951-4038-9382-61b0c236892c@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/66dc630a..42820306

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=14-15

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

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Mon Apr  8 18:44:51 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 8 Apr 2024 18:44:51 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v17]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <L_QJNe1rj7r5aSshwGfYv6W140LB4Bc7pg6VIIZyirg=.3798e831-6a69-4600-bfac-9af447673660@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/42820306..f0459fc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/17945

From sgibbons at openjdk.org  Mon Apr  8 19:11:19 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 8 Apr 2024 19:11:19 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v7]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Add movq to locate_operand

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/fd6f04f7..f81aaa9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/18555

From mdoerr at openjdk.org  Mon Apr  8 19:48:14 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 8 Apr 2024 19:48:14 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v17]
In-Reply-To: <L_QJNe1rj7r5aSshwGfYv6W140LB4Bc7pg6VIIZyirg=.3798e831-6a69-4600-bfac-9af447673660@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <L_QJNe1rj7r5aSshwGfYv6W140LB4Bc7pg6VIIZyirg=.3798e831-6a69-4600-bfac-9af447673660@github.com>
Message-ID: <gz62KKckc6SIGEjc5nMjg-e79S-t96xk3A5D-WPPLWI=.72efec23-5b7f-476c-8e71-018c3ccaa74b@github.com>

On Mon, 8 Apr 2024 18:44:51 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test change

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 36:

> 34:         String libraryName = "awt";
> 35:         File awtSharedObjectPath = new File("/test/lib/libawt.so");
> 36:         File awtArchivePath = new File("/test/lib/libawt.a");

How does this work? Did you create a "/test" directory? I don't have it on my machine.

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 37:

> 35:         File awtSharedObjectPath = new File("/test/lib/libawt.so");
> 36:         File awtArchivePath = new File("/test/lib/libawt.a");
> 37:         awtSharedObjectPath.renameTo(awtArchivePath);

This should work for this test. But, what if an AWT test gets executed after your test? I think copy is safer than renaming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1556361989
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1556360137

From viktor.klang at oracle.com  Mon Apr  8 20:10:32 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 8 Apr 2024 20:10:32 +0000
Subject: [External] : Re: JEP 473: Stream Gatherers (Second Preview)
In-Reply-To: <33a36ca1-b4db-4344-a868-f9993ce534ad@raelity.com>
References: <8d9a2edb-505a-4253-bfa2-054d092f0db2@raelity.com>
 <MW4PR10MB5774C9305240C4692DACCFB0FF012@MW4PR10MB5774.namprd10.prod.outlook.com>
 <33a36ca1-b4db-4344-a868-f9993ce534ad@raelity.com>
Message-ID: <MW4PR10MB57740CE0A21A35DC5ACC1B42FF002@MW4PR10MB5774.namprd10.prod.outlook.com>

>"could" not "would"?

If the operation is strictly many-to-one, then it will always emit a single element, this means that it might need to track as a part of its state whether it has emitted something in its integrator and if not then emit it in the finisher.

But I, guess that one could reason about it from multiple levels of zoom: a Stream can have end-to-end a specific N:M-ratio, a Gatherer could have a specific N:M-ratio, and an Integrator itself could have a specific N:M-ratio.

Think of something like a `sort()`-Gatherer, it would not be able to emit anything until it has consumed all upstream elements, and it would only know that all upstream elements have been consumed once its finisher is invoked, and as a response to that it could then iterate over the entire sorted set of elements and emit them in the new order downstream.

>Other than at  initialization or finish, is it possible to have an "empty" input?

No, not an empty as in "absense of". You'd have to emit in the finisher then.



Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Ernie Rael <errael at raelity.com>
Sent: Sunday, 7 April 2024 18:31
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: JEP 473: Stream Gatherers (Second Preview)

On 24/04/07 9:11 AM, Viktor Klang wrote:
Hi Ernie,

"Many" in this case refers to "N", which is "0 ... N",
OK, I was wondering about "many" including "0".
so I'd say while it is techincally correct as-is, perhaps more precise would be to say "1-to-0..1" gatherer, since for every element in, there is 0 or 1 element out.
I see.

Many-to-one would be 0..N -> 1, which means that an empty input would
"could" not "would"?
yield a single output.

Out of curiosity, is either correct technically?


Other than at  initialization or finish, is it possible to have an "empty" input?


-ernie

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org><mailto:core-libs-dev-retn at openjdk.org> on behalf of Ernie Rael <errael at raelity.com><mailto:errael at raelity.com>
Sent: Sunday, 7 April 2024 18:06
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org><mailto:core-libs-dev at openjdk.org>
Subject: JEP 473: Stream Gatherers (Second Preview)


This is about what might be a minor doc issue.

In https://openjdk.org/jeps/473 it says

As another example, Stream::filter takes a predicate that determines whether an input element should be passed downstream; this is simply a stateless one-to-many gatherer.
Shouldn't this be "many-to-one"?

-ernie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240408/6da6416c/attachment-0001.htm>

From enikitin at openjdk.org  Mon Apr  8 21:40:21 2024
From: enikitin at openjdk.org (Evgeny Nikitin)
Date: Mon, 8 Apr 2024 21:40:21 GMT
Subject: RFR: 8325659: Normalize Random usage by incubator vector tests
Message-ID: <pQTKJS13VI6J72OWEyEsXTLQXvxjtJKAwiYH4g5PU5U=.f8adbf5a-1f75-42af-b1c2-66125db9f457@github.com>

Improve RNG usage in said tests:

1. The RNG is not created by our Utils class, as suggested in our JTReg tests;
2. The seed, accordingly, is not a fixed value now, but truly random;
3. The tests that had been creating their own Random instances, are now using RAND static member from the AbstractVectorTest;
4. The generated tests sources have been re-generated.

The most important change is #2, it could add variability and help cover more JIT Compiler and Runtime scenarios.

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

Commit messages:
 - Adjust generated tests
 - Use class member RNG vs newly created one
 - 8325659: Normalize Random usage by incubator vector tests

Changes: https://git.openjdk.org/jdk/pull/18675/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18675&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325659
  Stats: 469 lines in 69 files changed: 188 ins; 0 del; 281 mod
  Patch: https://git.openjdk.org/jdk/pull/18675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18675/head:pull/18675

PR: https://git.openjdk.org/jdk/pull/18675

From psandoz at openjdk.org  Mon Apr  8 21:40:21 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 8 Apr 2024 21:40:21 GMT
Subject: RFR: 8325659: Normalize Random usage by incubator vector tests
In-Reply-To: <pQTKJS13VI6J72OWEyEsXTLQXvxjtJKAwiYH4g5PU5U=.f8adbf5a-1f75-42af-b1c2-66125db9f457@github.com>
References: <pQTKJS13VI6J72OWEyEsXTLQXvxjtJKAwiYH4g5PU5U=.f8adbf5a-1f75-42af-b1c2-66125db9f457@github.com>
Message-ID: <MvyUgmWaiGqPAcd4RX-FCkLeHBx8Rbs3eQgOFjAnX2w=.dda78de9-7853-4299-a583-78c93da50528@github.com>

On Mon, 8 Apr 2024 10:50:00 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> Improve RNG usage in said tests:
> 
> 1. The RNG is not created by our Utils class, as suggested in our JTReg tests;
> 2. The seed, accordingly, is not a fixed value now, but truly random;
> 3. The tests that had been creating their own Random instances, are now using RAND static member from the AbstractVectorTest;
> 4. The generated tests sources have been re-generated.
> 
> The most important change is #2, it could add variability and help cover more JIT Compiler and Runtime scenarios.

Looks good, thank you for cleaning this up.

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18675#pullrequestreview-1987442519

From dlong at openjdk.org  Mon Apr  8 22:19:12 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 8 Apr 2024 22:19:12 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v7]
In-Reply-To: <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
Message-ID: <ky4p9r9CxL2JgMiOlq1zoVj0RzQXTPx34Cc34eJF8gQ=.a5b7a17a-2f55-4b97-a630-a257c5c22d6d@github.com>

On Mon, 8 Apr 2024 19:11:19 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add movq to locate_operand

Thanks, I see that my ideas have pretty much already been discussed in https://github.com/openjdk/jdk/pull/16760.  I might have missed it, but has the possibility of always setting the aligned interior region with 8 byte stores been discussed?  A literal reading of the javadoc seems to disallow it, but it seems like it should be allowed based on memory coherence.  Only the unaligned head and tail would need special treatment.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2043732829

From jpai at openjdk.org  Tue Apr  9 00:55:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 00:55:09 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant
In-Reply-To: <tfq0N5V-twZt_DE17cLQejKB4mo_x-_kSjfv9t8A80s=.6157a881-9ad5-4e08-b47d-f534626674a4@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <WeknLfDNR-GL0nSULJqPMQ9cN6o0d12MMIAsYJzvAlE=.4aa50e78-33ea-4254-a9a7-f4f3b411e82d@github.com>
 <tfq0N5V-twZt_DE17cLQejKB4mo_x-_kSjfv9t8A80s=.6157a881-9ad5-4e08-b47d-f534626674a4@github.com>
Message-ID: <N0w6m5yWI8OZjuPY6svLJnLRfhmQN0NpKK3hvRpb9Es=.78ad4a95-7842-433f-bde1-5f2d92d1a6fd@github.com>

On Mon, 8 Apr 2024 18:16:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/temporal/ChronoField.java line 590:
>> 
>>> 588:      * This is necessary to ensure interoperation between calendars.
>>> 589:      */
>>> 590:     // ValueRange matches the min and max epoch second supported by java.time.Instant
>> 
>> Would we want to include this in the javadoc?
>
> The code should reference the constants in Instant.java (though may need to make them package private.)
> 
> The javadoc can/should reference Instant.MIN and Instant.MAX (as the test does).

Hello Roger,

> The code should reference the constants in Instant.java (though may need to make them package private.)

The `ChronoField` class and the `Instant` class reside in separate packages, so making these two fields in `Instant`, package private will not help. I will have to make them public, which I think probably isn't a good idea. Unless you think we should do it? There is one other place already in the JDK where we have copy/pasted these values `src/java.base/share/classes/java/nio/file/attribute/FileTime.java`, so maybe we can continue with this copy/paste here too?

As for the javadoc, after we decide about this field access detail, I'll update it accordingly to note that the values min and max range complies with the min and max epoch seconds supported by `Instant`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1556676053

From jpai at openjdk.org  Tue Apr  9 01:18:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 01:18:24 GMT
Subject: RFR: 8329729: java/util/Properties/StoreReproducibilityTest.java times
 out
Message-ID: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>

Can I please get a review of this test-only change which proposes to address the intermittent failures in `java/util/Properties/StoreReproducibilityTest.java`? This should address https://bugs.openjdk.org/browse/JDK-8329729.

These failures in `StoreReproducibilityTest` have been observed in higher tiers where the test tasks are launched with various JVM options, one of them being `-Xcomp`. The goal of the `StoreReproducibilityTest` is to verify that the content which the `java.util.Properties` code generates for a properties file and reproducible across multiple different runs/launches of an Java application. To do that it launches a test application (using `java` command) several times within the test (for different scenarios). That comes up to a combined total of 25 launches, for different scenarios. Normally each such launch of the `java` application completes within a second or two. 

Recently, we have been updating our tests to pass along the JVM options that were used for launching the test task, to the child processes that are launched from within the tests. That now means that these trivial small java application that this test launches several times will now be passed the `-Xcomp` option too (when the test task is launched with that option). It has been observed that when `-Xcomp` is used to launch those trivial applications from within the test, each such application takes around 30 seconds to a minute to complete. This then causes the test to timeout.

Given the context of this test case, it's not necessary to run this test when `-Xcomp` is used. The commit in this PR add a `@requires` to disable this test when `-Xcomp` is present in the test task's JVM args. 

I've run this change in our CI and the test continues to run (and pass) when `-Xcomp` is absent and is skipped when it is present.

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

Commit messages:
 - 8329729: java/util/Properties/StoreReproducibilityTest.java times out

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

PR: https://git.openjdk.org/jdk/pull/18681

From jpai at openjdk.org  Tue Apr  9 01:27:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 01:27:29 GMT
Subject: RFR: 8329729: java/util/Properties/StoreReproducibilityTest.java
 times out [v2]
In-Reply-To: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>
References: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>
Message-ID: <H2AbB8X3V7_2VEBRzujIMurv1rw3q2Ie1q2W8JlerM0=.61552bee-9cc2-40ff-b2c0-daa5617b64f7@github.com>

> Can I please get a review of this test-only change which proposes to address the intermittent failures in `java/util/Properties/StoreReproducibilityTest.java`? This should address https://bugs.openjdk.org/browse/JDK-8329729.
> 
> These failures in `StoreReproducibilityTest` have been observed in higher tiers where the test tasks are launched with various JVM options, one of them being `-Xcomp`. The goal of the `StoreReproducibilityTest` is to verify that the content which the `java.util.Properties` code generates for a properties file and reproducible across multiple different runs/launches of an Java application. To do that it launches a test application (using `java` command) several times within the test (for different scenarios). That comes up to a combined total of 25 launches, for different scenarios. Normally each such launch of the `java` application completes within a second or two. 
> 
> Recently, we have been updating our tests to pass along the JVM options that were used for launching the test task, to the child processes that are launched from within the tests. That now means that these trivial small java application that this test launches several times will now be passed the `-Xcomp` option too (when the test task is launched with that option). It has been observed that when `-Xcomp` is used to launch those trivial applications from within the test, each such application takes around 30 seconds to a minute to complete. This then causes the test to timeout.
> 
> Given the context of this test case, it's not necessary to run this test when `-Xcomp` is used. The commit in this PR add a `@requires` to disable this test when `-Xcomp` is present in the test task's JVM args. 
> 
> I've run this change in our CI and the test continues to run (and pass) when `-Xcomp` is absent and is skipped when it is present.

Jaikiran Pai 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 latest from master branch
 - 8329729: java/util/Properties/StoreReproducibilityTest.java times out

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18681/files
  - new: https://git.openjdk.org/jdk/pull/18681/files/843ef6b5..8cca30dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18681&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18681&range=00-01

  Stats: 5038 lines in 90 files changed: 3546 ins; 1200 del; 292 mod
  Patch: https://git.openjdk.org/jdk/pull/18681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18681/head:pull/18681

PR: https://git.openjdk.org/jdk/pull/18681

From naoto at openjdk.org  Tue Apr  9 01:38:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Apr 2024 01:38:06 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant
In-Reply-To: <N0w6m5yWI8OZjuPY6svLJnLRfhmQN0NpKK3hvRpb9Es=.78ad4a95-7842-433f-bde1-5f2d92d1a6fd@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <WeknLfDNR-GL0nSULJqPMQ9cN6o0d12MMIAsYJzvAlE=.4aa50e78-33ea-4254-a9a7-f4f3b411e82d@github.com>
 <tfq0N5V-twZt_DE17cLQejKB4mo_x-_kSjfv9t8A80s=.6157a881-9ad5-4e08-b47d-f534626674a4@github.com>
 <N0w6m5yWI8OZjuPY6svLJnLRfhmQN0NpKK3hvRpb9Es=.78ad4a95-7842-433f-bde1-5f2d92d1a6fd@github.com>
Message-ID: <fm7NMg6DXB_4uHS4XdMdet36qn-rf9JvNZ5P0K9xM5g=.6a9b1edc-1a4a-4264-8354-54e4556efb1f@github.com>

On Tue, 9 Apr 2024 00:52:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The code should reference the constants in Instant.java (though may need to make them package private.)
>> 
>> The javadoc can/should reference Instant.MIN and Instant.MAX (as the test does).
>
> Hello Roger,
> 
>> The code should reference the constants in Instant.java (though may need to make them package private.)
> 
> The `ChronoField` class and the `Instant` class reside in separate packages, so making these two fields in `Instant`, package private will not help. I will have to make them public, which I think probably isn't a good idea. Unless you think we should do it? There is one other place already in the JDK where we have copy/pasted these values `src/java.base/share/classes/java/nio/file/attribute/FileTime.java`, so maybe we can continue with this copy/paste here too?
> 
> As for the javadoc, after we decide about this field access detail, I'll update it accordingly to note that the values min and max range complies with the min and max epoch seconds supported by `Instant`.

Should `INSTANT_SECONDS("InstantSeconds", SECONDS, FOREVER, ValueRange.of(Instant.MIN.getEpochSecond(), Instant.MAX.getEpochSecond())),
` work?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1556721063

From syan at openjdk.org  Tue Apr  9 01:41:07 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 9 Apr 2024 01:41:07 GMT
Subject: RFR: 8327486: java/util/Properties/PropertiesStoreTest.java fails
 "Text 'xxx' could not be parsed at index 20" after 8174269 [v3]
In-Reply-To: <uXMJVbzME6n126d3w9-3KcJdirDqfgovowjP80WHy2E=.2c2328d9-6d70-47b1-b134-cc026e51f3fa@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
 <uXMJVbzME6n126d3w9-3KcJdirDqfgovowjP80WHy2E=.2c2328d9-6d70-47b1-b134-cc026e51f3fa@github.com>
Message-ID: <41bPV9_faBmcZ0lwH9hi67SHwR4JYe4oM_gco4uHApg=.80b4b957-38d0-45a1-a2c4-6d84fce580fa@github.com>

On Sat, 9 Mar 2024 13:18:14 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Date.toString() uses Locale.US explicitly for printing the time zone, so replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>> 
>> This testcase fixed has been verified.
>> 
>> Only change the testcase, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the Locale.US code comment
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

> /sponsor

@DamonFool Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18155#issuecomment-2043989514

From syan at openjdk.org  Tue Apr  9 01:41:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 9 Apr 2024 01:41:06 GMT
Subject: RFR: 8327486: java/util/Properties/PropertiesStoreTest.java fails
 "Text 'xxx' could not be parsed at index 20" after 8174269 [v3]
In-Reply-To: <JWjDHa4em1JDLh1DAPV2ih_UbUh5t2qz39li_GuxBrE=.85795349-4a43-4c00-96dd-1467817554c7@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
 <uXMJVbzME6n126d3w9-3KcJdirDqfgovowjP80WHy2E=.2c2328d9-6d70-47b1-b134-cc026e51f3fa@github.com>
 <JWjDHa4em1JDLh1DAPV2ih_UbUh5t2qz39li_GuxBrE=.85795349-4a43-4c00-96dd-1467817554c7@github.com>
Message-ID: <gv1WcKIVc94TSVEYgQZ0znhTLHnCxnSiXcG1absMwzQ=.280ce9e0-a310-47a5-823b-9ca0cb3d9c92@github.com>

On Mon, 11 Mar 2024 15:15:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> LGTM

@naotoj Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18155#issuecomment-2043989340

From syan at openjdk.org  Tue Apr  9 01:51:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 9 Apr 2024 01:51:14 GMT
Subject: RFR: 8326461: tools/jlink/CheckExecutable.java fails as .debuginfo
 files are not executable
In-Reply-To: <H-EUI3mBbwHjhzj76gd8hDfRDPs1RgeKzkJOEZundJU=.e577a246-2909-4692-894d-7e10b2c5473c@github.com>
References: <H-EUI3mBbwHjhzj76gd8hDfRDPs1RgeKzkJOEZundJU=.e577a246-2909-4692-894d-7e10b2c5473c@github.com>
Message-ID: <mljM7y4dsjRfNstoxpuxCvJm6J56exuoVpHqi1GPo-s=.c1d8a551-9ee1-4832-8a5d-e5267f3a7ad5@github.com>

On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan <syan at openjdk.org> wrote:

> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-7125-4d09-8793-8a5a10b785c2)
> 
> 
> After JDK-8325342, all the *.debuginfo files in build/linux-x86_64-server-release/images/jdk/bin are not executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/c8d190f2-3db0-439b-82b9-5121567cb1d5)
> 
> 
> This PR only modifies the testcase to adapt to the modification of the corresponding build script, ignoring the check of debuginfo file executable permissions, and the risk is low

> /sponsor

@shipilev @AlanBateman Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17958#issuecomment-2043997665

From syan at openjdk.org  Tue Apr  9 01:54:18 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 9 Apr 2024 01:54:18 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v3]
In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
Message-ID: <x47N3T-ft00FFdjWzImGgebY2W5F5lnj6HpjDWzEaoc=.0090ce6c-615d-4181-9c8d-4f8e82df6ce3@github.com>

On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

> /sponsor

@jerboaa Thanks for the review and the sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-2044000397

From alanb at openjdk.org  Tue Apr  9 05:54:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 05:54:11 GMT
Subject: RFR: 8329729: java/util/Properties/StoreReproducibilityTest.java
 times out [v2]
In-Reply-To: <H2AbB8X3V7_2VEBRzujIMurv1rw3q2Ie1q2W8JlerM0=.61552bee-9cc2-40ff-b2c0-daa5617b64f7@github.com>
References: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>
 <H2AbB8X3V7_2VEBRzujIMurv1rw3q2Ie1q2W8JlerM0=.61552bee-9cc2-40ff-b2c0-daa5617b64f7@github.com>
Message-ID: <SQA4sMD-gvCEv0r70qX9uxkGcsMl7PTNinnERb4bmIw=.e2f5392f-f76c-450a-b3ae-a77f830ec372@github.com>

On Tue, 9 Apr 2024 01:27:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to address the intermittent failures in `java/util/Properties/StoreReproducibilityTest.java`? This should address https://bugs.openjdk.org/browse/JDK-8329729.
>> 
>> These failures in `StoreReproducibilityTest` have been observed in higher tiers where the test tasks are launched with various JVM options, one of them being `-Xcomp`. The goal of the `StoreReproducibilityTest` is to verify that the content which the `java.util.Properties` code generates for a properties file and reproducible across multiple different runs/launches of an Java application. To do that it launches a test application (using `java` command) several times within the test (for different scenarios). That comes up to a combined total of 25 launches, for different scenarios. Normally each such launch of the `java` application completes within a second or two. 
>> 
>> Recently, we have been updating our tests to pass along the JVM options that were used for launching the test task, to the child processes that are launched from within the tests. That now means that these trivial small java application that this test launches several times will now be passed the `-Xcomp` option too (when the test task is launched with that option). It has been observed that when `-Xcomp` is used to launch those trivial applications from within the test, each such application takes around 30 seconds to a minute to complete. This then causes the test to timeout.
>> 
>> Given the context of this test case, it's not necessary to run this test when `-Xcomp` is used. The commit in this PR add a `@requires` to disable this test when `-Xcomp` is present in the test task's JVM args. 
>> 
>> I've run this change in our CI and the test continues to run (and pass) when `-Xcomp` is absent and is skipped when it is present.
>
> Jaikiran Pai 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 latest from master branch
>  - 8329729: java/util/Properties/StoreReproducibilityTest.java times out

Looks fine. If you can want, the comment could be much shorter. It just has to say that the test launches several processes and is too just with -Xcomp.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18681#pullrequestreview-1988155446

From mcimadamore at openjdk.org  Tue Apr  9 08:17:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 Apr 2024 08:17:02 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v4]
In-Reply-To: <tBmcxcgnfC4Pq_GP93yFAe6W4bsI72i-IPK8htuIoG0=.cd3b62a0-fdcb-49dc-a103-ce217075428b@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <zaaY3TupJSFFwIkLPI9GHQvPnT1-rev4AuP2_rqO3aM=.8ba12ab3-b288-4558-b1b9-ade436f8e896@github.com>
 <tBmcxcgnfC4Pq_GP93yFAe6W4bsI72i-IPK8htuIoG0=.cd3b62a0-fdcb-49dc-a103-ce217075428b@github.com>
Message-ID: <Je2x0tgW-MFQyf1qv2A1zOqvF6_F2hcAWVCeDPfPfoo=.ccbc8160-75fa-43eb-a113-f0d956e86573@github.com>

On Fri, 5 Apr 2024 02:40:16 GMT, Dean Long <dlong at openjdk.org> wrote:

> That way C2 can do all its usual optimizations, like unrolling, vectorization, and redundant store elimination (if it is an on-heap primitive array that was just allocated, then there is no need to zero the parts that are being "set").

I second that. It is something that came up quite frequently in the discussions around the FFM API.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2044409509

From jpai at openjdk.org  Tue Apr  9 08:18:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 08:18:21 GMT
Subject: RFR: 8329729: java/util/Properties/StoreReproducibilityTest.java
 times out [v2]
In-Reply-To: <H2AbB8X3V7_2VEBRzujIMurv1rw3q2Ie1q2W8JlerM0=.61552bee-9cc2-40ff-b2c0-daa5617b64f7@github.com>
References: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>
 <H2AbB8X3V7_2VEBRzujIMurv1rw3q2Ie1q2W8JlerM0=.61552bee-9cc2-40ff-b2c0-daa5617b64f7@github.com>
Message-ID: <4sW3L15WEAiySZGIUK6RYQeOQEWvPGi69Pc3ppJdTfY=.65829f60-db85-4b33-9a5c-f9cb1599a2cd@github.com>

On Tue, 9 Apr 2024 01:27:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to address the intermittent failures in `java/util/Properties/StoreReproducibilityTest.java`? This should address https://bugs.openjdk.org/browse/JDK-8329729.
>> 
>> These failures in `StoreReproducibilityTest` have been observed in higher tiers where the test tasks are launched with various JVM options, one of them being `-Xcomp`. The goal of the `StoreReproducibilityTest` is to verify that the content which the `java.util.Properties` code generates for a properties file and reproducible across multiple different runs/launches of an Java application. To do that it launches a test application (using `java` command) several times within the test (for different scenarios). That comes up to a combined total of 25 launches, for different scenarios. Normally each such launch of the `java` application completes within a second or two. 
>> 
>> Recently, we have been updating our tests to pass along the JVM options that were used for launching the test task, to the child processes that are launched from within the tests. That now means that these trivial small java application that this test launches several times will now be passed the `-Xcomp` option too (when the test task is launched with that option). It has been observed that when `-Xcomp` is used to launch those trivial applications from within the test, each such application takes around 30 seconds to a minute to complete. This then causes the test to timeout.
>> 
>> Given the context of this test case, it's not necessary to run this test when `-Xcomp` is used. The commit in this PR add a `@requires` to disable this test when `-Xcomp` is present in the test task's JVM args. 
>> 
>> I've run this change in our CI and the test continues to run (and pass) when `-Xcomp` is absent and is skipped when it is present.
>
> Jaikiran Pai 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 latest from master branch
>  - 8329729: java/util/Properties/StoreReproducibilityTest.java times out

Hello Alan, thank you for the review. I've shortened the test's comment as per your suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/18681#issuecomment-2044409962

From jpai at openjdk.org  Tue Apr  9 08:18:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 08:18:20 GMT
Subject: RFR: 8329729: java/util/Properties/StoreReproducibilityTest.java
 times out [v3]
In-Reply-To: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>
References: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>
Message-ID: <RYIFihhGopr6JsY54VD-4O7u8ocHHglEMYeucj15dCM=.ae4e24f8-e344-4a62-9b69-4186222a0533@github.com>

> Can I please get a review of this test-only change which proposes to address the intermittent failures in `java/util/Properties/StoreReproducibilityTest.java`? This should address https://bugs.openjdk.org/browse/JDK-8329729.
> 
> These failures in `StoreReproducibilityTest` have been observed in higher tiers where the test tasks are launched with various JVM options, one of them being `-Xcomp`. The goal of the `StoreReproducibilityTest` is to verify that the content which the `java.util.Properties` code generates for a properties file and reproducible across multiple different runs/launches of an Java application. To do that it launches a test application (using `java` command) several times within the test (for different scenarios). That comes up to a combined total of 25 launches, for different scenarios. Normally each such launch of the `java` application completes within a second or two. 
> 
> Recently, we have been updating our tests to pass along the JVM options that were used for launching the test task, to the child processes that are launched from within the tests. That now means that these trivial small java application that this test launches several times will now be passed the `-Xcomp` option too (when the test task is launched with that option). It has been observed that when `-Xcomp` is used to launch those trivial applications from within the test, each such application takes around 30 seconds to a minute to complete. This then causes the test to timeout.
> 
> Given the context of this test case, it's not necessary to run this test when `-Xcomp` is used. The commit in this PR add a `@requires` to disable this test when `-Xcomp` is present in the test task's JVM args. 
> 
> I've run this change in our CI and the test continues to run (and pass) when `-Xcomp` is absent and is skipped when it is present.

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

  Alan's suggestion - shorten the test comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18681/files
  - new: https://git.openjdk.org/jdk/pull/18681/files/8cca30dc..692eb90e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18681&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18681&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/18681

From jpai at openjdk.org  Tue Apr  9 08:37:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 08:37:29 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
Message-ID: <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
> 
> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
> 
> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.

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

  Naoto's suggestion - use Instant.MIN and Instant.MAX instead of hardcoded values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18674/files
  - new: https://git.openjdk.org/jdk/pull/18674/files/1fea0f71..6e535779

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18674&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18674&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18674/head:pull/18674

PR: https://git.openjdk.org/jdk/pull/18674

From jpai at openjdk.org  Tue Apr  9 08:37:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 08:37:29 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <fm7NMg6DXB_4uHS4XdMdet36qn-rf9JvNZ5P0K9xM5g=.6a9b1edc-1a4a-4264-8354-54e4556efb1f@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <WeknLfDNR-GL0nSULJqPMQ9cN6o0d12MMIAsYJzvAlE=.4aa50e78-33ea-4254-a9a7-f4f3b411e82d@github.com>
 <tfq0N5V-twZt_DE17cLQejKB4mo_x-_kSjfv9t8A80s=.6157a881-9ad5-4e08-b47d-f534626674a4@github.com>
 <N0w6m5yWI8OZjuPY6svLJnLRfhmQN0NpKK3hvRpb9Es=.78ad4a95-7842-433f-bde1-5f2d92d1a6fd@github.com>
 <fm7NMg6DXB_4uHS4XdMdet36qn-rf9JvNZ5P0K9xM5g=.6a9b1edc-1a4a-4264-8354-54e4556efb1f@github.com>
Message-ID: <0uXJDc_7vTPCrReRu6X5u8W2sSIQu695b57YyyffUpw=.35967499-34c5-4cc0-b8ec-2bb396c8ec46@github.com>

On Tue, 9 Apr 2024 01:34:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello Roger,
>> 
>>> The code should reference the constants in Instant.java (though may need to make them package private.)
>> 
>> The `ChronoField` class and the `Instant` class reside in separate packages, so making these two fields in `Instant`, package private will not help. I will have to make them public, which I think probably isn't a good idea. Unless you think we should do it? There is one other place already in the JDK where we have copy/pasted these values `src/java.base/share/classes/java/nio/file/attribute/FileTime.java`, so maybe we can continue with this copy/paste here too?
>> 
>> As for the javadoc, after we decide about this field access detail, I'll update it accordingly to note that the values min and max range complies with the min and max epoch seconds supported by `Instant`.
>
> Should `INSTANT_SECONDS("InstantSeconds", SECONDS, FOREVER, ValueRange.of(Instant.MIN.getEpochSecond(), Instant.MAX.getEpochSecond())),
> ` work?

Hello Naoto, that's a very good point. I was too caught up with the constant values that it didn't occur to me that the `Instant.MIN` and `Instant.MAX` public fields could be used for this. I have followed your suggestion and updated the PR. I have also updated the javadoc to link to `Instant.MIN` and `Instant.MAX` as the supported epoch second range.

The test continues to pass with this change and fails (as expected) without the source change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1557216492

From asotona at openjdk.org  Tue Apr  9 08:44:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 08:44:03 GMT
Subject: Integrated: 8326744: Class-File API transition to Second Preview
In-Reply-To: <bHBXoOarwcHAJa8geMS-YlHdV9IfvS-anumPxyh8qDE=.e70c8b60-3640-4c06-b9ec-d23b22fd64bd@github.com>
References: <bHBXoOarwcHAJa8geMS-YlHdV9IfvS-anumPxyh8qDE=.e70c8b60-3640-4c06-b9ec-d23b22fd64bd@github.com>
Message-ID: <If9ei8lEZjGoG7GfJ6AeEk7d_2mQNStQLyIBCVrIO9c=.a6e2d7a1-f81b-495d-a536-a46be11d8207@github.com>

On Tue, 27 Feb 2024 08:45:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Task providing Class-File API transition to Second Preview.

This pull request has now been integrated.

Changeset: 19a99d02
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19a99d023e32fa9f4d26b76bd36993719e1dfe21
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8326744: Class-File API transition to Second Preview

Reviewed-by: jlahoda

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

PR: https://git.openjdk.org/jdk/pull/18021

From jlahoda at openjdk.org  Tue Apr  9 08:53:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 08:53:02 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v8]
In-Reply-To: <B36ahBT-Byi3Z52KLTRFFkYRH50jSeZGL7PW64WBE60=.4f62075d-1bc6-48f1-bbee-f3b76d1ecec3@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <0k62PoyjaMG_YZw-xV9T1H2q7W9JYCeoCx6VOcZoVRQ=.2089eb99-3979-4b48-af9d-9dff89a4068a@github.com>
 <B36ahBT-Byi3Z52KLTRFFkYRH50jSeZGL7PW64WBE60=.4f62075d-1bc6-48f1-bbee-f3b76d1ecec3@github.com>
Message-ID: <R8bCspHnxSsNV11ojOSWCX4dxudzBzegG-igWV2_Dy4=.e6336225-dc16-46c8-ab9c-9af855d5990b@github.com>

On Fri, 5 Apr 2024 18:30:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback:
>>   - pre-generating the JCVarDecls in Attr, to aid Flow
>>   - adding a note on how the desugared code looks like
>
> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 135:
> 
>> 133:     COMPONENT_LOCAL_VARIABLE;
>> 134: 
>> 135:     // Maintenance note: check if the default implementation of
> 
> From a quick look, I don't think Elements.getOutermostTypeElement needs updating for COMPONENT_LOCAL_VARIABLE, but it would be good to add a test case.

Tests added: https://github.com/openjdk/jdk/pull/18509/commits/e09306885e5c6cd2aba7779025fc7efcb8991e8e

Thanks!

> src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java line 91:
> 
>> 89: 
>> 90:     /**
>> 91:      * {@inheritDoc ElementKindVisitor6}
> 
> If possible, would be good to add some minimal testing/use of the element kind visitors on component local variables.

Tests added: https://github.com/openjdk/jdk/pull/18509/commits/e09306885e5c6cd2aba7779025fc7efcb8991e8e

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1557243414
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1557243525

From jlahoda at openjdk.org  Tue Apr  9 09:00:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 09:00:09 GMT
Subject: RFR: 8329527: Opcode.IFNONNULL.primaryTypeKind() is not
 ReferenceType
In-Reply-To: <GCAjVjLuCMwjMYVac3LXuPRayFffbsoUraQkqbwlW44=.89d26e9c-b406-4aee-b801-bf1b9c81e114@github.com>
References: <GCAjVjLuCMwjMYVac3LXuPRayFffbsoUraQkqbwlW44=.89d26e9c-b406-4aee-b801-bf1b9c81e114@github.com>
Message-ID: <McHMveVgK0u2ODfkUA9ZC4P8byCvGwge7nahfTiEkYQ=.d663c27c-6866-44cc-b7ba-647e58589ec2@github.com>

On Wed, 3 Apr 2024 08:15:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `Opcode.IFNONNULL.primaryTypeKind()` wrongly returned `IntType` instead of the right `ReferenceType`.
> Primary type kinds of `BRANCH` opcodes have yet no functional effect in the Class-File API.
> This simple patch fixes the typo.
> 
> Please review.
> 
> Thank you,
> Adam

Looks good.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18593#pullrequestreview-1988500479

From jlahoda at openjdk.org  Tue Apr  9 09:01:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 09:01:13 GMT
Subject: RFR: 8325485: IncrementInstructions.of(int,
 int) is not storing the args [v2]
In-Reply-To: <WV0JKwzHeWnS73Jk2K4PZlVjy8-lUxxIKLx85QPEWIw=.23fa1158-3b08-41f8-a619-46482ea919fd@github.com>
References: <ummlnEnYJX872pPmGfm1EXcGqqswpbC7b4_29bEUDpg=.8986e6e4-c49f-4a97-a216-c78082259fb7@github.com>
 <WV0JKwzHeWnS73Jk2K4PZlVjy8-lUxxIKLx85QPEWIw=.23fa1158-3b08-41f8-a619-46482ea919fd@github.com>
Message-ID: <17Vjow6a2Z2UxLGwPSSI13KArSv9GLcgKNCUU2ousFM=.c3812f37-bc15-4e63-8b2c-6021ec1cc04c@github.com>

On Fri, 9 Feb 2024 10:47:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API provides two sets of instructions implementations (bound and unbound).
>> Unbound implementation of `IncrementInstruction::constant` returns invalid value. 
>> This bug discovered a hole in the ClassFile API test coverage.
>> 
>> This patch provides very simple fix of `IncrementInstruction`
>> and more complex fix of the test framework to cover all unbound instruction with automated tests.
>> 
>> The test framework fix includes correction of hash calculation of instructions in `ClassRecord` and
>> two-pass transformation in `RebuildingTransformation`. Second pass has been added to discover bugs in unbound-to-unbound instruction conversions.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17770#pullrequestreview-1988500946

From jlahoda at openjdk.org  Tue Apr  9 09:28:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 09:28:23 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v10]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

  Reflecting review feedback:
  - reverting unnecessary changes in TransPatterns
  - moving the patters/withers/Model test to a more appropriate place

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/e0930688..a05480cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=08-09

  Stats: 37 lines in 4 files changed: 14 ins; 17 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

PR: https://git.openjdk.org/jdk/pull/18509

From jlahoda at openjdk.org  Tue Apr  9 09:28:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 09:28:23 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v9]
In-Reply-To: <sE8wdu-Ite3_AyTKaXFcr6b-GdJA8R5ZtGh08C4-Q-s=.f2c6b92b-2063-4c31-a181-643897110c8d@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <HA2CicFGNm0tG_DC2OgKLFEtAg6Wv-kfAa3EAhUUd2o=.8e2abb3d-431b-4582-84f6-ef562054e49d@github.com>
 <sE8wdu-Ite3_AyTKaXFcr6b-GdJA8R5ZtGh08C4-Q-s=.f2c6b92b-2063-4c31-a181-643897110c8d@github.com>
Message-ID: <c2wx-XUPUDVyhBmf5bPyK7KR4HUd9zYqE_8EjoGB2Is=.c4fb87d3-3d66-466e-8b72-dcb03c4a5dee@github.com>

On Mon, 8 Apr 2024 16:36:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding tests as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 101:
> 
>> 99: import com.sun.tools.javac.tree.JCTree.JCPattern;
>> 100: import com.sun.tools.javac.tree.JCTree.JCPatternCaseLabel;
>> 101: import com.sun.tools.javac.tree.JCTree.JCDerivedInstance;
> 
> changes to this file can be removed now

Thanks, removed:
https://github.com/openjdk/jdk/pull/18509/commits/a05480cd1a436014ba00505db71d54d82a37ecd1

> test/langtools/tools/javac/patterns/withers/Model.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> probably this test should be in another location not under `patterns`, same for other tests added inside `patterns` folder

Thanks, moved:
https://github.com/openjdk/jdk/pull/18509/commits/a05480cd1a436014ba00505db71d54d82a37ecd1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1557304771
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1557304921

From asotona at openjdk.org  Tue Apr  9 09:32:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 09:32:38 GMT
Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory
 methods  accepting Opcode [v4]
In-Reply-To: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
References: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
Message-ID: <0HaASAfZR1oL9lX_aokjW3zb_HAFz8rjMdAbV-3zv6I=.00d4ace6-6f41-41e8-8d20-dc07229ae15d@github.com>

> `IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented:
> 
> - `ArrayLoadInstruction`
> - `ArrayStoreInstruction`
> - `BranchInstruction`
> - `ConvertInstruction`
> - `DiscontinuedInstruction`
> - `FieldInstruction`
> - `InvokeInstruction`
> - `LoadInstruction`
> - `MonitorInstruction`
> - `NewPrimitiveArrayInstruction`
> - `OperatorInstruction`
> - `ReturnInstruction`
> - `StackInstruction`
> - `StoreInstruction`
> - `TypeCheckInstruction`
> 
> `NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument.
> 
> This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check.
> 
> Please review.
> 
> Thank you,
> Adam

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

  added NPE statement to package-info

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18578/files
  - new: https://git.openjdk.org/jdk/pull/18578/files/71165f1e..7af3f7c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18578&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18578&range=02-03

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18578/head:pull/18578

PR: https://git.openjdk.org/jdk/pull/18578

From asotona at openjdk.org  Tue Apr  9 09:38:14 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 09:38:14 GMT
Subject: Integrated: 8329527: Opcode.IFNONNULL.primaryTypeKind() is not
 ReferenceType
In-Reply-To: <GCAjVjLuCMwjMYVac3LXuPRayFffbsoUraQkqbwlW44=.89d26e9c-b406-4aee-b801-bf1b9c81e114@github.com>
References: <GCAjVjLuCMwjMYVac3LXuPRayFffbsoUraQkqbwlW44=.89d26e9c-b406-4aee-b801-bf1b9c81e114@github.com>
Message-ID: <mvxDWhh3urEG-cRWx1tHRhP5jOgrhsrwLYJc_RyF1Iw=.5e6ae865-fa18-4996-ac86-e76c0fc6d88e@github.com>

On Wed, 3 Apr 2024 08:15:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `Opcode.IFNONNULL.primaryTypeKind()` wrongly returned `IntType` instead of the right `ReferenceType`.
> Primary type kinds of `BRANCH` opcodes have yet no functional effect in the Class-File API.
> This simple patch fixes the typo.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 71c5bbce
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71c5bbcec7052a8394dd49c0a8c46801adbfcae4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8329527: Opcode.IFNONNULL.primaryTypeKind() is not ReferenceType

Reviewed-by: jlahoda

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

PR: https://git.openjdk.org/jdk/pull/18593

From sgehwolf at openjdk.org  Tue Apr  9 09:48:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 9 Apr 2024 09:48:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
Message-ID: <44E_TpjVa9rDhYIHl_1BYjpR721_p4xrAvOBYc95m3w=.4882f3ae-076b-46d1-9fe6-3201d04305e2@github.com>

On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move CreateLinkableRuntimePlugin to build folder
>>   
>>   Keep runtime link supporting classes in package
>>   jdk.tools.jlink.internal.runtimelink
>
> Thanks for the investigation w.r.t. extending jimage.  It does not seem worth the effort in pursuing the support of adding resources to an existing jimage file.   To me, putting the diff data under `lib` directory as a private file is a simpler and acceptable solution.   It allows the second jlink invocation to avoid the plugin pipeline if the per-module metadata is generated in normal jlink invocation.
> 
> (An observation: The current implementation requires the diffs to be generated as a plugin.  For this approach, it may be possible to implement with a separate main class that calls JLink API and generates the diffs.)

@mlchung @AlanBateman Any thoughts on this latest version? Is this going into the direction you had envisioned? Any more blockers? The CSR should be up-to-date and is open for review as well. If no more blockers I'll go over this patch once more and clean it up to prepare for integration. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2044593102

From vklang at openjdk.org  Tue Apr  9 10:00:38 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 9 Apr 2024 10:00:38 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped streams
Message-ID: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>

This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.

Below is the performance of `Stream::flatMap` (for reference types):

Before this PR:


Benchmark            (size)   Mode  Cnt        Score       Error  Units
FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s


After this PR:


Benchmark            (size)   Mode  Cnt        Score        Error  Units
FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s

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

Commit messages:
 - Adding JavaDoc to isShortCircuitingPipeline()
 - Removing the use of @Stable
 - Adding conditional logic to optimize for non-shortcircuiting flatmaps
 - Converting the Int/Long/DoublePipelines
 - Switching flatMap implementations to ones inspired by Gatherer encoding

Changes: https://git.openjdk.org/jdk/pull/18625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8196106
  Stats: 409 lines in 8 files changed: 236 ins; 84 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/18625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18625/head:pull/18625

PR: https://git.openjdk.org/jdk/pull/18625

From vklang at openjdk.org  Tue Apr  9 10:00:38 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 9 Apr 2024 10:00:38 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <hyBNY-T0J46X8dBqKy1j8NKWx51I7S9D5iFrWGNZdy0=.2a5821c1-4440-4e74-b72b-3a409caca60c@github.com>

On Thu, 4 Apr 2024 12:18:07 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
> 
> 
> After this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score        Error  Units
> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s

@PaulSandoz @AlanBateman I've added a commit to this PR which removes the use of Gatherer for Stream::flatMap, but instead implements flatMap for all of the pipelines using the same encoding which Gatherer would use. It seems very competitive performance-wise, and resolves at least one open JBS-issue with flatMap (will look to see if it resolves more than that)

src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 436:

> 434:      }
> 435: 
> 436:     /**

Note to self, update Copyright year to 2024

src/java.base/share/classes/java/util/stream/GathererOp.java line 30:

> 28: 
> 29: import java.lang.invoke.MethodHandles;
> 30: import java.lang.invoke.VarHandle;

Note to self, update copyright year

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

PR Comment: https://git.openjdk.org/jdk/pull/18625#issuecomment-2042381405
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1557358718
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1557359258

From psandoz at openjdk.org  Tue Apr  9 10:00:38 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 9 Apr 2024 10:00:38 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams
In-Reply-To: <hyBNY-T0J46X8dBqKy1j8NKWx51I7S9D5iFrWGNZdy0=.2a5821c1-4440-4e74-b72b-3a409caca60c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <hyBNY-T0J46X8dBqKy1j8NKWx51I7S9D5iFrWGNZdy0=.2a5821c1-4440-4e74-b72b-3a409caca60c@github.com>
Message-ID: <8bqF5vEbKODzCBUAWjw111-IUDoBPKAen8T5hGqiwOY=.a0128c2f-e0c2-40f0-a9c3-7db63db9bfef@github.com>

On Mon, 8 Apr 2024 10:20:11 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> @PaulSandoz @AlanBateman I've added a commit to this PR which removes the use of Gatherer for Stream::flatMap, but instead implements flatMap for all of the pipelines using the same encoding which Gatherer would use. It seems very competitive performance-wise, and resolves at least one open JBS-issue with flatMap (will look to see if it resolves more than that)

That's a rather clever use of `allMatch`!

Did you observe performance improvements using `@Stable` on the `cancel` field? It's really hard to predict in the abstract (since the default value of the field will be read in proportion to the number of elements until the stream is cancelled).

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

PR Comment: https://git.openjdk.org/jdk/pull/18625#issuecomment-2043218633

From vklang at openjdk.org  Tue Apr  9 10:00:38 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 9 Apr 2024 10:00:38 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams
In-Reply-To: <8bqF5vEbKODzCBUAWjw111-IUDoBPKAen8T5hGqiwOY=.a0128c2f-e0c2-40f0-a9c3-7db63db9bfef@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <hyBNY-T0J46X8dBqKy1j8NKWx51I7S9D5iFrWGNZdy0=.2a5821c1-4440-4e74-b72b-3a409caca60c@github.com>
 <8bqF5vEbKODzCBUAWjw111-IUDoBPKAen8T5hGqiwOY=.a0128c2f-e0c2-40f0-a9c3-7db63db9bfef@github.com>
Message-ID: <yuhqDkNsJcIkn9DQxcyB7K-nnF5WDaAWhEdQoY5B10Y=.5b2b78b2-64a7-4137-b08a-fedc9c002f92@github.com>

On Mon, 8 Apr 2024 16:47:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > @PaulSandoz @AlanBateman I've added a commit to this PR which removes the use of Gatherer for Stream::flatMap, but instead implements flatMap for all of the pipelines using the same encoding which Gatherer would use. It seems very competitive performance-wise, and resolves at least one open JBS-issue with flatMap (will look to see if it resolves more than that)
> 
> That's a rather clever use of `allMatch`!

Thank you :)

> 
> Did you observe performance improvements using `@Stable` on the `cancel` field? It's really hard to predict in the abstract (since the default value of the field will be read in proportion to the number of elements until the stream is cancelled).

I'm currently exploring some different venues for optimization. Stay tuned :)

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

PR Comment: https://git.openjdk.org/jdk/pull/18625#issuecomment-2043559783

From sroy at openjdk.org  Tue Apr  9 10:05:15 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 9 Apr 2024 10:05:15 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v17]
In-Reply-To: <gz62KKckc6SIGEjc5nMjg-e79S-t96xk3A5D-WPPLWI=.72efec23-5b7f-476c-8e71-018c3ccaa74b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <L_QJNe1rj7r5aSshwGfYv6W140LB4Bc7pg6VIIZyirg=.3798e831-6a69-4600-bfac-9af447673660@github.com>
 <gz62KKckc6SIGEjc5nMjg-e79S-t96xk3A5D-WPPLWI=.72efec23-5b7f-476c-8e71-018c3ccaa74b@github.com>
Message-ID: <-_HBuQ_BnCR50XDI9rDO0R1hdKb_i7W89K4dzI5KqOg=.9876aca9-9d71-4fee-bfba-a11e2218ebd3@github.com>

On Mon, 8 Apr 2024 19:45:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test change
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 36:
> 
>> 34:         String libraryName = "awt";
>> 35:         File awtSharedObjectPath = new File("/test/lib/libawt.so");
>> 36:         File awtArchivePath = new File("/test/lib/libawt.a");
> 
> How does this work? Did you create a "/test" directory? I don't have it on my machine.

I am not 100% sure. I think it is a temporary directory under jtreg. I referred to the other test under loadLibrary. @mlchung  Could you clarify this ?

> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 37:
> 
>> 35:         File awtSharedObjectPath = new File("/test/lib/libawt.so");
>> 36:         File awtArchivePath = new File("/test/lib/libawt.a");
>> 37:         awtSharedObjectPath.renameTo(awtArchivePath);
> 
> This should work for this test. But, what if an AWT test gets executed after your test? I think copy is safer than renaming.

Maybe i need to rename it back. If we just copy, it would take the .so itself, so we cant enforce it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1557366150
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1557365063

From vklang at openjdk.org  Tue Apr  9 10:07:46 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 9 Apr 2024 10:07:46 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v2]
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <XxUidI9csWKBzCHIceyCYY7dN8zT4PB0rSEIJ9Y1QvQ=.7a2e0c61-0227-4bc4-bdb2-3c69c9673563@github.com>

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
> 
> 
> After this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score        Error  Units
> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s

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

  Updating copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18625/files
  - new: https://git.openjdk.org/jdk/pull/18625/files/e31c764f..3ff40739

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/18625

From vklang at openjdk.org  Tue Apr  9 10:07:46 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 9 Apr 2024 10:07:46 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <QRuU5-c4rNTQNkjdbgnqItVhj8rLS0uRqXFe9puwOmA=.8ca52c84-9225-4d95-ae58-62c32745cd50@github.com>

On Thu, 4 Apr 2024 12:18:07 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
> 
> 
> After this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score        Error  Units
> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s

@AlanBateman @PaulSandoz Moving this to a candidate PR, see the updated description for performance numbers, the sequential improvements are very encouraging, as well as the improvements which addresses https://bugs.openjdk.org/browse/JDK-8196106

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

PR Comment: https://git.openjdk.org/jdk/pull/18625#issuecomment-2044624899

From vklang at openjdk.org  Tue Apr  9 10:07:46 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 9 Apr 2024 10:07:46 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v2]
In-Reply-To: <XxUidI9csWKBzCHIceyCYY7dN8zT4PB0rSEIJ9Y1QvQ=.7a2e0c61-0227-4bc4-bdb2-3c69c9673563@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <XxUidI9csWKBzCHIceyCYY7dN8zT4PB0rSEIJ9Y1QvQ=.7a2e0c61-0227-4bc4-bdb2-3c69c9673563@github.com>
Message-ID: <pPfCk_ngYUib5ZMTQ-Um27QaJ1hwOyHJeId_iIoxEGI=.b08682e6-b4f3-4ac9-849f-b16d49ed1b7c@github.com>

On Tue, 9 Apr 2024 10:04:44 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
>> 
>> Below is the performance of `Stream::flatMap` (for reference types):
>> 
>> Before this PR:
>> 
>> 
>> Benchmark            (size)   Mode  Cnt        Score       Error  Units
>> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
>> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
>> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
>> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
>> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
>> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
>> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
>> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
>> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
>> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
>> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
>> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
>> 
>> 
>> After this PR:
>> 
>> 
>> Benchmark            (size)   Mode  Cnt        Score        Error  Units
>> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
>> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
>> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
>> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
>> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
>> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
>> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
>> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
>> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
>> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
>> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
>> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year

src/java.base/share/classes/java/util/stream/DoublePipeline.java line 268:

> 266:                 class FlatMap implements Sink.OfDouble, DoublePredicate {
> 267:                     boolean cancel;
> 268:                     private final boolean shorts = isShortCircuitingPipeline();

If there's a known, short-circuiting, operation in the pipeline, we have to use `allMatch` but in the case where we know that there's nothing which could short-circuit we can go down a fast-path to `forEach`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1557369039

From asotona at openjdk.org  Tue Apr  9 11:11:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 11:11:20 GMT
Subject: Integrated: 8325485: IncrementInstructions.of(int,
 int) is not storing the args
In-Reply-To: <ummlnEnYJX872pPmGfm1EXcGqqswpbC7b4_29bEUDpg=.8986e6e4-c49f-4a97-a216-c78082259fb7@github.com>
References: <ummlnEnYJX872pPmGfm1EXcGqqswpbC7b4_29bEUDpg=.8986e6e4-c49f-4a97-a216-c78082259fb7@github.com>
Message-ID: <xLdbg1tOEK7vmrLJYL60_lZu8mTKERcUPzq_cq1aRfE=.61445461-3c4a-4ce0-a213-74d44b0bb8be@github.com>

On Thu, 8 Feb 2024 13:18:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API provides two sets of instructions implementations (bound and unbound).
> Unbound implementation of `IncrementInstruction::constant` returns invalid value. 
> This bug discovered a hole in the ClassFile API test coverage.
> 
> This patch provides very simple fix of `IncrementInstruction`
> and more complex fix of the test framework to cover all unbound instruction with automated tests.
> 
> The test framework fix includes correction of hash calculation of instructions in `ClassRecord` and
> two-pass transformation in `RebuildingTransformation`. Second pass has been added to discover bugs in unbound-to-unbound instruction conversions.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 8907eda7
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8907eda779f0c3f870bb31deb74c0a483251f1e2
Stats:     786 lines in 4 files changed: 391 ins; 379 del; 16 mod

8325485: IncrementInstructions.of(int, int) is not storing the args

Reviewed-by: liach, jlahoda

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

PR: https://git.openjdk.org/jdk/pull/17770

From jlahoda at openjdk.org  Tue Apr  9 11:17:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 11:17:35 GMT
Subject: RFR: 8328481: Implement Module Imports [v3]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <jHYFkwh0r6Lfk31t4etDX0ZZv_5coHwTmFn7yNODlzk=.ec718d90-5b0f-4ca1-b6f2-36fdea20cd7c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/b9331cd2...c44031ed

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

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=02
  Stats: 1065 lines in 28 files changed: 989 ins; 11 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From mcimadamore at openjdk.org  Tue Apr  9 11:49:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 Apr 2024 11:49:32 GMT
Subject: RFR: 8329948: Remove string template feature
Message-ID: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>

This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:

https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

Commit messages:
 - Drop spurious changes
 - Merge branch 'master' into template_removal
 - Drop string templates

Changes: https://git.openjdk.org/jdk/pull/18688/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329948
  Stats: 7402 lines in 67 files changed: 135 ins; 7208 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/18688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18688/head:pull/18688

PR: https://git.openjdk.org/jdk/pull/18688

From redestad at openjdk.org  Tue Apr  9 12:06:31 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 9 Apr 2024 12:06:31 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
Message-ID: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>

This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 

Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the straightforward one-class per expression.

There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms, which means we might end up with a higher number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 

I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:

Baseline strategy:
13 args: 6.3M
23 args: 18M
123 args: 868M

`-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
13 args: 2.11M
23 args: 3.67M
123 args: 4.75M

For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.

I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

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

Commit messages:
 - Bump threshold after experiments
 - Port ASM to CFA
 - Lower compilation overhead for large concat expressions, initial ASM-based version based on pre-existing implementation

Changes: https://git.openjdk.org/jdk/pull/18690/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327247
  Stats: 213 lines in 2 files changed: 210 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From jlahoda at openjdk.org  Tue Apr  9 13:38:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 13:38:29 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Adding more tests for ambiguities.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/c44031ed..0ca05b7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=02-03

  Stats: 69 lines in 1 file changed: 68 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From asotona at openjdk.org  Tue Apr  9 13:46:33 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 13:46:33 GMT
Subject: RFR: 8329955: Class-File API ClassPrinter does not print bootstrap
 methods arguments
Message-ID: <H6blQ4bTkZnCEIHnpyDaiIehWCNjbq-xgCMePBpm86I=.4486af81-325e-4176-b431-5b61294a3caf@github.com>

Class-File API `ClassPrinter` prints many useful info about bootstrap methods and invoke dynamic instructions, however bootstrap methods arguments are missing.
This patch fixes bootstrap methods and invoke dynamic instructions printing.
`ClassPrinterTest` is extended to print bootstrap method and invoke dynamic instruction.

Please review.

Thanks,
Adam

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

Commit messages:
 - added test
 - 8329955: Class-File API ClassPrinter does not print bootstrap methods arguments

Changes: https://git.openjdk.org/jdk/pull/18695/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18695&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329955
  Stats: 335 lines in 2 files changed: 71 ins; 0 del; 264 mod
  Patch: https://git.openjdk.org/jdk/pull/18695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18695/head:pull/18695

PR: https://git.openjdk.org/jdk/pull/18695

From rriggs at openjdk.org  Tue Apr  9 13:48:03 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Apr 2024 13:48:03 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
Message-ID: <gjAPkLHCjd0owPIZV6PfS9v_maCSTF0HZx4QB0eZm5M=.d9eda3ae-54e5-4042-88c2-f61b3d1b350c@github.com>

On Tue, 9 Apr 2024 08:37:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's suggestion - use Instant.MIN and Instant.MAX instead of hardcoded values

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18674#pullrequestreview-1989084996

From rriggs at openjdk.org  Tue Apr  9 13:48:05 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Apr 2024 13:48:05 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <0uXJDc_7vTPCrReRu6X5u8W2sSIQu695b57YyyffUpw=.35967499-34c5-4cc0-b8ec-2bb396c8ec46@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <WeknLfDNR-GL0nSULJqPMQ9cN6o0d12MMIAsYJzvAlE=.4aa50e78-33ea-4254-a9a7-f4f3b411e82d@github.com>
 <tfq0N5V-twZt_DE17cLQejKB4mo_x-_kSjfv9t8A80s=.6157a881-9ad5-4e08-b47d-f534626674a4@github.com>
 <N0w6m5yWI8OZjuPY6svLJnLRfhmQN0NpKK3hvRpb9Es=.78ad4a95-7842-433f-bde1-5f2d92d1a6fd@github.com>
 <fm7NMg6DXB_4uHS4XdMdet36qn-rf9JvNZ5P0K9xM5g=.6a9b1edc-1a4a-4264-8354-54e4556efb1f@github.com>
 <0uXJDc_7vTPCrReRu6X5u8W2sSIQu695b57YyyffUpw=.35967499-34c5-4cc0-b8ec-2bb396c8ec46@github.com>
Message-ID: <V_WzJpCL_GslM4eeWT2qT1XQmI3KQ7usNAMw_QyGP0I=.88145058-9f6f-4e20-8ac6-2bde2d674471@github.com>

On Tue, 9 Apr 2024 08:34:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Should `INSTANT_SECONDS("InstantSeconds", SECONDS, FOREVER, ValueRange.of(Instant.MIN.getEpochSecond(), Instant.MAX.getEpochSecond())),
>> ` work?
>
> Hello Naoto, that's a very good point. I was too caught up with the constant values that it didn't occur to me that the `Instant.MIN` and `Instant.MAX` public fields could be used for this. I have followed your suggestion and updated the PR. I have also updated the javadoc to link to `Instant.MIN` and `Instant.MAX` as the supported epoch second range.
> 
> The test continues to pass with this change and fails (as expected) without the source change.

Good, that was going to be my backup suggestion; trying to avoid a method call even for the init. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1557657347

From jpai at openjdk.org  Tue Apr  9 13:56:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 13:56:11 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <LgTSy0w9XD0ENJDnIbKrZrQ4VV0Fv5-htKytWg1C4c0=.3b00a837-f7b6-4022-b8ce-b8168f6c5eb2@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/java/lang/System.java line 2279:

> 2277:         }
> 2278: 
> 2279:         public void write(int b) throws IOException {

Nit - missing an `@Override`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557670428

From asotona at openjdk.org  Tue Apr  9 14:00:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 14:00:03 GMT
Subject: RFR: JDK-8326836 Incorrect `@since` Tags for ClassSignature
 methods [v2]
In-Reply-To: <emnKMZ-WItnQQLRD83517Y-dqdN45CfEo9154kkWTfI=.d53f0fc6-8f34-4a27-9a51-f6a1b9ddb798@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
 <emnKMZ-WItnQQLRD83517Y-dqdN45CfEo9154kkWTfI=.d53f0fc6-8f34-4a27-9a51-f6a1b9ddb798@github.com>
Message-ID: <fYqtfyjksbjWuEUz3yaq8YvnU_I9YeFOeDB6H7KRetM=.7400a3b2-b893-42bd-bd27-1406bb081c5b@github.com>

On Wed, 20 Mar 2024 02:10:35 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were made to the method signatures but this modification isn't reflected in the @ since tags. The @ since tags need to be updated.
>> 
>> I changed the `@since` tags to better accurately show when the methods were introduced. This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the copyright year to 2024

Looks good, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18030#pullrequestreview-1989118816

From jpai at openjdk.org  Tue Apr  9 14:01:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 14:01:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <C0LCNaIZIWUc-tlb7oVcHSboIfVhkTFaTkF_KkM9YZ8=.500c781e-647b-4137-9938-873f370eb5ac@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/java/lang/System.java line 2262:

> 2260:         @Override
> 2261:         public long transferTo(OutputStream out) throws IOException {
> 2262:             boolean attempted = Blocker.begin();

Hello Alan, why do we mark transferTo as potentially blocking operation which might need compensation? As far as I can see in the underlying implementation of `FileInputStream.transferTo()` it either calls the `FileChannel.transferTo()` or does a `in.read()` followed by `out.write()`. In either of those cases wouldn't the underlying `InputStream/OutputStream` already have the necessary `Blocker` calls?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557679570

From asotona at openjdk.org  Tue Apr  9 14:03:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 14:03:13 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v4]
In-Reply-To: <1obW1-l1wFpTjbAlnhXqTlgr8i89LStvH8SmhqhniC0=.bf0763f6-bfb3-459b-aed1-a23835226615@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
 <1obW1-l1wFpTjbAlnhXqTlgr8i89LStvH8SmhqhniC0=.bf0763f6-bfb3-459b-aed1-a23835226615@github.com>
Message-ID: <3lJK9PIo3K3thIoGpQDR8_s7q4v5_8sLwPCQYJUUyeo=.6ae0006d-5dff-4c00-b4c7-7288dbcd4c02@github.com>

On Mon, 26 Feb 2024 17:48:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
>> 
>> Additional questions:
>> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`
>
> Chen Liang 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 https://github.com/openjdk/jdk into fix/typearg-model
>  - Missed renaming in tests, thanks to Adam Sotona
>    
>    Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>
>  - Rename no wildcard indicator, improve docs slightly
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Merge branch 'master' into fix/typearg-model
>  - redundant line
>  - Fix a test in langtools, copyright year
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Implementation cleanup, test update
>  - Merge branch 'master' into fix/typearg-model
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/f62b5789...839efabd

Looks good, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16517#pullrequestreview-1989125867

From jpai at openjdk.org  Tue Apr  9 14:17:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 14:17:00 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <P3M_aQvocA4ztcQhv_aoY2TcbRMVZjF7QEVsCcmtAm8=.38eddeb5-c89e-4396-a47a-4ccd70a63f75@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/jdk/internal/misc/CarrierThread.java line 104:

> 102:         if (compensating == COMPENSATING) {
> 103:             ForkJoinPools.endCompensatedBlock(getPool(), compensateValue);
> 104:             compensating = NOT_COMPENSATING;

For the sake for consistency between the state and the `compensateValue`, would it be good to reset `compensateValue` to `0` when we switch to `NOT_COMPENSATING`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557714608

From jpai at openjdk.org  Tue Apr  9 14:23:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 14:23:13 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <QdsRmmoGMwsfN8r9R063sk-YxfysfPNyRSCb9Iv1TH4=.025603ce-ff23-4791-a931-a6404b218922@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 304:

> 302:                     return 0;
> 303:                 do {
> 304:                     boolean attempted = Blocker.begin(sync | direct);

Is the use of the bitwise operator `|` instead of `||` on `boolean` fields, here and other places, intentional?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557727112

From briangoetz at openjdk.org  Tue Apr  9 14:25:02 2024
From: briangoetz at openjdk.org (Brian Goetz)
Date: Tue, 9 Apr 2024 14:25:02 GMT
Subject: RFR: 8325371: Missing ClassFile.Option in package summary
In-Reply-To: <oH5hWpwJW9-6CtItagQJvZERRGqJn4D4l7raxEpPe90=.be44eb4f-1e8a-412e-b4df-8991368c7e44@github.com>
References: <oH5hWpwJW9-6CtItagQJvZERRGqJn4D4l7raxEpPe90=.be44eb4f-1e8a-412e-b4df-8991368c7e44@github.com>
Message-ID: <wStuzZDRUMJDy71iWCAFQ8VFNqeamGl0QAz74vsnHrc=.fc34a34a-09bf-40d5-8dcf-45dd59a5fdab@github.com>

On Wed, 3 Apr 2024 08:48:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Some of the Class-File API options were not mentioned in the package summary and one exception mentioned `ClassFile.DeadLabelsOption` javadoc was wrong.
> This patch fixes the javadoc.
> 
> Please review.
> 
> Thank you,
> Adam

Marked as reviewed by briangoetz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18594#pullrequestreview-1989198603

From briangoetz at openjdk.org  Tue Apr  9 14:25:12 2024
From: briangoetz at openjdk.org (Brian Goetz)
Date: Tue, 9 Apr 2024 14:25:12 GMT
Subject: RFR: 8329955: Class-File API ClassPrinter does not print bootstrap
 methods arguments
In-Reply-To: <H6blQ4bTkZnCEIHnpyDaiIehWCNjbq-xgCMePBpm86I=.4486af81-325e-4176-b431-5b61294a3caf@github.com>
References: <H6blQ4bTkZnCEIHnpyDaiIehWCNjbq-xgCMePBpm86I=.4486af81-325e-4176-b431-5b61294a3caf@github.com>
Message-ID: <kvn1hn70nZ2Plikc4BHRe_Zz-iKdwOSSEN_UD-8VjQU=.b198c169-c5c0-4362-aa84-c8476521c912@github.com>

On Tue, 9 Apr 2024 13:39:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API `ClassPrinter` prints many useful info about bootstrap methods and invoke dynamic instructions, however bootstrap methods arguments are missing.
> This patch fixes bootstrap methods and invoke dynamic instructions printing.
> `ClassPrinterTest` is extended to print bootstrap method and invoke dynamic instruction.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by briangoetz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18695#pullrequestreview-1989196787

From briangoetz at openjdk.org  Tue Apr  9 14:26:10 2024
From: briangoetz at openjdk.org (Brian Goetz)
Date: Tue, 9 Apr 2024 14:26:10 GMT
Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory
 methods  accepting Opcode [v4]
In-Reply-To: <0HaASAfZR1oL9lX_aokjW3zb_HAFz8rjMdAbV-3zv6I=.00d4ace6-6f41-41e8-8d20-dc07229ae15d@github.com>
References: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
 <0HaASAfZR1oL9lX_aokjW3zb_HAFz8rjMdAbV-3zv6I=.00d4ace6-6f41-41e8-8d20-dc07229ae15d@github.com>
Message-ID: <sKiduHVFMr7BkeS4uhzmH7Dt8KvO-bHW9dV38DyNWuE=.0d7a2833-7fb9-4847-a804-78745bcd2975@github.com>

On Tue, 9 Apr 2024 09:32:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> `IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented:
>> 
>> - `ArrayLoadInstruction`
>> - `ArrayStoreInstruction`
>> - `BranchInstruction`
>> - `ConvertInstruction`
>> - `DiscontinuedInstruction`
>> - `FieldInstruction`
>> - `InvokeInstruction`
>> - `LoadInstruction`
>> - `MonitorInstruction`
>> - `NewPrimitiveArrayInstruction`
>> - `OperatorInstruction`
>> - `ReturnInstruction`
>> - `StackInstruction`
>> - `StoreInstruction`
>> - `TypeCheckInstruction`
>> 
>> `NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument.
>> 
>> This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added NPE statement to package-info

While the @throws is not technically necessary here, specifying it here is reasonable.

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

Marked as reviewed by briangoetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18578#pullrequestreview-1989201955

From alanb at openjdk.org  Tue Apr  9 14:41:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 14:41:00 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <QdsRmmoGMwsfN8r9R063sk-YxfysfPNyRSCb9Iv1TH4=.025603ce-ff23-4791-a931-a6404b218922@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <QdsRmmoGMwsfN8r9R063sk-YxfysfPNyRSCb9Iv1TH4=.025603ce-ff23-4791-a931-a6404b218922@github.com>
Message-ID: <h5V94FY4uI7Ydl-F9Q94ck1fh_cJSxgYkW0cEplYCxs=.2de09ef8-6b68-449e-af63-9a57a5dda745@github.com>

On Tue, 9 Apr 2024 14:20:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in the loom repo for several months.
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 304:
> 
>> 302:                     return 0;
>> 303:                 do {
>> 304:                     boolean attempted = Blocker.begin(sync | direct);
> 
> Is the use of the bitwise operator `|` instead of `||` on `boolean` fields, here and other places, intentional?

Well spotted, these should be ||.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557761764

From asotona at openjdk.org  Tue Apr  9 14:44:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 14:44:04 GMT
Subject: RFR: 8325371: Missing ClassFile.Option in package summary
In-Reply-To: <wStuzZDRUMJDy71iWCAFQ8VFNqeamGl0QAz74vsnHrc=.fc34a34a-09bf-40d5-8dcf-45dd59a5fdab@github.com>
References: <oH5hWpwJW9-6CtItagQJvZERRGqJn4D4l7raxEpPe90=.be44eb4f-1e8a-412e-b4df-8991368c7e44@github.com>
 <wStuzZDRUMJDy71iWCAFQ8VFNqeamGl0QAz74vsnHrc=.fc34a34a-09bf-40d5-8dcf-45dd59a5fdab@github.com>
Message-ID: <zyunFfqV3-vH237lZ8UhXpvEIoYr2ztM2cykyogs1fM=.01cf297c-2ce2-474e-8c31-d4b683492bbb@github.com>

On Tue, 9 Apr 2024 14:22:37 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Some of the Class-File API options were not mentioned in the package summary and one exception mentioned `ClassFile.DeadLabelsOption` javadoc was wrong.
>> This patch fixes the javadoc.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Marked as reviewed by briangoetz (Reviewer).

@briangoetz Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/18594#issuecomment-2045353899

From asotona at openjdk.org  Tue Apr  9 14:44:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 14:44:05 GMT
Subject: Integrated: 8325371: Missing ClassFile.Option in package summary
In-Reply-To: <oH5hWpwJW9-6CtItagQJvZERRGqJn4D4l7raxEpPe90=.be44eb4f-1e8a-412e-b4df-8991368c7e44@github.com>
References: <oH5hWpwJW9-6CtItagQJvZERRGqJn4D4l7raxEpPe90=.be44eb4f-1e8a-412e-b4df-8991368c7e44@github.com>
Message-ID: <ygaBR8I2FpypvOzkS5bEmAUXJB5QiZsvOdIfC0ogudE=.868df82f-e7f6-4101-be9b-d9fdfaae6d20@github.com>

On Wed, 3 Apr 2024 08:48:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Some of the Class-File API options were not mentioned in the package summary and one exception mentioned `ClassFile.DeadLabelsOption` javadoc was wrong.
> This patch fixes the javadoc.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: f9bc2db9
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9bc2db9a9b8e5b7314fba5f70cb79e07ed02bd8
Stats:     23 lines in 2 files changed: 12 ins; 6 del; 5 mod

8325371: Missing ClassFile.Option in package summary

Reviewed-by: briangoetz

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

PR: https://git.openjdk.org/jdk/pull/18594

From alanb at openjdk.org  Tue Apr  9 14:46:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 14:46:00 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <LgTSy0w9XD0ENJDnIbKrZrQ4VV0Fv5-htKytWg1C4c0=.3b00a837-f7b6-4022-b8ce-b8168f6c5eb2@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <LgTSy0w9XD0ENJDnIbKrZrQ4VV0Fv5-htKytWg1C4c0=.3b00a837-f7b6-4022-b8ce-b8168f6c5eb2@github.com>
Message-ID: <OH7P6lYcgVFp3jCc1zqe1nd_LbjTxAIG5lqK9F4-b_0=.8211a47f-83cf-407a-a0a0-58c31142fa18@github.com>

On Tue, 9 Apr 2024 13:53:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in the loom repo for several months.
>
> src/java.base/share/classes/java/lang/System.java line 2279:
> 
>> 2277:         }
>> 2278: 
>> 2279:         public void write(int b) throws IOException {
> 
> Nit - missing an `@Override`

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557769608

From asotona at openjdk.org  Tue Apr  9 14:47:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 14:47:11 GMT
Subject: RFR: 8329955: Class-File API ClassPrinter does not print bootstrap
 methods arguments
In-Reply-To: <kvn1hn70nZ2Plikc4BHRe_Zz-iKdwOSSEN_UD-8VjQU=.b198c169-c5c0-4362-aa84-c8476521c912@github.com>
References: <H6blQ4bTkZnCEIHnpyDaiIehWCNjbq-xgCMePBpm86I=.4486af81-325e-4176-b431-5b61294a3caf@github.com>
 <kvn1hn70nZ2Plikc4BHRe_Zz-iKdwOSSEN_UD-8VjQU=.b198c169-c5c0-4362-aa84-c8476521c912@github.com>
Message-ID: <HrjsXRoYvUz6BFXVrg6a018CG-iQEOPhBMCIJs0JXVY=.41608c46-9fb7-4cdd-a30c-6c5c54683767@github.com>

On Tue, 9 Apr 2024 14:21:59 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Class-File API `ClassPrinter` prints many useful info about bootstrap methods and invoke dynamic instructions, however bootstrap methods arguments are missing.
>> This patch fixes bootstrap methods and invoke dynamic instructions printing.
>> `ClassPrinterTest` is extended to print bootstrap method and invoke dynamic instruction.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Marked as reviewed by briangoetz (Reviewer).

@briangoetz Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/18695#issuecomment-2045359689

From asotona at openjdk.org  Tue Apr  9 14:47:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 14:47:11 GMT
Subject: Integrated: 8329955: Class-File API ClassPrinter does not print
 bootstrap methods arguments
In-Reply-To: <H6blQ4bTkZnCEIHnpyDaiIehWCNjbq-xgCMePBpm86I=.4486af81-325e-4176-b431-5b61294a3caf@github.com>
References: <H6blQ4bTkZnCEIHnpyDaiIehWCNjbq-xgCMePBpm86I=.4486af81-325e-4176-b431-5b61294a3caf@github.com>
Message-ID: <7yeTwqUUGo8inJFJWxeqCcKTQAFT8b3h-7Sn7leg64Y=.00a31c3a-95dc-4871-b1a1-5e869a456ff4@github.com>

On Tue, 9 Apr 2024 13:39:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API `ClassPrinter` prints many useful info about bootstrap methods and invoke dynamic instructions, however bootstrap methods arguments are missing.
> This patch fixes bootstrap methods and invoke dynamic instructions printing.
> `ClassPrinterTest` is extended to print bootstrap method and invoke dynamic instruction.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: e75e1cb0
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e75e1cb02c3d115762846e47fb2d2b10a177f6de
Stats:     335 lines in 2 files changed: 71 ins; 0 del; 264 mod

8329955: Class-File API ClassPrinter does not print bootstrap methods arguments

Reviewed-by: briangoetz

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

PR: https://git.openjdk.org/jdk/pull/18695

From alanb at openjdk.org  Tue Apr  9 14:53:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 14:53:12 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <C0LCNaIZIWUc-tlb7oVcHSboIfVhkTFaTkF_KkM9YZ8=.500c781e-647b-4137-9938-873f370eb5ac@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <C0LCNaIZIWUc-tlb7oVcHSboIfVhkTFaTkF_KkM9YZ8=.500c781e-647b-4137-9938-873f370eb5ac@github.com>
Message-ID: <E42flQwU68H3wf1wawnq7S5HURoh62icAA7DOHlbDH0=.6eae52ce-5a53-479c-809d-0a9c30fa7e45@github.com>

On Tue, 9 Apr 2024 13:58:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in the loom repo for several months.
>
> src/java.base/share/classes/java/lang/System.java line 2262:
> 
>> 2260:         @Override
>> 2261:         public long transferTo(OutputStream out) throws IOException {
>> 2262:             boolean attempted = Blocker.begin();
> 
> Hello Alan, why do we mark transferTo as potentially blocking operation which might need compensation? As far as I can see in the underlying implementation of `FileInputStream.transferTo()` it either calls the `FileChannel.transferTo()` or does a `in.read()` followed by `out.write()`. In either of those cases wouldn't the underlying `InputStream/OutputStream` already have the necessary `Blocker` calls?

It's to increase the target parallelism for the duration of the transfer rather than specific read operations. System.in.transferTo(out) should be rare so it's not super important of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557786640

From jpai at openjdk.org  Tue Apr  9 15:02:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 15:02:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <FL2QV9WLto_qdVAm5QDAukEOHOj3wHoqFahokLR88nQ=.4b9aca70-46d0-4fdd-a8a6-3d20e8afb436@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/jdk/internal/misc/Blocker.java line 79:

> 77:      * Marks the beginning of a possibly blocking operation.
> 78:      * @param blocking true if the operation may block, otherwise false
> 79:      * @return true if tryCompensate attempted

Was the use the word `tryCompensate` intentional here? I don't see that method in this class or in the implementation of `CarrierThread.beginBlocking()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557805449

From jpai at openjdk.org  Tue Apr  9 15:10:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 15:10:09 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <d6GRU4vzFdWFvXBKJ4pBkzn8s4SQSn54hNSdORHDDwI=.daeb33bb-e31a-48ce-8a06-731ca9bd2533@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes.

What I understand of these changes overall is that, we no longer consider most of the file operations that work against an actual file as needing to be compensated by the ForkJoinPool. It doesn't matter even if the read() is being done with a large buffer - we still consider it an operation that doesn't deserve a compensation. 

The only file operations where we do appear to compensate is certain `write` operations which are backed by `O_SYNC`, `O_DSYNC` or direct IO writes.

The places where `FileOutputStream` is used against a file descriptor which isn't a file have been update to continue to using the `Blocker` to potentially compensate the operations.

Overall, based on my limited knowledge of this area, the changes look OK to me. There are a few questions I had which I've added inline. The copyright years on many of the files will need an update.

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

PR Comment: https://git.openjdk.org/jdk/pull/18598#issuecomment-2045417779

From alanb at openjdk.org  Tue Apr  9 15:10:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 15:10:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <FL2QV9WLto_qdVAm5QDAukEOHOj3wHoqFahokLR88nQ=.4b9aca70-46d0-4fdd-a8a6-3d20e8afb436@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <FL2QV9WLto_qdVAm5QDAukEOHOj3wHoqFahokLR88nQ=.4b9aca70-46d0-4fdd-a8a6-3d20e8afb436@github.com>
Message-ID: <zzjRaseVQ0vvIKuwcB-oVLQLlplz_F4v7WJX3UbiuWA=.613d6131-0d4d-402a-8840-6f289372c765@github.com>

On Tue, 9 Apr 2024 14:59:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Was the use the word `tryCompensate` intentional here? I don't see that method in this class or in the implementation of `CarrierThread.beginBlocking()`

The FJP method is named tryCompensate and the same method name was used here at one point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557814857

From jpai at openjdk.org  Tue Apr  9 15:18:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 15:18:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <RCQwidP2djVhYAyfUdjmxC-psNb06IGNCK15ip46Cg4=.e8a29ba0-3fb1-4b6a-a206-8f6d5bf0f2f6@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/jdk/internal/misc/CarrierThread.java line 81:

> 79:                 value = ForkJoinPools.beginCompensatedBlock(getPool());
> 80:             } catch (Throwable e) {
> 81:                 if (compensating == COMPENSATE_IN_PROGRESS) {

I don't fully follow these checks `if (compensating == COMPENSATE_IN_PROGRESS) {`. Surely it's not for concurrent access (given the `assert` at the start of this method, this code path happens in a single thread). So I think these checks are about the re-entrancy that is mentioned in the description of this PR.
In the context of re-entrancy, if I am reading the code correctly, I don't see how a re-entrant call would end up on this line (and other similar lines) in this top level `if` block. When a thread enters the top level `if` block it immediately sets the `compensating` to `COMPENSATE_IN_PROGRESS`:


if (compensating == NOT_COMPENSATING) {
    compensating = COMPENSATE_IN_PROGRESS;
...

So a subsequent re-entrant call would never enter that top level `if` block again. Which leads me to question the need of these additional `if (compensating == COMPENSATE_IN_PROGRESS) {` checks. I feel like I am missing something in this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557834582

From jpai at openjdk.org  Tue Apr  9 15:22:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 15:22:08 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <E42flQwU68H3wf1wawnq7S5HURoh62icAA7DOHlbDH0=.6eae52ce-5a53-479c-809d-0a9c30fa7e45@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <C0LCNaIZIWUc-tlb7oVcHSboIfVhkTFaTkF_KkM9YZ8=.500c781e-647b-4137-9938-873f370eb5ac@github.com>
 <E42flQwU68H3wf1wawnq7S5HURoh62icAA7DOHlbDH0=.6eae52ce-5a53-479c-809d-0a9c30fa7e45@github.com>
Message-ID: <DzazV7lzXkuR-GEBoV34UwxAEbpva5AkcM4MxyPh2Uw=.1594bcef-37b7-4606-b60c-ecc4b912b6c8@github.com>

On Tue, 9 Apr 2024 14:50:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's to increase the target parallelism for the duration of the transfer rather than specific read operations.

Do you think we would need to do something similar in`PipeInputStream` that belongs to `Process`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557842319

From mbaesken at openjdk.org  Tue Apr  9 15:33:17 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 9 Apr 2024 15:33:17 GMT
Subject: RFR: JDK-8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
Message-ID: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>

We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

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

Commit messages:
 - JDK-8329862

Changes: https://git.openjdk.org/jdk/pull/18699/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329862
  Stats: 18 lines in 3 files changed: 15 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18699/head:pull/18699

PR: https://git.openjdk.org/jdk/pull/18699

From enikitin at openjdk.org  Tue Apr  9 15:43:14 2024
From: enikitin at openjdk.org (Evgeny Nikitin)
Date: Tue, 9 Apr 2024 15:43:14 GMT
Subject: Integrated: 8325659: Normalize Random usage by incubator vector tests
In-Reply-To: <pQTKJS13VI6J72OWEyEsXTLQXvxjtJKAwiYH4g5PU5U=.f8adbf5a-1f75-42af-b1c2-66125db9f457@github.com>
References: <pQTKJS13VI6J72OWEyEsXTLQXvxjtJKAwiYH4g5PU5U=.f8adbf5a-1f75-42af-b1c2-66125db9f457@github.com>
Message-ID: <CaEp8ipLRkA4tXWUVo55Yl_5xuNHgygcTAUXksALQbo=.825c0241-576f-47a6-a28e-0d735c01443a@github.com>

On Mon, 8 Apr 2024 10:50:00 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> Improve RNG usage in said tests:
> 
> 1. The RNG is not created by our Utils class, as suggested in our JTReg tests;
> 2. The seed, accordingly, is not a fixed value now, but truly random;
> 3. The tests that had been creating their own Random instances, are now using RAND static member from the AbstractVectorTest;
> 4. The generated tests sources have been re-generated.
> 
> The most important change is #2, it could add variability and help cover more JIT Compiler and Runtime scenarios.

This pull request has now been integrated.

Changeset: 4bba445d
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4bba445d835837db5ab145edb24030fc6f42ec24
Stats:     469 lines in 69 files changed: 188 ins; 0 del; 281 mod

8325659: Normalize Random usage by incubator vector tests

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/jdk/pull/18675

From mbaesken at openjdk.org  Tue Apr  9 15:45:08 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 9 Apr 2024 15:45:08 GMT
Subject: RFR: JDK-8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <VGOXNq0t2zHfYg3IwRy54MtYYDQvbl_Tr5iKGoZZWGc=.67e71860-e7dc-4387-a254-282222e6bf46@github.com>

On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

Btw. I noticed that  GetModuleFileName return value is not checked, should this be done (at other locations in the JDk codebase it is done) ?
See  https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea

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

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2045514750

From alanb at openjdk.org  Tue Apr  9 16:25:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 16:25:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <RCQwidP2djVhYAyfUdjmxC-psNb06IGNCK15ip46Cg4=.e8a29ba0-3fb1-4b6a-a206-8f6d5bf0f2f6@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <RCQwidP2djVhYAyfUdjmxC-psNb06IGNCK15ip46Cg4=.e8a29ba0-3fb1-4b6a-a206-8f6d5bf0f2f6@github.com>
Message-ID: <5lg4y7d6bB8Ukdegw2K2wwFR_g2gb8gwy5eQwFMsTug=.d580be20-7220-4159-9979-ecf923a231f3@github.com>

On Tue, 9 Apr 2024 15:15:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in the loom repo for several months.
>
> src/java.base/share/classes/jdk/internal/misc/CarrierThread.java line 81:
> 
>> 79:                 value = ForkJoinPools.beginCompensatedBlock(getPool());
>> 80:             } catch (Throwable e) {
>> 81:                 if (compensating == COMPENSATE_IN_PROGRESS) {
> 
> I don't fully follow these checks `if (compensating == COMPENSATE_IN_PROGRESS) {`. Surely it's not for concurrent access (given the `assert` at the start of this method, this code path happens in a single thread). So I think these checks are about the re-entrancy that is mentioned in the description of this PR.
> In the context of re-entrancy, if I am reading the code correctly, I don't see how a re-entrant call would end up on this line (and other similar lines) in this top level `if` block. When a thread enters the top level `if` block it immediately sets the `compensating` to `COMPENSATE_IN_PROGRESS`:
> 
> 
> if (compensating == NOT_COMPENSATING) {
>     compensating = COMPENSATE_IN_PROGRESS;
> ...
> 
> So a subsequent re-entrant call would never enter that top level `if` block again. Which leads me to question the need of these additional `if (compensating == COMPENSATE_IN_PROGRESS) {` checks. I feel like I am missing something in this code.

> In the context of re-entrancy, if I am reading the code correctly, I don't see how a re-entrant call would end up on this line (and other similar lines) in this top level if block. When a thread enters the top level if block it immediately sets the compensating to COMPENSATE_IN_PROGRESS: I feel like I am missing something in this code.

These are fields on the carrier. If a virtual thread is preempted when compensating (or in the progress of) then it may continue on a different carrier or the original carrier may execute the task for a different virtual thread that does I/O. These are the cases that are handled here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557950295

From naoto at openjdk.org  Tue Apr  9 16:32:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Apr 2024 16:32:10 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
Message-ID: <RPLE81TlmSQ76sgyH4xz5D1AWzylsCUzL_Zta_-gTDc=.e2dbaf98-2aad-49ab-a6e3-97f0a77c1184@github.com>

On Tue, 9 Apr 2024 08:37:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's suggestion - use Instant.MIN and Instant.MAX instead of hardcoded values

Thanks, Jai. The code change looks good. (Left a minor nit)

src/java.base/share/classes/java/time/temporal/ChronoField.java line 590:

> 588:      * This is necessary to ensure interoperation between calendars.
> 589:      * <p>
> 590:      * Range of {@code InstantSeconds} is between {@link Instant#MIN} and {@link Instant#MAX}

Nit: `InstantSeconds` -> `INSTANT_SECONDS`

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

PR Review: https://git.openjdk.org/jdk/pull/18674#pullrequestreview-1989561065
PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1557961266

From psandoz at openjdk.org  Tue Apr  9 16:52:10 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 9 Apr 2024 16:52:10 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v2]
In-Reply-To: <XxUidI9csWKBzCHIceyCYY7dN8zT4PB0rSEIJ9Y1QvQ=.7a2e0c61-0227-4bc4-bdb2-3c69c9673563@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <XxUidI9csWKBzCHIceyCYY7dN8zT4PB0rSEIJ9Y1QvQ=.7a2e0c61-0227-4bc4-bdb2-3c69c9673563@github.com>
Message-ID: <af9tmbjFcGKAo7IzbsYsQWeC6hHNFPdTo_Nia_F2gfg=.f639c805-b47c-468a-8b02-ffc8b581695f@github.com>

On Tue, 9 Apr 2024 10:07:46 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
>> 
>> Below is the performance of `Stream::flatMap` (for reference types):
>> 
>> Before this PR:
>> 
>> Benchmark            (size)   Mode  Cnt        Score       Error  Units
>> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
>> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
>> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
>> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
>> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
>> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
>> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
>> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
>> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
>> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
>> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
>> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
>> 
>> 
>> After this PR:
>> 
>> 
>> Benchmark            (size)   Mode  Cnt        Score        Error  Units
>> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
>> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
>> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
>> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
>> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
>> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
>> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
>> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
>> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
>> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
>> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
>> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s
>> 
>> 
>> For streams of size 100k, the following numbers are interesting:
>> 
>> Before this PR:
>> 
>> Benchmark            (size)   Mode  Cnt  Score    Error  Units
>> FlatMap.par_array    100000  thrpt   12  0,325 ?  0,004  ops/s
>> FlatMap.par_iterate  100000  thrpt   12  0,106 ?  0,008  o...
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year

src/java.base/share/classes/java/util/stream/DoublePipeline.java line 280:

> 278:                                     result.sequential().allMatch(this);
> 279:                                 else
> 280:                                     result.sequential().forEach(sink::accept);

I think that might create a new double consumer instance for every input element. Alternatively you can compute and cache it as a field, replacing `shorts` and use a `null` check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1557995257

From alanb at openjdk.org  Tue Apr  9 17:29:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 17:29:09 GMT
Subject: RFR: JDK-8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <1OgWz9GmBNCQM98Kxh_mSKrlJohlYallG3rrV8hfC5A=.ffd723bb-fb67-4d9b-a7ba-1438cfa2d54e@github.com>

On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

This looks very ad hoc. Not opposed to expanding the set of trace messages when this env variable is set but what is proposed here looks like trace messages that are left over from a debugging session. If we expand the tracing then I think it should be consistent with the existing tracing.

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

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2045740185

From sroy at openjdk.org  Tue Apr  9 17:46:31 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 9 Apr 2024 17:46:31 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v18]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <10Ko0CxPDgV_G0HlofwzZsuAQFG7mgrANub5ptvn46Q=.79341f67-8431-43f5-bb95-652debb20f1d@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 - test change
 - test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/f0459fc3..d2f040b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=16-17

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

PR: https://git.openjdk.org/jdk/pull/17945

From liach at openjdk.org  Tue Apr  9 20:34:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 Apr 2024 20:34:11 GMT
Subject: RFR: 8329948: Remove string template feature
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>

On Tue, 9 Apr 2024 11:34:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 120:

> 118:      * @since 21
> 119:      */
> 120:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;

May this value change in the future? If yes, we might change this to a method to avoid incorrect eager inlining by the java compiler, or drop this with string templates.

src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 44:

> 42:  *
> 43:  * @since 21
> 44:  */

Spurious javadoc

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1558241809
PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1558250463

From liach at openjdk.org  Tue Apr  9 20:53:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 Apr 2024 20:53:01 GMT
Subject: RFR: JDK-8326836 Incorrect `@since` Tags for ClassSignature
 methods
In-Reply-To: <bF2NayfvAv_WOeAU_mtVDVgkGEbVRidmLJTePKFF5nw=.38f2590d-d32e-4b97-a2cd-c072235a1c86@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
 <bF2NayfvAv_WOeAU_mtVDVgkGEbVRidmLJTePKFF5nw=.38f2590d-d32e-4b97-a2cd-c072235a1c86@github.com>
Message-ID: <62JOvvR-OgFdonq4SgVi3imk9WXOMjQpCMarulI44N0=.daef3785-a843-4e78-8a89-970e30bec418@github.com>

On Mon, 11 Mar 2024 15:50:41 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were made to the method signatures but this modification isn't reflected in the @ since tags. The @ since tags need to be updated.
>> 
>> I changed the `@since` tags to better accurately show when the methods were introduced. This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> `/covered`

@nizarbenalla Why don't you add since tags for `superclassSignature` and `superinterfaceSignatures` methods, both of which have their signatures changed like the two `of` methods?

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

PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-2046026372

From prappo at openjdk.org  Tue Apr  9 21:07:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 9 Apr 2024 21:07:09 GMT
Subject: RFR: JDK-8326836 Incorrect `@since` Tags for ClassSignature
 methods [v2]
In-Reply-To: <emnKMZ-WItnQQLRD83517Y-dqdN45CfEo9154kkWTfI=.d53f0fc6-8f34-4a27-9a51-f6a1b9ddb798@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
 <emnKMZ-WItnQQLRD83517Y-dqdN45CfEo9154kkWTfI=.d53f0fc6-8f34-4a27-9a51-f6a1b9ddb798@github.com>
Message-ID: <Z3Swa9jBmEKAqji5VIhbQ8j2sC_s9PNkBYnbvQiJGrI=.85b67fd5-d1ff-4fee-b719-43354c481381@github.com>

On Wed, 20 Mar 2024 02:10:35 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were made to the method signatures but this modification isn't reflected in the @ since tags. The @ since tags need to be updated.
>> 
>> I changed the `@since` tags to better accurately show when the methods were introduced. This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the copyright year to 2024

Trivially, what's the reason you capitalised the word "tags" in the PR title and the respective JBS issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-2046043571

From duke at openjdk.org  Tue Apr  9 21:39:08 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Tue, 9 Apr 2024 21:39:08 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 <NC3E6wpsavqRXUqdgNHh3y26lFSIPXoA0yi
 KcV_2CyI=.391c9553-458a-417f-b86d-2c88dacf7df1@github.com>
 <Kc8tP6_hlFmF_NqcwSHEX6NF9atmoeglRsRFTrLaA5A=.bacb4a7d-26cb-4fdc-8f7b-f883587cd58c@github.com>
 <xrA2rqmjQ-gHGaZ23SQIYZCgda6sHslW2oHIqQxyM2Y=.f4ae4438-78b0-4eb1-b4aa-ed461c31ef1f@github.com>
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
 <hSP68W3vGCfGCOlUCf84DDw0qzt9Z7d-56LKLALocYo=.6c507f84-037d-449f-b4f6-f8c9771e6409@github.com>
 <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@github.com>
 <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>
 <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
Message-ID: <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>

On Mon, 11 Mar 2024 19:31:45 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hi Vladimir (@iaroslavski),
>> 
>> Please see the data below.
>> 
>> Thanks,
>> Vamsi
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> Builder | Size | Stock JDK | b01 | r27b | r27p | r27s
>> -- | -- | -- | -- | -- | -- | --
>> RANDOM | 600 | 1.615 | 1.59 | 2.316 | 1.805 | 1.77
>> RANDOM | 2000 | 6.794 | 6.638 | 8.443 | 6.354 | 6.295
>> RANDOM | 90000 | 296.877 | 304.15 | 337.625 | 341.999 | 307.099
>> RANDOM | 400000 | 838.061 | 801.108 | 1136.688 | 1161.181 | 781.487
>> RANDOM | 3000000 | 5468.214 | 5452.125 | 8522.698 | 8476.445 | 5368.777
>> PERIOD | 600 | 0.877 | 0.875 | 0.663 | 0.663 | 0.685
>> PERIOD | 2000 | 1.57 | 1.548 | 1.458 | 1.451 | 1.487
>> PERIOD | 90000 | 97.208 | 97.677 | 106.01 | 106.516 | 106.629
>> PERIOD | 400000 | 237.4 | 264.103 | 235.466 | 231.349 | 231.235
>> PERIOD | 3000000 | 2604.56 | 2829.935 | 4867.668 | 4872.361 | 4888.391
>> STAGGER | 600 | 1.052 | 1.064 | 0.774 | 0.78 | 0.791
>> STAGGER | 2000 | 3.449 | 3.443 | 2.604 | 2.627 | 2.597
>> STAGGER | 90000 | 102.331 | 103.464 | 73.582 | 73.532 | 75.85
>> STAGGER | 400000 | 210.829 | 229.37 | 207.356 | 208.565 | 205.141
>> STAGGER | 3000000 | 2205.565 | 2174.588 | 2086.885 | 2070.132 | 2373.443
>> SHUFFLE | 600 | 1.885 | 1.892 | 1.934 | 1.36 | 1.386
>> SHUFFLE | 2000 | 6.787 | 6.724 | 7.338 | 4.994 | 4.96
>> SHUFFLE | 90000 | 158.065 | 154.48 | 152.874 | 148.337 | 140.703
>> SHUFFLE | 400000 | 415.089 | 424.777 | 676.272 | 676.89 | 410.717
>> SHUFFLE | 3000000 | 3999.006 | 4017.496 | 6861.872 | 6894.785 | 3880.883
>> RANDOM | 600 | 1.614 | 1.588 | 2.329 | 1.789 | 1.847
>> RANDOM | 2000 | 6.756 | 6.634 | 7.757 | 6.224 | 6.23
>> RANDOM | 90000 | 516.671 | 512.52 | 623.995 | 488.492 | 482.646
>> RANDOM | 400000 | 2400.818 | 2399.264 | 2903.654 | 2356.675 | 2358.409
>> RANDOM | 3000000 | 20933.23 | 20822.49 | 24428.27 | 20847.57 | 20868.68
>> PERIOD | 600 | 0.864 | 0.871 | 0.681 | 0.665 | 0.664
>> PERIOD | 2000 | 1.583 | 1.547 | 1.451 | 1.46 | 1.483
>> PERIOD | 90000 | 63.4...
>
>> Hi Vamsi (@vamsi-parasa), few questions on your test environment:
>> 
>> * what are the hardware specs of your server ?
>> * bare-metal or virtual ?
>> * are other services or big processes running ?
>> * os tuning ? CPU HT: off? Fixed CPU governor or frequency ?
>> * isolation using taskset ?
>> 
>> Maybe C2 JIT (+ CDS archive) are given more performance on stock jdk sort than same code running outside jdk...
>> 
>> Thanks, Laurent
> 
> Hi Laurent,
> 
> The benchmarks are run on Intel TigerLake Core i7 machine. It's bare-metal without any virtualization. HT is ON and there is no other specific OS tuning or isolation using taskset.
> 
> Thanks,
> Vamsi

Hello Vamsi (@vamsi-parasa),

Could you please run the new benchmarking?
To save time and don't patch JDK several times, I've created JavaBenchmarkHarness
class which is under package java.util and compares several versions of DPQS.
Also I prepared several versions of current sorting source from JDK to detect what is going wrong.

What you need is to compile and run JavaBenchmarkHarness once:

javac --patch-module java.base=. -d classes *.java
java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness

Find the sources there:

https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java  
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_ins.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_mrg.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_piv.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_prt.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r29p.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r29p5.java

Thank you,
Vladimir

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2046090360

From duke at openjdk.org  Tue Apr  9 22:21:10 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 9 Apr 2024 22:21:10 GMT
Subject: RFR: JDK-8326836 Incorrect `@since` Tags for ClassSignature
 methods
In-Reply-To: <62JOvvR-OgFdonq4SgVi3imk9WXOMjQpCMarulI44N0=.daef3785-a843-4e78-8a89-970e30bec418@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
 <bF2NayfvAv_WOeAU_mtVDVgkGEbVRidmLJTePKFF5nw=.38f2590d-d32e-4b97-a2cd-c072235a1c86@github.com>
 <62JOvvR-OgFdonq4SgVi3imk9WXOMjQpCMarulI44N0=.daef3785-a843-4e78-8a89-970e30bec418@github.com>
Message-ID: <ZAfekofvvDKL9Zmcvtte1ToIJJUV53ZRfZJKK4_5Cj8=.41a72343-9da4-4e11-9604-19780957e0c7@github.com>

On Tue, 9 Apr 2024 20:50:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `/covered`
>
> @nizarbenalla Why don't you add since tags for `superclassSignature` and `superinterfaceSignatures` methods, both of which have their signatures changed like the two `of` methods?

@liach good find! maybe I should look more carefully into members of Classes annotated with `@PreviewFeature`, I'll keep those for now. Until I can get my tool to programmatically pickup on them.

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

PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-2046133913

From duke at openjdk.org  Tue Apr  9 23:43:08 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 9 Apr 2024 23:43:08 GMT
Subject: RFR: JDK-8326836 Incorrect `@since` Tags for ClassSignature
 methods [v2]
In-Reply-To: <Z3Swa9jBmEKAqji5VIhbQ8j2sC_s9PNkBYnbvQiJGrI=.85b67fd5-d1ff-4fee-b719-43354c481381@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
 <emnKMZ-WItnQQLRD83517Y-dqdN45CfEo9154kkWTfI=.d53f0fc6-8f34-4a27-9a51-f6a1b9ddb798@github.com>
 <Z3Swa9jBmEKAqji5VIhbQ8j2sC_s9PNkBYnbvQiJGrI=.85b67fd5-d1ff-4fee-b719-43354c481381@github.com>
Message-ID: <Wl1BJdZU4nv14Vqox2A46Y55CJhWl8AQy7X5hTkCTd0=.65395699-2e1d-4fc6-aabf-e20534d188d0@github.com>

On Tue, 9 Apr 2024 21:03:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the copyright year to 2024
>
> Trivially, what's the reason you capitalised the word "tags" in the PR title and the respective JBS issue?

@pavelrappo no real reason, that's just how I wrote it in my notes and it persisted until now.
I can change it here if you change it in the JBS

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

PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-2046204353

From sgibbons at openjdk.org  Tue Apr  9 23:48:09 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 9 Apr 2024 23:48:09 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <2X2qG_TCmbIfhM4CCepi7PHttQGFuMXlLgea1Yq15uc=.3d4bdee1-2eed-4df9-bcb4-f08bf8060119@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <9BH6kkaQU5kSjlJUnNenUeWBK2EdahCuks8qEUjDlv0=.b8979589-32df-4fa3-b5a6-f56dad76c58d@github.com>
 <lHOUGJcmoxK_FDm_gP5yj6BU6ccDCujHCGTB_FMNHYg=.69287fa4-dc59-4cc5-98c6-f91c070662da@github.com>
 <2X2qG_TCmbIfhM4CCepi7PHttQGFuMXlLgea1Yq15uc=.3d4bdee1-2eed-4df9-bcb4-f08bf8060119@github.com>
Message-ID: <aLlDStjTsmA-7zIfaeSxiJ7_d7nKL75t5DkU1ipqlbY=.108867c5-5994-48a9-bfe1-efe59f50dc38@github.com>

On Sun, 7 Apr 2024 05:14:08 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> I went ahead and tried a pure-Java implementation, and it is faster for small sizes (up to 8) and only about 1.5x slower for larger sizes, so that might make for an interesting fallback if there is no customized assembler implementation available or if the size is known to me small.
>> 
>> Ideally, I think we would want C2 to be more aware of setMemory stores, so that it can remove redundant stores, like it does with InitializeNode.
>
> @dean-long in my old PR I have done the same, choosing a (not yet) configurable cutoff value. 
> 
> See https://github.com/openjdk/jdk/pull/16760

As an experiment I added the java code that @franz1981 supplied and ran performance vs. the intrinsic stub.  I used 128 bytes as the cutoff value as in that code.  I saw about 0.75 to 1ns improvement for sizes of 1 or 2 bytes only.  Anything larger and the stub performed better.

@mcimadamore Is there any way to disable some of the optimizations C2 will attempt on the IR?  We need to maintain atomicity, so vectorization shouldn't occur, for instance.  This seems like a rat-hole that would need constant maintenance as C2 optimizations get better.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2046208254

From bpb at openjdk.org  Wed Apr 10 00:44:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 10 Apr 2024 00:44:13 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <-Zea7R_YyTjfcZl140hcu3dXQiG132FP9Q__a447BgQ=.8237cc56-a0dd-413b-85a9-5c2115d956b5@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

The `CarrierThread` changes look to be the most complicated here but I don't see any problems. Otherwise, I don't have any comments aside from some that @jaikiran already made hence not worth repeating.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18598#pullrequestreview-1990512527

From jpai at openjdk.org  Wed Apr 10 01:34:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 01:34:16 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <RPLE81TlmSQ76sgyH4xz5D1AWzylsCUzL_Zta_-gTDc=.e2dbaf98-2aad-49ab-a6e3-97f0a77c1184@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
 <RPLE81TlmSQ76sgyH4xz5D1AWzylsCUzL_Zta_-gTDc=.e2dbaf98-2aad-49ab-a6e3-97f0a77c1184@github.com>
Message-ID: <Fc0I0vfhCglQriFpwZLdoIELNzUXRRP3SbXX2-VHqU0=.46d70629-6c85-475d-82ac-883eef34f950@github.com>

On Tue, 9 Apr 2024 16:29:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto's suggestion - use Instant.MIN and Instant.MAX instead of hardcoded values
>
> src/java.base/share/classes/java/time/temporal/ChronoField.java line 590:
> 
>> 588:      * This is necessary to ensure interoperation between calendars.
>> 589:      * <p>
>> 590:      * Range of {@code InstantSeconds} is between {@link Instant#MIN} and {@link Instant#MAX}
> 
> Nit: `InstantSeconds` -> `INSTANT_SECONDS`

Hello Naoto, I had used `InstantSeconds` to keep it consistent with how a similar doc is used for the `EPOCH_DAY` field. Let me know if you still prefer this to be `INSTANT_SECONDS` and I will update it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1558644428

From jpai at openjdk.org  Wed Apr 10 01:38:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 01:38:11 GMT
Subject: Integrated: 8329729:
 java/util/Properties/StoreReproducibilityTest.java times out
In-Reply-To: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>
References: <oJ0PRWBstvD2VG7ZauUM0bo1VJ0xtJ_pLiBi_78CIR4=.35c380d6-de5e-45ef-af8d-e6d8cb6f44a3@github.com>
Message-ID: <0YLHpr_0yOJglgfSvKAaIC005Fmgu3uPNbAEXIlrpeU=.23fb0f3f-c1a4-43b8-9e29-7d6ba81e85c7@github.com>

On Tue, 9 Apr 2024 01:13:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address the intermittent failures in `java/util/Properties/StoreReproducibilityTest.java`? This should address https://bugs.openjdk.org/browse/JDK-8329729.
> 
> These failures in `StoreReproducibilityTest` have been observed in higher tiers where the test tasks are launched with various JVM options, one of them being `-Xcomp`. The goal of the `StoreReproducibilityTest` is to verify that the content which the `java.util.Properties` code generates for a properties file and reproducible across multiple different runs/launches of an Java application. To do that it launches a test application (using `java` command) several times within the test (for different scenarios). That comes up to a combined total of 25 launches, for different scenarios. Normally each such launch of the `java` application completes within a second or two. 
> 
> Recently, we have been updating our tests to pass along the JVM options that were used for launching the test task, to the child processes that are launched from within the tests. That now means that these trivial small java application that this test launches several times will now be passed the `-Xcomp` option too (when the test task is launched with that option). It has been observed that when `-Xcomp` is used to launch those trivial applications from within the test, each such application takes around 30 seconds to a minute to complete. This then causes the test to timeout.
> 
> Given the context of this test case, it's not necessary to run this test when `-Xcomp` is used. The commit in this PR add a `@requires` to disable this test when `-Xcomp` is present in the test task's JVM args. 
> 
> I've run this change in our CI and the test continues to run (and pass) when `-Xcomp` is absent and is skipped when it is present.

This pull request has now been integrated.

Changeset: b81b86da
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b81b86da9849fbc4fb341bff8a23d10aee9967b3
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8329729: java/util/Properties/StoreReproducibilityTest.java times out

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/18681

From alanb at openjdk.org  Wed Apr 10 06:22:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Apr 2024 06:22:02 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <-Zea7R_YyTjfcZl140hcu3dXQiG132FP9Q__a447BgQ=.8237cc56-a0dd-413b-85a9-5c2115d956b5@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <-Zea7R_YyTjfcZl140hcu3dXQiG132FP9Q__a447BgQ=.8237cc56-a0dd-413b-85a9-5c2115d956b5@github.com>
Message-ID: <hlRJCBsL83-Zqo_ruIuRinMCMV-ek40t0YRNc-Te9t8=.6b196b39-0360-4cea-9f0c-90ef8b8945c6@github.com>

On Wed, 10 Apr 2024 00:41:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> changes look to be the most complicated here but I don't see any problems. 

I have some changes come that should make this easier to read, I'll update the PR in a few days.

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

PR Comment: https://git.openjdk.org/jdk/pull/18598#issuecomment-2046613420

From alanb at openjdk.org  Wed Apr 10 06:26:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Apr 2024 06:26:13 GMT
Subject: Withdrawn: 8329593: Drop adjustments to target parallelism when
 virtual threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <TJLEqj1uamveRWOCEQ9NAl3YN9J3O_SXEGKhDC_jM9Q=.2d7b6c98-c03a-4a94-849b-1ea96fd6cad4@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/18598

From mbaesken at openjdk.org  Wed Apr 10 07:19:09 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 10 Apr 2024 07:19:09 GMT
Subject: RFR: JDK-8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <1OgWz9GmBNCQM98Kxh_mSKrlJohlYallG3rrV8hfC5A=.ffd723bb-fb67-4d9b-a7ba-1438cfa2d54e@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <1OgWz9GmBNCQM98Kxh_mSKrlJohlYallG3rrV8hfC5A=.ffd723bb-fb67-4d9b-a7ba-1438cfa2d54e@github.com>
Message-ID: <XRZWaILXsubG85zvogxU1Zp8J9uUA299IAF3Nyvkdgs=.84e18304-115f-415a-9027-eb9ef41f0322@github.com>

On Tue, 9 Apr 2024 17:26:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  If we expand the tracing then I think it should be consistent with the existing tracing.

I just added some tracing calls where I missed them. Do you think  I should do some more adjustments ?
Btw. is the  `GetApplicationHomeFromDll`   (which in fact is getting the image location from the jli shared lib location) approach for the launcher documented somewhere or is this something that  'just works' for a log time  ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2046694106

From mdoerr at openjdk.org  Wed Apr 10 08:12:13 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 Apr 2024 08:12:13 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v17]
In-Reply-To: <-_HBuQ_BnCR50XDI9rDO0R1hdKb_i7W89K4dzI5KqOg=.9876aca9-9d71-4fee-bfba-a11e2218ebd3@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <L_QJNe1rj7r5aSshwGfYv6W140LB4Bc7pg6VIIZyirg=.3798e831-6a69-4600-bfac-9af447673660@github.com>
 <gz62KKckc6SIGEjc5nMjg-e79S-t96xk3A5D-WPPLWI=.72efec23-5b7f-476c-8e71-018c3ccaa74b@github.com>
 <-_HBuQ_BnCR50XDI9rDO0R1hdKb_i7W89K4dzI5KqOg=.9876aca9-9d71-4fee-bfba-a11e2218ebd3@github.com>
Message-ID: <9mWncAmQ1M3nXTXxsi5EedQaV3eHRbp-FyS2l7xyLCc=.1bd3e29c-6183-4d61-8840-dc2fcbbf7278@github.com>

On Tue, 9 Apr 2024 10:01:59 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 37:
>> 
>>> 35:         File awtSharedObjectPath = new File("/test/lib/libawt.so");
>>> 36:         File awtArchivePath = new File("/test/lib/libawt.a");
>>> 37:         awtSharedObjectPath.renameTo(awtArchivePath);
>> 
>> This should work for this test. But, what if an AWT test gets executed after your test? I think copy is safer than renaming.
>
> Maybe i need to rename it back. If we just copy, it would take the .so itself, so we cant enforce it.

No, you would just need to change the name to maybe "libdummyarchive.a".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1559030522

From prappo at openjdk.org  Wed Apr 10 08:40:12 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 10 Apr 2024 08:40:12 GMT
Subject: RFR: JDK-8326836 Incorrect `@since` Tags for ClassSignature
 methods [v2]
In-Reply-To: <Z3Swa9jBmEKAqji5VIhbQ8j2sC_s9PNkBYnbvQiJGrI=.85b67fd5-d1ff-4fee-b719-43354c481381@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
 <emnKMZ-WItnQQLRD83517Y-dqdN45CfEo9154kkWTfI=.d53f0fc6-8f34-4a27-9a51-f6a1b9ddb798@github.com>
 <Z3Swa9jBmEKAqji5VIhbQ8j2sC_s9PNkBYnbvQiJGrI=.85b67fd5-d1ff-4fee-b719-43354c481381@github.com>
Message-ID: <V3tOP9aYKsBUPqIO-4aI-q0P4-cKe1F-yKTKC1GBgk4=.175e3580-2353-4ea5-bfb4-5fab7f750a76@github.com>

On Tue, 9 Apr 2024 21:03:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the copyright year to 2024
>
> Trivially, what's the reason you capitalised the word "tags" in the PR title and the respective JBS issue?

> @pavelrappo no real reason, that's just how I wrote it in my notes and it persisted until now. I can change it here if you change it in the JBS

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-2046913573

From cstein at openjdk.org  Wed Apr 10 08:44:11 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 10 Apr 2024 08:44:11 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
Message-ID: <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>

On Tue, 9 Apr 2024 13:38:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more tests for ambiguities.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3553:

> 3551: # 0: symbol
> 3552: compiler.err.import.module.does.not.read=\
> 3553:     current modules does not read: {0}

Suggestion:

    current module does not read: {0}


It would even be better to print the name of the "current" module, so that the user-facing message reads:
`current module foo does not read module bar - possible fix: add "requires bar;" to foo's module descriptor `

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559074245

From sroy at openjdk.org  Wed Apr 10 09:48:33 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 10 Apr 2024 09:48:33 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v19]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <_kKmMyRSHKOCaHqWhkSeYK7yqrDHz-v-Jfol4SN6l6c=.740cc550-d484-4fac-95e2-aa2f79a09740@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/d2f040b1..cab78e37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=17-18

  Stats: 23 lines in 1 file changed: 14 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From mcimadamore at openjdk.org  Wed Apr 10 10:38:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 10:38:12 GMT
Subject: RFR: 8329948: Remove string template feature [v2]
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <7L60G7fcdc2dZz5fMZJ3J9vE2QzE8_hePNjxLSCh7ls=.335d46ea-07c2-43bb-be55-e69dff55ed0c@github.com>

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

  Address review comments
  Drop redundant imports in digit classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18688/files
  - new: https://git.openjdk.org/jdk/pull/18688/files/99e940f6..da5b32c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=00-01

  Stats: 20 lines in 4 files changed: 0 ins; 17 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18688/head:pull/18688

PR: https://git.openjdk.org/jdk/pull/18688

From jpai at openjdk.org  Wed Apr 10 10:44:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 10:44:12 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags [v2]
In-Reply-To: <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
Message-ID: <rUsFP0fu6DBphVwV7m8kh7P3k_stHjdWn5AswxcDQoY=.1a499628-b022-49e7-8c92-c9cc51d2d47e@github.com>

On Thu, 4 Apr 2024 17:16:22 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Updated following tests to use ProcessTools methods:
>>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>>  test/jdk/javax/naming/spi/providers/InitialContextTest.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.
>   Updated EscapePath test.

test/jdk/javax/naming/spi/providers/InitialContextTest.java line 65:

> 63:  * @library /test/lib
> 64:  * @build jdk.test.lib.process.ProcessTools
> 65:  * @run main/othervm InitialContextTest

Hello Mahendra, I see that this test and one other test is being changed to `/othervm` and I suspect it's because, we now call:


System.setProperty("test.noclasspath", "true");

for the `ProcessTools` to skip adding the default `-cp` option to the launched Java process. 
In reality, we don't have to set that system property and thus you don't have to change this and the other test to `othervm`. See a previous discussion about the classpath handling by `ProcessTools` here https://github.com/openjdk/jdk/pull/17787/files/a9fcc6c2900356250b29b3d11b402790a84d9317#r1484276695 - essentially, whatever classpath you end up passing as part of the command to `ProcessTools.createTestJavaProcessBuilder()` will end up getting used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1559224415

From mcimadamore at openjdk.org  Wed Apr 10 10:48:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 10:48:39 GMT
Subject: RFR: 8329948: Remove string template feature [v3]
In-Reply-To: <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>
Message-ID: <5RuKC7OJFsFyaUYkks205sl6QlaU1-W7owcjpgwb0bE=.63df07df-6793-45fe-a999-2e5128487022@github.com>

On Tue, 9 Apr 2024 20:22:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert StringConcatFactory field to before string template
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 120:
> 
>> 118:      * @since 21
>> 119:      */
>> 120:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
> 
> May this value change in the future? If yes, we might change this to a method to avoid incorrect eager inlining by the java compiler, or drop this with string templates.

Good catch. Since this was tweaked to be a public API as part of the string template feature, I've reverted this code to what it was prior to string template. That is, now this is a private static final constant, with initializer set to 200 (no need to inhibit javac constant folding, since all uses are from this file).

> src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 44:
> 
>> 42:  *
>> 43:  * @since 21
>> 44:  */
> 
> Spurious javadoc

fixed, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1559228274
PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1559228920

From jpai at openjdk.org  Wed Apr 10 10:49:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 10:49:01 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags [v2]
In-Reply-To: <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
Message-ID: <1Qj9GW2u-cCp_V4w0Yd71XbUZjMLBNWg_LDwQ6rZwE8=.29d6d01c-db03-4b05-9502-bd71ce4730ee@github.com>

On Thu, 4 Apr 2024 17:16:22 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Updated following tests to use ProcessTools methods:
>>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>>  test/jdk/javax/naming/spi/providers/InitialContextTest.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.
>   Updated EscapePath test.

test/jdk/javax/naming/spi/providers/InitialContextTest.java line 268:

> 266:             OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(commands);
> 267:             if(outputAnalyzer.getExitValue() != 0) {
> 268:                 throw new RuntimeException(outputAnalyzer.getOutput());

I think it would be better to just call:

outputAnalyzer.shouldHaveExitValue(0);

that way it even prints the stdout/stderr logs and throws the exception.

test/jdk/javax/naming/spi/providers/InitialContextTest.java line 286:

> 284:             OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(commands.toArray(new String[commands.size()]));
> 285:             if(outputAnalyzer.getExitValue() != 0) {
> 286:                 throw new RuntimeException(outputAnalyzer.getOutput());

Same comment as above `outputAnalyzer.shouldHaveExitValue(0)` would be better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1559229610
PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1559230010

From mcimadamore at openjdk.org  Wed Apr 10 10:48:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 10:48:38 GMT
Subject: RFR: 8329948: Remove string template feature [v3]
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <FyY9fKVFpzoGfhsEVa0f21rjVFf1Cl6whkJqWJ0u8Pw=.7595911c-c7e5-4241-b3a4-4960be540c5e@github.com>

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

  Revert StringConcatFactory field to before string template

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18688/files
  - new: https://git.openjdk.org/jdk/pull/18688/files/da5b32c9..a7396ce0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/18688

From jpai at openjdk.org  Wed Apr 10 10:54:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 10:54:09 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags [v2]
In-Reply-To: <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
Message-ID: <v3CBejrqpSOWPwj_UQgsE3jBEm0T_3tUtlIQR7IbiCo=.b362d9f7-2ce9-4866-9fbc-1e7eab33748e@github.com>

On Thu, 4 Apr 2024 17:16:22 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Updated following tests to use ProcessTools methods:
>>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>>  test/jdk/javax/naming/spi/providers/InitialContextTest.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.
>   Updated EscapePath test.

test/jdk/javax/naming/spi/providers/InitialContextTest.java line 271:

> 269:             }
> 270:         } catch (Exception ex) {
> 271:             throw new RuntimeException(ex.getMessage());

This and other similar places in this PR will end up swallowing the underlying exception. It would be better to just have the method have a `throws Exception` or change this to:


throw new RuntimeException(ex);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1559235120

From mcimadamore at openjdk.org  Wed Apr 10 10:59:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 10:59:25 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <pQ7KfrIBPSZz0ktsYzF1_7tUsCfWErjze-3Ez8kNGYE=.79b45003-ad90-4e6a-8ff4-aca7a7386fa1@github.com>

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

  Fix issues in digit classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18688/files
  - new: https://git.openjdk.org/jdk/pull/18688/files/a7396ce0..51e261bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=02-03

  Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18688/head:pull/18688

PR: https://git.openjdk.org/jdk/pull/18688

From jpai at openjdk.org  Wed Apr 10 11:00:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 11:00:13 GMT
Subject: RFR: JDK-8319678: Several tests from corelibs areas ignore VM
 flags [v2]
In-Reply-To: <1Qj9GW2u-cCp_V4w0Yd71XbUZjMLBNWg_LDwQ6rZwE8=.29d6d01c-db03-4b05-9502-bd71ce4730ee@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
 <1Qj9GW2u-cCp_V4w0Yd71XbUZjMLBNWg_LDwQ6rZwE8=.29d6d01c-db03-4b05-9502-bd71ce4730ee@github.com>
Message-ID: <LVAMoP2hXNFyTZBYeqg6o7toErWN2eLLJm8BcuoP1n8=.92cdceca-49fc-47bd-9468-314e1536432e@github.com>

On Wed, 10 Apr 2024 10:45:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>>   Updated EscapePath test.
>
> test/jdk/javax/naming/spi/providers/InitialContextTest.java line 286:
> 
>> 284:             OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(commands.toArray(new String[commands.size()]));
>> 285:             if(outputAnalyzer.getExitValue() != 0) {
>> 286:                 throw new RuntimeException(outputAnalyzer.getOutput());
> 
> Same comment as above `outputAnalyzer.shouldHaveExitValue(0)` would be better.

Applies to some other files in this PR as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1559242406

From sroy at openjdk.org  Wed Apr 10 11:00:48 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 10 Apr 2024 11:00:48 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v20]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <38VcnqAFAhm0SSATiy6Ls_2-RtcrbYQcStAvWdanO98=.e05389f0-e8d6-4255-831a-68b68c572625@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/cab78e37..33257fe5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=18-19

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Wed Apr 10 11:06:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 10 Apr 2024 11:06:21 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v21]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <NV-L-pgfwYjTWYvWdRmRfYTQLnJ_syvh3OufI7M6xVA=.1dbc0b6a-4075-4073-9238-4e5194de6df4@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/33257fe5..488779a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=19-20

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

PR: https://git.openjdk.org/jdk/pull/17945

From mcimadamore at openjdk.org  Wed Apr 10 11:34:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 11:34:10 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v6]
In-Reply-To: <aLlDStjTsmA-7zIfaeSxiJ7_d7nKL75t5DkU1ipqlbY=.108867c5-5994-48a9-bfe1-efe59f50dc38@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <9BH6kkaQU5kSjlJUnNenUeWBK2EdahCuks8qEUjDlv0=.b8979589-32df-4fa3-b5a6-f56dad76c58d@github.com>
 <lHOUGJcmoxK_FDm_gP5yj6BU6ccDCujHCGTB_FMNHYg=.69287fa4-dc59-4cc5-98c6-f91c070662da@github.com>
 <2X2qG_TCmbIfhM4CCepi7PHttQGFuMXlLgea1Yq15uc=.3d4bdee1-2eed-4df9-bcb4-f08bf8060119@github.com>
 <aLlDStjTsmA-7zIfaeSxiJ7_d7nKL75t5DkU1ipqlbY=.108867c5-5994-48a9-bfe1-efe59f50dc38@github.com>
Message-ID: <jC7jWS6GgH1D61QevcKDIMz6upts6OgGUrzTYQvdwC8=.513cbc9d-99dc-452d-88e5-82cc2f65605b@github.com>

On Tue, 9 Apr 2024 23:45:39 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

> Is there any way to disable some of the optimizations C2 will attempt on the IR? We need to maintain atomicity, so vectorization shouldn't occur, for instance. This seems like a rat-hole that would need constant maintenance as C2 optimizations get better.

Sorry, I do not know that (I'm not a C2 engineer :-) ). One small observation: how important is atomicity in the "full off-heap case" ? E.g. if a `setMemory` is occurring at a location that is provably off-heap (and we should have ways to detect that, we do that also for other unsafe memory access routines), then perhaps the atomicity requirement can go (as I suppose that requirement is there for the Java Memory Model) ?

So, perhaps, while we might not be able to fully optimize for on-heap access, we might be able to do so for off-heap access (which is an important case for FFM).

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2047288498

From mcimadamore at openjdk.org  Wed Apr 10 11:55:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 11:55:10 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
Message-ID: <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>

On Tue, 9 Apr 2024 13:38:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more tests for ambiguities.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 719:

> 717:     public static class JCModuleImport extends JCImportBase {
> 718:         /** The module name. */
> 719:         public JCExpression module;

Does it need to be an expression? Or is a name enough?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559303562

From naoto at openjdk.org  Wed Apr 10 12:29:59 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Apr 2024 12:29:59 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <Fc0I0vfhCglQriFpwZLdoIELNzUXRRP3SbXX2-VHqU0=.46d70629-6c85-475d-82ac-883eef34f950@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
 <RPLE81TlmSQ76sgyH4xz5D1AWzylsCUzL_Zta_-gTDc=.e2dbaf98-2aad-49ab-a6e3-97f0a77c1184@github.com>
 <Fc0I0vfhCglQriFpwZLdoIELNzUXRRP3SbXX2-VHqU0=.46d70629-6c85-475d-82ac-883eef34f950@github.com>
Message-ID: <VJ5yPQjXLWGNSY1VTXIAbw-O_gtu1rf8_wAUo4ZTE0U=.9772ff7d-6e02-4478-b8b0-c72e813c9e31@github.com>

On Wed, 10 Apr 2024 01:31:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/temporal/ChronoField.java line 590:
>> 
>>> 588:      * This is necessary to ensure interoperation between calendars.
>>> 589:      * <p>
>>> 590:      * Range of {@code InstantSeconds} is between {@link Instant#MIN} and {@link Instant#MAX}
>> 
>> Nit: `InstantSeconds` -> `INSTANT_SECONDS`
>
> Hello Naoto, I had used `InstantSeconds` to keep it consistent with how a similar doc is used for the `EPOCH_DAY` field. Let me know if you still prefer this to be `INSTANT_SECONDS` and I will update it.

With the @code tag, I initially thought it can be used programmatically, but apparently, it was simply an Enum name. Users may not notice it till they see the source (or run its `toString()`). I am fine with either way, but probably keep consistent with `EPOCH_DAY` where it is not using @code tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1559346584

From pminborg at openjdk.org  Wed Apr 10 12:54:31 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 10 Apr 2024 12:54:31 GMT
Subject: RFR: 8329997: Add MemorySegment::reinterpretate overloads for
 alignment constraints
Message-ID: <_85tSefjZUGI3VQbbktp9tgQVba9HymE0o2x-P_xL9Y=.856ec02f-a42c-4634-aa89-c5faaf03924f@github.com>

This PR proposes to add two overloads `MemorySegment::reinterpretate` to allow aligned reinterpretation.

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

Commit messages:
 - Update copyright year
 - Add MemorySegment::reinterpretate overloads for alignment constraints

Changes: https://git.openjdk.org/jdk/pull/18717/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18717&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329997
  Stats: 126 lines in 6 files changed: 111 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18717.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18717/head:pull/18717

PR: https://git.openjdk.org/jdk/pull/18717

From ihse at openjdk.org  Wed Apr 10 12:59:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 10 Apr 2024 12:59:19 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
Message-ID: <u5VFr7CtWuUevJlxAd2lgriXXoTymhM5n-eCxFzdXsQ=.0c0d774b-5bdc-4743-abd6-d1dfe6c1ef20@github.com>

On Thu, 4 Apr 2024 16:46:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shorter name for the build tool
>  - Review feedback from Erik J.
>  - Remove dependency on CDS which isn't needed anymore

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-1991612359

From jlahoda at openjdk.org  Wed Apr 10 13:32:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 13:32:00 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
 <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>
Message-ID: <dykimHLkPTQ3DOlg_958nShX_C6jg2R8LyYiYty9dvo=.8e80a4d4-50d4-476b-9c99-7caabe850c93@github.com>

On Wed, 10 Apr 2024 11:52:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more tests for ambiguities.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 719:
> 
>> 717:     public static class JCModuleImport extends JCImportBase {
>> 718:         /** The module name. */
>> 719:         public JCExpression module;
> 
> Does it need to be an expression? Or is a name enough?

Expression is more consistent with e.g. the module directives (`JCRequires` has `JCExpression moduleName`). Also allows us to keep positions for the name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559440577

From jlahoda at openjdk.org  Wed Apr 10 15:06:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 15:06:30 GMT
Subject: RFR: 8328481: Implement Module Imports [v5]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Uaz4XY4xMPhWtROJwJZXvj3xTpaLM9PkENBv2I7a5v0=.05e6dd91-b210-44b5-bdf9-55956ddb02d3@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Including current module name as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/0ca05b7d..7cfaff80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=03-04

  Stats: 76 lines in 4 files changed: 73 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From jlahoda at openjdk.org  Wed Apr 10 15:06:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 15:06:30 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
 <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>
Message-ID: <ppdqge1epw5D3i0ClDI94dSJEhzgUcnGhSxGYGZoiWU=.8f834464-b2c7-441b-85f0-520ba637c8ef@github.com>

On Wed, 10 Apr 2024 08:41:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more tests for ambiguities.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3553:
> 
>> 3551: # 0: symbol
>> 3552: compiler.err.import.module.does.not.read=\
>> 3553:     current modules does not read: {0}
> 
> Suggestion:
> 
>     current module does not read: {0}
> 
> 
> It would even be better to print the name of the "current" module, so that the user-facing message reads:
> `current module foo does not read module bar - possible fix: add "requires bar;" to foo's module descriptor `

Thanks. I've tweaked the error to include the module name here:
https://github.com/openjdk/jdk/pull/18614/commits/7cfaff80eac6261b62c5cdb9614a0e708bce7e33

Regarding possible fix(es) - it may be better to introduce some framework for that, and convert the most typical errors, separately. (As I don't think we do that for other errors.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559616761

From jlahoda at openjdk.org  Wed Apr 10 15:20:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 15:20:00 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <5RuKC7OJFsFyaUYkks205sl6QlaU1-W7owcjpgwb0bE=.63df07df-6793-45fe-a999-2e5128487022@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>
 <5RuKC7OJFsFyaUYkks205sl6QlaU1-W7owcjpgwb0bE=.63df07df-6793-45fe-a999-2e5128487022@github.com>
Message-ID: <sLe7LwlNZ0tmjHahjRp9_K_TJ5bt5x5P7YxohEm21tA=.3a43d9ec-f93d-4add-a2f5-d0903af6030f@github.com>

On Wed, 10 Apr 2024 10:44:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 120:
>> 
>>> 118:      * @since 21
>>> 119:      */
>>> 120:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
>> 
>> May this value change in the future? If yes, we might change this to a method to avoid incorrect eager inlining by the java compiler, or drop this with string templates.
>
> Good catch. Since this was tweaked to be a public API as part of the string template feature, I've reverted this code to what it was prior to string template. That is, now this is a private static final constant, with initializer set to 200 (no need to inhibit javac constant folding, since all uses are from this file).

Just for completeness - note the field is not initialized in its initializator, but using a static init below. Fields like this are not inlined as constants by javac - that would require the value to be provided in the field initializator.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1559643723

From jvernee at openjdk.org  Wed Apr 10 15:26:10 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Apr 2024 15:26:10 GMT
Subject: RFR: 8329997: Add MemorySegment::reinterpretate overloads for
 alignment constraints
In-Reply-To: <_85tSefjZUGI3VQbbktp9tgQVba9HymE0o2x-P_xL9Y=.856ec02f-a42c-4634-aa89-c5faaf03924f@github.com>
References: <_85tSefjZUGI3VQbbktp9tgQVba9HymE0o2x-P_xL9Y=.856ec02f-a42c-4634-aa89-c5faaf03924f@github.com>
Message-ID: <y_uBzqiHDgA_AbWLHKJz9wL9_0zgLvLD6OWR57O1j48=.66e7ee8e-1ae2-4a5d-a6b7-45ff8ea261d1@github.com>

On Wed, 10 Apr 2024 12:49:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add two overloads `MemorySegment::reinterpretate` to allow aligned reinterpretation.

src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 72:

> 70:             sessionImpl.addCloseAction(action);
> 71:         }
> 72:         return new NativeMemorySegmentImpl(Utils.alignUp(min, byteAlignment), byteSize, false, sessionImpl);

This is not correct. The base address of the segment should not change after a call to reinterpret. The alignment constraint should just be used for checking that the base address is somewhat sane. Instead, I think `reinterpretInternal` or the overloads that take a memory layout should do the check of the alignment of `addres()` with the given alignment constraint.

test/jdk/java/foreign/TestSegments.java line 396:

> 394:         AtomicInteger counter = new AtomicInteger();
> 395:         try (Arena arena = Arena.ofConfined()){
> 396:             var segment = MemorySegment.ofAddress(41).reinterpret(JAVA_INT);

i.e. this call (and the one below) should throw an exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18717#discussion_r1559643107
PR Review Comment: https://git.openjdk.org/jdk/pull/18717#discussion_r1559649552

From mcimadamore at openjdk.org  Wed Apr 10 15:26:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 15:26:11 GMT
Subject: RFR: 8329997: Add MemorySegment::reinterpretate overloads for
 alignment constraints
In-Reply-To: <y_uBzqiHDgA_AbWLHKJz9wL9_0zgLvLD6OWR57O1j48=.66e7ee8e-1ae2-4a5d-a6b7-45ff8ea261d1@github.com>
References: <_85tSefjZUGI3VQbbktp9tgQVba9HymE0o2x-P_xL9Y=.856ec02f-a42c-4634-aa89-c5faaf03924f@github.com>
 <y_uBzqiHDgA_AbWLHKJz9wL9_0zgLvLD6OWR57O1j48=.66e7ee8e-1ae2-4a5d-a6b7-45ff8ea261d1@github.com>
Message-ID: <_wR_MocXRp-xs34a7ljYDMLZ6hmnydZFHrphYuM2MIU=.54810244-5b07-489b-bd93-dd92bbed15fc@github.com>

On Wed, 10 Apr 2024 15:19:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR proposes to add two overloads `MemorySegment::reinterpretate` to allow aligned reinterpretation.
>
> test/jdk/java/foreign/TestSegments.java line 396:
> 
>> 394:         AtomicInteger counter = new AtomicInteger();
>> 395:         try (Arena arena = Arena.ofConfined()){
>> 396:             var segment = MemorySegment.ofAddress(41).reinterpret(JAVA_INT);
> 
> i.e. this call (and the one below) should throw an exception.

Note - this means that the javadoc of the new methods should also document an IllegalArgumentException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18717#discussion_r1559656059

From mcimadamore at openjdk.org  Wed Apr 10 15:30:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 15:30:10 GMT
Subject: RFR: 8329997: Add MemorySegment::reinterpretate overloads for
 alignment constraints
In-Reply-To: <_85tSefjZUGI3VQbbktp9tgQVba9HymE0o2x-P_xL9Y=.856ec02f-a42c-4634-aa89-c5faaf03924f@github.com>
References: <_85tSefjZUGI3VQbbktp9tgQVba9HymE0o2x-P_xL9Y=.856ec02f-a42c-4634-aa89-c5faaf03924f@github.com>
Message-ID: <B3vYPb9N1wIPULxOI9JQx3EVWqFY8F3C9lS3xX6lm20=.26f4a657-88d5-41e2-a278-c9df5bd1d72f@github.com>

On Wed, 10 Apr 2024 12:49:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add two overloads `MemorySegment::reinterpretate` to allow aligned reinterpretation.

Should we add the full set of overloads? E.g.
reinterpret(arena, cleanup)
reinterpret(size)
reinterpret(size, arena, cleanup)
reinterpret(size, align) // this is missing
reinterpret(size, align, arena, cleanup)  // this is missing
reinterpret(layout)
reinterpret(layout, arena, cleanup)

In other places (e.g. `asSlice`) we accept size/align where we also accept a layout

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

PR Comment: https://git.openjdk.org/jdk/pull/18717#issuecomment-2047856585

From mcimadamore at openjdk.org  Wed Apr 10 15:38:59 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 15:38:59 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <sLe7LwlNZ0tmjHahjRp9_K_TJ5bt5x5P7YxohEm21tA=.3a43d9ec-f93d-4add-a2f5-d0903af6030f@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>
 <5RuKC7OJFsFyaUYkks205sl6QlaU1-W7owcjpgwb0bE=.63df07df-6793-45fe-a999-2e5128487022@github.com>
 <sLe7LwlNZ0tmjHahjRp9_K_TJ5bt5x5P7YxohEm21tA=.3a43d9ec-f93d-4add-a2f5-d0903af6030f@github.com>
Message-ID: <an8ZYi4YGqnB6GIu7hFYUbuTRiPW0TrAOkAgwPhQCAI=.8bad2ef8-6827-492c-9d6f-b636d58fbc84@github.com>

On Wed, 10 Apr 2024 15:17:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Good catch. Since this was tweaked to be a public API as part of the string template feature, I've reverted this code to what it was prior to string template. That is, now this is a private static final constant, with initializer set to 200 (no need to inhibit javac constant folding, since all uses are from this file).
>
> Just for completeness - note the field is not initialized in its initializator, but using a static init below. Fields like this are not inlined as constants by javac - that would require the value to be provided in the field initializator.

@lahodaj - I understand that - but I reverted to use the initializer, since the initializer was used before string templates (when the field was private).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1559676399

From jvernee at openjdk.org  Wed Apr 10 15:42:18 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Apr 2024 15:42:18 GMT
Subject: RFR: 8330049: Remove unused AbstractLinker::linkerByteOrder
Message-ID: <GsFkHXwmmJklludgA2z7Kwxw4xk25O0Iru_G5ylHY_I=.4e8e87e4-c92c-415e-93df-6b4a4355fbc0@github.com>

Please review this simple cleanup which removes the `AbstractLinker::linkerByteOrder` method. It was only used in `AixPPC64Linker`, where we know it will always return `ByteOrder.BIG_ENDIAN` so we can just replace the call with that.

Testing: Local run of `run-test-jdk_foreign`.

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

Commit messages:
 - Remove unused AbstractLinker::linkerByteOrder

Changes: https://git.openjdk.org/jdk/pull/18726/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18726&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330049
  Stats: 59 lines in 12 files changed: 0 ins; 58 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18726/head:pull/18726

PR: https://git.openjdk.org/jdk/pull/18726

From mdoerr at openjdk.org  Wed Apr 10 15:44:15 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 Apr 2024 15:44:15 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v21]
In-Reply-To: <NV-L-pgfwYjTWYvWdRmRfYTQLnJ_syvh3OufI7M6xVA=.1dbc0b6a-4075-4073-9238-4e5194de6df4@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <NV-L-pgfwYjTWYvWdRmRfYTQLnJ_syvh3OufI7M6xVA=.1dbc0b6a-4075-4073-9238-4e5194de6df4@github.com>
Message-ID: <j09GcV3BmHyFZep0RgecWqI4Wfue1WYRj_GZorYlrZU=.883a9164-3302-4e3d-861d-9769c0dfa8de@github.com>

On Wed, 10 Apr 2024 11:06:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test change

JTREG usually places libraries here: https://github.com/openjdk/jdk/blob/279ed0ddd505fb3052b818f755b4b220ed5557e6/make/test/JtregNativeJdk.gmk#L47
Files can get copied by `Files.copy`: https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#copy-java.nio.file.Path-java.nio.file.Path-java.nio.file.CopyOption...-

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2047886211

From mcimadamore at openjdk.org  Wed Apr 10 16:00:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 16:00:12 GMT
Subject: RFR: 8330049: Remove unused AbstractLinker::linkerByteOrder
In-Reply-To: <GsFkHXwmmJklludgA2z7Kwxw4xk25O0Iru_G5ylHY_I=.4e8e87e4-c92c-415e-93df-6b4a4355fbc0@github.com>
References: <GsFkHXwmmJklludgA2z7Kwxw4xk25O0Iru_G5ylHY_I=.4e8e87e4-c92c-415e-93df-6b4a4355fbc0@github.com>
Message-ID: <syI8k1Jko3qKs5sN6tYCHmFO5I6jibJk9TebRzesH64=.b902ae61-2ef5-4c65-918b-8741634d9265@github.com>

On Wed, 10 Apr 2024 15:38:22 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Please review this simple cleanup which removes the `AbstractLinker::linkerByteOrder` method. It was only used in `AixPPC64Linker`, where we know it will always return `ByteOrder.BIG_ENDIAN` so we can just replace the call with that.
> 
> Testing: Local run of `run-test-jdk_foreign`.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18726#pullrequestreview-1992115409

From jvernee at openjdk.org  Wed Apr 10 16:03:21 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 Apr 2024 16:03:21 GMT
Subject: RFR: 8330049: Remove unused AbstractLinker::linkerByteOrder [v2]
In-Reply-To: <GsFkHXwmmJklludgA2z7Kwxw4xk25O0Iru_G5ylHY_I=.4e8e87e4-c92c-415e-93df-6b4a4355fbc0@github.com>
References: <GsFkHXwmmJklludgA2z7Kwxw4xk25O0Iru_G5ylHY_I=.4e8e87e4-c92c-415e-93df-6b4a4355fbc0@github.com>
Message-ID: <dHfgu8Is7OxjhacKkpOQVjj4cC7giO8Wix_4f_wirwg=.9a4b3ded-30dc-47d5-a5a8-3b3b21df4d3b@github.com>

> Please review this simple cleanup which removes the `AbstractLinker::linkerByteOrder` method. It was only used in `AixPPC64Linker`, where we know it will always return `ByteOrder.BIG_ENDIAN` so we can just replace the call with that.
> 
> Testing: Local run of `run-test-jdk_foreign`.

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

  update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18726/files
  - new: https://git.openjdk.org/jdk/pull/18726/files/12ccb842..eff6f471

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18726&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18726&range=00-01

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18726/head:pull/18726

PR: https://git.openjdk.org/jdk/pull/18726

From jpai at openjdk.org  Wed Apr 10 16:17:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 16:17:32 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v3]
In-Reply-To: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
Message-ID: <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
> 
> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
> 
> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.

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

  no need for {@code} in javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18674/files
  - new: https://git.openjdk.org/jdk/pull/18674/files/6e535779..ca265686

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18674&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18674&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/18674

From jpai at openjdk.org  Wed Apr 10 16:17:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 16:17:32 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
Message-ID: <eI6tDL-TutMSWcP9jXRPAS85ALU4GHw3t9mEcxuJVgA=.0ce88013-32c9-4b7a-9808-66ed72a44fe0@github.com>

On Tue, 9 Apr 2024 08:37:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's suggestion - use Instant.MIN and Instant.MAX instead of hardcoded values

Now that the changes have been finalized, I'll raise the CSR tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/18674#issuecomment-2047968321

From jpai at openjdk.org  Wed Apr 10 16:17:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 16:17:33 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v2]
In-Reply-To: <VJ5yPQjXLWGNSY1VTXIAbw-O_gtu1rf8_wAUo4ZTE0U=.9772ff7d-6e02-4478-b8b0-c72e813c9e31@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <owPR042ieYX4B3sty0pIzdrqPmPhKwLp2YyVbARxBck=.5f2be340-8d1f-46af-9ad0-74a6f63042e3@github.com>
 <RPLE81TlmSQ76sgyH4xz5D1AWzylsCUzL_Zta_-gTDc=.e2dbaf98-2aad-49ab-a6e3-97f0a77c1184@github.com>
 <Fc0I0vfhCglQriFpwZLdoIELNzUXRRP3SbXX2-VHqU0=.46d70629-6c85-475d-82ac-883eef34f950@github.com>
 <VJ5yPQjXLWGNSY1VTXIAbw-O_gtu1rf8_wAUo4ZTE0U=.9772ff7d-6e02-4478-b8b0-c72e813c9e31@github.com>
Message-ID: <ZeU1byKJZMVMd1u3ThVMblAvPvh8rW2E2Wdkv0V1er4=.f99cbe90-5c94-483c-b875-d15c8b06dc0e@github.com>

On Wed, 10 Apr 2024 12:27:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello Naoto, I had used `InstantSeconds` to keep it consistent with how a similar doc is used for the `EPOCH_DAY` field. Let me know if you still prefer this to be `INSTANT_SECONDS` and I will update it.
>
> With the @code tag, I initially thought it can be used programmatically, but apparently, it was simply an Enum name. Users may not notice it till they see the source (or run its `toString()`). I am fine with either way, but probably keep consistent with `EPOCH_DAY` where it is not using @code tag.

Hello Naoto, that's good point. I've updated the PR to remove `{@code}`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1559741398

From sroy at openjdk.org  Wed Apr 10 16:36:17 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 10 Apr 2024 16:36:17 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v21]
In-Reply-To: <j09GcV3BmHyFZep0RgecWqI4Wfue1WYRj_GZorYlrZU=.883a9164-3302-4e3d-861d-9769c0dfa8de@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <NV-L-pgfwYjTWYvWdRmRfYTQLnJ_syvh3OufI7M6xVA=.1dbc0b6a-4075-4073-9238-4e5194de6df4@github.com>
 <j09GcV3BmHyFZep0RgecWqI4Wfue1WYRj_GZorYlrZU=.883a9164-3302-4e3d-861d-9769c0dfa8de@github.com>
Message-ID: <ejHYh155VMYXr1Waee0BA953R7hT_JovY8ury2t1DfQ=.06009c7d-a8b0-402a-92d2-9fad61eab826@github.com>

On Wed, 10 Apr 2024 15:40:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> JTREG usually places libraries here:
> 
> https://github.com/openjdk/jdk/blob/279ed0ddd505fb3052b818f755b4b220ed5557e6/make/test/JtregNativeJdk.gmk#L47
> 
> 
> Files can get copied by `Files.copy`: https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#copy-java.nio.file.Path-java.nio.file.Path-java.nio.file.CopyOption...-

I have referred to the lib directory under jdk and not jtreg anymore. Wouldn't that be fine ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2048007327

From sroy at openjdk.org  Wed Apr 10 16:46:30 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 10 Apr 2024 16:46:30 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  Files copy method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/488779a4..3cd8bd1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=20-21

  Stats: 18 lines in 1 file changed: 2 ins; 15 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From ascarpino at openjdk.org  Wed Apr 10 17:22:09 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 10 Apr 2024 17:22:09 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
Message-ID: <n3KbSNXmQjwZZDFqbnehqVryLJ9FYQZzh4_bOLxymec=.4bc5a417-81e5-4dbc-819a-65924bcd2543@github.com>

On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove use of jdk.crypto.ec

In `ECOperations.java`, if I understand this correctly, it is to replace the existing `PointMultiplier` with montgomery-based PointMuliplier.  But when I look at the code, I see both are still options.  If I read this correctly, it checks for the old `IntegerFieldModuloP`, then looks for the new `IntegerMontgomeryFieldModuloP`.  It appears to use the new one always.
Why doesn't it just replace the old implementation entry in the `fields` Map?  Is there a reason to keep it around?

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2048090075

From mdoerr at openjdk.org  Wed Apr 10 17:36:05 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 Apr 2024 17:36:05 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v21]
In-Reply-To: <ejHYh155VMYXr1Waee0BA953R7hT_JovY8ury2t1DfQ=.06009c7d-a8b0-402a-92d2-9fad61eab826@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <NV-L-pgfwYjTWYvWdRmRfYTQLnJ_syvh3OufI7M6xVA=.1dbc0b6a-4075-4073-9238-4e5194de6df4@github.com>
 <j09GcV3BmHyFZep0RgecWqI4Wfue1WYRj_GZorYlrZU=.883a9164-3302-4e3d-861d-9769c0dfa8de@github.com>
 <ejHYh155VMYXr1Waee0BA953R7hT_JovY8ury2t1DfQ=.06009c7d-a8b0-402a-92d2-9fad61eab826@github.com>
Message-ID: <Dj_GLZro6bPTxhKQO_Q9yqSbZdMvTV-d4wnaN7qL3Yc=.2e1b4f25-1497-4652-ba16-32b7eb1165fb@github.com>

On Wed, 10 Apr 2024 16:33:53 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> I have referred to the lib directory under jdk and not jtreg anymore. Wouldn't that be fine ?

I don't think writing to the jdk is a good design. People may even want to write protect it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2048113271

From duke at openjdk.org  Wed Apr 10 17:41:21 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Wed, 10 Apr 2024 17:41:21 GMT
Subject: RFR: JDK-8326836 Incorrect `@since` tags for ClassSignature
 methods [v3]
In-Reply-To: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
Message-ID: <QJB-hjLD02ZUcVc3JK2T0r5Z0J5cnSZMnIDABd8zz9A=.17f337c3-bd2d-4664-8f27-798faa4f1daf@github.com>

> # Issue
> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were made to the method signatures but this modification isn't reflected in the @ since tags. The @ since tags need to be updated.
> 
> I changed the `@since` tags to better accurately show when the methods were introduced. This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

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

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18030/files
  - new: https://git.openjdk.org/jdk/pull/18030/files/8c0c7122..f73ce11a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18030&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18030&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18030/head:pull/18030

PR: https://git.openjdk.org/jdk/pull/18030

From naoto at openjdk.org  Wed Apr 10 17:46:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Apr 2024 17:46:10 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v3]
In-Reply-To: <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
Message-ID: <evf77TGQWVM3GGie1Yc-V35uRiDOTIc0k732mhk8Xd0=.0012f02b-48b9-4a98-acc2-268d5ef8b970@github.com>

On Wed, 10 Apr 2024 16:17:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need for {@code} in javadoc

Looks good, Jai. Thanks for the fix!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18674#pullrequestreview-1992333798

From duke at openjdk.org  Wed Apr 10 18:05:10 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 10 Apr 2024 18:05:10 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <n3KbSNXmQjwZZDFqbnehqVryLJ9FYQZzh4_bOLxymec=.4bc5a417-81e5-4dbc-819a-65924bcd2543@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <n3KbSNXmQjwZZDFqbnehqVryLJ9FYQZzh4_bOLxymec=.4bc5a417-81e5-4dbc-819a-65924bcd2543@github.com>
Message-ID: <k-S63XajUKQKl9lZkp_UzlhDjVJ6shdpqMYwTZLRPNA=.332a8e42-b4c4-4bb8-b642-df1478eda176@github.com>

On Wed, 10 Apr 2024 17:18:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> In `ECOperations.java`, if I understand this correctly, it is to replace the existing `PointMultiplier` with montgomery-based PointMuliplier. But when I look at the code, I see both are still options. If I read this correctly, it checks for the old `IntegerFieldModuloP`, then looks for the new `IntegerMontgomeryFieldModuloP`. It appears to use the new one always. Why doesn't it just replace the old implementation entry in the `fields` Map? Is there a reason to keep it around?

Hmm, thats a good point I haven't fully considered; i.e. (if I read correctly) "for `CurveDB.P_256` remove the fallback path to non-montgomery entirely".. that might also help in cleaning a few things up in the construction. Maybe even get rid of this nested ECOperations inside ECOperations.. Perhaps nesting isnt a big deal, but all attempts to make the ECC stack clearer is positive!

One functional reason that might justify keeping it as-is, is fuzz-testing; with the fallback available, I am able to write the included Fuzz tests and have them check the values against the existing implementation. While I also included a few KAT tests using openssl-generated values, the fuzz tests check millions of values and it does add a lot more certainty about correctness of this code.

Can it be removed? For the operations that do not involve multiplication (i.e. `setSum(*)`), montgomery is expensive. I think I did go through the uses of this code some time back (i.e. ECDHE, ECDSA and KeyGeneration) and existing IntegerPolynomialP256 is no longer used (I should verify that again) and only P256OrderField remains non-montgomery. So removing references to IntegerPolynomialP256 in ECOperations should be possible and cleaner. Removing IntegerPolynomialP256 from MontgomeryIntegerPolynomialP256 is harder (fromMontgomery() uses IntegerPolynomialP256) but perhaps also worth some thought..

I tend to like `ECOperationsFuzzTest.java` and would prefer to keep it, but it could also be chucked up as part of 'scaffolding' and removed in name of code quality?

Thanks @ascarpino 

PS: Perhaps there is some middle ground, remove the `ECOperations montgomeryOps` nesting, and construct (somehow?? singleton makes most things inaccessible..) the reference ECOperations in the fuzz test instead.. not sure how yet, but perhaps worth a further thought..

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2048159645

From sviswanathan at openjdk.org  Wed Apr 10 18:08:11 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 10 Apr 2024 18:08:11 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v7]
In-Reply-To: <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
Message-ID: <3zfjFlFN7zLHvF7jU3jtpVqLDbqiLMsofAzkYOAoqsk=.67a431df-5a4d-4a87-b333-3e6e3da7fad6@github.com>

On Mon, 8 Apr 2024 19:11:19 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add movq to locate_operand

To me doing the compiler intrinsic for Unsafe setMemory looked to be the right first step as in this PR. There is precedence with Unsafe copyMemory intrinsic so we are in sync with what is done before. We could request Fei Yang/Hamlin Li for RISC-V intrinsic and Bhavana Kilambi/Nick Gasson for AARCH64 intrinsic as follow up PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2048164233

From sroy at openjdk.org  Wed Apr 10 18:10:13 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 10 Apr 2024 18:10:13 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
Message-ID: <WtlZqWAr6fGrEbrBGYspCmojrjFBqgynNjhab7DcccE=.ce7653e2-a2e5-4789-986d-9c639cd050c6@github.com>

On Wed, 10 Apr 2024 16:46:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy method

> BUILD_JDK_JTREG_OUTPUT_DIR

I agree. How can i fetch this path ? I tried System.getEnv("BUILD_JDK_JTREG_OUTPUT_DIR") But it doesn't seem to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2048167273

From vklang at openjdk.org  Wed Apr 10 19:18:37 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 10 Apr 2024 19:18:37 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v3]
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <xERM37mI7mcvhgfy0wQ2FxHusbd8qfcuSMvwoPSXr-s=.69170342-3cac-4bf5-bb73-53a73bc0600c@github.com>

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR:
> 
> Benchmark            (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
> 
> 
> After this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score        Error  Units
> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s
> 
> 
> For streams of size 100k, the following numbers are interesting:
> 
> Before this PR:
> 
> Benchmark            (size)   Mode  Cnt  Score    Error  Units
> FlatMap.par_array    100000  thrpt   12  0,325 ?  0,004  ops/s
> FlatMap.par_iterate  100000  thrpt   12  0,106 ?  0,008  ops/s
> FlatMap.seq_array    100000  thrpt   12  0,173 ?  0,003  ops/s
> FlatMap.seq_iterate  100...

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

  More optimization work

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18625/files
  - new: https://git.openjdk.org/jdk/pull/18625/files/3ff40739..d6d35d53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=01-02

  Stats: 135 lines in 4 files changed: 71 ins; 1 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/18625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18625/head:pull/18625

PR: https://git.openjdk.org/jdk/pull/18625

From mdoerr at openjdk.org  Wed Apr 10 19:39:12 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 Apr 2024 19:39:12 GMT
Subject: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <WtlZqWAr6fGrEbrBGYspCmojrjFBqgynNjhab7DcccE=.ce7653e2-a2e5-4789-986d-9c639cd050c6@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
 <WtlZqWAr6fGrEbrBGYspCmojrjFBqgynNjhab7DcccE=.ce7653e2-a2e5-4789-986d-9c639cd050c6@github.com>
Message-ID: <8WFA7C-bcpRioyTfTdk94L_0JlbIFrXY1Ti3KX8pf40=.a70401a1-ae96-406c-ad07-ad5798003486@github.com>

On Wed, 10 Apr 2024 18:07:33 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > BUILD_JDK_JTREG_OUTPUT_DIR
> 
> I agree. How can i fetch this path ? I tried System.getEnv("BUILD_JDK_JTREG_OUTPUT_DIR") But it doesn't seem to work.

Hmm. Good question. Maybe it can get extracted from the library path. I noticed that other tests use e.g. https://github.com/openjdk/jdk/blob/70944ca54ad0090c734bb5b3082beb33450c4877/test/jdk/java/nio/file/Files/TemporaryFiles.java#L40
Maybe using that directory is easier. Does anybody else have a suggestion?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2048299821

From jlu at openjdk.org  Wed Apr 10 20:20:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Apr 2024 20:20:36 GMT
Subject: RFR: JDK-8327640: Allow NumberFormat strict parsing [v6]
In-Reply-To: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
Message-ID: <1MrLm5OWO8pdgD3UDTeYb7dIX2iYdFxpc0j8GzbXEWs=.25453a21-cc8d-477d-bac5-7ed3c51596a4@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
> 
> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
> 
> Below is an example of the change, the CSR can be viewed for further detail.
> 
> 
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
> 
> 
> The associated tests are all localized, and the data is converted properly during runtime.

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

 - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
 - improve wording consistency and see tags
 - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
 - revert cleanup changes; (to go into a separate change)
 - use directed 'inheritDoc' tag
 - update example for lenient parsing
 - replace protected field for private fields in subclasses for consistency
 - drop Format implNote as well
 - setStrict and isStrict should be optional in NumberFormat
   - specify and throw UOE as default
   - override and implement in dFmt and cmpctNFmt
   parseStrict should be protected, and utilized by subclasses. The public methods should just
   serve as API.
 - Re-work specification wording from Format down to subclasses
 - ... and 4 more: https://git.openjdk.org/jdk/compare/5de48d4a...aa1c284b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/3f2b097a..aa1c284b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=04-05

  Stats: 32548 lines in 782 files changed: 14532 ins; 12719 del; 5297 mod
  Patch: https://git.openjdk.org/jdk/pull/18339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339

PR: https://git.openjdk.org/jdk/pull/18339

From jlu at openjdk.org  Wed Apr 10 20:21:25 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Apr 2024 20:21:25 GMT
Subject: RFR: JDK-8329222: java.text.NumberFormat (and subclasses) spec updates
Message-ID: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>

Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.

The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.

To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);

I will update the CSR once the wording is finalized.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/18731/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18731&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329222
  Stats: 481 lines in 3 files changed: 166 ins; 152 del; 163 mod
  Patch: https://git.openjdk.org/jdk/pull/18731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18731/head:pull/18731

PR: https://git.openjdk.org/jdk/pull/18731

From duke at openjdk.org  Wed Apr 10 22:55:01 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 10 Apr 2024 22:55:01 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v7]
In-Reply-To: <9pFkX6iZWYDM9cBUh53VHch45MaKZnmpLkpZxWTDSnk=.4560f9b1-3099-42ef-8357-6e8a5ac35c9d@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <gmI4eExOapsFiXpbevIZd_b8MrqyH-eKs2m1dqXg93w=.06e8abe9-32c0-44be-9762-35fd1476a88b@github.com>
 <aFMQBLyS9_PFhMZS2T6GxvLK0wtM15-ICqZaehliQiw=.62e8cfd3-d8cd-4755-a853-9d1792fdd757@github.com>
 <9pFkX6iZWYDM9cBUh53VHch45MaKZnmpLkpZxWTDSnk=.4560f9b1-3099-42ef-8357-6e8a5ac35c9d@github.com>
Message-ID: <_5oFY7dwooDAhtYl87Nx2dQiguyRR7n2-VYavurkp_8=.4accd4b0-685c-4a5e-bb6c-646fd76da2df@github.com>

On Fri, 5 Apr 2024 15:57:24 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> I tried looking at the docs with `make docs-image`, but I can't test that the syntax/links are actually correct because `@implNote` does not actually show up in the web pages. As I understand from [the original proposal](https://mail.openjdk.org/pipermail/lambda-libs-spec-experts/2013-January/001211.html), `@implNote` is there to help to developer understand implementation, and is not intended to be exposed in the web docs.
>> 
>> This seems like information that would be useful to the consumer. So maybe we can consider moving this into the main comment block?
>
>> I tried looking at the docs with `make docs-image`, but I can't test that the syntax/links are actually correct because `@implNote` does not actually show up in the web pages. As I understand from [the original proposal](https://mail.openjdk.org/pipermail/lambda-libs-spec-experts/2013-January/001211.html), `@implNote` is there to help to developer understand implementation, and is not intended to be exposed in the web docs.
>> 
>> This seems like information that would be useful to the consumer. So maybe we can consider moving this into the main comment block?
> 
> @caojoshua the `@implNote` should definitely appear in the public API documentation, if not something is wrong. See for example: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Collections.html#method-detail

@simonis it was not showing up because the `implNote` was attached to private `putMapEntries`. I moved the `implNote` to public `putAll()`. It makes more sense there since the comment actually just talks about `putAll()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-2048561831

From duke at openjdk.org  Wed Apr 10 22:55:01 2024
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 10 Apr 2024 22:55:01 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v8]
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <OZJ6a0tTFEhhnYCCkpZIqbyYIHqRO2VIm19Nkv5bxAw=.7936f515-482c-4592-8d7e-480bb06bf92d@github.com>

> Add notes for `HashMap::putAll()` conservative resizing.
> 
> Note: everything below this line is from the original change. After discussion, we decided to keep the conservative resizing, but we should add an `@implNote` for the decision.
> 
> ---
> 
> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
> 
> ---
> 
> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
> 
> Before change:
> 
> 
> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       87...

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

 - Move implNote to putAll()
 - Merge branch 'master' into hashmap
 - Use @link for javadoc
 - Update implNotes to explain conservative resizing decisions and suggest
   options to avoid expensive resizing
 - Merge branch 'master' into hashmap
 - Add note about conservative resizing
 - Merge branch 'master' into hashmap
 - extract msize variable
 - Use max of both sizes and other maps size in case of overflow
 - Add benchmark with all duplicate keys
 - ... and 1 more: https://git.openjdk.org/jdk/compare/0e273613...2644e4d7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17544/files
  - new: https://git.openjdk.org/jdk/pull/17544/files/8db9e125..2644e4d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=06-07

  Stats: 31023 lines in 760 files changed: 13382 ins; 12516 del; 5125 mod
  Patch: https://git.openjdk.org/jdk/pull/17544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17544/head:pull/17544

PR: https://git.openjdk.org/jdk/pull/17544

From tprinzing at openjdk.org  Wed Apr 10 23:51:34 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 10 Apr 2024 23:51:34 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v6]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

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

  remove selector spin event attempt and associated test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/2e11e84a..d10be83e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=04-05

  Stats: 46 lines in 2 files changed: 1 ins; 43 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710

PR: https://git.openjdk.org/jdk/pull/16710

From duke at openjdk.org  Wed Apr 10 23:59:41 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 10 Apr 2024 23:59:41 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <YwzqZOEDfuKsay4D10uJVN77llZhRvIZxRApbPiAHz8=.a9e83ea8-7e18-437b-bc2d-3e2759558a25@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <YwzqZOEDfuKsay4D10uJVN77llZhRvIZxRApbPiAHz8=.a9e83ea8-7e18-437b-bc2d-3e2759558a25@github.com>
Message-ID: <48md2WEAhqPyuVf4AYOxBQDykUiOaEL0PQb-ki0_TYM=.6c25bf41-b0ae-49ec-b606-236deb4561e3@github.com>

On Fri, 5 Apr 2024 09:17:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Few early comments.
> 
> Please update the copyright year of all the modified files.
> 
> You can even consider splitting this into two patches, Java side changes in one and x86 optimized intrinsic in next one.

Thanks Jatin, will fix!

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2048618452

From duke at openjdk.org  Thu Apr 11 00:14:55 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Thu, 11 Apr 2024 00:14:55 GMT
Subject: RFR: 8326951: Missing `@since` tags [v5]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <F9hstn9Pda5BuTsAIUGOZelo_b83H_DLOkQI2EyMhno=.11e0b618-2dd6-4ea7-8c34-454360a3eae6@github.com>

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

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

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/7d6e969e..97f4c946

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=03-04

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055

PR: https://git.openjdk.org/jdk/pull/18055

From sviswanathan at openjdk.org  Thu Apr 11 00:33:48 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 11 Apr 2024 00:33:48 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v7]
In-Reply-To: <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
Message-ID: <XynEIFtYpP9dtpyTgjQ_NGc1uZ413F0r9GmwuDwuLMw=.046350cb-4c51-4874-b0a5-39f4c4fbd02c@github.com>

On Mon, 8 Apr 2024 19:11:19 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add movq to locate_operand

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2497:

> 2495: //
> 2496: address StubGenerator::generate_unsafe_setmemory(const char *name,
> 2497:                                                  address byte_fill_entry) {

Need to add UnsafeSetMemoryMark on similar lines as UnsafeCopyMemoryMark to handle page error.

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2522:

> 2520: #define rScratch3 r8
> 2521: #undef rScratch4
> 2522: #define rScratch4 r11

We could do this setup using const Register declaration instead of using #undef/#define pair.

src/hotspot/share/opto/library_call.cpp line 4950:

> 4948: 
> 4949: bool LibraryCallKit::inline_unsafe_setMemory() {
> 4950:   if (callee()->is_static())  return false;  // caller must have the capability!

Also need to return false if StubRoutines::unsafe_setmemory() == nullptr.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1560201153
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1560202218
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1560194011

From sviswanathan at openjdk.org  Thu Apr 11 00:47:56 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 11 Apr 2024 00:47:56 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v7]
In-Reply-To: <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
Message-ID: <GXsMdHCW0oFQNY0R1LTdxUUu1v3GHQVjr71PRJ5al9A=.344aa58b-14b7-4224-9b4b-5e48e7141931@github.com>

On Mon, 8 Apr 2024 19:11:19 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add movq to locate_operand

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5988:

> 5986:     movw(Address(to, 0), value);
> 5987:     addptr(to, 2);
> 5988:     subptr(count, 1<<(shift-1));

At line 5968 also we need the change from cmpl to cmpptr.
cmpl(count, 2<<shift); // Short arrays (< 8 bytes) fill by element

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6050:

> 6048:           vpbroadcastd(xtmp, xtmp, Assembler::AVX_512bit);
> 6049: 
> 6050:           subptr(count, 16 << shift);

At line 6045 also the cmpl should change to cmpptr:
cmpl(count, VM_Version::avx3_threshold());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1560205702
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1560213265

From duke at openjdk.org  Thu Apr 11 01:07:50 2024
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 11 Apr 2024 01:07:50 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
Message-ID: <9JQPjKJdFNfMbQsG7eF-byD6QoTLDxi98IRKeh70CRg=.0fcf810e-ee6a-4456-88cc-7e4f96a18751@github.com>

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

Keep open

On Wed, Apr 10, 2024, 17:40 bridgekeeper[bot] ***@***.***>
wrote:

> @Pr0methean <https://github.com/Pr0methean> 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!
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/17703#issuecomment-2048653656>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABF3NBOYVF4MBMKJ4FQBGIDY4XLYLAVCNFSM6AAAAABCZOX3UOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBYGY2TGNRVGY>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2048715593

From naoto at openjdk.org  Thu Apr 11 01:49:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 Apr 2024 01:49:23 GMT
Subject: RFR: 8327640: Allow NumberFormat strict parsing [v6]
In-Reply-To: <1MrLm5OWO8pdgD3UDTeYb7dIX2iYdFxpc0j8GzbXEWs=.25453a21-cc8d-477d-bac5-7ed3c51596a4@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
 <1MrLm5OWO8pdgD3UDTeYb7dIX2iYdFxpc0j8GzbXEWs=.25453a21-cc8d-477d-bac5-7ed3c51596a4@github.com>
Message-ID: <80VOFG9TzKd6if8SZnhLOJqcgy9GQf25GByd2sUQ1q4=.600d1abb-bd67-4105-8f71-6681e8b1e931@github.com>

On Wed, 10 Apr 2024 20:20:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
>> 
>> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
>> 
>> Below is an example of the change, the CSR can be viewed for further detail.
>> 
>> 
>> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
>> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
>> fmt.setLenient(false);
>> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
>> fmt.setGroupingSize(2);
>> fmt.parse("12,34,567"); // throws ParseException
>> fmt.setParseIntegerOnly(true)
>> fmt.parse("12,34.56"); // throws ParseException
>> fmt.parse("12,34"); // successfully returns the Number 1234
>> 
>> 
>> The associated tests are all localized, and the data is converted properly during runtime.
>
> Justin Lu 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:
> 
>  - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
>  - improve wording consistency and see tags
>  - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
>  - revert cleanup changes; (to go into a separate change)
>  - use directed 'inheritDoc' tag
>  - update example for lenient parsing
>  - replace protected field for private fields in subclasses for consistency
>  - drop Format implNote as well
>  - setStrict and isStrict should be optional in NumberFormat
>    - specify and throw UOE as default
>    - override and implement in dFmt and cmpctNFmt
>    parseStrict should be protected, and utilized by subclasses. The public methods should just
>    serve as API.
>  - Re-work specification wording from Format down to subclasses
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/645f53d4...aa1c284b

Looks good overall. Left some minor comments.
As to the tests, good to see those corner cases, but they should have unit tests for the new methods, i.e, `isStrict()` and `setStrict()`. Also I think equality/serialization for those methods should be examined.

src/java.base/share/classes/java/text/DecimalFormat.java line 43:

> 41: import sun.util.locale.provider.LocaleProviderAdapter;
> 42: import sun.util.locale.provider.ResourceBundleBasedAdapter;
> 43: 

Internal packages typically follow public packages.

src/java.base/share/classes/java/text/DecimalFormat.java line 2653:

> 2651:     }
> 2652: 
> 2653:     // Checks to make sure grouping size is not violated. Used when strict.

If it is only supposed to be used in `strict`, might be helpful to put an assertion here.

src/java.base/share/classes/java/text/DecimalFormat.java line 2663:

> 2661: 
> 2662:     // Calculates the index that violated the grouping size
> 2663:     // Calculation is determined whether it was an under or over violation

Not quite sure what `under/over violation` means here. Need more comments?

src/java.base/share/classes/java/text/NumberFormat.java line 43:

> 41: import sun.util.locale.provider.LocaleProviderAdapter;
> 42: import sun.util.locale.provider.LocaleServiceProviderPool;
> 43: 

Same as above

src/java.base/share/classes/java/text/NumberFormat.java line 493:

> 491:      */
> 492:     public boolean isStrict() {
> 493:         throw new UnsupportedOperationException();

Some message might be helpful.

src/java.base/share/classes/java/text/NumberFormat.java line 512:

> 510:      */
> 511:     public void setStrict(boolean strict) {
> 512:         throw new UnsupportedOperationException();

Same here

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

PR Review: https://git.openjdk.org/jdk/pull/18339#pullrequestreview-1993112743
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1560317735
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1560323356
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1560326734
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1560330147
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1560332122
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1560332205

From alanb at openjdk.org  Thu Apr 11 06:42:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Apr 2024 06:42:46 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v6]
In-Reply-To: <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
Message-ID: <vkAfGBcCwA134bS_a_-bKcz7a1NZSjQ81fUvuscEbaU=.4016c271-f0b7-4f4c-bf97-7dc38933f61a@github.com>

On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove selector spin event attempt and associated test.

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 40:

> 38: 
> 39:     @Label("SelectionKey Count")
> 40:     @Description("Number of channels ready for I/O or added to ready set")

We'll need to give you a better description for this. The value is the number of selection keys were updated by the selection operation. In many usages this will be the same as the number of keys added to the selected-key set (not "ready set") but they can be different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1560501216

From egahlin at openjdk.org  Thu Apr 11 07:39:44 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 11 Apr 2024 07:39:44 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v6]
In-Reply-To: <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
Message-ID: <KP4S1ke5frFQRlgdWqIvgX-o903FEspmLRsD_Dge4bk=.0ca033ef-62ad-4698-8435-18973fd7be56@github.com>

On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove selector spin event attempt and associated test.

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 33:

> 31: 
> 32: @Name(Type.EVENT_NAME_PREFIX + "SelectorSelect")
> 33: @Label("SelectorSelect")

This label should "Selector Select" and the description could be dropped as it doesn't add information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1560574399

From egahlin at openjdk.org  Thu Apr 11 07:47:47 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 11 Apr 2024 07:47:47 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v6]
In-Reply-To: <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
Message-ID: <utjR_oV2LV-NdTdhuX8AdZ5HboeEOEZ7JKToTUCAiJ8=.2a084b03-b842-4565-98c5-fdf98aae7fde@github.com>

On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove selector spin event attempt and associated test.

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44:

> 42: 
> 43:     @Label("Timeout Value")
> 44:     @Description("Milliseconds to block, or zero to block indefinitely")

The unit should not be mentioned. A GUI will typically convert it from the TimeSpan information and it will just look confusing if the descriptions says milliseconds when it's, for instance, displayed as 1 s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1560583317

From attila at openjdk.org  Thu Apr 11 07:54:44 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Thu, 11 Apr 2024 07:54:44 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: <IIfGXFqru0IHXjz0bKwaoofJKm5TUg9vvBrNR5fOX7Q=.68dcf8f5-1017-41c3-b6dc-8c8daa045d6f@github.com>
References: <DruTgFzQmTSLjZHTdyZFqLJ48CYFLYuhz-fpG0rQXnc=.de8bb8ac-eab4-4f05-8f73-5ca6a5c7b727@github.com>
 <IIfGXFqru0IHXjz0bKwaoofJKm5TUg9vvBrNR5fOX7Q=.68dcf8f5-1017-41c3-b6dc-8c8daa045d6f@github.com>
Message-ID: <YycPqcmZZtpNCjhHCFWaKw2wM8gXxHUPjZ8uFY2rKLw=.f2352697-8824-4c50-83e0-6dd0b66eeb95@github.com>

On Wed, 14 Feb 2024 23:37:03 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
>> 
>> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.
>
> (Discussion mainly of historical interest.)
> 
> @pavelrappo Correct, historically, `Collections.sort` would fail to sort `CopyOnWriteArrayList`. You have to go back to JDK 7 to see this. The sorting approach used by `Collections.sort` (still present in the default implementation of `List.sort`) gets an array using `toArray()`, sorts it, and then copies the sorted elements back using `ListIterator.set`. Since `CopyOnWriteArrayList` doesn't support modifications using `ListIterator`, it fails with `UnsupportedOperationException`. The overrides of `List.sort` have fixed this problem.
> 
> COWAL still has some problems with other things that use similar techniques, such as `Collections.shuffle`. That uses get/set to swap elements, which COWAL does support, but it copies the array on each set() operation. This results in N copies of the array being made for an N-element list.

Hey folks (@stuart-marks or @JimLaskey) it's been a while ??can I get a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-2049131137

From mchhipa at openjdk.org  Thu Apr 11 09:07:10 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 11 Apr 2024 09:07:10 GMT
Subject: RFR: 8319678: Several tests from corelibs areas ignore VM flags
 [v3]
In-Reply-To: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
Message-ID: <ZXXQeqyGZyg0nuu4rNrt9mTNQrwp-EKuo3BcvPj8fyM=.46082cd4-2b21-46ef-9a96-ed90fb13a7a8@github.com>

> Updated following tests to use ProcessTools methods:
>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>  test/jdk/javax/naming/spi/providers/InitialContextTest.java

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

  Implemented the review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18602/files
  - new: https://git.openjdk.org/jdk/pull/18602/files/04a35331..4d258b00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18602&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18602&range=01-02

  Stats: 21 lines in 3 files changed: 0 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/18602.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18602/head:pull/18602

PR: https://git.openjdk.org/jdk/pull/18602

From mchhipa at openjdk.org  Thu Apr 11 09:07:10 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 11 Apr 2024 09:07:10 GMT
Subject: RFR: 8319678: Several tests from corelibs areas ignore VM flags
 [v2]
In-Reply-To: <rUsFP0fu6DBphVwV7m8kh7P3k_stHjdWn5AswxcDQoY=.1a499628-b022-49e7-8c92-c9cc51d2d47e@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
 <rUsFP0fu6DBphVwV7m8kh7P3k_stHjdWn5AswxcDQoY=.1a499628-b022-49e7-8c92-c9cc51d2d47e@github.com>
Message-ID: <a5hSuS0BbKDdW0lUYKAbmtJBKDmjArr9i1BjMzxC6m8=.3840a85c-35ee-439a-acb2-1d6ef36c095c@github.com>

On Wed, 10 Apr 2024 10:40:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>>   Updated EscapePath test.
>
> test/jdk/javax/naming/spi/providers/InitialContextTest.java line 65:
> 
>> 63:  * @library /test/lib
>> 64:  * @build jdk.test.lib.process.ProcessTools
>> 65:  * @run main/othervm InitialContextTest
> 
> Hello Mahendra, I see that this test and one other test is being changed to `/othervm` and I suspect it's because, we now call:
> 
> 
> System.setProperty("test.noclasspath", "true");
> 
> for the `ProcessTools` to skip adding the default `-cp` option to the launched Java process. 
> In reality, we don't have to set that system property and thus you don't have to change this and the other test to `othervm`. See a previous discussion about the classpath handling by `ProcessTools` here https://github.com/openjdk/jdk/pull/17787/files/a9fcc6c2900356250b29b3d11b402790a84d9317#r1484276695 - essentially, whatever classpath you end up passing as part of the command to `ProcessTools.createTestJavaProcessBuilder()` will end up getting used.

Thanks. Implemented in this commit.

> test/jdk/javax/naming/spi/providers/InitialContextTest.java line 268:
> 
>> 266:             OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(commands);
>> 267:             if(outputAnalyzer.getExitValue() != 0) {
>> 268:                 throw new RuntimeException(outputAnalyzer.getOutput());
> 
> I think it would be better to just call:
> 
> outputAnalyzer.shouldHaveExitValue(0);
> 
> that way it even prints the stdout/stderr logs and throws the exception.

Thanks. Implemented in this commit.

> test/jdk/javax/naming/spi/providers/InitialContextTest.java line 271:
> 
>> 269:             }
>> 270:         } catch (Exception ex) {
>> 271:             throw new RuntimeException(ex.getMessage());
> 
> This and other similar places in this PR will end up swallowing the underlying exception. It would be better to just have the method have a `throws Exception` or change this to:
> 
> 
> throw new RuntimeException(ex);

Thanks. Implemented in this commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1560681857
PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1560682373
PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1560683141

From mchhipa at openjdk.org  Thu Apr 11 09:07:10 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 11 Apr 2024 09:07:10 GMT
Subject: RFR: 8319678: Several tests from corelibs areas ignore VM flags
 [v2]
In-Reply-To: <LVAMoP2hXNFyTZBYeqg6o7toErWN2eLLJm8BcuoP1n8=.92cdceca-49fc-47bd-9468-314e1536432e@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <TE0NlU1wk-rgqwGIhaDod2QCWNOUvPs5Z0rhk77XsFM=.8c0eec4d-9d89-46d2-92ab-532c46bdbb1b@github.com>
 <1Qj9GW2u-cCp_V4w0Yd71XbUZjMLBNWg_LDwQ6rZwE8=.29d6d01c-db03-4b05-9502-bd71ce4730ee@github.com>
 <LVAMoP2hXNFyTZBYeqg6o7toErWN2eLLJm8BcuoP1n8=.92cdceca-49fc-47bd-9468-314e1536432e@github.com>
Message-ID: <3j8VyNq1RaVzEM84yh1BfNmpAR0UFH6nIlcsSKmEFZE=.1eeddc99-4ac7-485f-8f15-920220166b65@github.com>

On Wed, 10 Apr 2024 10:57:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/javax/naming/spi/providers/InitialContextTest.java line 286:
>> 
>>> 284:             OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(commands.toArray(new String[commands.size()]));
>>> 285:             if(outputAnalyzer.getExitValue() != 0) {
>>> 286:                 throw new RuntimeException(outputAnalyzer.getOutput());
>> 
>> Same comment as above `outputAnalyzer.shouldHaveExitValue(0)` would be better.
>
> Applies to some other files in this PR as well.

Thanks. Implemented in this commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1560682745

From dfuchs at openjdk.org  Thu Apr 11 09:15:42 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Apr 2024 09:15:42 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
Message-ID: <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>

On Mon, 26 Feb 2024 17:40:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Is n == 0 intended to detect a spinning condition where the selector goes back into select when the event has not been handled?
>> 
>> In that case should we still emit an event if a timeout is present and the duration is greater than the timeout? For instance, in the HttpClient, we have a selector thread that will wake up at regular interval - we set up a timeout which is the min between the next expected timer event and 1500ms. So that could potentially fire an event every 1500ms if for instance the connection threshold is less than 1500ms and the connection is idle.
>> 
>> Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms?
>> 
>> Or should it be ((n == 0 && durationToMillis(duration) < timeoutToMillis(timeout)) || ...)) (duration and timeout probably are not in the same unit of time) - also if shouldCommit return false will the event actually be emitted down the road? Because if not then the ( n== 0 || ...) won't work.
>
>> Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms?
> 
> The threshold is 20ms so these timed-select ops in the HTTP client will record an event when they timeout.

We should probably find a way to not emit the event if n == 0 and the operation was interrupted by `Selector.wakeUp`. Since we have another issue logged to emit a spin event, I wonder if we should only commit the event here if `n != 0`? The case where n == 0 would be handled by the spin event (added later) 
@AlanBateman what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1560693482

From jlahoda at openjdk.org  Thu Apr 11 09:18:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Apr 2024 09:18:43 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <pQ7KfrIBPSZz0ktsYzF1_7tUsCfWErjze-3Ez8kNGYE=.79b45003-ad90-4e6a-8ff4-aca7a7386fa1@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <pQ7KfrIBPSZz0ktsYzF1_7tUsCfWErjze-3Ez8kNGYE=.79b45003-ad90-4e6a-8ff4-aca7a7386fa1@github.com>
Message-ID: <j_XuSoJzBAz3AW8nG95sI8kEU0JtNB_F-B1dBReMTDk=.5d5c7e6a-bd58-4d9a-b77e-fe062a55d368@github.com>

On Wed, 10 Apr 2024 10:59:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
>> 
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issues in digit classes

javac and JShell changes look good to me (with a nit in JShell tests).

For consideration: using `{` will now produce the "illegal escape character" error. Which is technically correct, but maybe we could add a special error, saying that StringTemplates are removed for now? So that if someone will try to compile source code with StringTemplates, they would now this was intentional. Just for consideration.

test/langtools/jdk/jshell/CompletionSuggestionTest.java line 327:

> 325:         assertSignature("String.format(|",
> 326:                 "String String.format(String, Object...)",
> 327:                 "String String.format(java.util.Locale, String, Object...)"

Nit: this change appears to be unnecessary?

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18688#pullrequestreview-1993673798
PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1560692978

From jpai at openjdk.org  Thu Apr 11 09:28:43 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Apr 2024 09:28:43 GMT
Subject: RFR: 8319678: Several tests from corelibs areas ignore VM flags
 [v3]
In-Reply-To: <ZXXQeqyGZyg0nuu4rNrt9mTNQrwp-EKuo3BcvPj8fyM=.46082cd4-2b21-46ef-9a96-ed90fb13a7a8@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <ZXXQeqyGZyg0nuu4rNrt9mTNQrwp-EKuo3BcvPj8fyM=.46082cd4-2b21-46ef-9a96-ed90fb13a7a8@github.com>
Message-ID: <6Rb5MiM-ThI6NRACBLrmDcfZcslsWrd423cFpFX1zYU=.5e2187b7-daa2-408b-bd14-03a215642812@github.com>

On Thu, 11 Apr 2024 09:07:10 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Updated following tests to use ProcessTools methods:
>>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>>  test/jdk/javax/naming/spi/providers/InitialContextTest.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

test/jdk/javax/naming/spi/providers/InitialContextTest.java line 301:

> 299:                 .map(Path::toString)
> 300:                 .collect(Collectors.joining(File.pathSeparator));
> 301: //        System.setProperty("test.noclasspath", "true");

This newly introduced commented code can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1560711526

From jpai at openjdk.org  Thu Apr 11 09:31:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Apr 2024 09:31:44 GMT
Subject: RFR: 8319678: Several tests from corelibs areas ignore VM flags
 [v3]
In-Reply-To: <ZXXQeqyGZyg0nuu4rNrt9mTNQrwp-EKuo3BcvPj8fyM=.46082cd4-2b21-46ef-9a96-ed90fb13a7a8@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <ZXXQeqyGZyg0nuu4rNrt9mTNQrwp-EKuo3BcvPj8fyM=.46082cd4-2b21-46ef-9a96-ed90fb13a7a8@github.com>
Message-ID: <WPd7wG66pbY1sKPhPKIbAOgh-nrvG9aDchkGTizC3qE=.a1500983-e748-4068-95d7-406cc0ed5239@github.com>

On Thu, 11 Apr 2024 09:07:10 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Updated following tests to use ProcessTools methods:
>>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>>  test/jdk/javax/naming/spi/providers/InitialContextTest.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

Hello Mahendra, thank you for the updates. There's one review comment I've added about a stray code comment, other than that the changes look OK to me.

I haven't checked which tiers these tests reside in. Before integrating, it would be good to run the specific tiers (or tier1, tier2 and tier3) and make sure these changes don't cause issues.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18602#pullrequestreview-1993707442

From sgehwolf at openjdk.org  Thu Apr 11 09:35:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 11 Apr 2024 09:35:44 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <DpCaI_OsPiqyJVu9yrrU-g4Zo4_qsd_sHeaAnzsuUCY=.8a42d36b-7e3f-41f2-b7a2-fa733fb08fea@github.com>

On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Gentle ping.

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2049297883

From mchhipa at openjdk.org  Thu Apr 11 09:54:53 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 11 Apr 2024 09:54:53 GMT
Subject: RFR: 8319678: Several tests from corelibs areas ignore VM flags
 [v4]
In-Reply-To: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
Message-ID: <bCu6GGImVBynfLNDINLOwLQfIyLGsHNr4Ybcw8QC0DM=.c4fded58-41b5-4ce3-b423-1db3965b610b@github.com>

> Updated following tests to use ProcessTools methods:
>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>  test/jdk/javax/naming/spi/providers/InitialContextTest.java

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

  Removed commented code.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18602/files
  - new: https://git.openjdk.org/jdk/pull/18602/files/4d258b00..8aba98ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18602&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18602&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/18602

From mchhipa at openjdk.org  Thu Apr 11 09:54:53 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 11 Apr 2024 09:54:53 GMT
Subject: RFR: 8319678: Several tests from corelibs areas ignore VM flags
 [v3]
In-Reply-To: <6Rb5MiM-ThI6NRACBLrmDcfZcslsWrd423cFpFX1zYU=.5e2187b7-daa2-408b-bd14-03a215642812@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <ZXXQeqyGZyg0nuu4rNrt9mTNQrwp-EKuo3BcvPj8fyM=.46082cd4-2b21-46ef-9a96-ed90fb13a7a8@github.com>
 <6Rb5MiM-ThI6NRACBLrmDcfZcslsWrd423cFpFX1zYU=.5e2187b7-daa2-408b-bd14-03a215642812@github.com>
Message-ID: <CLu835XZ5WXZtOFXL0GgOs80UM00WTdUw-sLUVQiN_A=.512eace2-927f-445c-a815-d710c966e62f@github.com>

On Thu, 11 Apr 2024 09:26:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/jdk/javax/naming/spi/providers/InitialContextTest.java line 301:
> 
>> 299:                 .map(Path::toString)
>> 300:                 .collect(Collectors.joining(File.pathSeparator));
>> 301: //        System.setProperty("test.noclasspath", "true");
> 
> This newly introduced commented code can be removed.

Sorry, I missed this. Removed in current commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18602#discussion_r1560754800

From jpai at openjdk.org  Thu Apr 11 09:57:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Apr 2024 09:57:46 GMT
Subject: RFR: 8319678: Several tests from corelibs areas ignore VM flags
 [v4]
In-Reply-To: <bCu6GGImVBynfLNDINLOwLQfIyLGsHNr4Ybcw8QC0DM=.c4fded58-41b5-4ce3-b423-1db3965b610b@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
 <bCu6GGImVBynfLNDINLOwLQfIyLGsHNr4Ybcw8QC0DM=.c4fded58-41b5-4ce3-b423-1db3965b610b@github.com>
Message-ID: <SZSSChPNyXf2DyCTKiKcVPVksNwCMfgDjuIyPgHJ2D4=.d2f8c6c7-5c5c-484d-aee8-c82e1521f48a@github.com>

On Thu, 11 Apr 2024 09:54:53 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Updated following tests to use ProcessTools methods:
>>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>>  test/jdk/javax/naming/spi/providers/InitialContextTest.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed commented code.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18602#pullrequestreview-1993775818

From mcimadamore at openjdk.org  Thu Apr 11 10:11:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Apr 2024 10:11:43 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <j_XuSoJzBAz3AW8nG95sI8kEU0JtNB_F-B1dBReMTDk=.5d5c7e6a-bd58-4d9a-b77e-fe062a55d368@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <pQ7KfrIBPSZz0ktsYzF1_7tUsCfWErjze-3Ez8kNGYE=.79b45003-ad90-4e6a-8ff4-aca7a7386fa1@github.com>
 <j_XuSoJzBAz3AW8nG95sI8kEU0JtNB_F-B1dBReMTDk=.5d5c7e6a-bd58-4d9a-b77e-fe062a55d368@github.com>
Message-ID: <MBks6WmEM3S73bv3iI6XMo8EpAkIEhljv6ScZk63vdM=.eda7ef3d-cb10-4a41-b92e-9896a4cc6f91@github.com>

On Thu, 11 Apr 2024 09:12:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issues in digit classes
>
> test/langtools/jdk/jshell/CompletionSuggestionTest.java line 327:
> 
>> 325:         assertSignature("String.format(|",
>> 326:                 "String String.format(String, Object...)",
>> 327:                 "String String.format(java.util.Locale, String, Object...)"
> 
> Nit: this change appears to be unnecessary?

I'll revert - thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1560775208

From mcimadamore at openjdk.org  Thu Apr 11 10:15:54 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Apr 2024 10:15:54 GMT
Subject: RFR: 8329948: Remove string template feature [v5]
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

  Drop spurious jshell test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18688/files
  - new: https://git.openjdk.org/jdk/pull/18688/files/51e261bd..bbe05c97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/18688

From pminborg at openjdk.org  Thu Apr 11 10:42:46 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 11 Apr 2024 10:42:46 GMT
Subject: Withdrawn: 8329997: Add MemorySegment::reinterpretate overloads for
 alignment constraints
In-Reply-To: <_85tSefjZUGI3VQbbktp9tgQVba9HymE0o2x-P_xL9Y=.856ec02f-a42c-4634-aa89-c5faaf03924f@github.com>
References: <_85tSefjZUGI3VQbbktp9tgQVba9HymE0o2x-P_xL9Y=.856ec02f-a42c-4634-aa89-c5faaf03924f@github.com>
Message-ID: <x7bHVr0hlLzVx6S43WC5r6DmrdEOtzXCs_hiq5IOeEo=.9a19e18e-b2c3-4ee0-9021-a4edb3fd7de1@github.com>

On Wed, 10 Apr 2024 12:49:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add two overloads `MemorySegment::reinterpretate` to allow aligned reinterpretation.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/18717

From pminborg at openjdk.org  Thu Apr 11 10:42:50 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 11 Apr 2024 10:42:50 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find
Message-ID: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>

While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.

This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

Commit messages:
 - Remove white space
 - Add SymbolLookup::findOrThrow

Changes: https://git.openjdk.org/jdk/pull/18474/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314592
  Stats: 93 lines in 21 files changed: 30 ins; 0 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/18474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18474/head:pull/18474

PR: https://git.openjdk.org/jdk/pull/18474

From jpai at openjdk.org  Thu Apr 11 10:49:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 Apr 2024 10:49:48 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
Message-ID: <ILLNIrxvbzRvUE_LtORubZ88jGYBIC0Pfms9E5WEZ7U=.99fc2296-78f9-4367-b46c-e297d12192a6@github.com>

On Wed, 10 Apr 2024 16:46:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy method

Hello Martin,

> Maybe using that directory is easier. Does anybody else have a suggestion?

Each jtreg test, when it is run, will be run in a "scratch" directory. Details about that are explained here https://openjdk.org/jtreg/faq.html#scratch-directory. That directory can be used to create test specific content.

As for the test, I think what you will need is something like this (I don't know or have access to AIX, so this obviously isn't tested)


import java.nio.file.Files;
import java.nio.file.Path;

import jdk.test.lib.process.ProcessTools;

/**
 * @test
 * @bug 8319516
 * @summary verify that System.loadLibrary on AIX is able to load libraries from ".a" (archive) file
 * @requires os.family == "aix"
 * @library /test/lib/
 * @build jdk.test.lib.process.ProcessTools
 * @run driver AIXLoadLibraryDriver
 */
public class AIXLoadLibraryDriver {

    private static final String TEST_LIBRARY_NAME = "foobar";

    // creates a ".a" archive file in a test specific directory and then
    // launches a java application passing this directory through "-Djava.library.path".
    // the java application then attempts to load the library using System.loadLibrary()
    public static void main(final String[] args) throws Exception {
        final String javaHome = System.getProperty("java.home");
        final Path libawtSo = Path.of(javaHome).resolve("lib", "libawt.so");
        if (!Files.exists(libawtSo)) {
            throw new AssertionError(libawtSo + " is missing");
        }
        final String archiveFileName = "lib" + TEST_LIBRARY_NAME + ".a";
        // copy over libawt.so as an archive file to test specific scratch dir
        final Path testNativeLibDir = Path.of("native").toAbsolutePath();
        Files.createDirectories(testNativeLibDir);
        final Path libDummyArchive = testNativeLibDir.resolve(archiveFileName);
        Files.copy(libawtSo, libDummyArchive);

        // launch a java application which calls System.loadLibrary and is passed
        // the directory containing the native library archive file, through
        // -Djava.library.path
        System.out.println("Launching application with library path " + testNativeLibDir);
        final ProcessBuilder processBuilder = ProcessTools.createTestJavaProcessBuilder(
                "-Djava.library.path=" + testNativeLibDir,
                AIXLoadLibraryDriver.LoadLibraryApp.class.getName());
        ProcessTools.executeCommand(processBuilder).shouldHaveExitValue(0);
    }

    static class LoadLibraryApp {
        public static void main(final String[] args) throws Exception {
            System.out.println("attempting to load library " + TEST_LIBRARY_NAME);
            System.loadLibrary(TEST_LIBRARY_NAME);
            System.out.println(TEST_LIBRARY_NAME + " successfully loaded");
        }
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2049416575

From mcimadamore at openjdk.org  Thu Apr 11 11:43:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Apr 2024 11:43:42 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <O5hSvRzOvRt7EDz0BAgIw5bOYFiN10jBwad19H0uc9Q=.c6021c11-0647-4375-a4f9-00aae201a67f@github.com>

On Mon, 25 Mar 2024 14:56:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 152:

> 150: 
> 151:     /**
> 152:      * {@return the address of the symbol with the provided {@code name} or throws an

I suggest using the same javadoc structure as the main `find` method. Note that there we have a summary, then a more detailed `@return` which talks about zero length memory segments. This should do the same.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 155:

> 153:      *          {@linkplain IllegalArgumentException} if no such address can be found}
> 154:      *<p>
> 155:      * This is a convenience method that provides better exception messages compared

I would reframe this as: "this is equivalent to the following code, but with better exception message" (for consistency with other API points in FFM where we show what a method boils down to)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1560889723
PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1560893974

From mcimadamore at openjdk.org  Thu Apr 11 11:46:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Apr 2024 11:46:40 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <NjGEgqr5SEJ-IadHMjjwV24YJLxIk8h529VASlqhqkE=.0b564bc8-a088-4820-8fa2-ac13bd654445@github.com>

On Mon, 25 Mar 2024 14:56:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 177:

> 175:         }
> 176:         throw new IllegalArgumentException(
> 177:                 "Unable to to find a symbol with the name: " + name);

Another, more succinct, text could be "Symbol not found: <name>"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1560897671

From vklang at openjdk.org  Thu Apr 11 11:48:04 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 11 Apr 2024 11:48:04 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v4]
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <fF62S8beTLYIolAX4pkfujxCsrqT4nwQInRZYbGzrnE=.5cbea396-4639-4ab3-948d-cd332207037e@github.com>

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR:
> 
> Benchmark            (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
> 
> 
> After this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score        Error  Units
> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s
> 
> 
> For streams of size 100k, the following numbers are interesting:
> 
> Before this PR:
> 
> Benchmark            (size)   Mode  Cnt  Score    Error  Units
> FlatMap.par_array    100000  thrpt   12  0,325 ?  0,004  ops/s
> FlatMap.par_iterate  100000  thrpt   12  0,106 ?  0,008  ops/s
> FlatMap.seq_array    100000  thrpt   12  0,173 ?  0,003  ops/s
> FlatMap.seq_iterate  100...

Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:

 - Hoisted downstream fastpath
 - Making the FlatMap bench more complete

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18625/files
  - new: https://git.openjdk.org/jdk/pull/18625/files/d6d35d53..8356e69e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=02-03

  Stats: 176 lines in 6 files changed: 150 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/18625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18625/head:pull/18625

PR: https://git.openjdk.org/jdk/pull/18625

From sgehwolf at openjdk.org  Thu Apr 11 12:08:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 11 Apr 2024 12:08:02 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Severin Gehwolf 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 ten additional commits since the last revision:

 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - jcheck fixes
 - Fix tests
 - Implement Metrics.isContainerized()
 - Some clean-up
 - Drop cgroups testing on plain Linux
 - Implement fall-back logic for non-ro controller mounts
 - Make find_ro static and local to compilation unit
 - 8261242: [Linux] OSContainer::is_containerized() returns true

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18201/files
  - new: https://git.openjdk.org/jdk/pull/18201/files/98325f18..0df26ebd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=00-01

  Stats: 407791 lines in 3887 files changed: 43423 ins; 33650 del; 330718 mod
  Patch: https://git.openjdk.org/jdk/pull/18201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18201/head:pull/18201

PR: https://git.openjdk.org/jdk/pull/18201

From vklang at openjdk.org  Thu Apr 11 12:33:58 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 11 Apr 2024 12:33:58 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v5]
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <3vaTJ1_Q2KFnnOd3MI5p69xaSaaZXv7yS36ilsAsajE=.f897331e-f525-4ef6-b3b6-78a7f5e23ea2@github.com>

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR:
> 
> Benchmark            (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
> 
> 
> After this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score        Error  Units
> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s
> 
> 
> For streams of size 100k, the following numbers are interesting:
> 
> Before this PR:
> 
> Benchmark            (size)   Mode  Cnt  Score    Error  Units
> FlatMap.par_array    100000  thrpt   12  0,325 ?  0,004  ops/s
> FlatMap.par_iterate  100000  thrpt   12  0,106 ?  0,008  ops/s
> FlatMap.seq_array    100000  thrpt   12  0,173 ?  0,003  ops/s
> FlatMap.seq_iterate  100...

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

  Revert "Hoisted downstream fastpath"
  
  This reverts commit 8356e69e88160efe6d49ff9f10bd5d45573cc907.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18625/files
  - new: https://git.openjdk.org/jdk/pull/18625/files/8356e69e..bedbab85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=03-04

  Stats: 54 lines in 4 files changed: 2 ins; 35 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/18625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18625/head:pull/18625

PR: https://git.openjdk.org/jdk/pull/18625

From mchhipa at openjdk.org  Thu Apr 11 13:53:47 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 11 Apr 2024 13:53:47 GMT
Subject: Integrated: 8319678: Several tests from corelibs areas ignore VM flags
In-Reply-To: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
References: <5z1hA5jJsFdwhFihdxJz2rady44Nx1QG2MR9c0W5Y78=.104792be-90be-496a-97ed-b2817420f3dc@github.com>
Message-ID: <_3KyLywnD3bG_pnzTl-ZXpGRfdUqAzDJjgBSatORrhM=.e45df063-7982-47e4-8628-4ba2d7b04fd2@github.com>

On Wed, 3 Apr 2024 11:47:45 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Updated following tests to use ProcessTools methods:
>  test/jdk/java/lang/Thread/UncaughtExceptionsTest.java
>  test/jdk/java/lang/annotation/LoaderLeakTest.java
>  test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java
>  test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java
>  test/jdk/javax/naming/spi/providers/InitialContextTest.java

This pull request has now been integrated.

Changeset: 2e3682a7
Author:    Mahendra Chhipa <mchhipa at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e3682a7f2983cd58b9564253dc698760faba4b8
Stats:     161 lines in 6 files changed: 56 ins; 58 del; 47 mod

8319678: Several tests from corelibs areas ignore VM flags

Reviewed-by: naoto, jpai

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

PR: https://git.openjdk.org/jdk/pull/18602

From mdoerr at openjdk.org  Thu Apr 11 14:00:49 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 11 Apr 2024 14:00:49 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
Message-ID: <7Hq8UqP19w-WUgvIX_HKPNeSU9p9h8yBrf2-AjpyBSo=.9b974008-7b8c-4b9c-a3c0-0bb1d8565ab0@github.com>

On Wed, 10 Apr 2024 16:46:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy method

Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2049756576

From sgibbons at openjdk.org  Thu Apr 11 14:38:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Apr 2024 14:38:45 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v7]
In-Reply-To: <GXsMdHCW0oFQNY0R1LTdxUUu1v3GHQVjr71PRJ5al9A=.344aa58b-14b7-4224-9b4b-5e48e7141931@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <VDzAabd5Lu09Ds-AloWhmmn6IpZIOjTOVkOS1QfjM80=.d2104f79-694c-45ec-9600-1d492584178e@github.com>
 <GXsMdHCW0oFQNY0R1LTdxUUu1v3GHQVjr71PRJ5al9A=.344aa58b-14b7-4224-9b4b-5e48e7141931@github.com>
Message-ID: <D38yh18xmJqenoR5d5OlCxnfdKydwc9SoguMOc3laXM=.e8835673-3c61-427e-bf21-68de5be817a5@github.com>

On Thu, 11 Apr 2024 00:38:11 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add movq to locate_operand
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5988:
> 
>> 5986:     movw(Address(to, 0), value);
>> 5987:     addptr(to, 2);
>> 5988:     subptr(count, 1<<(shift-1));
> 
> At line 5968 also we need the change from cmpl to cmpptr.
> cmpl(count, 2<<shift); // Short arrays (< 8 bytes) fill by element

Will do.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6050:
> 
>> 6048:           vpbroadcastd(xtmp, xtmp, Assembler::AVX_512bit);
>> 6049: 
>> 6050:           subptr(count, 16 << shift);
> 
> At line 6045 also the cmpl should change to cmpptr:
> cmpl(count, VM_Version::avx3_threshold());

Will do.

> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2497:
> 
>> 2495: //
>> 2496: address StubGenerator::generate_unsafe_setmemory(const char *name,
>> 2497:                                                  address byte_fill_entry) {
> 
> Need to add UnsafeSetMemoryMark on similar lines as UnsafeCopyMemoryMark to handle page error.

Will do.

> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2522:
> 
>> 2520: #define rScratch3 r8
>> 2521: #undef rScratch4
>> 2522: #define rScratch4 r11
> 
> We could do this setup using const Register declaration instead of using #undef/#define pair.

We discussed this and the #define option was your preferred method since the registers are being re-used.  Do you want this changed back again?

> src/hotspot/share/opto/library_call.cpp line 4950:
> 
>> 4948: 
>> 4949: bool LibraryCallKit::inline_unsafe_setMemory() {
>> 4950:   if (callee()->is_static())  return false;  // caller must have the capability!
> 
> Also need to return false if StubRoutines::unsafe_setmemory() == nullptr.

Will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561128613
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561128862
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561129186
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561128151
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561130102

From liach at openjdk.org  Thu Apr 11 14:46:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Apr 2024 14:46:49 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v3]
In-Reply-To: <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
Message-ID: <QKAQFYZG6wZbXTyzF3bnWNGEanKisOODjhLBzAcdevo=.aff77ee9-3df0-4b5c-998c-8caa80cf42da@github.com>

On Thu, 7 Mar 2024 05:33:16 GMT, Korov <duke at openjdk.org> wrote:

>> When the specified key did not associated with a value, should check the `key` and `value` type.
>
> Korov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use testNG builtin functionalities and modify the test function name

Keep-alive, maybe people like @viktorklang-ora might look at this simple fix too

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

PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-2049861147

From sgibbons at openjdk.org  Thu Apr 11 14:47:07 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Apr 2024 14:47:07 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v8]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <havbKb1CCStJP3D2IoTveAa0N6zviYIh8hrlNW-OkfY=.65797f0b-f473-4efc-862e-42ef545466df@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Address review comments (#15)
  
  * Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/f81aaa9f..b0ac8577

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=06-07

  Stats: 170 lines in 9 files changed: 147 ins; 11 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From liach at openjdk.org  Thu Apr 11 14:48:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Apr 2024 14:48:44 GMT
Subject: RFR: 8326617: String Template FMT removes unnecessary int to long
 type cast
In-Reply-To: <OVHqFGT9bzKfyJvEa7YwuLmZwRWMBOKrpJbUjR9cPNQ=.c71d50a1-8b3d-4a6d-a169-2929d35309f5@github.com>
References: <OVHqFGT9bzKfyJvEa7YwuLmZwRWMBOKrpJbUjR9cPNQ=.c71d50a1-8b3d-4a6d-a169-2929d35309f5@github.com>
Message-ID: <IBGgH6iHVDqDn7ZsheD0DyioN_DMF64kF0O8aujTRnw=.6cadebcd-c2f4-4784-b6be-0ff7a3215398@github.com>

On Mon, 2 Oct 2023 23:05:29 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In the current version, FMT."v =%d{1}" will call the StringConcatHelper.prepend(long/byte[]/long) method, which should behave the same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int), should not convert int to long
> 
> Please review and don't hesitate to critique my approach and patch.

See #18688, String template is being removed for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/16017#issuecomment-2049863809

From liach at openjdk.org  Thu Apr 11 14:50:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Apr 2024 14:50:43 GMT
Subject: RFR: 8329948: Remove string template feature [v5]
In-Reply-To: <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
Message-ID: <get1Vfs3KfPmTX8GCk3daxcCw8opzfeYUHVc-b08b3E=.1736e7b8-4ef0-454f-8a5b-c9c250089340@github.com>

On Thu, 11 Apr 2024 10:15:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
>> 
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop spurious jshell test change

Also, is `java.lang.runtime.Carriers` to be kept? This utility is really helpful, but it probably should be moved to `jdk.internal` if String Templates is dropped.

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

PR Comment: https://git.openjdk.org/jdk/pull/18688#issuecomment-2049870402

From alanb at openjdk.org  Thu Apr 11 16:10:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Apr 2024 16:10:45 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
 <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
Message-ID: <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>

On Thu, 11 Apr 2024 09:12:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms?
>> 
>> The threshold is 20ms so these timed-select ops in the HTTP client will record an event when they timeout.
>
> We should probably find a way to not emit the event if n == 0 and the operation was interrupted by `Selector.wakeUp`. Since we have another issue logged to emit a spin event, I wonder if we should only commit the event here if `n != 0`? The case where n == 0 would be handled by the spin event (added later) 
> @AlanBateman what do you think?

I think it's okay for now. If there is another phase of this work to help diagnose spinning issues then it will need to re-visited. I'm very concerned about the possible changes for that second phase, but this first phase of instrumentation is not disruptive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1561279163

From dfuchs at openjdk.org  Thu Apr 11 16:41:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Apr 2024 16:41:44 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
 <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
 <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>
Message-ID: <_5zaiminpkaaX8Bwx4BhcULhyii-W0zCUswNab-aQVg=.19a2551a-b69c-4238-9aab-cffc3d9e9751@github.com>

On Thu, 11 Apr 2024 16:08:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We should probably find a way to not emit the event if n == 0 and the operation was interrupted by `Selector.wakeUp`. Since we have another issue logged to emit a spin event, I wonder if we should only commit the event here if `n != 0`? The case where n == 0 would be handled by the spin event (added later) 
>> @AlanBateman what do you think?
>
> I think it's okay for now. If there is another phase of this work to help diagnose spinning issues then it will need to re-visited. I'm very concerned about the possible changes for that second phase, but this first phase of instrumentation is not disruptive.

OK. I am a little concerned about how often this event will be fired when using the HttpClient - given that it's enabled by default. Idle connections sitting in the pool will fire it at least once per connection every 1500ms. That may not be too bad.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1561313983

From sroy at openjdk.org  Thu Apr 11 17:11:45 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 11 Apr 2024 17:11:45 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
Message-ID: <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>

On Wed, 10 Apr 2024 16:46:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy method

> Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".



> Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".

I am facing the same error. But i do not understand why is it resolved to libawt_headless.so .

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2050138340

From liach at openjdk.org  Thu Apr 11 17:12:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Apr 2024 17:12:51 GMT
Subject: RFR: 8180892: Correct handling of annotations on parameters [v3]
In-Reply-To: <CoB7fxGrmsVwcB4S_wOK3OHbph7zlVGSCE02IKIz3OY=.4f5bdcbd-43b8-4a23-a504-4937f9e6e7f5@github.com>
References: <A5gWbMb6WLzQW2wbgC5USyPITDoslCEJKWCEO1IGOgs=.d89a8805-8e74-4e2f-8fcd-a4768c95ef7e@github.com>
 <CoB7fxGrmsVwcB4S_wOK3OHbph7zlVGSCE02IKIz3OY=.4f5bdcbd-43b8-4a23-a504-4937f9e6e7f5@github.com>
Message-ID: <hu8cFenl485gO3_hXNxMMLVm6N9rLEUyht8W2iaLN8k=.281b75db-21f0-4854-a821-6002f8290d53@github.com>

On Sun, 18 Feb 2024 16:52:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch aims to correct handling of annotations on parameters with the help of `MethodParameters` attribute, which will be always available once #9862 is integrated.
>> 
>> It utilizes and expands upon the existing parameter matching logic present in `Executable::getAllGenericParameterTypes`, and delegate parameter parameterized types, parameter annotation, and parameter type annotation accesses through the matched results, if matching is available. If matching failed, it falls back to existing heuristics that works without `MethodParameters` attributes for annotations, in `Executable::handleParameterNumberMismatch` and `TypeAnnotationParser::buildAnnotatedTypes` (renamed `buildAnnotatedTypesWithHeuristics` in this patch)
>> 
>> `ParameterMappingTest` covers these scenarios with class files that have `MethodParameters` or `Signature` attributes stripped or preserved to ensure the new Reflection API implementation works for both class files generated before #9862 and after its integration.
>> 
>> Also special thanks to Joe Darcy for reviewing 8304918 (#13183); this brings much convenience to this patch.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Update copyright year, cleanup and fix volatile, fix test
>  - Merge branch 'master' into param-implicit-mapping
>  - Merge branch 'master' into param-implicit-mapping
>  - Fix assuming match without MethodParameters for type annotations, move implementation related to getAnnotatedParameterTypes to around it
>  - copyright years
>  - Complete ParameterMappingTest to take care of interested scenarios
>  - Merge branch 'master' into param-implicit-mapping
>  - test wip
>  - Introduce base for annotated types if signature is absent but method parameters is present
>  - simplify code with further contracts
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c2d9fa26...611deabe

Keep-alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-2050140022

From ascarpino at openjdk.org  Thu Apr 11 17:17:44 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 11 Apr 2024 17:17:44 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <k-S63XajUKQKl9lZkp_UzlhDjVJ6shdpqMYwTZLRPNA=.332a8e42-b4c4-4bb8-b642-df1478eda176@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <n3KbSNXmQjwZZDFqbnehqVryLJ9FYQZzh4_bOLxymec=.4bc5a417-81e5-4dbc-819a-65924bcd2543@github.com>
 <k-S63XajUKQKl9lZkp_UzlhDjVJ6shdpqMYwTZLRPNA=.332a8e42-b4c4-4bb8-b642-df1478eda176@github.com>
Message-ID: <njm7imXx1Ls7Jt7nZ2mCyOR5UfCPiiT14EA8c7OAX2w=.899bdb80-6d3b-4354-99d6-e126f47a682e@github.com>

On Wed, 10 Apr 2024 18:02:38 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> > In `ECOperations.java`, if I understand this correctly, it is to replace the existing `PointMultiplier` with montgomery-based PointMuliplier. But when I look at the code, I see both are still options. If I read this correctly, it checks for the old `IntegerFieldModuloP`, then looks for the new `IntegerMontgomeryFieldModuloP`. It appears to use the new one always. Why doesn't it just replace the old implementation entry in the `fields` Map? Is there a reason to keep it around?
> 
> Hmm, thats a good point I haven't fully considered; i.e. (if I read correctly) "for `CurveDB.P_256` remove the fallback path to non-montgomery entirely".. that might also help in cleaning a few things up in the construction. Maybe even get rid of this nested ECOperations inside ECOperations.. Perhaps nesting isnt a big deal, but all attempts to make the ECC stack clearer is positive!
> 
> One functional reason that might justify keeping it as-is, is fuzz-testing; with the fallback available, I am able to write the included Fuzz tests and have them check the values against the existing implementation. While I also included a few KAT tests using openssl-generated values, the fuzz tests check millions of values and it does add a lot more certainty about correctness of this code.

I hadn't looked at your fuzz test until you mentioned it.  I see you are using reflection to change the values.  Is that what you mean by "fallback"?  I'm assuming there is no to access the older implementation without reflection.

> 
> Can it be removed? For the operations that do not involve multiplication (i.e. `setSum(*)`), montgomery is expensive. I think I did go through the uses of this code some time back (i.e. ECDHE, ECDSA and KeyGeneration) and existing IntegerPolynomialP256 is no longer used (I should verify that again) and only P256OrderField remains non-montgomery. So removing references to IntegerPolynomialP256 in ECOperations should be possible and cleaner. Removing IntegerPolynomialP256 from MontgomeryIntegerPolynomialP256 is harder (fromMontgomery() uses IntegerPolynomialP256) but perhaps also worth some thought..
> 
> I tend to like `ECOperationsFuzzTest.java` and would prefer to keep it, but it could also be chucked up as part of 'scaffolding' and removed in name of code quality?

I wouldn't rip out the old implementation.  I have been wondering if we should make the older implementation available, maybe by security property.  I was looking at the static Maps at the top of `ECOperations`, `forParameters`, and the constructors where it checks if the `montgomeryOps` was null or set.  It would be nice if we could have one set of `fields` Maps by putting the montgomery entry into the `fields` to replace it.  I think that should work because `IntegerMontgomeryFieldModuloP` extends `IntegerFieldModuloP`.  `instanceof` or other `montgomeryOps`  checks would still need to exist because not all the `fields` support mongomery, and the older implementation would still be accessible for your fuzz tester.   At least that is my theory.

> 
> Thanks @ascarpino
> 
> PS: Perhaps there is some middle ground, remove the `ECOperations montgomeryOps` nesting, and construct (somehow?? singleton makes most things inaccessible..) the reference ECOperations in the fuzz test instead.. not sure how yet, but perhaps worth a further thought..

It would be nice to remove the nesting and it would be nice to be a singleton.  Maybe some combination of what I mentioned above chance can help that.  I haven't fully thought this out either.

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2050148475

From sroy at openjdk.org  Thu Apr 11 17:18:47 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 11 Apr 2024 17:18:47 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
Message-ID: <HTBTR7H-Y39Fx_yib8tmRQAruWQOqfawnxCXZ8y8_Qk=.b1b7404f-a983-4bc8-a946-76b2540f4421@github.com>

On Wed, 10 Apr 2024 16:46:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy method

`String libraryName = "awt";
        File awtSharedObjectPathCopy = new File("/test/lib/libawt.so");
        File awtSharedObjectPath = new File("/test/lib/libawt.so");
        File awtArchivePath = new File("/test/lib/libawt.a");
        awtSharedObjectPath.renameTo(awtArchivePath);
        if (awtSharedObjectPath.exists()) {
            awtSharedObjectPath.renameTo(awtSharedObjectPathCopy);
            throw new RuntimeException("LoadAIXLibraryFromArchiveObject: .so should not exist.");
            `
            
            @jaikiran  is this also right way to use the /test/lib directory ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2050149972

From sgibbons at openjdk.org  Thu Apr 11 18:17:01 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Apr 2024 18:17:01 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v9]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <-8Y7DVQtgJh8lec7MbHRv1jYx3VhURh0n5mpwgs6eSw=.13972572-1542-4280-a2ea-acf3bdc77352@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Set memory test (#16)
  
  Add framework for other platforms.  Moved fill_to_memory_atomic back to the .cpp from the .hpp in order to get 32-bit fixed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/b0ac8577..95230e29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=07-08

  Stats: 179 lines in 14 files changed: 115 ins; 49 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Thu Apr 11 18:26:58 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Apr 2024 18:26:58 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v10]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <j1ozPztQony1Vgch4JG9d2H6xhOzvF-zKqAZGGIizXY=.08ca487c-5596-47a9-8093-0ec2bffd532c@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge master
 - Set memory test (#16)
   
   Add framework for other platforms.  Moved fill_to_memory_atomic back to the .cpp from the .hpp in order to get 32-bit fixed.
 - Address review comments (#15)
   
   * Address review comments
 - Add movq to locate_operand
 - Oops
 - Fixed generate_fill when count > 0x80000000
 - Fix Windows
 - Addressing review comments.
 - Remove dead code
 - Use non-sse fill (old left in)
 - ... and 9 more: https://git.openjdk.org/jdk/compare/31ee5108...41ffcc32

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

Changes: https://git.openjdk.org/jdk/pull/18555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=09
  Stats: 734 lines in 38 files changed: 680 ins; 5 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Thu Apr 11 18:26:58 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Apr 2024 18:26:58 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v9]
In-Reply-To: <-8Y7DVQtgJh8lec7MbHRv1jYx3VhURh0n5mpwgs6eSw=.13972572-1542-4280-a2ea-acf3bdc77352@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <-8Y7DVQtgJh8lec7MbHRv1jYx3VhURh0n5mpwgs6eSw=.13972572-1542-4280-a2ea-acf3bdc77352@github.com>
Message-ID: <2VYJw_lhaOBzrrWVPTtbFwdXQbcVzpqlFrY2dYJErSE=.2440284f-286b-4e23-bb3c-f2f2ae745f84@github.com>

On Thu, 11 Apr 2024 18:17:01 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set memory test (#16)
>   
>   Add framework for other platforms.  Moved fill_to_memory_atomic back to the .cpp from the .hpp in order to get 32-bit fixed.

I added the framework for setting unsafe access marks within all platforms, and fixed a bug with the Linux 32-bit runtime tests.  Adding stub intrinsic for setMemory0 for other platforms should be easier now.

Passes CI testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2050267842

From sroy at openjdk.org  Thu Apr 11 18:32:47 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 11 Apr 2024 18:32:47 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
 <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>
Message-ID: <2ATAMorSuL_VV0fo_Fn-9an4D0D-fksyD723uiqZxzc=.98cd220b-8267-4290-988d-54741401e047@github.com>

On Thu, 11 Apr 2024 17:08:49 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
> 
> > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
> 
> I am facing the same error. But i do not understand why is it resolved to libawt_headless.so .

 stdout: [attempting to load library foobar
];
 stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406)
        at java.base/java.lang.Runtime.load0(Runtime.java:852)
        at java.base/java.lang.System.load(System.java:2030)
        at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
        at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139)
        at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:251)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
        at java.base/java.lang.System.loadLibrary(System.java:2068)
        at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52)
]
 exitValue = 1

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2050279516

From sgibbons at openjdk.org  Thu Apr 11 18:42:56 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Apr 2024 18:42:56 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v11]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <7yXL0LWE8zWff1vL2JL9exL6IaHrD1yKsyTLGzJg4Eo=.15b0f724-54e5-4ab7-8c22-b35766eb0bca@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Fix whitespace error.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/41ffcc32..b99499a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=09-10

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

PR: https://git.openjdk.org/jdk/pull/18555

From jlaskey at openjdk.org  Thu Apr 11 18:47:44 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 11 Apr 2024 18:47:44 GMT
Subject: RFR: 8329948: Remove string template feature [v5]
In-Reply-To: <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
Message-ID: <AUuq0A99nrPYaYWrZp2S-OCYR-JVjOJx_QeOpKfVFg4=.7606f4c3-1478-40f5-b544-c8094c6e0d2b@github.com>

On Thu, 11 Apr 2024 10:15:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
>> 
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop spurious jshell test change

Carriers is used by pattern matching as well and should remain in runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/18688#issuecomment-2050304721

From sviswanathan at openjdk.org  Thu Apr 11 20:40:46 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 11 Apr 2024 20:40:46 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v11]
In-Reply-To: <7yXL0LWE8zWff1vL2JL9exL6IaHrD1yKsyTLGzJg4Eo=.15b0f724-54e5-4ab7-8c22-b35766eb0bca@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <7yXL0LWE8zWff1vL2JL9exL6IaHrD1yKsyTLGzJg4Eo=.15b0f724-54e5-4ab7-8c22-b35766eb0bca@github.com>
Message-ID: <jANu9TAPhsc5av-xjCRFRZBneGqaYWfgM46UYWzb5Wg=.a73d65bf-e51f-42ca-9f83-ac2a4b8cc1c2@github.com>

On Thu, 11 Apr 2024 18:42:56 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 8343:

> 8341:       UnsafeCopyMemory::create_table(8);
> 8342:     }
> 8343: 

Did you mean to initialize UnsafeSetMemory::_table here instead?

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 155:

> 153:   StubRoutines::_arrayof_jint_fill = generate_fill(T_INT, true, "arrayof_jint_fill");
> 154: 
> 155: // #ifdef _LP64

We could remove the #ifdef _LP64, #endif commented pair.

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 735:

> 733: 
> 734:   if (MaxVectorSize == 64) {
> 735:     UnsafeCopyMemoryMark ucmm(this, !is_oop && !aligned, false, ucme_exit_pc);

This is not related to Unsafe::setMemory?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561587296
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561606554
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561620598

From jlu at openjdk.org  Thu Apr 11 20:55:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 Apr 2024 20:55:14 GMT
Subject: RFR: 8327640: Allow NumberFormat strict parsing [v6]
In-Reply-To: <80VOFG9TzKd6if8SZnhLOJqcgy9GQf25GByd2sUQ1q4=.600d1abb-bd67-4105-8f71-6681e8b1e931@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
 <1MrLm5OWO8pdgD3UDTeYb7dIX2iYdFxpc0j8GzbXEWs=.25453a21-cc8d-477d-bac5-7ed3c51596a4@github.com>
 <80VOFG9TzKd6if8SZnhLOJqcgy9GQf25GByd2sUQ1q4=.600d1abb-bd67-4105-8f71-6681e8b1e931@github.com>
Message-ID: <k82QsC4VEH60RGq7eHUkKLqt9caAOnAoJMcQVZxYIIo=.6a6cfaad-ac70-43f4-85d3-b0acfbc7cd30@github.com>

On Thu, 11 Apr 2024 01:46:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu 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:
>> 
>>  - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
>>  - improve wording consistency and see tags
>>  - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
>>  - revert cleanup changes; (to go into a separate change)
>>  - use directed 'inheritDoc' tag
>>  - update example for lenient parsing
>>  - replace protected field for private fields in subclasses for consistency
>>  - drop Format implNote as well
>>  - setStrict and isStrict should be optional in NumberFormat
>>    - specify and throw UOE as default
>>    - override and implement in dFmt and cmpctNFmt
>>    parseStrict should be protected, and utilized by subclasses. The public methods should just
>>    serve as API.
>>  - Re-work specification wording from Format down to subclasses
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f894b148...aa1c284b
>
> Looks good overall. Left some minor comments.
> As to the tests, good to see those corner cases, but they should have unit tests for the new methods, i.e, `isStrict()` and `setStrict()`. Also I think equality/serialization for those methods should be examined.

Thank you for the review @naotoj. All of your comments should be reflected in the two previous commits.

As for the test suggestions, I added to existing tests if possible, otherwise I created new test files to address your suggestions. The new DecimalFormat equality and serialization test can definitely have other qualities tested (beyond parseStrict), but perhaps that's best for a separate issue.

> src/java.base/share/classes/java/text/DecimalFormat.java line 43:
> 
>> 41: import sun.util.locale.provider.LocaleProviderAdapter;
>> 42: import sun.util.locale.provider.ResourceBundleBasedAdapter;
>> 43: 
> 
> Internal packages typically follow public packages.

Fixed. (IntelliJ is adamant on having it that way, and even after I previously reverted it, it seems like it slipped through again. Oddly, it never used to do this, need to look at the settings)

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

PR Comment: https://git.openjdk.org/jdk/pull/18339#issuecomment-2050518798
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1561677534

From jlu at openjdk.org  Thu Apr 11 20:55:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 Apr 2024 20:55:11 GMT
Subject: RFR: 8327640: Allow NumberFormat strict parsing [v7]
In-Reply-To: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
Message-ID: <kji-bsyANttXckvHPgoG2jjZ_9Agkn0jWeAnBK-NrvA=.a09e7e1a-b144-4abc-978a-3ba05df3d7f7@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
> 
> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
> 
> Below is an example of the change, the CSR can be viewed for further detail.
> 
> 
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
> 
> 
> The associated tests are all localized, and the data is converted properly during runtime.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Reflect test suggestions
 - reflect impl suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/aa1c284b..eec992e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=05-06

  Stats: 277 lines in 7 files changed: 260 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/18339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339

PR: https://git.openjdk.org/jdk/pull/18339

From jjg at openjdk.org  Thu Apr 11 20:55:24 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Apr 2024 20:55:24 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <au6_FZORG1xVh5VnfoMMR60a_2oa1qny0ElKeIGpvFI=.94ed31a5-a875-4bc6-927b-da0f512ad43e@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  adjust call for `saveDanglingDocComments` for enum members

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3d6f1f95..56d6dcac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From jvernee at openjdk.org  Thu Apr 11 20:56:45 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 11 Apr 2024 20:56:45 GMT
Subject: Integrated: 8330049: Remove unused AbstractLinker::linkerByteOrder
In-Reply-To: <GsFkHXwmmJklludgA2z7Kwxw4xk25O0Iru_G5ylHY_I=.4e8e87e4-c92c-415e-93df-6b4a4355fbc0@github.com>
References: <GsFkHXwmmJklludgA2z7Kwxw4xk25O0Iru_G5ylHY_I=.4e8e87e4-c92c-415e-93df-6b4a4355fbc0@github.com>
Message-ID: <a7D1Xb-olvUJgtYOVnZScpl8bxUs7OzZX5lhW2m55aI=.78d2872a-2dd6-413f-806e-28be1986a2c5@github.com>

On Wed, 10 Apr 2024 15:38:22 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Please review this simple cleanup which removes the `AbstractLinker::linkerByteOrder` method. It was only used in `AixPPC64Linker`, where we know it will always return `ByteOrder.BIG_ENDIAN` so we can just replace the call with that.
> 
> Testing: Local run of `run-test-jdk_foreign`.

This pull request has now been integrated.

Changeset: 0db42906
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0db42906e390a98b3a6be078f1b8c3f2a03a838f
Stats:     69 lines in 12 files changed: 0 ins; 58 del; 11 mod

8330049: Remove unused AbstractLinker::linkerByteOrder

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/18726

From sgibbons at openjdk.org  Thu Apr 11 21:00:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Apr 2024 21:00:45 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v11]
In-Reply-To: <jANu9TAPhsc5av-xjCRFRZBneGqaYWfgM46UYWzb5Wg=.a73d65bf-e51f-42ca-9f83-ac2a4b8cc1c2@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <7yXL0LWE8zWff1vL2JL9exL6IaHrD1yKsyTLGzJg4Eo=.15b0f724-54e5-4ab7-8c22-b35766eb0bca@github.com>
 <jANu9TAPhsc5av-xjCRFRZBneGqaYWfgM46UYWzb5Wg=.a73d65bf-e51f-42ca-9f83-ac2a4b8cc1c2@github.com>
Message-ID: <vOl8xYczX-YpxUZvpxpIar0QMdYmhoOlgSOiGWyiDQ0=.902b8e39-01e9-4fac-8c9b-7d1c50499042@github.com>

On Thu, 11 Apr 2024 20:08:18 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace error.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 8343:
> 
>> 8341:       UnsafeCopyMemory::create_table(8);
>> 8342:     }
>> 8343: 
> 
> Did you mean to initialize UnsafeSetMemory::_table here instead?

Yes.  Good catch.

> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 155:
> 
>> 153:   StubRoutines::_arrayof_jint_fill = generate_fill(T_INT, true, "arrayof_jint_fill");
>> 154: 
>> 155: // #ifdef _LP64
> 
> We could remove the #ifdef _LP64, #endif commented pair.

Done.

> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 735:
> 
>> 733: 
>> 734:   if (MaxVectorSize == 64) {
>> 735:     UnsafeCopyMemoryMark ucmm(this, !is_oop && !aligned, false, ucme_exit_pc);
> 
> This is not related to Unsafe::setMemory?

No.  Reviewing the code I saw this as a potential error, as `arraycopy_avx3_large` could cause a SIGBUS which wouldn't be caught.  It conforms to the other instances of copy in the code.  I think it was missed by the original developer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561687577
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561688018
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561695561

From sgibbons at openjdk.org  Thu Apr 11 21:47:01 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 11 Apr 2024 21:47:01 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v12]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <s31GoF1j5diAB9u6HkZRnl0ijGHil1E1y3NpWa6ePMQ=.c1aafab1-5798-4624-ba83-b2410a98c6b6@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Addressing more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/b99499a9..89db3eb6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=10-11

  Stats: 250 lines in 2 files changed: 85 ins; 97 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From naoto at openjdk.org  Thu Apr 11 22:14:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 Apr 2024 22:14:42 GMT
Subject: RFR: 8327640: Allow NumberFormat strict parsing [v7]
In-Reply-To: <kji-bsyANttXckvHPgoG2jjZ_9Agkn0jWeAnBK-NrvA=.a09e7e1a-b144-4abc-978a-3ba05df3d7f7@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
 <kji-bsyANttXckvHPgoG2jjZ_9Agkn0jWeAnBK-NrvA=.a09e7e1a-b144-4abc-978a-3ba05df3d7f7@github.com>
Message-ID: <8bepjS12UwaXnHm-aynhLE2w4JnApzAHoUqxhfsQE0s=.f64e507c-1f9b-4ee1-b858-85647b6da9d2@github.com>

On Thu, 11 Apr 2024 20:55:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
>> 
>> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
>> 
>> Below is an example of the change, the CSR can be viewed for further detail.
>> 
>> 
>> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
>> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
>> fmt.setLenient(false);
>> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
>> fmt.setGroupingSize(2);
>> fmt.parse("12,34,567"); // throws ParseException
>> fmt.setParseIntegerOnly(true)
>> fmt.parse("12,34.56"); // throws ParseException
>> fmt.parse("12,34"); // successfully returns the Number 1234
>> 
>> 
>> The associated tests are all localized, and the data is converted properly during runtime.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reflect test suggestions
>  - reflect impl suggestions

LGTM. Thanks for the changes.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18339#pullrequestreview-1995566425

From redestad at openjdk.org  Thu Apr 11 23:24:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 11 Apr 2024 23:24:40 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <_-ge6E5aPK5VoldI8gCrH1Ay2ce1F4KnHe9huZW8Gtw=.49b80e2e-8aa0-4401-bbf2-a64511ee1274@github.com>

On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

Anyone out there?

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2050707573

From sviswanathan at openjdk.org  Thu Apr 11 23:34:43 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 11 Apr 2024 23:34:43 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v11]
In-Reply-To: <vOl8xYczX-YpxUZvpxpIar0QMdYmhoOlgSOiGWyiDQ0=.902b8e39-01e9-4fac-8c9b-7d1c50499042@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <7yXL0LWE8zWff1vL2JL9exL6IaHrD1yKsyTLGzJg4Eo=.15b0f724-54e5-4ab7-8c22-b35766eb0bca@github.com>
 <jANu9TAPhsc5av-xjCRFRZBneGqaYWfgM46UYWzb5Wg=.a73d65bf-e51f-42ca-9f83-ac2a4b8cc1c2@github.com>
 <vOl8xYczX-YpxUZvpxpIar0QMdYmhoOlgSOiGWyiDQ0=.902b8e39-01e9-4fac-8c9b-7d1c50499042@github.com>
Message-ID: <tzbFt3gSZ2bzoZtUNgElomBX-Gz1NwMaHqbLQ9K-d7g=.804e3cd5-20d9-44a9-9f2b-412d116e24c9@github.com>

On Thu, 11 Apr 2024 20:58:00 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 735:
>> 
>>> 733: 
>>> 734:   if (MaxVectorSize == 64) {
>>> 735:     UnsafeCopyMemoryMark ucmm(this, !is_oop && !aligned, false, ucme_exit_pc);
>> 
>> This is not related to Unsafe::setMemory?
>
> No.  Reviewing the code I saw this as a potential error, as `arraycopy_avx3_large` could cause a SIGBUS which wouldn't be caught.  It conforms to the other instances of copy in the code.  I think it was missed by the original developer.

Would be good to do it in a separate PR then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561801825

From sviswanathan at openjdk.org  Thu Apr 11 23:34:46 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 11 Apr 2024 23:34:46 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v12]
In-Reply-To: <s31GoF1j5diAB9u6HkZRnl0ijGHil1E1y3NpWa6ePMQ=.c1aafab1-5798-4624-ba83-b2410a98c6b6@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <s31GoF1j5diAB9u6HkZRnl0ijGHil1E1y3NpWa6ePMQ=.c1aafab1-5798-4624-ba83-b2410a98c6b6@github.com>
Message-ID: <P3HzpOG-j2hTlWUzGFWlGeVwrVQ-l_K-RydUik_vNYM=.29057482-91c8-400b-a9e8-bf9b0fd360cb@github.com>

On Thu, 11 Apr 2024 21:47:01 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing more review comments

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2751:

> 2749:         UnsafeSetMemoryMark usmm(this, true, true);
> 2750: 
> 2751:         __ generate_fill(T_BYTE, false, c_rarg0, c_rarg1, r11, rax, xmm0);

We will be duplicating the code gen for generate_fill here? Could we not do a tail call to _jbyte_fill here and add UnsafeSetMemoryMark inside _jbyte_fill?

src/hotspot/share/opto/library_call.cpp line 4952:

> 4950: }
> 4951: 
> 4952: bool LibraryCallKit::inline_unsafe_setMemory() {

It will be good to add the signature of Unsafe.setMemory0 as a comment above line 4952.

src/hotspot/share/opto/runtime.cpp line 783:

> 781:   fields[argp++] = TypeLong::LONG;      // size
> 782:   fields[argp++] = Type::HALF;          // size
> 783:   fields[argp++] = TypeInt::INT;        // bytevalue

Should this be TypeInt::BYTE?

src/hotspot/share/runtime/sharedRuntime.cpp line 181:

> 179: 
> 180: uint SharedRuntime::_unsafe_set_memory_ctr=0;
> 181: 

Extra blank line before line 180 could be removed.

src/hotspot/share/runtime/sharedRuntime.cpp line 1994:

> 1992:   if (_rethrow_ctr) tty->print_cr("%5u rethrow handler", _rethrow_ctr);
> 1993: 
> 1994:   if (_unsafe_set_memory_ctr) tty->print_cr("%5u unsafe set memorys", _unsafe_set_memory_ctr);

Extra blank line before line 1994 could be removed.

src/hotspot/share/runtime/sharedRuntime.hpp line 546:

> 544: 
> 545:   static uint _unsafe_set_memory_ctr;      // Slow-path includes alignment checks
> 546: 

Extra blank line before line 545 could be removed.

test/jdk/sun/misc/CopyMemory.java line 214:

> 212:         random.setSeed(seed);
> 213:         System.out.println("Seed set to "+ seed);
> 214: 

Looks like these lines were added for debugging, could be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561853120
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561831702
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561820596
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561822279
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561822556
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561823861
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561828829

From sgibbons at openjdk.org  Fri Apr 12 00:07:56 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 12 Apr 2024 00:07:56 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v13]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <2W-3EZqHS-07qzZ4RS72u33Hav0LMRfeIG4QPAyvk10=.8a35e043-6803-42d5-8ea0-bff5378a8c50@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Addressing yet more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/89db3eb6..970c5751

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=11-12

  Stats: 21 lines in 6 files changed: 6 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Fri Apr 12 00:07:57 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 12 Apr 2024 00:07:57 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v11]
In-Reply-To: <tzbFt3gSZ2bzoZtUNgElomBX-Gz1NwMaHqbLQ9K-d7g=.804e3cd5-20d9-44a9-9f2b-412d116e24c9@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <7yXL0LWE8zWff1vL2JL9exL6IaHrD1yKsyTLGzJg4Eo=.15b0f724-54e5-4ab7-8c22-b35766eb0bca@github.com>
 <jANu9TAPhsc5av-xjCRFRZBneGqaYWfgM46UYWzb5Wg=.a73d65bf-e51f-42ca-9f83-ac2a4b8cc1c2@github.com>
 <vOl8xYczX-YpxUZvpxpIar0QMdYmhoOlgSOiGWyiDQ0=.902b8e39-01e9-4fac-8c9b-7d1c50499042@github.com>
 <tzbFt3gSZ2bzoZtUNgElomBX-Gz1NwMaHqbLQ9K-d7g=.804e3cd5-20d9-44a9-9f2b-412d116e24c9@github.com>
Message-ID: <R8lx1yw3B218TZVfciWVR9EZgd4sPaNbjJ6Toufz9K8=.a2bb0bad-bbc6-45de-b56b-96d8eb42df8d@github.com>

On Thu, 11 Apr 2024 22:00:01 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> No.  Reviewing the code I saw this as a potential error, as `arraycopy_avx3_large` could cause a SIGBUS which wouldn't be caught.  It conforms to the other instances of copy in the code.  I think it was missed by the original developer.
>
> Would be good to do it in a separate PR then.

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561866645

From sgibbons at openjdk.org  Fri Apr 12 00:07:58 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 12 Apr 2024 00:07:58 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v12]
In-Reply-To: <P3HzpOG-j2hTlWUzGFWlGeVwrVQ-l_K-RydUik_vNYM=.29057482-91c8-400b-a9e8-bf9b0fd360cb@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <s31GoF1j5diAB9u6HkZRnl0ijGHil1E1y3NpWa6ePMQ=.c1aafab1-5798-4624-ba83-b2410a98c6b6@github.com>
 <P3HzpOG-j2hTlWUzGFWlGeVwrVQ-l_K-RydUik_vNYM=.29057482-91c8-400b-a9e8-bf9b0fd360cb@github.com>
Message-ID: <bFNzSjrU974UCoTvZOsbqMiHvy-cS2kUbjfs4vKpy2M=.945a9171-34ce-4545-b1fb-66525622b64d@github.com>

On Thu, 11 Apr 2024 23:30:07 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing more review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2751:
> 
>> 2749:         UnsafeSetMemoryMark usmm(this, true, true);
>> 2750: 
>> 2751:         __ generate_fill(T_BYTE, false, c_rarg0, c_rarg1, r11, rax, xmm0);
> 
> We will be duplicating the code gen for generate_fill here? Could we not do a tail call to _jbyte_fill here and add UnsafeSetMemoryMark inside _jbyte_fill?

It would not be appropriate to add set memory marks to the existing _jbyte_fill as it is being used by other routines, and the effect of the mark will be very hard to track down (if any).

Are you *sure* we want to do that?

> src/hotspot/share/opto/library_call.cpp line 4952:
> 
>> 4950: }
>> 4951: 
>> 4952: bool LibraryCallKit::inline_unsafe_setMemory() {
> 
> It will be good to add the signature of Unsafe.setMemory0 as a comment above line 4952.

Done

> src/hotspot/share/opto/runtime.cpp line 783:
> 
>> 781:   fields[argp++] = TypeLong::LONG;      // size
>> 782:   fields[argp++] = Type::HALF;          // size
>> 783:   fields[argp++] = TypeInt::INT;        // bytevalue
> 
> Should this be TypeInt::BYTE?

Should be TypeInt::UBYTE.  Changed.

> src/hotspot/share/runtime/sharedRuntime.cpp line 181:
> 
>> 179: 
>> 180: uint SharedRuntime::_unsafe_set_memory_ctr=0;
>> 181: 
> 
> Extra blank line before line 180 could be removed.

Done

> src/hotspot/share/runtime/sharedRuntime.cpp line 1994:
> 
>> 1992:   if (_rethrow_ctr) tty->print_cr("%5u rethrow handler", _rethrow_ctr);
>> 1993: 
>> 1994:   if (_unsafe_set_memory_ctr) tty->print_cr("%5u unsafe set memorys", _unsafe_set_memory_ctr);
> 
> Extra blank line before line 1994 could be removed.

Done.

> src/hotspot/share/runtime/sharedRuntime.hpp line 546:
> 
>> 544: 
>> 545:   static uint _unsafe_set_memory_ctr;      // Slow-path includes alignment checks
>> 546: 
> 
> Extra blank line before line 545 could be removed.

Done.

> test/jdk/sun/misc/CopyMemory.java line 214:
> 
>> 212:         random.setSeed(seed);
>> 213:         System.out.println("Seed set to "+ seed);
>> 214: 
> 
> Looks like these lines were added for debugging, could be removed.

Yes, but I believe we should adopt this for the future since reproducing random test failures is extremely difficult without knowing the seed of the RNG.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561867359
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561867575
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561867857
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561867923
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561868084
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561868158
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561868630

From sgibbons at openjdk.org  Fri Apr 12 00:07:58 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 12 Apr 2024 00:07:58 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v12]
In-Reply-To: <bFNzSjrU974UCoTvZOsbqMiHvy-cS2kUbjfs4vKpy2M=.945a9171-34ce-4545-b1fb-66525622b64d@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <s31GoF1j5diAB9u6HkZRnl0ijGHil1E1y3NpWa6ePMQ=.c1aafab1-5798-4624-ba83-b2410a98c6b6@github.com>
 <P3HzpOG-j2hTlWUzGFWlGeVwrVQ-l_K-RydUik_vNYM=.29057482-91c8-400b-a9e8-bf9b0fd360cb@github.com>
 <bFNzSjrU974UCoTvZOsbqMiHvy-cS2kUbjfs4vKpy2M=.945a9171-34ce-4545-b1fb-66525622b64d@github.com>
Message-ID: <ZkeBgc0Y_sLAmYoyBU0WKxTRJ-2Ph566HCK5y08zAzg=.c1bfc326-37e7-4384-baf9-a275ce9f693e@github.com>

On Fri, 12 Apr 2024 00:03:10 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> test/jdk/sun/misc/CopyMemory.java line 214:
>> 
>>> 212:         random.setSeed(seed);
>>> 213:         System.out.println("Seed set to "+ seed);
>>> 214: 
>> 
>> Looks like these lines were added for debugging, could be removed.
>
> Yes, but I believe we should adopt this for the future since reproducing random test failures is extremely difficult without knowing the seed of the RNG.

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561868727

From sviswanathan at openjdk.org  Fri Apr 12 00:28:50 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 12 Apr 2024 00:28:50 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v13]
In-Reply-To: <Lixq79faFKdpBDWmIcjFwFzMgiEe-Dsvmau_sZoQDxk=.938a6974-f179-428d-9687-3417c57046fe@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <2W-3EZqHS-07qzZ4RS72u33Hav0LMRfeIG4QPAyvk10=.8a35e043-6803-42d5-8ea0-bff5378a8c50@github.com>
 <Lixq79faFKdpBDWmIcjFwFzMgiEe-Dsvmau_sZoQDxk=.938a6974-f179-428d-9687-3417c57046fe@github.com>
Message-ID: <xAlej-OqvaJzj8LtOlC_ptB3mcuQMYmN8Gp_h64f5aY=.f0325b72-b389-47e4-a129-8f9e3036b8a5@github.com>

On Fri, 12 Apr 2024 00:10:22 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing yet more review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2521:
> 
>> 2519:       const Register byteVal = rdx;
>> 2520: 
>> 2521:       // Propagate byte to full Register
> 
> The comment refers to lines 2524-2526, please move it down.

Still continuing to look through StubGenerator::generate_unsafe_setmemory(), more comments to come. Thank you for your patience.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561878666

From sviswanathan at openjdk.org  Fri Apr 12 00:28:51 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 12 Apr 2024 00:28:51 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v12]
In-Reply-To: <bFNzSjrU974UCoTvZOsbqMiHvy-cS2kUbjfs4vKpy2M=.945a9171-34ce-4545-b1fb-66525622b64d@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <s31GoF1j5diAB9u6HkZRnl0ijGHil1E1y3NpWa6ePMQ=.c1aafab1-5798-4624-ba83-b2410a98c6b6@github.com>
 <P3HzpOG-j2hTlWUzGFWlGeVwrVQ-l_K-RydUik_vNYM=.29057482-91c8-400b-a9e8-bf9b0fd360cb@github.com>
 <bFNzSjrU974UCoTvZOsbqMiHvy-cS2kUbjfs4vKpy2M=.945a9171-34ce-4545-b1fb-66525622b64d@github.com>
Message-ID: <IIBoFwfIyBwYlGx941c0mUzv6WWh6eR69hpr2abDMOg=.3acdb49d-b847-41ee-aca4-76294105d5fe@github.com>

On Fri, 12 Apr 2024 00:00:38 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2751:
>> 
>>> 2749:         UnsafeSetMemoryMark usmm(this, true, true);
>>> 2750: 
>>> 2751:         __ generate_fill(T_BYTE, false, c_rarg0, c_rarg1, r11, rax, xmm0);
>> 
>> We will be duplicating the code gen for generate_fill here? Could we not do a tail call to _jbyte_fill here and add UnsafeSetMemoryMark inside _jbyte_fill?
>
> It would not be appropriate to add set memory marks to the existing _jbyte_fill as it is being used by other routines, and the effect of the mark will be very hard to track down (if any).
> 
> Are you *sure* we want to do that?

Yes we want to do that. It is all guarded by thread->doing_unsafe_access() which is only true when we are getting to this code from unsafe. Similar technique is used in copyMemory as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561877858

From sviswanathan at openjdk.org  Fri Apr 12 00:28:50 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 12 Apr 2024 00:28:50 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v13]
In-Reply-To: <2W-3EZqHS-07qzZ4RS72u33Hav0LMRfeIG4QPAyvk10=.8a35e043-6803-42d5-8ea0-bff5378a8c50@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <2W-3EZqHS-07qzZ4RS72u33Hav0LMRfeIG4QPAyvk10=.8a35e043-6803-42d5-8ea0-bff5378a8c50@github.com>
Message-ID: <Lixq79faFKdpBDWmIcjFwFzMgiEe-Dsvmau_sZoQDxk=.938a6974-f179-428d-9687-3417c57046fe@github.com>

On Fri, 12 Apr 2024 00:07:56 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing yet more review comments

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2504:

> 2502:     Label L_exit, L_fillQuadwords, L_fillDwords, L_fillBytes;
> 2503: 
> 2504:     setup_arg_regs(3);

A comment stating the placement of dest, size, and byteVal after call to setup_arg_regs() would be very helpful.

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2521:

> 2519:       const Register byteVal = rdx;
> 2520: 
> 2521:       // Propagate byte to full Register

The comment refers to lines 2524-2526, please move it down.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561873770
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1561871872

From duke at openjdk.org  Fri Apr 12 03:19:41 2024
From: duke at openjdk.org (Brett Okken)
Date: Fri, 12 Apr 2024 03:19:41 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <iB3-M1Zqko_5S8dh67o0tGxQYcd0kbDCqroGFmK0GAA=.d59284b1-c058-42df-abe9-83c016939f44@github.com>

On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1430:

> 1428:                     cb.new_(STRING_BUILDER);
> 1429:                     cb.dup();
> 1430:                     cb.invokespecial(STRING_BUILDER, "<init>", MethodTypeDesc.ofDescriptor("()V"));

Would there be value in initializing to a larger capacity? Given the number of append calls, seems the default cap of 16 is unlikely to be sufficient.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1561966067

From jpai at openjdk.org  Fri Apr 12 04:06:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Apr 2024 04:06:48 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v3]
In-Reply-To: <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
Message-ID: <0QOUIwhikGpUpzROwg_cxcyRIyTVAM0XKdJ5-tQatHE=.43cb6999-f1cd-46ec-b249-d830f5732c10@github.com>

On Wed, 10 Apr 2024 16:17:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need for {@code} in javadoc

I've now created the CSR https://bugs.openjdk.org/browse/JDK-8330135. I'll move it to Finalized once I get a review for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18674#issuecomment-2050930262

From stuefe at openjdk.org  Fri Apr 12 06:36:43 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 06:36:43 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <oJNFwokHhktyAvzeC0gl1LbjM8Xwv8mBQc_iK5RR-DE=.3bbcfef1-b1a9-40a8-ae92-8cfb342cca70@github.com>

On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low

Stupid question maybe, this would be one LambdaForm per argument set? E.g. would two invocations with the same arguments re-use the same LambdaForm?

I would like to get an understanding of the numbers of classes involved for these solutions, and whether they are bounded. Mostly for Lilliput reason.

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051082454

From stuefe at openjdk.org  Fri Apr 12 07:35:47 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 07:35:47 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <kO9aumlksJiwqy79mXDdfwymk6xUoYWN9u5iU-txPvs=.fcda8c84-8001-4f6a-9786-cd379a62e5a0@github.com>

On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

Fyi: https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2024-April/074787.html

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051184229

From vklang at openjdk.org  Fri Apr 12 07:55:12 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 12 Apr 2024 07:55:12 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v6]
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <-vpvJp8m8dzxsODBn3cCJSPUyVB0aRkaOSWj2J1Pftw=.be26b36a-09c6-4fa9-9f49-08b04b43b160@github.com>

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR:
> 
> Benchmark            (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array        10  thrpt   12   294008,937 ? 54369,110  ops/s
> FlatMap.par_array       100  thrpt   12    62411,229 ? 14868,119  ops/s
> FlatMap.par_array      1000  thrpt   12     8263,821 ?   452,622  ops/s
> FlatMap.par_iterate      10  thrpt   12    23029,978 ?  4274,449  ops/s
> FlatMap.par_iterate     100  thrpt   12    10532,907 ?   321,694  ops/s
> FlatMap.par_iterate    1000  thrpt   12      981,571 ?   135,270  ops/s
> FlatMap.seq_array        10  thrpt   12  2955648,495 ? 32539,142  ops/s
> FlatMap.seq_array       100  thrpt   12    41851,009 ?   377,546  ops/s
> FlatMap.seq_array      1000  thrpt   12     1740,281 ?  1229,974  ops/s
> FlatMap.seq_iterate      10  thrpt   12   321727,690 ?  5149,356  ops/s
> FlatMap.seq_iterate     100  thrpt   12     8437,198 ?    56,635  ops/s
> FlatMap.seq_iterate    1000  thrpt   12       76,994 ?     0,965  ops/s
> 
> 
> After this PR:
> 
> 
> Benchmark            (size)   Mode  Cnt        Score        Error  Units
> FlatMap.par_array        10  thrpt   12   283350,051 ?  35567,223  ops/s
> FlatMap.par_array       100  thrpt   12    53846,906 ?  19241,913  ops/s
> FlatMap.par_array      1000  thrpt   12     8230,909 ?    156,362  ops/s
> FlatMap.par_iterate      10  thrpt   12    26328,500 ?   5411,401  ops/s
> FlatMap.par_iterate     100  thrpt   12    10470,862 ?    249,991  ops/s
> FlatMap.par_iterate    1000  thrpt   12      986,511 ?    224,050  ops/s
> FlatMap.seq_array        10  thrpt   12  5654826,565 ?  27317,453  ops/s
> FlatMap.seq_array       100  thrpt   12   187929,786 ?    542,787  ops/s
> FlatMap.seq_array      1000  thrpt   12     2385,346 ?      9,827  ops/s
> FlatMap.seq_iterate      10  thrpt   12   812722,403 ? 160500,399  ops/s
> FlatMap.seq_iterate     100  thrpt   12    13542,472 ?    118,769  ops/s
> FlatMap.seq_iterate    1000  thrpt   12      157,056 ?      1,814  ops/s
> 
> 
> For streams of size 100k, the following numbers are interesting:
> 
> Before this PR:
> 
> Benchmark            (size)   Mode  Cnt  Score    Error  Units
> FlatMap.par_array    100000  thrpt   12  0,325 ?  0,004  ops/s
> FlatMap.par_iterate  100000  thrpt   12  0,106 ?  0,008  ops/s
> FlatMap.seq_array    100000  thrpt   12  0,173 ?  0,003  ops/s
> FlatMap.seq_iterate  100...

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

  Fixes 8196106 by reencoding flatMap as sa Gatherer-inspired operation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18625/files
  - new: https://git.openjdk.org/jdk/pull/18625/files/bedbab85..a3f1e518

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=04-05

  Stats: 165 lines in 4 files changed: 39 ins; 77 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/18625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18625/head:pull/18625

PR: https://git.openjdk.org/jdk/pull/18625

From vklang at openjdk.org  Fri Apr 12 08:51:43 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 12 Apr 2024 08:51:43 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams
In-Reply-To: <8bqF5vEbKODzCBUAWjw111-IUDoBPKAen8T5hGqiwOY=.a0128c2f-e0c2-40f0-a9c3-7db63db9bfef@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <hyBNY-T0J46X8dBqKy1j8NKWx51I7S9D5iFrWGNZdy0=.2a5821c1-4440-4e74-b72b-3a409caca60c@github.com>
 <8bqF5vEbKODzCBUAWjw111-IUDoBPKAen8T5hGqiwOY=.a0128c2f-e0c2-40f0-a9c3-7db63db9bfef@github.com>
Message-ID: <jkZwxaExDg4iZGXV-nQFp6cdJqilinaRhQUy-NKjeq0=.1cb010ec-cd82-4c0e-b254-fd77e9719b11@github.com>

On Mon, 8 Apr 2024 16:47:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @PaulSandoz @AlanBateman I've added a commit to this PR which removes the use of Gatherer for Stream::flatMap, but instead implements flatMap for all of the pipelines using the same encoding which Gatherer would use. It seems very competitive performance-wise, and resolves at least one open JBS-issue with flatMap (will look to see if it resolves more than that)
>
>> @PaulSandoz @AlanBateman I've added a commit to this PR which removes the use of Gatherer for Stream::flatMap, but instead implements flatMap for all of the pipelines using the same encoding which Gatherer would use. It seems very competitive performance-wise, and resolves at least one open JBS-issue with flatMap (will look to see if it resolves more than that)
> 
> That's a rather clever use of `allMatch`!
> 
> Did you observe performance improvements using `@Stable` on the `cancel` field? It's really hard to predict in the abstract (since the default value of the field will be read in proportion to the number of elements until the stream is cancelled).

@PaulSandoz @AlanBateman This should be ready for review now, if you find some time :)

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

PR Comment: https://git.openjdk.org/jdk/pull/18625#issuecomment-2051317333

From vklang at openjdk.org  Fri Apr 12 08:57:44 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 12 Apr 2024 08:57:44 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v3]
In-Reply-To: <QKAQFYZG6wZbXTyzF3bnWNGEanKisOODjhLBzAcdevo=.aff77ee9-3df0-4b5c-998c-8caa80cf42da@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
 <QKAQFYZG6wZbXTyzF3bnWNGEanKisOODjhLBzAcdevo=.aff77ee9-3df0-4b5c-998c-8caa80cf42da@github.com>
Message-ID: <-vP2LBiOyFHeCcqOM-GB6kKMaWlgc4mj7tvFaobBTLk=.1b3673cc-faf7-4c61-9dd2-736665f4c986@github.com>

On Thu, 11 Apr 2024 14:44:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Korov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use testNG builtin functionalities and modify the test function name
>
> Keep-alive, maybe people like @viktorklang-ora might look at this simple fix too

@liach I'm not a Reviewer (yet) so I'll defer to someone like @stuart-marks :)

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

PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-2051326819

From redestad at openjdk.org  Fri Apr 12 10:10:42 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Apr 2024 10:10:42 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <oJNFwokHhktyAvzeC0gl1LbjM8Xwv8mBQc_iK5RR-DE=.3bbcfef1-b1a9-40a8-ae92-8cfb342cca70@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <oJNFwokHhktyAvzeC0gl1LbjM8Xwv8mBQc_iK5RR-DE=.3bbcfef1-b1a9-40a8-ae92-8cfb342cca70@github.com>
Message-ID: <jqVrVvso2Etu82bcn5SkWmM4yPC7tUWeSwGJ1GV2-3g=.6a20dd93-bd14-446c-80f4-70ab755dde68@github.com>

On Fri, 12 Apr 2024 06:34:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Stupid question maybe, this would be one LambdaForm per argument set? E.g. would two invocations with the same arguments re-use the same LambdaForm?
> 
> I would like to get an understanding of the numbers of classes involved for these solutions, and whether they are bounded. Mostly for Lilliput reason.

Any concat expression sharing the same exact shape will ideally share the same chain of LFs, and many of the intermediary LFs will be shared between concat expressions of all manner of shapes and sizes. On the extreme of an application with one singular, huge expression we might see quite a few LF classes per call site, while the incremental number of classes loaded for an expression whose shape has been visited elsewhere will be none. 

One could guess there is some upper bound based on the number of variant types (7: int, long, float, double, char, boolean, Object) to the power of the highest possible arity (100 - after which javac will start splitting and chaining the indy calls), though since there are some softly referenced caches that the LF editor leans on then in theory it might very well be unbounded. In practice we're bounded by the number of call sites times some factor that depends on how much sharing is going on. Since most expressions are likely to be low arity with high degree of sharing, then a long tail of more complex high arity expressions that might see less degree of sharing the assumption has been that the number of classes loaded per concat will be low.

I guess Lilliput adds some hard or soft limit on the number of classes loaded?

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051462197

From jlahoda at openjdk.org  Fri Apr 12 10:21:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 12 Apr 2024 10:21:02 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static
Message-ID: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>

Consider code like:

public class MainClass {
    public MainClass() {
        System.out.println("Constructor called!");
    }
    public static void main() {
        System.out.println("main called!");
    }
}

and compile and run it, with preview enabled, like:

$ javac /tmp/MainClass.java 
$ java --enable-preview -classpath /tmp MainClass
Constructor called!
main called!


That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.

The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.

The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).

There is also a relatively closely related problem: what happens when the constructor throws an exception?

public class MainClass {
    public MainClass() {
        if (true) throw new RuntimeException();
    }
    public void main() {
        System.out.println("main called!");
    }
}


when compiled an run, this produces no output whatsoever:

$ javac /tmp/MainClass.java 
$ java --enable-preview -classpath /tmp MainClass
$


This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:

$ java --enable-preview -classpath /tmp/ MainClass 
Exception in thread "main" java.lang.RuntimeException
        at MainClass.<init>(MainClass.java:3)


This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.

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

Commit messages:
 - Updating year.
 - 8329420: Java 22 (and 23) launcher calls default constructor although main() is static

Changes: https://git.openjdk.org/jdk/pull/18753/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18753&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329420
  Stats: 150 lines in 2 files changed: 130 ins; 4 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18753/head:pull/18753

PR: https://git.openjdk.org/jdk/pull/18753

From redestad at openjdk.org  Fri Apr 12 10:21:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Apr 2024 10:21:43 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <iB3-M1Zqko_5S8dh67o0tGxQYcd0kbDCqroGFmK0GAA=.d59284b1-c058-42df-abe9-83c016939f44@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <iB3-M1Zqko_5S8dh67o0tGxQYcd0kbDCqroGFmK0GAA=.d59284b1-c058-42df-abe9-83c016939f44@github.com>
Message-ID: <pQIn1JZl2AUsIWkksGjJG7SDHfDVYYOE_TcvWBJx6x8=.556ffd4f-053c-490c-a046-0e125083923e@github.com>

On Fri, 12 Apr 2024 03:16:58 GMT, Brett Okken <duke at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1430:
> 
>> 1428:                     cb.new_(STRING_BUILDER);
>> 1429:                     cb.dup();
>> 1430:                     cb.invokespecial(STRING_BUILDER, "<init>", MethodTypeDesc.ofDescriptor("()V"));
> 
> Would there be value in initializing to a larger capacity? Given the number of append calls, seems the default cap of 16 is unlikely to be sufficient.

Possibly. I tried a few simple variants that initialized the `StringBuilder` capacity at various guesses, such as sum of constant sizes + some factor based on args, but across a diverse set of micros that gives both some wins and some regressions. Getting the estimation just right is pretty tricky, especially when size of the arguments are arbitrary (like for any String/Object arg).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562356874

From stuefe at openjdk.org  Fri Apr 12 11:43:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 11:43:41 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <jqVrVvso2Etu82bcn5SkWmM4yPC7tUWeSwGJ1GV2-3g=.6a20dd93-bd14-446c-80f4-70ab755dde68@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <oJNFwokHhktyAvzeC0gl1LbjM8Xwv8mBQc_iK5RR-DE=.3bbcfef1-b1a9-40a8-ae92-8cfb342cca70@github.com>
 <jqVrVvso2Etu82bcn5SkWmM4yPC7tUWeSwGJ1GV2-3g=.6a20dd93-bd14-446c-80f4-70ab755dde68@github.com>
Message-ID: <crfw1FaEl9KtOGwt3HlksNvWN4M8FdhlC82NZSrGwf4=.9d56dcc0-d4f6-4693-af7e-f282cc775b24@github.com>

On Fri, 12 Apr 2024 10:07:48 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I guess Lilliput adds some hard or soft limit on the number of classes loaded?

Yes, we are concerned with that, especially for a possible future where Lilliput is the sole default. Atm we can address about 4 million classes. There are thoughts about making this number of classes infinite, but if possible we would like to avoid that complexity.

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051597166

From redestad at openjdk.org  Fri Apr 12 13:13:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Apr 2024 13:13:43 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <crfw1FaEl9KtOGwt3HlksNvWN4M8FdhlC82NZSrGwf4=.9d56dcc0-d4f6-4693-af7e-f282cc775b24@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <oJNFwokHhktyAvzeC0gl1LbjM8Xwv8mBQc_iK5RR-DE=.3bbcfef1-b1a9-40a8-ae92-8cfb342cca70@github.com>
 <jqVrVvso2Etu82bcn5SkWmM4yPC7tUWeSwGJ1GV2-3g=.6a20dd93-bd14-446c-80f4-70ab755dde68@github.com>
 <crfw1FaEl9KtOGwt3HlksNvWN4M8FdhlC82NZSrGwf4=.9d56dcc0-d4f6-4693-af7e-f282cc775b24@github.com>
Message-ID: <uLs_7kTxETK-cwzqUdVFNZ03ifhwItCXKpNwNvbumzQ=.564fd1ab-49ac-44ad-9657-6073130f4e96@github.com>

On Fri, 12 Apr 2024 11:41:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Yes, we are concerned with that, especially for a possible future where Lilliput is the sole default. Atm we can address about 4 million classes. There are thoughts about making this number of classes infinite, but if possible we would like to avoid that complexity.

4M classes should be enough for everyone :-) Either way this PR shouldn't make the situation worse. I think for expressions of high arity the average number of classes generated by the current strategy is likely larger than 1. Forcing generation of exactly one class per such call site is thus unlikely to be worse. But since it depends on app having a parameter to adjust the level at which we fall back to simple bytecode generation seems reasonable.

There's a range of possible follow-up enhancements to reduce classes generated. For example we could generate classes where constants are injected rather than hardcoded and cache/reuse those classes at different call-sites. Further out we could pre-generate classes (one per arity) containing methods for known signatures when dumping CDS archives or running jlink plugins so that there's little to no bytecode generation at runtime and a bound number of classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051734530

From forax at openjdk.org  Fri Apr 12 13:46:45 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 12 Apr 2024 13:46:45 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <Z427VY7OpopoDeULLFwdX6n9lEhKR7GQgUHJdQL2TUM=.eaa92df0-0281-452a-97f2-9f3d8f9dc8c0@github.com>

On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

One class per arity + value classes can be a good combo ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051792260

From sgibbons at openjdk.org  Fri Apr 12 13:46:46 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 12 Apr 2024 13:46:46 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v13]
In-Reply-To: <Lixq79faFKdpBDWmIcjFwFzMgiEe-Dsvmau_sZoQDxk=.938a6974-f179-428d-9687-3417c57046fe@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <2W-3EZqHS-07qzZ4RS72u33Hav0LMRfeIG4QPAyvk10=.8a35e043-6803-42d5-8ea0-bff5378a8c50@github.com>
 <Lixq79faFKdpBDWmIcjFwFzMgiEe-Dsvmau_sZoQDxk=.938a6974-f179-428d-9687-3417c57046fe@github.com>
Message-ID: <b6VzRE4y_WeggfNa4rpx5JN3EOB6cHVWSWyHupuhOCY=.efc7c6db-d1c6-4897-98a0-c12eb9269909@github.com>

On Fri, 12 Apr 2024 00:14:29 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing yet more review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2504:
> 
>> 2502:     Label L_exit, L_fillQuadwords, L_fillDwords, L_fillBytes;
>> 2503: 
>> 2504:     setup_arg_regs(3);
> 
> A comment stating the placement of dest, size, and byteVal after call to setup_arg_regs() would be very helpful.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1562562649

From sgibbons at openjdk.org  Fri Apr 12 13:46:47 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 12 Apr 2024 13:46:47 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v13]
In-Reply-To: <xAlej-OqvaJzj8LtOlC_ptB3mcuQMYmN8Gp_h64f5aY=.f0325b72-b389-47e4-a129-8f9e3036b8a5@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <2W-3EZqHS-07qzZ4RS72u33Hav0LMRfeIG4QPAyvk10=.8a35e043-6803-42d5-8ea0-bff5378a8c50@github.com>
 <Lixq79faFKdpBDWmIcjFwFzMgiEe-Dsvmau_sZoQDxk=.938a6974-f179-428d-9687-3417c57046fe@github.com>
 <xAlej-OqvaJzj8LtOlC_ptB3mcuQMYmN8Gp_h64f5aY=.f0325b72-b389-47e4-a129-8f9e3036b8a5@github.com>
Message-ID: <lRtYV7nZs9z51zymvdi0sQ9S4RA4oh8tsN8KEJvbTrE=.19edaf6e-9ba4-49e5-a763-a967d8a2352b@github.com>

On Fri, 12 Apr 2024 00:25:34 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2521:
>> 
>>> 2519:       const Register byteVal = rdx;
>>> 2520: 
>>> 2521:       // Propagate byte to full Register
>> 
>> The comment refers to lines 2524-2526, please move it down.
>
> Still continuing to look through StubGenerator::generate_unsafe_setmemory(), more comments to come. Thank you for your patience.

Comment moved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1562563155

From sgibbons at openjdk.org  Fri Apr 12 13:46:48 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 12 Apr 2024 13:46:48 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v12]
In-Reply-To: <IIBoFwfIyBwYlGx941c0mUzv6WWh6eR69hpr2abDMOg=.3acdb49d-b847-41ee-aca4-76294105d5fe@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <s31GoF1j5diAB9u6HkZRnl0ijGHil1E1y3NpWa6ePMQ=.c1aafab1-5798-4624-ba83-b2410a98c6b6@github.com>
 <P3HzpOG-j2hTlWUzGFWlGeVwrVQ-l_K-RydUik_vNYM=.29057482-91c8-400b-a9e8-bf9b0fd360cb@github.com>
 <bFNzSjrU974UCoTvZOsbqMiHvy-cS2kUbjfs4vKpy2M=.945a9171-34ce-4545-b1fb-66525622b64d@github.com>
 <IIBoFwfIyBwYlGx941c0mUzv6WWh6eR69hpr2abDMOg=.3acdb49d-b847-41ee-aca4-76294105d5fe@github.com>
Message-ID: <JeLP2ZLUK5tKzffLVxe5mzXCOR7oEfPzGO8Oqs2MksE=.2a74f577-b5ec-46d1-8ca6-9c1d855e6e19@github.com>

On Fri, 12 Apr 2024 00:23:33 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> It would not be appropriate to add set memory marks to the existing _jbyte_fill as it is being used by other routines, and the effect of the mark will be very hard to track down (if any).
>> 
>> Are you *sure* we want to do that?
>
> Yes we want to do that. It is all guarded by thread->doing_unsafe_access() which is only true when we are getting to this code from unsafe. Similar technique is used in copyMemory as well.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1562573673

From liach at openjdk.org  Fri Apr 12 14:24:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Apr 2024 14:24:44 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v8]
In-Reply-To: <OZJ6a0tTFEhhnYCCkpZIqbyYIHqRO2VIm19Nkv5bxAw=.7936f515-482c-4592-8d7e-480bb06bf92d@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
 <OZJ6a0tTFEhhnYCCkpZIqbyYIHqRO2VIm19Nkv5bxAw=.7936f515-482c-4592-8d7e-480bb06bf92d@github.com>
Message-ID: <sXijyicHupH34NNKTleIvBYUEkCdMAYK75JzrO11uSo=.0a4fc7b2-23ee-46ac-9fcf-ffb36af04aa7@github.com>

On Wed, 10 Apr 2024 22:55:01 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> Add notes for `HashMap::putAll()` conservative resizing.
>> 
>> Note: everything below this line is from the original change. After discussion, we decided to keep the conservative resizing, but we should add an `@implNote` for the decision.
>> 
>> ---
>> 
>> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
>> 
>> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
>> 
>> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
>> 
>> 
>> Before change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
>> 
>> 
>> After change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
>> 
>> 
>> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
>> 
>> ---
>> 
>> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
>> 
>> Before change:
>> 
>> 
>> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
>> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
>> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
>> HashM...
>
> Joshua Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Move implNote to putAll()
>  - Merge branch 'master' into hashmap
>  - Use @link for javadoc
>  - Update implNotes to explain conservative resizing decisions and suggest
>    options to avoid expensive resizing
>  - Merge branch 'master' into hashmap
>  - Add note about conservative resizing
>  - Merge branch 'master' into hashmap
>  - extract msize variable
>  - Use max of both sizes and other maps size in case of overflow
>  - Add benchmark with all duplicate keys
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1ec85db1...2644e4d7

Since we are changing the javadoc, we need a csr review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-2051858721

From redestad at openjdk.org  Fri Apr 12 14:39:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Apr 2024 14:39:41 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <Z427VY7OpopoDeULLFwdX6n9lEhKR7GQgUHJdQL2TUM=.eaa92df0-0281-452a-97f2-9f3d8f9dc8c0@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <Z427VY7OpopoDeULLFwdX6n9lEhKR7GQgUHJdQL2TUM=.eaa92df0-0281-452a-97f2-9f3d8f9dc8c0@github.com>
Message-ID: <2boRFsLgLzI_5xT-9vGCHyDHSMqNml_nUEoV2a-Rkr4=.f7b221df-21b8-48a0-96c7-67a67922e4a3@github.com>

On Fri, 12 Apr 2024 13:44:23 GMT, R?mi Forax <forax at openjdk.org> wrote:

> One class per arity + value classes can be a good combo ?

Not sure value classes matter here? We would need one static instance per call site holding the constants. Trickier for performance is the potential for profile pollution between such classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051885862

From liach at openjdk.org  Fri Apr 12 14:39:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Apr 2024 14:39:43 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <qRcge092Bzg4B4ox7NvGZjgpv5M8tfXtkK3JkTi8mRY=.8c2e81cc-5655-443c-8615-a347a7b61b5a@github.com>

On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1406:

> 1404:                         @Override
> 1405:                         public void accept(ClassBuilder clb) {
> 1406:                             clb.withFlags(AccessFlag.PUBLIC, AccessFlag.FINAL, AccessFlag.SUPER, AccessFlag.SYNTHETIC)

Why is this hidden class public?

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1409:

> 1407:                                 .withMethodBody(METHOD_NAME,
> 1408:                                         MethodTypeDesc.ofDescriptor(args.toMethodDescriptorString()),
> 1409:                                         ClassFile.ACC_FINAL | ClassFile.ACC_PUBLIC | ClassFile.ACC_STATIC,

Why is this method final? Don't think this method can ever be hidden.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1416:

> 1414:                 Class<?> innerClass = lookup.defineHiddenClass(classBytes, true, STRONG).lookupClass();
> 1415:                 DUMPER.dumpClass(className, innerClass, classBytes);
> 1416:                 MethodHandle mh = lookup.findStatic(innerClass, METHOD_NAME, args);

We can probably make the method private, and use the lookup from `defineHiddenClass` instead of the host class lookup.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1425:

> 1423: 
> 1424:         private static Consumer<CodeBuilder> generateMethod(String[] constants, MethodType args) {
> 1425:             return new Consumer<CodeBuilder>() {

Are you using inner classes for startup performance concerns? java.lang.invoke should be ready when you can reach here so using lambdas is safe.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1458:

> 1456: 
> 1457:         // Load the argument of type cl at slot onto stack, return the number of argument stack slots consumed.
> 1458:         private static int load(CodeBuilder cb, Class<?> cl, int slot) {

You can replace all calls to `load(cb, cl, slot)` with `cb.loadInstruction(TypeKind.from(cl), slot)`, and the retrn slot count can be accessed by `TypeKind::slotSize`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562629418
PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562630031
PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562635315
PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562637025
PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562640252

From vklang at openjdk.org  Fri Apr 12 14:53:01 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 12 Apr 2024 14:53:01 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v7]
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR (on my MacBook, aarch64):
> 
> Non-short-circuiting:
> 
> Benchmark                 (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array             10  thrpt   12   257582,480 ? 31360,242  ops/s
> FlatMap.par_array            100  thrpt   12    55202,015 ? 14011,668  ops/s
> FlatMap.par_array           1000  thrpt   12     6546,252 ?  3675,764  ops/s
> FlatMap.par_doublestream      10  thrpt   12   267423,410 ? 37338,089  ops/s
> FlatMap.par_doublestream     100  thrpt   12    27140,703 ?  4979,878  ops/s
> FlatMap.par_doublestream    1000  thrpt   12     2978,178 ?  1890,250  ops/s
> FlatMap.par_intstream         10  thrpt   12   268194,530 ? 37295,092  ops/s
> FlatMap.par_intstream        100  thrpt   12    30897,034 ?  5388,245  ops/s
> FlatMap.par_intstream       1000  thrpt   12     3969,043 ?  2494,641  ops/s
> FlatMap.par_longstream        10  thrpt   12   279756,861 ? 19519,497  ops/s
> FlatMap.par_longstream       100  thrpt   12    45733,955 ? 18385,144  ops/s
> FlatMap.par_longstream      1000  thrpt   12     5115,615 ?  4147,237  ops/s
> FlatMap.seq_array             10  thrpt   12  2937192,934 ? 58605,583  ops/s
> FlatMap.seq_array            100  thrpt   12    41859,462 ?   139,021  ops/s
> FlatMap.seq_array           1000  thrpt   12      442,677 ?     1,041  ops/s
> FlatMap.seq_doublestream      10  thrpt   12  4972651,093 ? 35997,267  ops/s
> FlatMap.seq_doublestream     100  thrpt   12    99265,005 ?   193,497  ops/s
> FlatMap.seq_doublestream    1000  thrpt   12     1037,030 ?     3,254  ops/s
> FlatMap.seq_intstream         10  thrpt   12  5133751,888 ? 23516,294  ops/s
> FlatMap.seq_intstream        100  thrpt   12   145166,206 ?   399,263  ops/s
> FlatMap.seq_intstream       1000  thrpt   12     1565,004 ?     3,207  ops/s
> FlatMap.seq_longstream        10  thrpt   12  5047029,363 ? 24742,300  ops/s
> FlatMap.seq_longstream       100  thrpt   12   233225,307 ?  7162,604  ops/s
> FlatMap.seq_longstream      1000  thrpt   12     2999,926 ?     9,945  ops/s
> 
> // Short-circuiting:
> 
> Benchmark                   (size)   Mode  Cnt       Score       Error  Units
> FlatMap.par_iterate_double      10  thrpt   12   46336,834 ?  6803,751  ops/s
> FlatMap.par_iterate_double     100  thrpt   12   15365,884 ?  2750,656  ops/s
> FlatMap.par_iterate_double    1000 ...

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

  Adding additional, short-circuit-specific, cases to the FlatMap benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18625/files
  - new: https://git.openjdk.org/jdk/pull/18625/files/a3f1e518..7683a0f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=05-06

  Stats: 65 lines in 1 file changed: 55 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18625/head:pull/18625

PR: https://git.openjdk.org/jdk/pull/18625

From redestad at openjdk.org  Fri Apr 12 14:53:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Apr 2024 14:53:44 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <qRcge092Bzg4B4ox7NvGZjgpv5M8tfXtkK3JkTi8mRY=.8c2e81cc-5655-443c-8615-a347a7b61b5a@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <qRcge092Bzg4B4ox7NvGZjgpv5M8tfXtkK3JkTi8mRY=.8c2e81cc-5655-443c-8615-a347a7b61b5a@github.com>
Message-ID: <TTwEfuzPmvJjQjmnybjDoZLOq0GId1M6a1CY_6msjEU=.12bb9a3a-34cd-4f60-a187-9080fb852e1d@github.com>

On Fri, 12 Apr 2024 14:32:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1425:
> 
>> 1423: 
>> 1424:         private static Consumer<CodeBuilder> generateMethod(String[] constants, MethodType args) {
>> 1425:             return new Consumer<CodeBuilder>() {
> 
> Are you using inner classes for startup performance concerns? java.lang.invoke should be ready when you can reach here so using lambdas is safe.

We've opted to avoid lambda use in `java.lang.invoke` historically to avoid bootstrap surprises. A small price to pay, imho.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562661264

From liach at openjdk.org  Fri Apr 12 15:01:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Apr 2024 15:01:41 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <jzadfmnWmt_23bDh0YfmnKbywrelgVpL20RHnUJv3o8=.73ed8ced-3798-45a8-92e3-83616ddfefdb@github.com>

On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1437:

> 1435:                         for (int c = 0; c < args.parameterCount(); c++) {
> 1436:                             if (constants[c] != null) {
> 1437:                                 cb.ldc(constants[c]);

I think for Remi's approach, we change:
1. Insert an extra String array (maybe need a way to mark it stable?) arg representing constants
2. Change this ldc into aload + aaload (or List.get if we use immutable List)
3. Call `bindTo(constantStrings)` on the resulting MH

This approach can significantly reduce the number of classes spinned instead of generating one class per constant array; might need to measure performance to see if this is a good tradeoff

Oh, I just noticed that we need to erase everything to the generic method type. I think Remi's "value class" means there's no overhead for converting primitives into wrappers in this conversion to generic method type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562667143

From redestad at openjdk.org  Fri Apr 12 15:01:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Apr 2024 15:01:41 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <jzadfmnWmt_23bDh0YfmnKbywrelgVpL20RHnUJv3o8=.73ed8ced-3798-45a8-92e3-83616ddfefdb@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <jzadfmnWmt_23bDh0YfmnKbywrelgVpL20RHnUJv3o8=.73ed8ced-3798-45a8-92e3-83616ddfefdb@github.com>
Message-ID: <w_Q5asfvbEoeI-QJfh92FJ2sPKFhXuQCPyPm6XvHxww=.fee8131b-4f8b-45e7-99dd-854c79354c0a@github.com>

On Fri, 12 Apr 2024 14:53:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1437:
> 
>> 1435:                         for (int c = 0; c < args.parameterCount(); c++) {
>> 1436:                             if (constants[c] != null) {
>> 1437:                                 cb.ldc(constants[c]);
> 
> I think for Remi's approach, we change:
> 1. Insert an extra String array (maybe need a way to mark it stable?) arg representing constants
> 2. Change this ldc into aload + aaload (or List.get if we use immutable List)
> 3. Call `bindTo(constantStrings)` on the resulting MH
> 
> This approach can significantly reduce the number of classes spinned instead of generating one class per constant array; might need to measure performance to see if this is a good tradeoff
> 
> Oh, I just noticed that we need to erase everything to the generic method type. I think Remi's "value class" means there's no overhead for converting primitives into wrappers in this conversion to generic method type.

I'd prefer considering such optimizations as follow-ups. We need to think about where to define such shared classes in a way that considers the full lifecycle, facilitates class unloading (one cache per classloader?) while still getting good reuse.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562673638

From liach at openjdk.org  Fri Apr 12 15:09:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Apr 2024 15:09:43 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <w_Q5asfvbEoeI-QJfh92FJ2sPKFhXuQCPyPm6XvHxww=.fee8131b-4f8b-45e7-99dd-854c79354c0a@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <jzadfmnWmt_23bDh0YfmnKbywrelgVpL20RHnUJv3o8=.73ed8ced-3798-45a8-92e3-83616ddfefdb@github.com>
 <w_Q5asfvbEoeI-QJfh92FJ2sPKFhXuQCPyPm6XvHxww=.fee8131b-4f8b-45e7-99dd-854c79354c0a@github.com>
Message-ID: <Jig3lPKwypZSDvjHE10IltvPChHUIyTL3UWvs6wZ4SI=.463b84d8-19b3-4ee7-9cce-8e1f7765af86@github.com>

On Fri, 12 Apr 2024 14:57:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1437:
>> 
>>> 1435:                         for (int c = 0; c < args.parameterCount(); c++) {
>>> 1436:                             if (constants[c] != null) {
>>> 1437:                                 cb.ldc(constants[c]);
>> 
>> I think for Remi's approach, we change:
>> 1. Insert an extra String array (maybe need a way to mark it stable?) arg representing constants
>> 2. Change this ldc into aload + aaload (or List.get if we use immutable List)
>> 3. Call `bindTo(constantStrings)` on the resulting MH
>> 
>> This approach can significantly reduce the number of classes spinned instead of generating one class per constant array; might need to measure performance to see if this is a good tradeoff
>> 
>> Oh, I just noticed that we need to erase everything to the generic method type. I think Remi's "value class" means there's no overhead for converting primitives into wrappers in this conversion to generic method type.
>
> I'd prefer considering such optimizations as follow-ups. We need to think about where to define such shared classes in a way that considers the full lifecycle, facilitates class unloading (one cache per classloader?) while still getting good reuse.

I think `Invokers` might be a good place. Its lifetime is bound to its MT, and MT already handles class unloading well. If we are doing erased then a plain array suffices.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562686793

From redestad at openjdk.org  Fri Apr 12 15:21:54 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Apr 2024 15:21:54 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <Gx9v97OeRdjx0gerShHLlF51MEUOLaw4oBM_VqsGSaE=.5450320e-190d-4aa1-b27d-84a3469163fc@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

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

  @liach feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18690/files
  - new: https://git.openjdk.org/jdk/pull/18690/files/b5928994..1c3d354c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=00-01

  Stats: 32 lines in 1 file changed: 4 ins; 23 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From redestad at openjdk.org  Fri Apr 12 15:21:54 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 12 Apr 2024 15:21:54 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <qRcge092Bzg4B4ox7NvGZjgpv5M8tfXtkK3JkTi8mRY=.8c2e81cc-5655-443c-8615-a347a7b61b5a@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <qRcge092Bzg4B4ox7NvGZjgpv5M8tfXtkK3JkTi8mRY=.8c2e81cc-5655-443c-8615-a347a7b61b5a@github.com>
Message-ID: <GM9DKJvxT_AOPjdEae99wvQpvSuy6h-C5AD_4P0FRJI=.a657bb77-1702-4020-817e-ee2dcca8a20c@github.com>

On Fri, 12 Apr 2024 14:26:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @liach feedback
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1406:
> 
>> 1404:                         @Override
>> 1405:                         public void accept(ClassBuilder clb) {
>> 1406:                             clb.withFlags(AccessFlag.PUBLIC, AccessFlag.FINAL, AccessFlag.SUPER, AccessFlag.SYNTHETIC)
> 
> Why is this hidden class public?

Removed `PUBLIC`.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1458:
> 
>> 1456: 
>> 1457:         // Load the argument of type cl at slot onto stack, return the number of argument stack slots consumed.
>> 1458:         private static int load(CodeBuilder cb, Class<?> cl, int slot) {
> 
> You can replace all calls to `load(cb, cl, slot)` with `cb.loadInstruction(TypeKind.from(cl), slot)`, and the retrn slot count can be accessed by `TypeKind::slotSize`

Thanks, I've tried to simplify.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562702306
PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1562701048

From sgibbons at openjdk.org  Fri Apr 12 16:47:58 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 12 Apr 2024 16:47:58 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v14]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <SOE8BOnQndoHd-1208dollgry40e2h0BL-69QhF9aUA=.6e897576-33bf-4a01-84c8-512abac97e74@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Even more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/970c5751..6e731c86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=12-13

  Stats: 35 lines in 4 files changed: 14 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From jjg at openjdk.org  Fri Apr 12 17:24:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 17:24:43 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
Message-ID: <yoXk0XJ1mo_6lFPzenTjynOJmM2R8GNROFOTwN4p00g=.dcedceac-6d2a-4b1f-99ee-57d060b8a69b@github.com>

On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust call for `saveDanglingDocComments` for enum members
>
> The build changes look okay. 
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

@magicus 
> The build changes look okay.
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

The plan is to create an umbrella bug to clean up the individual modules. There is interest to clean up `java.base`, to keep that one free of any warnings, and I can see that the lang tools modules will get cleaner up as well. It will be up to other component teams to decide if and when to clean up other parts of the system.  Once this work has been integrated, it is relatively easy to enable the warnings for a module and to fix the ensuing issues. Since any changes "only" involve comments, it should be reasonably easy to fix them, unlike some pervasive other warnings, like `this-escape`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2052174696

From jlu at openjdk.org  Fri Apr 12 20:06:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Apr 2024 20:06:06 GMT
Subject: RFR: 8327640: Allow NumberFormat strict parsing [v8]
In-Reply-To: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
Message-ID: <3ONWnNJ2hSsj-tednKlM29911ilM3ZPNfdj-i-Byj_4=.5b3e89ab-73d6-4eb7-a431-2062ce720a4a@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
> 
> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
> 
> Below is an example of the change, the CSR can be viewed for further detail.
> 
> 
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
> 
> 
> The associated tests are all localized, and the data is converted properly during runtime.

Justin Lu 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 18 additional commits since the last revision:

 - correct assert statement
 - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
 - Reflect test suggestions
 - reflect impl suggestions
 - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
 - improve wording consistency and see tags
 - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
 - revert cleanup changes; (to go into a separate change)
 - use directed 'inheritDoc' tag
 - update example for lenient parsing
 - ... and 8 more: https://git.openjdk.org/jdk/compare/ada2bc7c...6c9c4692

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/eec992e3..6c9c4692

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=06-07

  Stats: 4628 lines in 184 files changed: 1334 ins; 1373 del; 1921 mod
  Patch: https://git.openjdk.org/jdk/pull/18339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339

PR: https://git.openjdk.org/jdk/pull/18339

From naoto at openjdk.org  Fri Apr 12 21:00:49 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Apr 2024 21:00:49 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
In-Reply-To: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
Message-ID: <NV_Up7_55MP8LKTO_6904TQ0dvD4V2_KFc-vfF-ES7s=.94b2b962-9055-4e16-a282-1961a5851f75@github.com>

On Wed, 10 Apr 2024 20:16:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
> 
> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
> 
> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
> 
> I will update the CSR once the wording is finalized.

Hi Justin, I went through the `NumberFormat` part. More to follow.

src/java.base/share/classes/java/text/NumberFormat.java line 61:

> 59:  * {@code NumberFormat} is the abstract base class for all number
> 60:  * formats. This class provides the interface for formatting and parsing
> 61:  * numbers in a {@link Locale localized} manner. This enables code that can be completely

Linking "localized" to the `Locale` class seems a bit odd to me. A user who clicks the link may be stranded.

src/java.base/share/classes/java/text/NumberFormat.java line 64:

> 62:  * independent of the locale conventions for decimal points, thousands-separators,
> 63:  * whether the number format is even decimal, or even the particular decimal
> 64:  * digits used. For example, this class could be used within an application to

I kind of prefer the original wording here, as non-decimal format is the rarest case IMO.

src/java.base/share/classes/java/text/NumberFormat.java line 66:

> 64:  * digits used. For example, this class could be used within an application to
> 65:  * produce a number in a currency format according to conventions of the locale
> 66:  * a user resides in.

"a user resides in" may not convey any additional value. The user doesn't have to be in that locale.

src/java.base/share/classes/java/text/NumberFormat.java line 87:

> 85:  *
> 86:  * Alternatively, if a {@code NumberFormat} for a different locale is required, use
> 87:  * one of the factory method variants that take {@code locale} as a parameter,

Instead of "variants", "overloaded" may be more definitive. Also, "locale" can be capitalized.

src/java.base/share/classes/java/text/NumberFormat.java line 88:

> 86:  * Alternatively, if a {@code NumberFormat} for a different locale is required, use
> 87:  * one of the factory method variants that take {@code locale} as a parameter,
> 88:  * for example, {@link #getIntegerInstance(Locale)}. To determine if the current

"the current locale" -> "a particular locale"

src/java.base/share/classes/java/text/NumberFormat.java line 91:

> 89:  * locale is supported by the installed locale-sensitive service implementation,
> 90:  * either use {@link #getAvailableLocales()} or ensure a factory method call is enclosed
> 91:  * within a try block.

Not sure this is correct. Even if a locale is not "supported" by a locale provider, it won't throw an exception, but fallback to, say ROOT, locale.

src/java.base/share/classes/java/text/NumberFormat.java line 101:

> 99:  * If both "nu" and "rg" are specified, the decimal digits from the "nu"
> 100:  * extension supersedes the implicit one from the "rg" extension. Additionally,
> 101:  * currency formats support the "cf" ({@link #getCurrencyInstance(Locale) Currency

Thanks for adding `cf` extension (I forgot this when I implemented it). Probably it is better to put it in the same level as others (nu/rg), instead of "additionally".

src/java.base/share/classes/java/text/NumberFormat.java line 102:

> 100:  * extension supersedes the implicit one from the "rg" extension. Additionally,
> 101:  * currency formats support the "cf" ({@link #getCurrencyInstance(Locale) Currency
> 102:  * Format style}) extension. Although the LDML specification defines various

It is probably better to use "Unicode extensions", instead of "LDML" which might strand readers.

src/java.base/share/classes/java/text/NumberFormat.java line 106:

> 104:  * Runtime Environment might not support any particular Unicode locale attributes
> 105:  * or key/type pairs.
> 106:  * <p>Below is an example of a "en-US" locale with Thai digits,

"en-US" can be replaced with "US" which implies English and is consistent with other locations.

src/java.base/share/classes/java/text/NumberFormat.java line 118:

> 116:  *
> 117:  * <h2>Customizing NumberFormat</h2>
> 118:  * {@code NumberFormat} provides API to customize formatting and parsing behavior,

Could make this PR a dependent PR of the leniency PR, and add `setStrict()` here as well.

src/java.base/share/classes/java/text/NumberFormat.java line 135:

> 133:  * {@code CompactNumberFormat} depending on the factory method used. For example,
> 134:  * cast to {@code DecimalFormat} to call {@link DecimalFormat#setGroupingSize(int)}
> 135:  * to change the desired digits between grouping separators.

Since there is a possibility that SPIs can return the NumberFormat instances, not sure recommending casting is the right thing. If you want to add this, at least suggest the type check beforehand.

src/java.base/share/classes/java/text/NumberFormat.java line 137:

> 135:  * to change the desired digits between grouping separators.
> 136:  * While this will work for the vast majority of locales; a {@code
> 137:  * try} block should be used in case a non-supported locale is encountered.

As above, try won't catch an exception even with non-supported locales.

src/java.base/share/classes/java/text/NumberFormat.java line 175:

> 173:  *
> 174:  * @implSpec
> 175:  * <h3>Null Parameter Handling</h3>

Not sure we'd want this as a h3 header, as it makes `@implSpec` less significant.

src/java.base/share/classes/java/text/NumberFormat.java line 183:

> 181:  * {@code NullPointerException}.
> 182:  *
> 183:  * <h3>Default RoundingMode</h3>

Same as above.

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

PR Review: https://git.openjdk.org/jdk/pull/18731#pullrequestreview-1998303983
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563111509
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563121307
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563106856
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563137394
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563147282
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563149911
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563164447
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563165884
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563168311
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563180331
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563187344
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563187969
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563192719
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563192836

From jjg at openjdk.org  Fri Apr 12 21:04:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 21:04:06 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v3]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <3Ynu_D2CcFh3usjCkWQVk7VFhTlxVzD4f2nVhvZrP50=.f1c29740-ff73-4a0c-a63b-3e00ece05bbf@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  call `saveDanglingDocComments` for local variable declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/56d6dcac..3f745431

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=01-02

  Stats: 10 lines in 1 file changed: 5 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From jlu at openjdk.org  Fri Apr 12 21:46:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Apr 2024 21:46:43 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
In-Reply-To: <NV_Up7_55MP8LKTO_6904TQ0dvD4V2_KFc-vfF-ES7s=.94b2b962-9055-4e16-a282-1961a5851f75@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
 <NV_Up7_55MP8LKTO_6904TQ0dvD4V2_KFc-vfF-ES7s=.94b2b962-9055-4e16-a282-1961a5851f75@github.com>
Message-ID: <hxl0q0jE25yFY1Ooc6pFTToSDn0F1MssrjA7m3dyCrs=.a5447aac-3a04-461c-8af2-c332e65d40a2@github.com>

On Fri, 12 Apr 2024 20:58:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
>> 
>> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
>> 
>> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
>> 
>> I will update the CSR once the wording is finalized.
>
> Hi Justin, I went through the `NumberFormat` part. More to follow.

Hi @naotoj , thanks for the detailed review. Working on the suggestions; left a few responses as well.

> src/java.base/share/classes/java/text/NumberFormat.java line 61:
> 
>> 59:  * {@code NumberFormat} is the abstract base class for all number
>> 60:  * formats. This class provides the interface for formatting and parsing
>> 61:  * numbers in a {@link Locale localized} manner. This enables code that can be completely
> 
> Linking "localized" to the `Locale` class seems a bit odd to me. A user who clicks the link may be stranded.

Makes sense, I'll remove the link.

The intent was to give a reader unfamiliar with i18n a little more background. But the next sentence expands on locale in that sense so perhaps that's enough.

> src/java.base/share/classes/java/text/NumberFormat.java line 66:
> 
>> 64:  * digits used. For example, this class could be used within an application to
>> 65:  * produce a number in a currency format according to conventions of the locale
>> 66:  * a user resides in.
> 
> "a user resides in" may not convey any additional value. The user doesn't have to be in that locale.

Fair enough, I don't want to give any misconceptions.

The point was to give a general use case example of an app allowing format(s) tailored to the locale of the user. As I imagine this would be the most common case, rather than getting a locale separate than that of the user. I'll adjust the example.

> src/java.base/share/classes/java/text/NumberFormat.java line 91:
> 
>> 89:  * locale is supported by the installed locale-sensitive service implementation,
>> 90:  * either use {@link #getAvailableLocales()} or ensure a factory method call is enclosed
>> 91:  * within a try block.
> 
> Not sure this is correct. Even if a locale is not "supported" by a locale provider, it won't throw an exception, but fallback to, say ROOT, locale.

Good to know, I didn't realize this was the case. This is inherited from the original wording: `"This will work for the vast majority of locales; just remember to put it in a try block in case you encounter an unusual one."`

I'll replace it with the actual behavior, that Locale.ROOT is a fallback, if the particular locale is not supported.

> src/java.base/share/classes/java/text/NumberFormat.java line 135:
> 
>> 133:  * {@code CompactNumberFormat} depending on the factory method used. For example,
>> 134:  * cast to {@code DecimalFormat} to call {@link DecimalFormat#setGroupingSize(int)}
>> 135:  * to change the desired digits between grouping separators.
> 
> Since there is a possibility that SPIs can return the NumberFormat instances, not sure recommending casting is the right thing. If you want to add this, at least suggest the type check beforehand.

This is also inherited from the original wording: `"If you want even more control over the format or parsing, or want to give your users more control, you can try casting the NumberFormat you get from the factory methods to a DecimalFormat or CompactNumberFormat depending on the factory method used."`

True that an SPI can return some other NumberFormat instance, but I think that we still need to emphasize casting to the JDK DecimalFormat or CompactNumberFormat, otherwise users have no way to access the subclass instance methods, unless they directly construct the subclass which we don't recommend.

I'll adjust the wording here (and include type checking)

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

PR Comment: https://git.openjdk.org/jdk/pull/18731#issuecomment-2052601485
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563246011
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563245987
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563246086
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563246207

From psandoz at openjdk.org  Fri Apr 12 22:02:41 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 12 Apr 2024 22:02:41 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v7]
In-Reply-To: <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
Message-ID: <Dqkmr7y2gIsqgxVW7IAcMwcZAl26LU_0EtT1_GaE8n4=.e86311ff-362c-448a-b15b-e04c878a70d5@github.com>

On Fri, 12 Apr 2024 14:53:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
>> 
>> Below is the performance of `Stream::flatMap` (for reference types):
>> 
>> Before this PR (on my MacBook, aarch64):
>> 
>> Non-short-circuiting:
>> 
>> Benchmark                 (size)   Mode  Cnt        Score       Error  Units
>> FlatMap.par_array             10  thrpt   12   257582,480 ? 31360,242  ops/s
>> FlatMap.par_array            100  thrpt   12    55202,015 ? 14011,668  ops/s
>> FlatMap.par_array           1000  thrpt   12     6546,252 ?  3675,764  ops/s
>> FlatMap.par_doublestream      10  thrpt   12   267423,410 ? 37338,089  ops/s
>> FlatMap.par_doublestream     100  thrpt   12    27140,703 ?  4979,878  ops/s
>> FlatMap.par_doublestream    1000  thrpt   12     2978,178 ?  1890,250  ops/s
>> FlatMap.par_intstream         10  thrpt   12   268194,530 ? 37295,092  ops/s
>> FlatMap.par_intstream        100  thrpt   12    30897,034 ?  5388,245  ops/s
>> FlatMap.par_intstream       1000  thrpt   12     3969,043 ?  2494,641  ops/s
>> FlatMap.par_longstream        10  thrpt   12   279756,861 ? 19519,497  ops/s
>> FlatMap.par_longstream       100  thrpt   12    45733,955 ? 18385,144  ops/s
>> FlatMap.par_longstream      1000  thrpt   12     5115,615 ?  4147,237  ops/s
>> FlatMap.seq_array             10  thrpt   12  2937192,934 ? 58605,583  ops/s
>> FlatMap.seq_array            100  thrpt   12    41859,462 ?   139,021  ops/s
>> FlatMap.seq_array           1000  thrpt   12      442,677 ?     1,041  ops/s
>> FlatMap.seq_doublestream      10  thrpt   12  4972651,093 ? 35997,267  ops/s
>> FlatMap.seq_doublestream     100  thrpt   12    99265,005 ?   193,497  ops/s
>> FlatMap.seq_doublestream    1000  thrpt   12     1037,030 ?     3,254  ops/s
>> FlatMap.seq_intstream         10  thrpt   12  5133751,888 ? 23516,294  ops/s
>> FlatMap.seq_intstream        100  thrpt   12   145166,206 ?   399,263  ops/s
>> FlatMap.seq_intstream       1000  thrpt   12     1565,004 ?     3,207  ops/s
>> FlatMap.seq_longstream        10  thrpt   12  5047029,363 ? 24742,300  ops/s
>> FlatMap.seq_longstream       100  thrpt   12   233225,307 ?  7162,604  ops/s
>> FlatMap.seq_longstream      1000  thrpt   12     2999,926 ?     9,945  ops/s
>> 
>> // Short-circuiting:
>> 
>> Benchmark                   (size)   Mode  Cnt       Score       Error  Units
>> FlatMap.par_iterate_double      10  thrpt   12   46336,834 ?  6803,751  ops/s
>> FlatMap.par_iterate_double     100 ...
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding additional, short-circuit-specific, cases to the FlatMap benchmark

Very nice work.

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18625#pullrequestreview-1998504550

From acobbs at openjdk.org  Fri Apr 12 23:06:02 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 12 Apr 2024 23:06:02 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v2]
In-Reply-To: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
Message-ID: <Ub2vMOM8gHaXDNMzhPQMtsF8GP7lcyku9q0Q8pH2yUc=.417360f6-c12a-4fca-a2ef-202b0b601ad8@github.com>

> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
> 
> There are several issues with this:
> 
> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
> 
> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
> 
> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Field name change and Javadoc wording tweaks.
 - Merge branch 'master' into JDK-8322256
 - Javadoc wording tweaks.
 - Merge branch 'master' into JDK-8322256
 - Clarify exceptions: sometimes ZipException, sometimes EOFException.
 - Merge branch 'master' into JDK-8322256
 - Javadoc wording tweaks.
 - Add "allowConcatenation" and "allowTrailingGarbage" to GZIPInputStream.

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

Changes: https://git.openjdk.org/jdk/pull/18385/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=01
  Stats: 304 lines in 2 files changed: 287 ins; 2 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/18385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385

PR: https://git.openjdk.org/jdk/pull/18385

From acobbs at openjdk.org  Fri Apr 12 23:15:11 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 12 Apr 2024 23:15:11 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v3]
In-Reply-To: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
Message-ID: <7yp6XjDI6Af1-GB_s0FW88372cKIsmgtTd8Jljjr13s=.da7a8dc3-e8cf-4845-8e38-a023c500b6bc@github.com>

> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
> 
> There are several issues with this:
> 
> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
> 
> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
> 
> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.

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

  Simplify code by eliminating an impossible case.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18385/files
  - new: https://git.openjdk.org/jdk/pull/18385/files/48b38049..32ff1abd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=01-02

  Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385

PR: https://git.openjdk.org/jdk/pull/18385

From darcy at openjdk.org  Fri Apr 12 23:58:50 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Apr 2024 23:58:50 GMT
Subject: RFR: 8330196: Make java/lang/invoke/defineHiddenClass/BasicTest
 release agnostic
Message-ID: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>

Straightforward test update so it doesn't have to be trivially updated for each JDK version.

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

Commit messages:
 - JDK-8330196: Make java/lang/invoke/defineHiddenClass/BasicTest release agnostic

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

PR: https://git.openjdk.org/jdk/pull/18769

From liach at openjdk.org  Sat Apr 13 00:43:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 13 Apr 2024 00:43:54 GMT
Subject: RFR: 8330196: Make java/lang/invoke/defineHiddenClass/BasicTest
 release agnostic
In-Reply-To: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
References: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
Message-ID: <Yg-sZzOYn6HrMt4TkKtK_j8lcinfzsP9KNbpnzeROBE=.f6cd311b-2fc1-458c-8705-b0b3b513737f@github.com>

On Fri, 12 Apr 2024 23:55:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Straightforward test update so it doesn't have to be trivially updated for each JDK version.

Thanks for this fix. I recall that I had to add this flag because otherwise compileSources fails when `@enablePreview` is there. If we can drop the preview flag, that would be the best.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/18769#pullrequestreview-1998775310

From forax at openjdk.org  Sat Apr 13 09:15:44 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 13 Apr 2024 09:15:44 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v7]
In-Reply-To: <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
Message-ID: <JKBA0xOD0AgUJH7Er-Ty3lkKl3j-BYXisSWQGWrIAoE=.3ecbe032-5184-43d7-8b56-c5397a410ace@github.com>

On Fri, 12 Apr 2024 14:53:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
>> 
>> Below is the performance of `Stream::flatMap` (for reference types):
>> 
>> Before this PR (on my MacBook, aarch64):
>> 
>> Non-short-circuiting:
>> 
>> Benchmark                 (size)   Mode  Cnt        Score       Error  Units
>> FlatMap.par_array             10  thrpt   12   257582,480 ? 31360,242  ops/s
>> FlatMap.par_array            100  thrpt   12    55202,015 ? 14011,668  ops/s
>> FlatMap.par_array           1000  thrpt   12     6546,252 ?  3675,764  ops/s
>> FlatMap.par_doublestream      10  thrpt   12   267423,410 ? 37338,089  ops/s
>> FlatMap.par_doublestream     100  thrpt   12    27140,703 ?  4979,878  ops/s
>> FlatMap.par_doublestream    1000  thrpt   12     2978,178 ?  1890,250  ops/s
>> FlatMap.par_intstream         10  thrpt   12   268194,530 ? 37295,092  ops/s
>> FlatMap.par_intstream        100  thrpt   12    30897,034 ?  5388,245  ops/s
>> FlatMap.par_intstream       1000  thrpt   12     3969,043 ?  2494,641  ops/s
>> FlatMap.par_longstream        10  thrpt   12   279756,861 ? 19519,497  ops/s
>> FlatMap.par_longstream       100  thrpt   12    45733,955 ? 18385,144  ops/s
>> FlatMap.par_longstream      1000  thrpt   12     5115,615 ?  4147,237  ops/s
>> FlatMap.seq_array             10  thrpt   12  2937192,934 ? 58605,583  ops/s
>> FlatMap.seq_array            100  thrpt   12    41859,462 ?   139,021  ops/s
>> FlatMap.seq_array           1000  thrpt   12      442,677 ?     1,041  ops/s
>> FlatMap.seq_doublestream      10  thrpt   12  4972651,093 ? 35997,267  ops/s
>> FlatMap.seq_doublestream     100  thrpt   12    99265,005 ?   193,497  ops/s
>> FlatMap.seq_doublestream    1000  thrpt   12     1037,030 ?     3,254  ops/s
>> FlatMap.seq_intstream         10  thrpt   12  5133751,888 ? 23516,294  ops/s
>> FlatMap.seq_intstream        100  thrpt   12   145166,206 ?   399,263  ops/s
>> FlatMap.seq_intstream       1000  thrpt   12     1565,004 ?     3,207  ops/s
>> FlatMap.seq_longstream        10  thrpt   12  5047029,363 ? 24742,300  ops/s
>> FlatMap.seq_longstream       100  thrpt   12   233225,307 ?  7162,604  ops/s
>> FlatMap.seq_longstream      1000  thrpt   12     2999,926 ?     9,945  ops/s
>> 
>> // Short-circuiting:
>> 
>> Benchmark                   (size)   Mode  Cnt       Score       Error  Units
>> FlatMap.par_iterate_double      10  thrpt   12   46336,834 ?  6803,751  ops/s
>> FlatMap.par_iterate_double     100 ...
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding additional, short-circuit-specific, cases to the FlatMap benchmark

src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 439:

> 437:      * Returns whether any of the stages in the (entire) pipeline is short-circuiting
> 438:      * or not.
> 439:      * @return {@code true} if any stage in this pipeline is stateful,

stateful -> short-circuiting

src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 442:

> 440:      *         {@code false} if not.
> 441:      */
> 442:     protected final boolean isShortCircuitingPipeline() {

protected can be replaced by package-private

src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 448:

> 446:              u = u.nextStage) {
> 447:         }
> 448:         return result;

can be written in a simpler way

for(var stage = sourceStage.nextStage; stage != null; stage = stage.nextStage) {
  if (StreamOpFlag.SHORT_CIRCUIT.isKnown(u.combinedFlags)) {
    return true;
  }
  return false;
}

no local variable and no SSA phi

src/java.base/share/classes/java/util/stream/DoublePipeline.java line 267:

> 265:             @Override
> 266:             Sink<Double> opWrapSink(int flags, Sink<Double> sink) {
> 267:                 final DoubleConsumer fastPath =

this `final` is unecessary, inconsistent with the style of all other fiels of this package.

src/java.base/share/classes/java/util/stream/DoublePipeline.java line 281:

> 279:                     @Override
> 280:                     public void accept(double e) {
> 281:                         try (final var result = mapper.apply(e)) {

`final` is unecessary and i will keep the type instead of `var` because this code quite complex and eliding the type does not help (and also mixing var and not var in the same method is not recommanded cf Stuart guide on where using 'var')

src/java.base/share/classes/java/util/stream/IntPipeline.java line 300:

> 298:             @Override
> 299:             Sink<Integer> opWrapSink(int flags, Sink<Integer> sink) {
> 300:                 final IntConsumer fastPath =

same as above

src/java.base/share/classes/java/util/stream/LongPipeline.java line 283:

> 281:             @Override
> 282:             Sink<Long> opWrapSink(int flags, Sink<Long> sink) {
> 283:                 final LongConsumer fastPath =

same as above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563885750
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563886287
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563887433
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563888203
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563889383
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563889757
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563889835

From forax at openjdk.org  Sat Apr 13 09:19:43 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 13 Apr 2024 09:19:43 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v7]
In-Reply-To: <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
Message-ID: <-ghdxfGJIQzpqRy7XJlyON_Pb971_EOb9UfMgubugPo=.01fbb86e-0dd9-4ae6-8b94-d3c621c63cbb@github.com>

On Fri, 12 Apr 2024 14:53:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
>> 
>> Below is the performance of `Stream::flatMap` (for reference types):
>> 
>> Before this PR (on my MacBook, aarch64):
>> 
>> Non-short-circuiting:
>> 
>> Benchmark                 (size)   Mode  Cnt        Score       Error  Units
>> FlatMap.par_array             10  thrpt   12   257582,480 ? 31360,242  ops/s
>> FlatMap.par_array            100  thrpt   12    55202,015 ? 14011,668  ops/s
>> FlatMap.par_array           1000  thrpt   12     6546,252 ?  3675,764  ops/s
>> FlatMap.par_doublestream      10  thrpt   12   267423,410 ? 37338,089  ops/s
>> FlatMap.par_doublestream     100  thrpt   12    27140,703 ?  4979,878  ops/s
>> FlatMap.par_doublestream    1000  thrpt   12     2978,178 ?  1890,250  ops/s
>> FlatMap.par_intstream         10  thrpt   12   268194,530 ? 37295,092  ops/s
>> FlatMap.par_intstream        100  thrpt   12    30897,034 ?  5388,245  ops/s
>> FlatMap.par_intstream       1000  thrpt   12     3969,043 ?  2494,641  ops/s
>> FlatMap.par_longstream        10  thrpt   12   279756,861 ? 19519,497  ops/s
>> FlatMap.par_longstream       100  thrpt   12    45733,955 ? 18385,144  ops/s
>> FlatMap.par_longstream      1000  thrpt   12     5115,615 ?  4147,237  ops/s
>> FlatMap.seq_array             10  thrpt   12  2937192,934 ? 58605,583  ops/s
>> FlatMap.seq_array            100  thrpt   12    41859,462 ?   139,021  ops/s
>> FlatMap.seq_array           1000  thrpt   12      442,677 ?     1,041  ops/s
>> FlatMap.seq_doublestream      10  thrpt   12  4972651,093 ? 35997,267  ops/s
>> FlatMap.seq_doublestream     100  thrpt   12    99265,005 ?   193,497  ops/s
>> FlatMap.seq_doublestream    1000  thrpt   12     1037,030 ?     3,254  ops/s
>> FlatMap.seq_intstream         10  thrpt   12  5133751,888 ? 23516,294  ops/s
>> FlatMap.seq_intstream        100  thrpt   12   145166,206 ?   399,263  ops/s
>> FlatMap.seq_intstream       1000  thrpt   12     1565,004 ?     3,207  ops/s
>> FlatMap.seq_longstream        10  thrpt   12  5047029,363 ? 24742,300  ops/s
>> FlatMap.seq_longstream       100  thrpt   12   233225,307 ?  7162,604  ops/s
>> FlatMap.seq_longstream      1000  thrpt   12     2999,926 ?     9,945  ops/s
>> 
>> // Short-circuiting:
>> 
>> Benchmark                   (size)   Mode  Cnt       Score       Error  Units
>> FlatMap.par_iterate_double      10  thrpt   12   46336,834 ?  6803,751  ops/s
>> FlatMap.par_iterate_double     100 ...
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding additional, short-circuit-specific, cases to the FlatMap benchmark

src/java.base/share/classes/java/util/stream/ReferencePipeline.java line 280:

> 278:             @Override
> 279:             Sink<P_OUT> opWrapSink(int flags, Sink<R> sink) {
> 280:                 final boolean shorts = isShortCircuitingPipeline();

Same as above (here having the two final aligned but having different meanings require some mental gymnastic)

src/java.base/share/classes/java/util/stream/ReferencePipeline.java line 326:

> 324:             @Override
> 325:             Sink<P_OUT> opWrapSink(int flags, Sink<Integer> sink) {
> 326:                 final IntConsumer fastPath =

same as above

src/java.base/share/classes/java/util/stream/ReferencePipeline.java line 377:

> 375:             @Override
> 376:             Sink<P_OUT> opWrapSink(int flags, Sink<Double> sink) {
> 377:                 final DoubleConsumer fastPath =

Same as above

src/java.base/share/classes/java/util/stream/ReferencePipeline.java line 429:

> 427:             @Override
> 428:             Sink<P_OUT> opWrapSink(int flags, Sink<Long> sink) {
> 429:                 final LongConsumer fastPath =

Same as above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563891484
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563891603
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563891736
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1563891826

From forax at openjdk.org  Sat Apr 13 09:22:42 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 13 Apr 2024 09:22:42 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v7]
In-Reply-To: <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
Message-ID: <7BjJpuC6zj-0a1qi01Qh9yLVfIcrAPwvUmj3dpT7sOk=.2680df98-721c-41df-b278-d70411fc9a0e@github.com>

On Fri, 12 Apr 2024 14:53:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
>> 
>> Below is the performance of `Stream::flatMap` (for reference types):
>> 
>> Before this PR (on my MacBook, aarch64):
>> 
>> Non-short-circuiting:
>> 
>> Benchmark                 (size)   Mode  Cnt        Score       Error  Units
>> FlatMap.par_array             10  thrpt   12   257582,480 ? 31360,242  ops/s
>> FlatMap.par_array            100  thrpt   12    55202,015 ? 14011,668  ops/s
>> FlatMap.par_array           1000  thrpt   12     6546,252 ?  3675,764  ops/s
>> FlatMap.par_doublestream      10  thrpt   12   267423,410 ? 37338,089  ops/s
>> FlatMap.par_doublestream     100  thrpt   12    27140,703 ?  4979,878  ops/s
>> FlatMap.par_doublestream    1000  thrpt   12     2978,178 ?  1890,250  ops/s
>> FlatMap.par_intstream         10  thrpt   12   268194,530 ? 37295,092  ops/s
>> FlatMap.par_intstream        100  thrpt   12    30897,034 ?  5388,245  ops/s
>> FlatMap.par_intstream       1000  thrpt   12     3969,043 ?  2494,641  ops/s
>> FlatMap.par_longstream        10  thrpt   12   279756,861 ? 19519,497  ops/s
>> FlatMap.par_longstream       100  thrpt   12    45733,955 ? 18385,144  ops/s
>> FlatMap.par_longstream      1000  thrpt   12     5115,615 ?  4147,237  ops/s
>> FlatMap.seq_array             10  thrpt   12  2937192,934 ? 58605,583  ops/s
>> FlatMap.seq_array            100  thrpt   12    41859,462 ?   139,021  ops/s
>> FlatMap.seq_array           1000  thrpt   12      442,677 ?     1,041  ops/s
>> FlatMap.seq_doublestream      10  thrpt   12  4972651,093 ? 35997,267  ops/s
>> FlatMap.seq_doublestream     100  thrpt   12    99265,005 ?   193,497  ops/s
>> FlatMap.seq_doublestream    1000  thrpt   12     1037,030 ?     3,254  ops/s
>> FlatMap.seq_intstream         10  thrpt   12  5133751,888 ? 23516,294  ops/s
>> FlatMap.seq_intstream        100  thrpt   12   145166,206 ?   399,263  ops/s
>> FlatMap.seq_intstream       1000  thrpt   12     1565,004 ?     3,207  ops/s
>> FlatMap.seq_longstream        10  thrpt   12  5047029,363 ? 24742,300  ops/s
>> FlatMap.seq_longstream       100  thrpt   12   233225,307 ?  7162,604  ops/s
>> FlatMap.seq_longstream      1000  thrpt   12     2999,926 ?     9,945  ops/s
>> 
>> // Short-circuiting:
>> 
>> Benchmark                   (size)   Mode  Cnt       Score       Error  Units
>> FlatMap.par_iterate_double      10  thrpt   12   46336,834 ?  6803,751  ops/s
>> FlatMap.par_iterate_double     100 ...
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding additional, short-circuit-specific, cases to the FlatMap benchmark

Hello, i will not pretend I fully understand the code, but i think it's important to keep a constistent code style.
(and no I do not want to start an holy war about the code style, I just think we should keep it consistent)

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

PR Comment: https://git.openjdk.org/jdk/pull/18625#issuecomment-2053586457

From vklang at openjdk.org  Sat Apr 13 14:09:43 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 13 Apr 2024 14:09:43 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v7]
In-Reply-To: <JKBA0xOD0AgUJH7Er-Ty3lkKl3j-BYXisSWQGWrIAoE=.3ecbe032-5184-43d7-8b56-c5397a410ace@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
 <JKBA0xOD0AgUJH7Er-Ty3lkKl3j-BYXisSWQGWrIAoE=.3ecbe032-5184-43d7-8b56-c5397a410ace@github.com>
Message-ID: <3gbdP6fNS_35sbRhcyb4EDfIAUXcbeJ0KU62Hyl0lx8=.7d5713e0-1b0e-40a9-803f-59dcab57bf91@github.com>

On Sat, 13 Apr 2024 09:04:36 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding additional, short-circuit-specific, cases to the FlatMap benchmark
>
> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 442:
> 
>> 440:      *         {@code false} if not.
>> 441:      */
>> 442:     protected final boolean isShortCircuitingPipeline() {
> 
> protected can be replaced by package-private

Since `hasAnyStateful()` is protected, I think this too should be, for consistency.

> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 448:
> 
>> 446:              u = u.nextStage) {
>> 447:         }
>> 448:         return result;
> 
> can be written in a simpler way
> 
> for(var stage = sourceStage.nextStage; stage != null; stage = stage.nextStage) {
>   if (StreamOpFlag.SHORT_CIRCUIT.isKnown(u.combinedFlags)) {
>     return true;
>   }
>   return false;
> }
> 
> no local variable and no SSA phi

In general, I don't like multiple exit-paths from methods, but I agree that in this case it increases readability.

> src/java.base/share/classes/java/util/stream/DoublePipeline.java line 267:
> 
>> 265:             @Override
>> 266:             Sink<Double> opWrapSink(int flags, Sink<Double> sink) {
>> 267:                 final DoubleConsumer fastPath =
> 
> this `final` is unecessary, inconsistent with the style of all other fiels of this package.

I think it is good practice to `final` anything which will be closed over. (Effectively Final is not as clear as Explicitly Final)

> src/java.base/share/classes/java/util/stream/DoublePipeline.java line 281:
> 
>> 279:                     @Override
>> 280:                     public void accept(double e) {
>> 281:                         try (final var result = mapper.apply(e)) {
> 
> `final` is unecessary and i will keep the type instead of `var` because this code quite complex and eliding the type does not help (and also mixing var and not var in the same method is not recommanded cf Stuart guide on where using 'var')

There's only a single var in this method, and no other variables. But I agree on keeping the type explicit, since the definition of the `mapper` is far away from the application thereof.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1564050082
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1564051078
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1564051678
PR Review Comment: https://git.openjdk.org/jdk/pull/18625#discussion_r1564052465

From vklang at openjdk.org  Sat Apr 13 14:27:12 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 13 Apr 2024 14:27:12 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v8]
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <JHRGHRtl4aDBeWbQAqHbBBt9FNPBhbRf_fHpnM57-Gc=.449c730b-6270-4fb4-8988-337f1069604d@github.com>

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR (on my MacBook, aarch64):
> 
> Non-short-circuiting:
> 
> Benchmark                 (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array             10  thrpt   12   257582,480 ? 31360,242  ops/s
> FlatMap.par_array            100  thrpt   12    55202,015 ? 14011,668  ops/s
> FlatMap.par_array           1000  thrpt   12     6546,252 ?  3675,764  ops/s
> FlatMap.par_doublestream      10  thrpt   12   267423,410 ? 37338,089  ops/s
> FlatMap.par_doublestream     100  thrpt   12    27140,703 ?  4979,878  ops/s
> FlatMap.par_doublestream    1000  thrpt   12     2978,178 ?  1890,250  ops/s
> FlatMap.par_intstream         10  thrpt   12   268194,530 ? 37295,092  ops/s
> FlatMap.par_intstream        100  thrpt   12    30897,034 ?  5388,245  ops/s
> FlatMap.par_intstream       1000  thrpt   12     3969,043 ?  2494,641  ops/s
> FlatMap.par_longstream        10  thrpt   12   279756,861 ? 19519,497  ops/s
> FlatMap.par_longstream       100  thrpt   12    45733,955 ? 18385,144  ops/s
> FlatMap.par_longstream      1000  thrpt   12     5115,615 ?  4147,237  ops/s
> FlatMap.seq_array             10  thrpt   12  2937192,934 ? 58605,583  ops/s
> FlatMap.seq_array            100  thrpt   12    41859,462 ?   139,021  ops/s
> FlatMap.seq_array           1000  thrpt   12      442,677 ?     1,041  ops/s
> FlatMap.seq_doublestream      10  thrpt   12  4972651,093 ? 35997,267  ops/s
> FlatMap.seq_doublestream     100  thrpt   12    99265,005 ?   193,497  ops/s
> FlatMap.seq_doublestream    1000  thrpt   12     1037,030 ?     3,254  ops/s
> FlatMap.seq_intstream         10  thrpt   12  5133751,888 ? 23516,294  ops/s
> FlatMap.seq_intstream        100  thrpt   12   145166,206 ?   399,263  ops/s
> FlatMap.seq_intstream       1000  thrpt   12     1565,004 ?     3,207  ops/s
> FlatMap.seq_longstream        10  thrpt   12  5047029,363 ? 24742,300  ops/s
> FlatMap.seq_longstream       100  thrpt   12   233225,307 ?  7162,604  ops/s
> FlatMap.seq_longstream      1000  thrpt   12     2999,926 ?     9,945  ops/s
> 
> // Short-circuiting:
> 
> Benchmark                   (size)   Mode  Cnt       Score       Error  Units
> FlatMap.par_iterate_double      10  thrpt   12   46336,834 ?  6803,751  ops/s
> FlatMap.par_iterate_double     100  thrpt   12   15365,884 ?  2750,656  ops/s
> FlatMap.par_iterate_double    1000 ...

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

  Addressing review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18625/files
  - new: https://git.openjdk.org/jdk/pull/18625/files/7683a0f3..07e2818b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18625&range=06-07

  Stats: 32 lines in 5 files changed: 0 ins; 1 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/18625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18625/head:pull/18625

PR: https://git.openjdk.org/jdk/pull/18625

From vklang at openjdk.org  Sat Apr 13 14:27:12 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 13 Apr 2024 14:27:12 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v7]
In-Reply-To: <7BjJpuC6zj-0a1qi01Qh9yLVfIcrAPwvUmj3dpT7sOk=.2680df98-721c-41df-b278-d70411fc9a0e@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <BcL9r2vKOZQgyz4bNZrxOYqynAcLwp3ezHiRy8cjtQQ=.6d934e08-05f4-4f35-ba81-e84755dd13a6@github.com>
 <7BjJpuC6zj-0a1qi01Qh9yLVfIcrAPwvUmj3dpT7sOk=.2680df98-721c-41df-b278-d70411fc9a0e@github.com>
Message-ID: <RDOFdmXTllzTqblOU1v7_Kdk3wxZss-MzsNSepmRfv4=.810780d8-732b-4642-ad53-1d23ad217f21@github.com>

On Sat, 13 Apr 2024 09:20:17 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding additional, short-circuit-specific, cases to the FlatMap benchmark
>
> Hello, i will not pretend I fully understand the code, but i think it's important to keep a constistent code style.
> (and no I do not want to start an holy war about the code style, I just think we should keep it consistent)

Just pushed another commit addressing feedback from @forax. (FYI @PaulSandoz & @AlanBateman)

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

PR Comment: https://git.openjdk.org/jdk/pull/18625#issuecomment-2053661059

From duke at openjdk.org  Sat Apr 13 17:57:44 2024
From: duke at openjdk.org (Brett Okken)
Date: Sat, 13 Apr 2024 17:57:44 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <pQIn1JZl2AUsIWkksGjJG7SDHfDVYYOE_TcvWBJx6x8=.556ffd4f-053c-490c-a046-0e125083923e@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <iB3-M1Zqko_5S8dh67o0tGxQYcd0kbDCqroGFmK0GAA=.d59284b1-c058-42df-abe9-83c016939f44@github.com>
 <pQIn1JZl2AUsIWkksGjJG7SDHfDVYYOE_TcvWBJx6x8=.556ffd4f-053c-490c-a046-0e125083923e@github.com>
Message-ID: <mWu8_L884G_BSe-S8svNeUqy-x_ha5BsPRqqGnfZ59I=.99e0cab6-5d82-4a9f-81f9-b7cf2415acf3@github.com>

On Fri, 12 Apr 2024 10:19:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1430:
>> 
>>> 1428:                     cb.new_(STRING_BUILDER);
>>> 1429:                     cb.dup();
>>> 1430:                     cb.invokespecial(STRING_BUILDER, "<init>", MethodTypeDesc.ofDescriptor("()V"));
>> 
>> Would there be value in initializing to a larger capacity? Given the number of append calls, seems the default cap of 16 is unlikely to be sufficient.
>
> Possibly. I tried a few simple variants that initialized the `StringBuilder` capacity at various guesses, such as sum of constant sizes + some factor based on args, but across a diverse set of micros that gives both some wins and some regressions. Getting the estimation just right is pretty tricky, especially when size of the arguments are arbitrary (like for any String/Object arg).

What are the scenarios which had regressions? 
Given the conservative growth for StringBuilder, it surprises me a bit that any scenario would regress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1564165946

From darcy at openjdk.org  Sat Apr 13 19:18:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 13 Apr 2024 19:18:40 GMT
Subject: RFR: 8330196: Make java/lang/invoke/defineHiddenClass/BasicTest
 release agnostic
In-Reply-To: <Yg-sZzOYn6HrMt4TkKtK_j8lcinfzsP9KNbpnzeROBE=.f6cd311b-2fc1-458c-8705-b0b3b513737f@github.com>
References: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
 <Yg-sZzOYn6HrMt4TkKtK_j8lcinfzsP9KNbpnzeROBE=.f6cd311b-2fc1-458c-8705-b0b3b513737f@github.com>
Message-ID: <1cJf7P5Zf6H1wXyI6Nb-fU99osGpcGQADFQh8902RXM=.81f98ad8-0980-4629-8b79-3ef323eb976b@github.com>

On Sat, 13 Apr 2024 00:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks for this fix. I recall that I had to add this flag because otherwise compileSources fails when `@enablePreview` is there. If we can drop the preview flag, that would be the best.

Thanks; I did a quick experiment and the test still fails if the compileSources() call does not contain the --enable-preview arguments.

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

PR Comment: https://git.openjdk.org/jdk/pull/18769#issuecomment-2053736138

From mchung at openjdk.org  Sat Apr 13 23:57:40 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 13 Apr 2024 23:57:40 GMT
Subject: RFR: 8330196: Make java/lang/invoke/defineHiddenClass/BasicTest
 release agnostic
In-Reply-To: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
References: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
Message-ID: <FvFUNShDuDSbBn6-GAvDu4vTLfnn1RcazpPwskRGwKg=.cb6ccfcf-5b26-448a-99af-2b7b76e34060@github.com>

On Fri, 12 Apr 2024 23:55:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Straightforward test update so it doesn't have to be trivially updated for each JDK version.

LGTM.  Thanks for fixing this.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18769#pullrequestreview-1999383137

From alanb at openjdk.org  Sun Apr 14 06:54:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 Apr 2024 06:54:49 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static
In-Reply-To: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
Message-ID: <SKpnHsqXtsr18Hf0Q34BIiOXDBdEPklutjJVVBoBwHA=.4e7bfe69-87d7-45ac-98d8-29a977714b3f@github.com>

On Fri, 12 Apr 2024 10:16:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class MainClass {
>     public MainClass() {
>         System.out.println("Constructor called!");
>     }
>     public static void main() {
>         System.out.println("main called!");
>     }
> }
> 
> and compile and run it, with preview enabled, like:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> Constructor called!
> main called!
> 
> 
> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
> 
> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
> 
> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
> 
> There is also a relatively closely related problem: what happens when the constructor throws an exception?
> 
> public class MainClass {
>     public MainClass() {
>         if (true) throw new RuntimeException();
>     }
>     public void main() {
>         System.out.println("main called!");
>     }
> }
> 
> 
> when compiled an run, this produces no output whatsoever:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> $
> 
> 
> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
> 
> $ java --enable-preview -classpath /tmp/ MainClass 
> Exception in thread "main" java.lang.RuntimeException
>         at MainClass.<init>(MainClass.java:3)
> 
> 
> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.

src/java.base/share/native/libjli/java.c line 434:

> 432:     CHECK_EXCEPTION_FAIL();
> 433:     jobject mainObject = (*env)->NewObject(env, mainClass, constructor);
> 434:     CHECK_EXCEPTION_NULL_PASS(mainObject);

There will be a pending exception if NewObject returns NULL. I think it would be a lot easier to read if this were to just check if mainObject is NULL and return 1. Same comment for the other usage in invokeInstanceMainWithoutArgs. That would avoid CHECK_EXCEPTION_NULL_PASS which is very confusing to see at the use-sites.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18753#discussion_r1564512331

From jkuhn at openjdk.org  Sun Apr 14 13:29:44 2024
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Sun, 14 Apr 2024 13:29:44 GMT
Subject: RFR: 8330196: Make java/lang/invoke/defineHiddenClass/BasicTest
 release agnostic
In-Reply-To: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
References: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
Message-ID: <LhTtPqTl-7PVV_KxhMJ1vjkd9uIBC1lRFriUaIEKxoc=.bdd6d68a-3420-49c3-b49e-9e14096a5305@github.com>

On Fri, 12 Apr 2024 23:55:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Straightforward test update so it doesn't have to be trivially updated for each JDK version.

Marked as reviewed by jkuhn (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/18769#pullrequestreview-1999661348

From redestad at openjdk.org  Sun Apr 14 14:36:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 14 Apr 2024 14:36:07 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v3]
In-Reply-To: <mWu8_L884G_BSe-S8svNeUqy-x_ha5BsPRqqGnfZ59I=.99e0cab6-5d82-4a9f-81f9-b7cf2415acf3@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <iB3-M1Zqko_5S8dh67o0tGxQYcd0kbDCqroGFmK0GAA=.d59284b1-c058-42df-abe9-83c016939f44@github.com>
 <pQIn1JZl2AUsIWkksGjJG7SDHfDVYYOE_TcvWBJx6x8=.556ffd4f-053c-490c-a046-0e125083923e@github.com>
 <mWu8_L884G_BSe-S8svNeUqy-x_ha5BsPRqqGnfZ59I=.99e0cab6-5d82-4a9f-81f9-b7cf2415acf3@github.com>
Message-ID: <0UsnNhF9Vebfzbp6bCmhNspgiGB0cXyYtB888ODwR_o=.c7eee3ee-c51e-40f2-befe-99b5ad7365c8@github.com>

On Sat, 13 Apr 2024 17:54:54 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Possibly. I tried a few simple variants that initialized the `StringBuilder` capacity at various guesses, such as sum of constant sizes + some factor based on args, but across a diverse set of micros that gives both some wins and some regressions. Getting the estimation just right is pretty tricky, especially when size of the arguments are arbitrary (like for any String/Object arg).
>
> What are the scenarios which had regressions? 
> Given the conservative growth for StringBuilder, it surprises me a bit that any scenario would regress.

I took a second look and it turns out that there were neither regressions nor improvements in my test, only a few false positives: For C2 the SB chain is recognized by the (fragile) C2 OptimizeStringConcat pass and transformed into a shape where the initial size in java bytecode - if any - is ignored.

With C1 having an initial size can have a significant effect. One way to provoke a regression there is to have a huge constant suffix while underestimating the size of the operands, which can lead to excessive allocation:


Name                             Cnt     Base    Error       Test    Error   Unit  Change
StringConcat.concat23StringConst   5  385,268 ?  5,238    341,251 ?  2,606  ns/op   1,13x (p = 0,000*)
  :gc.alloc.rate                     6039,095 ? 82,309  12764,169 ? 97,146 MB/sec   2,11x (p = 0,000*)
  :gc.alloc.rate.norm                2440,003 ?  0,000   4568,002 ?  0,000   B/op   1,87x (p = 0,000*)


Still a bit better on throughput from less actual copying.

*If* the `StringBuilder` is sized sufficiently (constants + args * N) things look much better, of course: 

-XX:TieredStopAtLevel=1
Name                             Cnt     Base    Error      Test    Error   Unit  Change
StringConcat.concat23StringConst   5  385,268 ?  5,238   259,628 ?  2,515  ns/op   1,48x (p = 0,000*)
  :gc.alloc.rate                     6039,095 ? 82,309  8902,803 ? 86,563 MB/sec   1,47x (p = 0,000*)
  :gc.alloc.rate.norm                2440,003 ?  0,000  2424,002 ?  0,000   B/op   0,99x (p = 0,000*)


For most cases having a size based on the sum of the constants plus some small factor per argument seem to be a decent heuristic - for C1. Since this adds just one bytecode to the generated method I guess it wouldn't hurt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1564753612

From redestad at openjdk.org  Sun Apr 14 14:36:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 14 Apr 2024 14:36:07 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v3]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <iGCF5PfmwhVutnMRi7yv7Q8NBzZJuDv-_eQEjZ5hJ7U=.30bc0e71-53dd-4d5f-8593-9ac4caa944d3@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

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

  Pre-size stringbuilders based on constant size and a small argument factor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18690/files
  - new: https://git.openjdk.org/jdk/pull/18690/files/1c3d354c..796d968b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=01-02

  Stats: 44 lines in 2 files changed: 42 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From davidalayachew at gmail.com  Mon Apr 15 03:56:38 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 14 Apr 2024 23:56:38 -0400
Subject: Could we add a lint warning for when the type parameter name
 overloads an existing type name?
In-Reply-To: <CAA9v-_OfFwCHMMufOFLzr5bsJMbDWN5Y877si=jhvHLeSpR6bg@mail.gmail.com>
References: <CAA9v-_OfFwCHMMufOFLzr5bsJMbDWN5Y877si=jhvHLeSpR6bg@mail.gmail.com>
Message-ID: <CAA9v-_ORrBYiTzvHt4fkPOojCeksysWiu5+oi9dg-djpP085gQ@mail.gmail.com>

Whoops, I meant core-libs, not client libs. I always mix up the 2.

Copy pasting below, so that people don't have to read the butchered version
that pipermail spits out.

Hello Amber Dev Team, Client Lib Team, and Compiler Dev Team,

In the vein of smoothing the on-ramp for beginners, one of the biggest pain
points I have found when tutoring beginners is when they start to learn
generics, and then do something like this.
import java.util.*;

public class abc
{

    public static void main(final String[] args)
    {

        final Map<String, Integer> cache = new HashMap<>();

        final int result = updateCache(cache, "abc", 123);

        System.out.println(result);

    }

    public static <String, Integer> Integer updateCache(final Map<String,
Integer> cache, final String key, final int value)
    {

        return cache.put(key, Integer.valueOf(value));

    }

}

$ javac abc.java
abc.java:21: error: cannot find symbol
                return cache.put(key, Integer.valueOf(value));
                                             ^
  symbol:   method valueOf(int)
  location: class Object
1 error

This type of error is the worst because it sends them on the wildest goose
chase. They start coming up with the most eldritch deductions as to what
could possibly be wrong, and they start actively unlearning stuff that they
know to be true. When I finally show them what is wrong, it's already too
late because (1) they start doubting the foundations because the "clearly
correct" solution doesn't work for a non-obvious reason, and (2) they
usually picked up some incorrect assumptions along the way that neither of
us have realized yet.

And the worst part is that, if you removed the "Integer.valueOf", and then
changed the third parameter to be final Integer value instead of final int
value, then the code compiles and works as expected. So, the student can
actually go pretty far before code starts breaking. That is the absolute
worst because they start turning this style of coding into a habit and then
when it finally blows up, all of their progress has to be undone. They feel
defeated, they hate the feature, they lose motivation, and now I have to
work triple time to rebuild all of that. It's a terrible time for everyone
involved.

Could we add a lint option that turns this into a warning? Basically says,
if you put an alias for a parameterized type that also happens to be an
exact match for an already imported class, throw a warning upon compile?
Then, this issue can be caught at compile time the second that they
introduce it. When they ask me about the warning, I can immediately explain
the problem, and this entire fiasco is avoided.

Finally, I also type up this email because this can be kind of easy to miss
when you are quickly cycling back and forth between students, trying to
make sure everyone is good. I don't have that many now, but back when it
was double digits, I distinctly remember falling into this pothole multiple
times.

Any thoughts on this feature?

Thank you for your time and consideration!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240414/093d41ca/attachment-0001.htm>

From jlahoda at openjdk.org  Mon Apr 15 07:36:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 15 Apr 2024 07:36:05 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v2]
In-Reply-To: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
Message-ID: <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>

> Consider code like:
> 
> public class MainClass {
>     public MainClass() {
>         System.out.println("Constructor called!");
>     }
>     public static void main() {
>         System.out.println("main called!");
>     }
> }
> 
> and compile and run it, with preview enabled, like:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> Constructor called!
> main called!
> 
> 
> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
> 
> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
> 
> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
> 
> There is also a relatively closely related problem: what happens when the constructor throws an exception?
> 
> public class MainClass {
>     public MainClass() {
>         if (true) throw new RuntimeException();
>     }
>     public void main() {
>         System.out.println("main called!");
>     }
> }
> 
> 
> when compiled an run, this produces no output whatsoever:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> $
> 
> 
> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
> 
> $ java --enable-preview -classpath /tmp/ MainClass 
> Exception in thread "main" java.lang.RuntimeException
>         at MainClass.<init>(MainClass.java:3)
> 
> 
> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.

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

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18753/files
  - new: https://git.openjdk.org/jdk/pull/18753/files/3ad521ae..2022aa5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18753&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18753&range=00-01

  Stats: 22 lines in 1 file changed: 10 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18753/head:pull/18753

PR: https://git.openjdk.org/jdk/pull/18753

From jlahoda at openjdk.org  Mon Apr 15 07:36:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 15 Apr 2024 07:36:05 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v2]
In-Reply-To: <SKpnHsqXtsr18Hf0Q34BIiOXDBdEPklutjJVVBoBwHA=.4e7bfe69-87d7-45ac-98d8-29a977714b3f@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <SKpnHsqXtsr18Hf0Q34BIiOXDBdEPklutjJVVBoBwHA=.4e7bfe69-87d7-45ac-98d8-29a977714b3f@github.com>
Message-ID: <vHqJjEQQIp7NmNeMfM_386yYdhJLPlnNnDXB2E8Z_SE=.3a1b4e81-93f4-477a-a5c7-c5e805852208@github.com>

On Sun, 14 Apr 2024 06:51:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/java.base/share/native/libjli/java.c line 434:
> 
>> 432:     CHECK_EXCEPTION_FAIL();
>> 433:     jobject mainObject = (*env)->NewObject(env, mainClass, constructor);
>> 434:     CHECK_EXCEPTION_NULL_PASS(mainObject);
> 
> There will be a pending exception if NewObject returns NULL. I think it would be a lot easier to read if this were to just check if mainObject is NULL and return 1. Same comment for the other usage in invokeInstanceMainWithoutArgs. That would avoid CHECK_EXCEPTION_NULL_PASS which is very confusing to see at the use-sites.

Thanks! I've done that here:
https://github.com/openjdk/jdk/pull/18753/commits/2022aa5a0d21f930d9b49d1bb0b91ecf7e60ead2

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18753#discussion_r1565302792

From pminborg at openjdk.org  Mon Apr 15 07:55:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 07:55:04 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints
Message-ID: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>

This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).

Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

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

Commit messages:
 - Fix imports and copyright
 - Update maxByteAlignment docs
 - Improve doc and tests
 - Add a MS::maxByteAlignment method

Changes: https://git.openjdk.org/jdk/pull/18779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329997
  Stats: 134 lines in 4 files changed: 128 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18779/head:pull/18779

PR: https://git.openjdk.org/jdk/pull/18779

From pminborg at openjdk.org  Mon Apr 15 08:25:50 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 08:25:50 GMT
Subject: RFR: 8330176: Typo in Linker javadoc
Message-ID: <iy3szzjtMDK-hPhur9p-aVAvKER63YZtLWasAXOGGmU=.be2acf69-8f7b-4376-acfc-ef889c05509e@github.com>

This PR fixes a typo in the `Linker` documentation.

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

Commit messages:
 - Fix typo in Linker javadoc

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

PR: https://git.openjdk.org/jdk/pull/18781

From sroy at openjdk.org  Mon Apr 15 08:33:48 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 08:33:48 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <2ATAMorSuL_VV0fo_Fn-9an4D0D-fksyD723uiqZxzc=.98cd220b-8267-4290-988d-54741401e047@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
 <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>
 <2ATAMorSuL_VV0fo_Fn-9an4D0D-fksyD723uiqZxzc=.98cd220b-8267-4290-988d-54741401e047@github.com>
Message-ID: <i9viEQVTaIE1uU4D3k4yC167xEEzGCUGyTkMmmTfNwE=.97f619a6-5447-46eb-860e-02a13e507ac1@github.com>

On Thu, 11 Apr 2024 18:29:36 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
> > 
> > 
> > > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
> > 
> > 
> > I am facing the same error. But i do not understand why is it resolved to libawt_headless.so .
> 
> stdout: [attempting to load library foobar ]; stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406) at java.base/java.lang.Runtime.load0(Runtime.java:852) at java.base/java.lang.System.load(System.java:2030) at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259) at java.base/jdk.internal.loader.NativeLibra
 ries.loadLibrary(NativeLibraries.java:251) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) at java.base/java.lang.System.loadLibrary(System.java:2068) at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52) ] exitValue = 1

@jaikiran I see it is attempting to load foobar. But for some reason it is referring to different .so file. Some issue with usage of ProcessTools/ProcessBuilder ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056171132

From pminborg at openjdk.org  Mon Apr 15 08:37:55 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 08:37:55 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v2]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <PnQQ1SSVPLCXgkF0ibFC6zS_4whAKNo5w3vf0CxsZ7g=.14452427-ceff-49c6-9327-7687e7594515@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Fix typo
 - Update after PR comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/159b9c44..7de90243

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=00-01

  Stats: 13 lines in 1 file changed: 3 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18474/head:pull/18474

PR: https://git.openjdk.org/jdk/pull/18474

From jpai at openjdk.org  Mon Apr 15 08:53:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 15 Apr 2024 08:53:49 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <i9viEQVTaIE1uU4D3k4yC167xEEzGCUGyTkMmmTfNwE=.97f619a6-5447-46eb-860e-02a13e507ac1@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
 <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>
 <2ATAMorSuL_VV0fo_Fn-9an4D0D-fksyD723uiqZxzc=.98cd220b-8267-4290-988d-54741401e047@github.com>
 <i9viEQVTaIE1uU4D3k4yC167xEEzGCUGyTkMmmTfNwE=.97f619a6-5447-46eb-860e-02a13e507ac1@github.com>
Message-ID: <uZBht5qgbAiE2AmM5O-PE8IzgOcNiQpwQ5plq8Wg36I=.09559960-95d7-46e6-8322-d0fc28cbba88@github.com>

On Mon, 15 Apr 2024 08:30:57 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
>>> 
>>> > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
>>> 
>>> I am facing the same error. But i do not understand why is it resolved to libawt_headless.so .
>> 
>>  stdout: [attempting to load library foobar
>> ];
>>  stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so
>>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406)
>>         at java.base/java.lang.Runtime.load0(Runtime.java:852)
>>         at java.base/java.lang.System.load(System.java:2030)
>>         at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
>>         at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331)
>>         at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197)
>>         at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139)
>>         at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259)
>>         at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:251)
>>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435)
>>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>>         at java.base/java.lang.System.loadLibrary(System.java:2068)
>>         at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52)
>> ]
>>  exitValue = 1
>
>> > > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
>> > 
>> > 
>> > > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
>> > 
>> > 
>> > I am facing the same error. But i do not understand why is it resolved to libawt_headless.so .
>> 
>> stdout: [attempting to load library foobar ]; stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406) at java.base/java.lang.Runtime.load0(Runtime.java:852) at java.base/java.lang.System.load(System.java:2030) at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259) at java.base/jdk.internal.loader.NativeLibr
 aries.loadLibrary(NativeLibraries.java:251) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) at java.base/java.lang.System.loadLibrary(System.java:2068) at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52) ] exitValue = 1
> 
> @jaikiran I see it is attempting to load foobar. But for some reason it is referring to different .so file. Some issue with usage of ProcessTools/ProcessBuilder ?

Hello @suchismith1993, I haven't looked too deep, but a quick check of the JDK code suggests that the library you have chosen for this test (`libawt`) appears to have dependencies on some other libraries too. The `libawt_headless.so` appears to be coming from here https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L88 (it might even need `libawt_xawt.so`). I think all you have to do is copy over these additional library files as `.so` files from the JDK installation directory into the test specific directory. Either that or maybe pick a library that doesn't have any dependency.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056258141

From mcimadamore at openjdk.org  Mon Apr 15 09:44:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 09:44:42 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v2]
In-Reply-To: <PnQQ1SSVPLCXgkF0ibFC6zS_4whAKNo5w3vf0CxsZ7g=.14452427-ceff-49c6-9327-7687e7594515@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <PnQQ1SSVPLCXgkF0ibFC6zS_4whAKNo5w3vf0CxsZ7g=.14452427-ceff-49c6-9327-7687e7594515@github.com>
Message-ID: <en2p_TxXXhpIpL1UoVnKaahC_ciqD6FxkrAXvYJn2Z4=.f7daf05a-ce73-4106-b22b-d15992e4101a@github.com>

On Mon, 15 Apr 2024 08:37:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix typo
>  - Update after PR comments

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 154:

> 152:      * Returns the address of the symbol with the given name or throws an Exception.
> 153:      *<p>
> 154:      * This is equivalent to the following code, but is more resource efficient:

Suggestion:

     * This is equivalent to the following code, but is more efficient:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1565485693

From mcimadamore at openjdk.org  Mon Apr 15 09:45:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 09:45:41 GMT
Subject: RFR: 8330176: Typo in Linker javadoc
In-Reply-To: <iy3szzjtMDK-hPhur9p-aVAvKER63YZtLWasAXOGGmU=.be2acf69-8f7b-4376-acfc-ef889c05509e@github.com>
References: <iy3szzjtMDK-hPhur9p-aVAvKER63YZtLWasAXOGGmU=.be2acf69-8f7b-4376-acfc-ef889c05509e@github.com>
Message-ID: <3x5LhFmqWTMn8e05ftvIlJSsBWWubE1ct97-l6C8qgk=.5c5c422e-c979-4c73-bf41-4a1bbac65e19@github.com>

On Mon, 15 Apr 2024 08:21:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a typo in the `Linker` documentation.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18781#pullrequestreview-2000556281

From alanb at openjdk.org  Mon Apr 15 09:52:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Apr 2024 09:52:43 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v2]
In-Reply-To: <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>
Message-ID: <YXTLR7BuoVxaJTmV_rKWUYpD_LIHG8N2xeKAx9niw40=.ffc0ac15-cc12-48a1-a639-b8a58868431c@github.com>

On Mon, 15 Apr 2024 07:36:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class MainClass {
>>     public MainClass() {
>>         System.out.println("Constructor called!");
>>     }
>>     public static void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> and compile and run it, with preview enabled, like:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> Constructor called!
>> main called!
>> 
>> 
>> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
>> 
>> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
>> 
>> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
>> 
>> There is also a relatively closely related problem: what happens when the constructor throws an exception?
>> 
>> public class MainClass {
>>     public MainClass() {
>>         if (true) throw new RuntimeException();
>>     }
>>     public void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> 
>> when compiled an run, this produces no output whatsoever:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> $
>> 
>> 
>> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
>> 
>> $ java --enable-preview -classpath /tmp/ MainClass 
>> Exception in thread "main" java.lang.RuntimeException
>>         at MainClass.<init>(MainClass.java:3)
>> 
>> 
>> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Thanks for the updated version, much easier to read/maintainer.
Minor nit is that you probably should be a space after each "//" to be consistent with the existing code.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18753#pullrequestreview-2000571601

From mcimadamore at openjdk.org  Mon Apr 15 10:02:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 10:02:43 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <1pebFr-am7t6-LuWh6b1Q6H3M8rieUGWqLqm1-qcslQ=.f08492a1-a2c5-4139-93ce-ced5bf952963@github.com>

On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 99:

> 97:  * Every memory segment has a {@linkplain #maxByteAlignment() maximum byte alignment}
> 98:  * (see <a href="#segment-alignment">Alignment</a>"), expressed as a {@code long} value
> 99:  * that is always an even power of two.

I think it's better not to say too much about alignment here, otherwise we end up referring to concepts that are not well adequately introduced. Perhaps it would be better to just say:

Every memory segment has a maximum byte alignment, expressed as a long value. The maximum alignment is always a power of two, derived from the segment address, and the segment type, as explained in more details below <link>.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565511275

From mcimadamore at openjdk.org  Mon Apr 15 10:14:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 10:14:43 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <HPyL7C0gNcrs78ywN-7txoVuWAZtn_9iDbgnK1V6MZQ=.7e1e7110-37fa-4ff0-9d81-bf6180fe913b@github.com>

On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 408:

> 406:  * }
> 407:  *
> 408:  * In order to simplify determination of alignment, in the case of either native or heap

This can be expressed more directly as follows:

Clients can use the ... method to check if a memory segment supports the alignment constraint of a memory layout, as follows:


I'd also advise against using a method in the snippet, as that looks like the method is part of the API. Perhaps something like this:


MemoryLayout layout = ...
MemorySegment segment = ...
boolean isAligned = segment.maxByteAlignment() >= layout.byteAlignment()

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 412:

> 410:  * {@snippet lang=java:
> 411:  * boolean isAligned(MemorySegment segment, long offset, MemoryLayout layout) {
> 412:  *   return segment.asSlice(offset).maxByteAlignment() >= layout.byteAlignment;

Suggestion:

 *   return segment.asSlice(offset).maxByteAlignment() >= layout.byteAlignment();

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 612:

> 610: 
> 611:     /**
> 612:      * {@return the <em>maximum</em> byte alignment (which is equal to or higher than

Here I would just say:

Return the maximum byte alignment associated with this memory segment (link to alignment section)

If you then want to say that the max alignment is useful for alignment check, or allocation, that probably goes in a separate para (but I note you have one already - e.g. to show how to check alignment).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 615:

> 613:      * the requested byte alignment during native segment allocation)}
> 614:      * <p>
> 615:      * The returned alignment is always an even power of two and is derived from:

Not sure about the "even". Surely 2^3 is a valid max alignment?

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 618:

> 616:      * <ul>
> 617:      *     <li>Heap:
> 618:      *     the segment offset and backing array type.</li>

Note that "segment offset" is `segment.address()`. So I don't think we want to use a new term here. We can also say, more succinctly:

derived from the segment address <link to address()> and the type of the backing heap storage <link to heapObject> (for heap segments).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 622:

> 620:      *     the {@linkplain MemorySegment#address() address()} function.</li>
> 621:      * </ul>
> 622:      * The {@linkplain MemorySegment#NULL NULL} segment returns a maximum byte alignment

I believe this should better be moved in the javadoc for `NULL` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565520043
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565520387
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565525848
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565522838
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565530922
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565526441

From mcimadamore at openjdk.org  Mon Apr 15 10:19:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 10:19:43 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <cAcJsn-iIsAyDWuOZBWVxXS-WMksshvm9g34Kj2K7UQ=.51686373-e920-4c7c-8196-fdab56c5ae77@github.com>

On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

test/jdk/java/foreign/TestMemoryAlignment.java line 154:

> 152:              Arena arena = Arena.ofConfined()) {
> 153:             var segment =channel.map(FileChannel.MapMode.READ_WRITE, 0L, 32L, arena);
> 154:             assertTrue(segment.maxByteAlignment() >= Long.BYTES);

Is this always the case? Smells of platform-dependent... (e.g. think also of x86)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565537503

From jvernee at openjdk.org  Mon Apr 15 11:52:45 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 15 Apr 2024 11:52:45 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <I7xElrdyDUaeS_-FXl9WlG41-aX7xtkFDvU7c2FtoFE=.30b09645-25d1-44fc-ad03-e9fbb10bf069@github.com>

On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java line 86:

> 84:             alignment = maxAlignMask();
> 85:         }
> 86:         return Math.min(maxAlignMask(), alignment);

Similarly here:

Suggestion:

        return address() == 0
            ? maxAlignMask()
            : Math.min(maxAlignMask(), Long.lowestOneBit(address()));

src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 68:

> 66:                 ? 1L << 62
> 67:                 : alignment;
> 68:     }

This relies on the fact that `lowestOneBit` returns `0` only if `address()` returns `0`, but I suggest making the intent clearer by checking against `address()` directly:

Suggestion:

        return address() == 0
                ? 1L << 62
                : Long.lowestOneBit(address());


(I also suggest introducing a name for the `1L << 62` constant, e.g. `MAX_NATIVE_ALIGN`)

test/jdk/java/foreign/TestMemoryAlignment.java line 194:

> 192:                         new Object[]{MemorySegment.ofArray(new float[]{1}), Float.BYTES},
> 193:                         new Object[]{MemorySegment.ofArray(new double[]{1}), Double.BYTES},
> 194:                         new Object[]{MemorySegment.ofBuffer(ByteBuffer.allocate(8)), Byte.BYTES}

What about the other (heap) buffer types?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565638655
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565637521
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565647024

From ihse at openjdk.org  Mon Apr 15 12:01:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 12:01:49 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <x59-5FRsoG8BgigMF9cO8pdIPeevWfwdq8ejSxnvRSg=.798655fc-6685-4a4c-b460-46f0b5da5ab2@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

I'll close this now. I guess if we want to make progress on this, we will probably have to evaluate every individual warning separately, and add those which does make sense (e.g. `import-preprocessor-directive-pedantic`), and ignore the rest. I personally will not have time nor interest in driving this forward, at least not right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-2056659089

From ihse at openjdk.org  Mon Apr 15 12:01:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 12:01:49 GMT
Subject: Withdrawn: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <rrtpUalai1V2FJAlnUszRYP6DiX3YbrT93jC2_hGk_I=.78d8446b-dbba-4e11-8bb7-b7b6fa326c14@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/17687

From pminborg at openjdk.org  Mon Apr 15 12:45:49 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 12:45:49 GMT
Subject: Integrated: 8330176: Typo in Linker javadoc
In-Reply-To: <iy3szzjtMDK-hPhur9p-aVAvKER63YZtLWasAXOGGmU=.be2acf69-8f7b-4376-acfc-ef889c05509e@github.com>
References: <iy3szzjtMDK-hPhur9p-aVAvKER63YZtLWasAXOGGmU=.be2acf69-8f7b-4376-acfc-ef889c05509e@github.com>
Message-ID: <LQlnKou_--QlMaWl7dg_0sh5XmODd_ZUFM__P4v8r24=.7efd822b-b07b-48de-b71b-ba2ba4cf0f39@github.com>

On Mon, 15 Apr 2024 08:21:41 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a typo in the `Linker` documentation.

This pull request has now been integrated.

Changeset: 60d88b7a
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60d88b7ae2945724ab4db44207e3390bcff172c0
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8330176: Typo in Linker javadoc

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/18781

From pminborg at openjdk.org  Mon Apr 15 12:49:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 12:49:08 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v2]
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <oO_d9dhvI_fE4NEO_OUg61kdOVDwO_bRhxcRm3Rho4M=.c23df2e0-c458-4434-a896-81cac2b9d63f@github.com>

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

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

 - Update src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18779/files
  - new: https://git.openjdk.org/jdk/pull/18779/files/dc0505ff..89bb916b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=00-01

  Stats: 10 lines in 3 files changed: 0 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18779/head:pull/18779

PR: https://git.openjdk.org/jdk/pull/18779

From sroy at openjdk.org  Mon Apr 15 12:49:19 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 12:49:19 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v23]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <JmNbaBfxtRWCABtuzmfchB6o17OApflFNtKxCv7Ji78=.1137f5bc-f2d8-432d-bd35-844cd3cb70e9@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  Use ProcessTool to use scratch space for archives.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/3cd8bd1a..22cd52d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=21-22

  Stats: 62 lines in 1 file changed: 25 ins; 24 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Mon Apr 15 12:49:19 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 12:49:19 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <i9viEQVTaIE1uU4D3k4yC167xEEzGCUGyTkMmmTfNwE=.97f619a6-5447-46eb-860e-02a13e507ac1@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
 <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>
 <2ATAMorSuL_VV0fo_Fn-9an4D0D-fksyD723uiqZxzc=.98cd220b-8267-4290-988d-54741401e047@github.com>
 <i9viEQVTaIE1uU4D3k4yC167xEEzGCUGyTkMmmTfNwE=.97f619a6-5447-46eb-860e-02a13e507ac1@github.com>
Message-ID: <naZT4GUjklZjoDW8nf6Vbu8DRO6udJmu5N1glj2FqJI=.b57861b0-39ae-4b1d-b065-fbe2add055c4@github.com>

On Mon, 15 Apr 2024 08:30:57 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
>>> 
>>> > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
>>> 
>>> I am facing the same error. But i do not understand why is it resolved to libawt_headless.so .
>> 
>>  stdout: [attempting to load library foobar
>> ];
>>  stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so
>>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406)
>>         at java.base/java.lang.Runtime.load0(Runtime.java:852)
>>         at java.base/java.lang.System.load(System.java:2030)
>>         at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
>>         at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331)
>>         at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197)
>>         at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139)
>>         at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259)
>>         at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:251)
>>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435)
>>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>>         at java.base/java.lang.System.loadLibrary(System.java:2068)
>>         at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52)
>> ]
>>  exitValue = 1
>
>> > > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
>> > 
>> > 
>> > > Thanks! This looks like a good idea. Only the directory handling needs some modification. This version tries to load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", but it should load "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a".
>> > 
>> > 
>> > I am facing the same error. But i do not understand why is it resolved to libawt_headless.so .
>> 
>> stdout: [attempting to load library foobar ]; stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406) at java.base/java.lang.Runtime.load0(Runtime.java:852) at java.base/java.lang.System.load(System.java:2030) at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259) at java.base/jdk.internal.loader.NativeLibr
 aries.loadLibrary(NativeLibraries.java:251) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) at java.base/java.lang.System.loadLibrary(System.java:2068) at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52) ] exitValue = 1
> 
> @jaikiran I see it is attempting to load foobar. But for some reason it is referring to different .so file. Some issue with usage of ProcessTools/ProcessBuilder ?

> Hello @suchismith1993, I haven't looked too deep, but a quick check of the JDK code suggests that the library you have chosen for this test (`libawt`) appears to have dependencies on some other libraries too. The `libawt_headless.so` appears to be coming from here https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L88 (it might even need `libawt_xawt.so`). I think all you have to do is copy over these additional library files as `.so` files from the JDK installation directory into the test specific directory. Either that or maybe pick a library that doesn't have any dependency.

Thanks. I tried with a different shared object. Is there any documentation for ProcessTools. I didn't find a good one. 
It made setting the library path easy using -D.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056770111

From mbaesken at openjdk.org  Mon Apr 15 12:49:45 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 15 Apr 2024 12:49:45 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <XRZWaILXsubG85zvogxU1Zp8J9uUA299IAF3Nyvkdgs=.84e18304-115f-415a-9027-eb9ef41f0322@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <1OgWz9GmBNCQM98Kxh_mSKrlJohlYallG3rrV8hfC5A=.ffd723bb-fb67-4d9b-a7ba-1438cfa2d54e@github.com>
 <XRZWaILXsubG85zvogxU1Zp8J9uUA299IAF3Nyvkdgs=.84e18304-115f-415a-9027-eb9ef41f0322@github.com>
Message-ID: <XS1zHh8AAiKNuOatVXGN0M1ODH33IJHjbd9nhCfTN5U=.24796af3-5600-455b-b05e-d2690596135f@github.com>

On Wed, 10 Apr 2024 07:16:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> If we expand the tracing then I think it should be consistent with the existing tracing.

What exactly do you see as inconsistent ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2056772309

From pminborg at openjdk.org  Mon Apr 15 12:59:41 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 12:59:41 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v2]
In-Reply-To: <HPyL7C0gNcrs78ywN-7txoVuWAZtn_9iDbgnK1V6MZQ=.7e1e7110-37fa-4ff0-9d81-bf6180fe913b@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <HPyL7C0gNcrs78ywN-7txoVuWAZtn_9iDbgnK1V6MZQ=.7e1e7110-37fa-4ff0-9d81-bf6180fe913b@github.com>
Message-ID: <Hf8F-iL1B3YU4UphqOumV9g1Z5BbmvTkAo_KAYdAn_Y=.7b539e3c-530f-4970-b9b7-ebea9013f215@github.com>

On Mon, 15 Apr 2024 10:05:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 408:
> 
>> 406:  * }
>> 407:  *
>> 408:  * In order to simplify determination of alignment, in the case of either native or heap
> 
> This can be expressed more directly as follows:
> 
> Clients can use the ... method to check if a memory segment supports the alignment constraint of a memory layout, as follows:
> 
> 
> I'd also advise against using a method in the snippet, as that looks like the method is part of the API. Perhaps something like this:
> 
> 
> MemoryLayout layout = ...
> MemorySegment segment = ...
> boolean isAligned = segment.maxByteAlignment() >= layout.byteAlignment()

The example was similar to an existing method shown in a snippet in the same class, but we could change it anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565751189

From jpai at openjdk.org  Mon Apr 15 13:00:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 15 Apr 2024 13:00:48 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <naZT4GUjklZjoDW8nf6Vbu8DRO6udJmu5N1glj2FqJI=.b57861b0-39ae-4b1d-b065-fbe2add055c4@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
 <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>
 <2ATAMorSuL_VV0fo_Fn-9an4D0D-fksyD723uiqZxzc=.98cd220b-8267-4290-988d-54741401e047@github.com>
 <i9viEQVTaIE1uU4D3k4yC167xEEzGCUGyTkMmmTfNwE=.97f619a6-5447-46eb-860e-02a13e507ac1@github.com>
 <naZT4GUjklZjoDW8nf6Vbu8DRO6udJmu5N1glj2FqJI=.b57861b0-39ae-4b1d-b065-fbe2add055c4@github.com>
Message-ID: <wE9OhFMqVoQ68izVSmOAa4S90PrE4MiY1XJBYYdHAsI=.6a808282-4829-48e6-9803-dd6937fbfe9a@github.com>

On Mon, 15 Apr 2024 12:46:01 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> Is there any documentation for ProcessTools

ProcessTools, specifically `jdk.test.lib.process.ProcessTools`, is just another utility class within the JDK's repo's test directory which is made available as a jtreg `@library` (https://openjdk.org/jtreg/tag-spec.html has the details - search for "@library" in there).  Since `ProcessTools` is just an internal utility class, the only documentation it currently has is the javadoc on that class' methods. The class resides here https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/process/ProcessTools.java

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056794487

From jpai at openjdk.org  Mon Apr 15 13:05:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 15 Apr 2024 13:05:47 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <naZT4GUjklZjoDW8nf6Vbu8DRO6udJmu5N1glj2FqJI=.b57861b0-39ae-4b1d-b065-fbe2add055c4@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
 <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>
 <2ATAMorSuL_VV0fo_Fn-9an4D0D-fksyD723uiqZxzc=.98cd220b-8267-4290-988d-54741401e047@github.com>
 <i9viEQVTaIE1uU4D3k4yC167xEEzGCUGyTkMmmTfNwE=.97f619a6-5447-46eb-860e-02a13e507ac1@github.com>
 <naZT4GUjklZjoDW8nf6Vbu8DRO6udJmu5N1glj2FqJI=.b57861b0-39ae-4b1d-b065-fbe2add055c4@github.com>
Message-ID: <AtsqS_tTkldalhcHFaSRp55hCRhi2HL9XI6dN3GsNR8=.7a6848ed-e45e-4222-94d7-d76a0d93db02@github.com>

On Mon, 15 Apr 2024 12:46:01 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> Thanks. I tried with a different shared object.

If you undo the changes that are being proposed in this PR in the `src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java` class (only undo that class changes), then rebuild the JDK and rerun this newly introduced test, what exception/failure do you see in the test? Don't push the changes, it's merely an exercise to ascertain that the test you are introducing will indeed verify the changes that you have done to support loading library from an archive object through System.loadLibrary().

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056799554

From pminborg at openjdk.org  Mon Apr 15 13:07:43 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 13:07:43 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v2]
In-Reply-To: <HPyL7C0gNcrs78ywN-7txoVuWAZtn_9iDbgnK1V6MZQ=.7e1e7110-37fa-4ff0-9d81-bf6180fe913b@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <HPyL7C0gNcrs78ywN-7txoVuWAZtn_9iDbgnK1V6MZQ=.7e1e7110-37fa-4ff0-9d81-bf6180fe913b@github.com>
Message-ID: <i6MVXCDqPdXWwcGHu9OLAZ_g3wUk3VBz75p3X9ZjIMM=.84610bb0-434d-4a15-9767-effe0cd6064b@github.com>

On Mon, 15 Apr 2024 10:07:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 615:
> 
>> 613:      * the requested byte alignment during native segment allocation)}
>> 614:      * <p>
>> 615:      * The returned alignment is always an even power of two and is derived from:
> 
> Not sure about the "even". Surely 2^3 is a valid max alignment?

The meaning of "even" here is that it is a number 2^n, n >= 0, n ? Z. But maybe "a power of two" is enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565762747

From mcimadamore at openjdk.org  Mon Apr 15 13:12:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 13:12:44 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v2]
In-Reply-To: <i6MVXCDqPdXWwcGHu9OLAZ_g3wUk3VBz75p3X9ZjIMM=.84610bb0-434d-4a15-9767-effe0cd6064b@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <HPyL7C0gNcrs78ywN-7txoVuWAZtn_9iDbgnK1V6MZQ=.7e1e7110-37fa-4ff0-9d81-bf6180fe913b@github.com>
 <i6MVXCDqPdXWwcGHu9OLAZ_g3wUk3VBz75p3X9ZjIMM=.84610bb0-434d-4a15-9767-effe0cd6064b@github.com>
Message-ID: <uIlLIFYp7sExZUSP1BG1iZYC5_Mj8yUW6AmPha3cEVk=.25b84790-a111-4ac2-9b8a-f016d204c641@github.com>

On Mon, 15 Apr 2024 13:05:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 615:
>> 
>>> 613:      * the requested byte alignment during native segment allocation)}
>>> 614:      * <p>
>>> 615:      * The returned alignment is always an even power of two and is derived from:
>> 
>> Not sure about the "even". Surely 2^3 is a valid max alignment?
>
> The meaning of "even" here is that it is a number 2^n, n >= 0, n ? Z. But maybe "a power of two" is enough.

power of two implies even, so I'd say it's better to omit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565769068

From sroy at openjdk.org  Mon Apr 15 13:17:06 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 13:17:06 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v24]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <J3hG7lq-JbKy4AMuEB61qTBthJuRMWIH6hIiRqgrAvE=.1ba0a146-e532-46fa-b2ce-f4a303298cc0@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  Files copy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/22cd52d7..f7ef9b04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=22-23

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From pminborg at openjdk.org  Mon Apr 15 13:19:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 13:19:47 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v2]
In-Reply-To: <cAcJsn-iIsAyDWuOZBWVxXS-WMksshvm9g34Kj2K7UQ=.51686373-e920-4c7c-8196-fdab56c5ae77@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <cAcJsn-iIsAyDWuOZBWVxXS-WMksshvm9g34Kj2K7UQ=.51686373-e920-4c7c-8196-fdab56c5ae77@github.com>
Message-ID: <V1QfMfqvejylQQbCXY_TJD1BCcnqIn_3USeSNchkqdk=.3ec65a90-0f73-46ca-8abe-14c8a195c749@github.com>

On Mon, 15 Apr 2024 10:16:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> test/jdk/java/foreign/TestMemoryAlignment.java line 154:
> 
>> 152:              Arena arena = Arena.ofConfined()) {
>> 153:             var segment =channel.map(FileChannel.MapMode.READ_WRITE, 0L, 32L, arena);
>> 154:             assertTrue(segment.maxByteAlignment() >= Long.BYTES);
> 
> Is this always the case? Smells of platform-dependent... (e.g. think also of x86)

I think the alignment is always the biggest of the directly supported primitive types so maybe we should change to `Integer.BYTES` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565781128

From mcimadamore at openjdk.org  Mon Apr 15 13:23:48 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 13:23:48 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v2]
In-Reply-To: <V1QfMfqvejylQQbCXY_TJD1BCcnqIn_3USeSNchkqdk=.3ec65a90-0f73-46ca-8abe-14c8a195c749@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <cAcJsn-iIsAyDWuOZBWVxXS-WMksshvm9g34Kj2K7UQ=.51686373-e920-4c7c-8196-fdab56c5ae77@github.com>
 <V1QfMfqvejylQQbCXY_TJD1BCcnqIn_3USeSNchkqdk=.3ec65a90-0f73-46ca-8abe-14c8a195c749@github.com>
Message-ID: <p7AgK4B6AiqueCLlMMqBYtfR3bR-O2haWraEzZf0S58=.4972a2f6-2c6e-4a99-9020-6aa5a39483bc@github.com>

On Mon, 15 Apr 2024 13:17:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> test/jdk/java/foreign/TestMemoryAlignment.java line 154:
>> 
>>> 152:              Arena arena = Arena.ofConfined()) {
>>> 153:             var segment =channel.map(FileChannel.MapMode.READ_WRITE, 0L, 32L, arena);
>>> 154:             assertTrue(segment.maxByteAlignment() >= Long.BYTES);
>> 
>> Is this always the case? Smells of platform-dependent... (e.g. think also of x86)
>
> I think the alignment is always the biggest of the directly supported primitive types so maybe we should change to `Integer.BYTES` here.

Yes, but, I mean, we don't have a test for checking what's the alignment of `malloc` - so I wonder why we should have a test for mapped segments - it's not like the API makes any promises there, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565789636

From sroy at openjdk.org  Mon Apr 15 13:23:22 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 13:23:22 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  Files copy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/f7ef9b04..f0672e76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=23-24

  Stats: 26 lines in 1 file changed: 23 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Mon Apr 15 13:30:47 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 13:30:47 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v22]
In-Reply-To: <AtsqS_tTkldalhcHFaSRp55hCRhi2HL9XI6dN3GsNR8=.7a6848ed-e45e-4222-94d7-d76a0d93db02@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <d2Qaa2mnxNl2fLK2BCe7qtOrjlCln6XI6w4yU0tWp5E=.06ab1e30-f21c-4018-ac6d-c24f6e61794c@github.com>
 <0O_RVyA7TTqAylc79hLUFy8s5G11MyIp63Tuy2PyNAA=.b216f51b-14cf-47e6-bb15-b3facc30368c@github.com>
 <2ATAMorSuL_VV0fo_Fn-9an4D0D-fksyD723uiqZxzc=.98cd220b-8267-4290-988d-54741401e047@github.com>
 <i9viEQVTaIE1uU4D3k4yC167xEEzGCUGyTkMmmTfNwE=.97f619a6-5447-46eb-860e-02a13e507ac1@github.com>
 <naZT4GUjklZjoDW8nf6Vbu8DRO6udJmu5N1glj2FqJI=.b57861b0-39ae-4b1d-b065-fbe2add055c4@github.com>
 <AtsqS_tTkldalhcHFaSRp55hCRhi2HL9XI6dN3GsNR8=.7a6848ed-e45e-4222-94d7-d76a0d93db02@github.com>
Message-ID: <KcwN9Jm7V0hM4UwM_4D1dLjzkS79Uhmm9NooI6F4UIY=.4bca6fb3-9ad8-452b-b9a9-64db17fe9dce@github.com>

On Mon, 15 Apr 2024 13:00:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > Thanks. I tried with a different shared object.
> 
> If you undo the changes that are being proposed in this PR in the `src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java` class (only undo that class changes), then rebuild the JDK and rerun this newly introduced test, what exception/failure do you see in the test? Don't push the changes, it's merely an exercise to ascertain that the test you are introducing will indeed verify the changes that you have done to support loading library from an archive object through System.loadLibrary().

attempting to load library foobar
Exception in thread "main" java.lang.UnsatisfiedLinkError: no foobar in java.library.path: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2442)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
        at java.base/java.lang.System.loadLibrary(System.java:2068)
        at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:67)

STDERR:
 stdout: [attempting to load library foobar
];
 stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: no foobar in java.library.path: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2442)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
        at java.base/java.lang.System.loadLibrary(System.java:2068)
        at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:67)
]
 exitValue = 1

java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
        at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
        at LoadAIXLibraryFromArchiveObject.main(LoadAIXLibraryFromArchiveObject.java:61)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
JavaTest Message: shutting down test

After setting loadLibraryOnlyIfPresent to true again.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056857173

From jpai at openjdk.org  Mon Apr 15 13:38:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 15 Apr 2024 13:38:47 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
Message-ID: <phRpo6MEib3epKe9RpTTDx1Ki7Xh6RpXciVT9uTWyRc=.4c7b806a-a33d-4cd8-ad16-bb44ffb267ce@github.com>

On Mon, 15 Apr 2024 13:23:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy

The test seems to be working fine then based on the output you noted. It catches the issue (by failing) when the source change proposed in this PR is absent and then verifies the change works as expected (by passing).

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056877427

From pminborg at openjdk.org  Mon Apr 15 13:48:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 13:48:09 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v3]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <ohwlY2f69wykOw4yOEJ02Gr0oQjD_jAi6JRZsavE-O4=.e10e68ca-f02a-4f57-96c6-55f918a5b199@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

  Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/7de90243..e173ff09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/18474

From mcimadamore at openjdk.org  Mon Apr 15 13:54:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 13:54:44 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v3]
In-Reply-To: <ohwlY2f69wykOw4yOEJ02Gr0oQjD_jAi6JRZsavE-O4=.e10e68ca-f02a-4f57-96c6-55f918a5b199@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <ohwlY2f69wykOw4yOEJ02Gr0oQjD_jAi6JRZsavE-O4=.e10e68ca-f02a-4f57-96c6-55f918a5b199@github.com>
Message-ID: <zYxe2VpE1LLGI_dpgWKKvk7TZ9fwuLQhIHgIm9Mq85g=.6c40cf8e-9053-4a98-bc0c-ba9442669006@github.com>

On Mon, 15 Apr 2024 13:48:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 152:

> 150: 
> 151:     /**
> 152:      * Returns the address of the symbol with the given name or throws an Exception.

Suggestion:

     * Returns the address of the symbol with the given name or throws an exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1565837858

From sroy at openjdk.org  Mon Apr 15 13:54:49 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 13:54:49 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <phRpo6MEib3epKe9RpTTDx1Ki7Xh6RpXciVT9uTWyRc=.4c7b806a-a33d-4cd8-ad16-bb44ffb267ce@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
 <phRpo6MEib3epKe9RpTTDx1Ki7Xh6RpXciVT9uTWyRc=.4c7b806a-a33d-4cd8-ad16-bb44ffb267ce@github.com>
Message-ID: <pAuOOF5WK1quC3yQcl7Bys7Q0egRvQIhXRKGh_gcWrc=.9949262a-c4cb-496b-8262-86047046ed35@github.com>

On Mon, 15 Apr 2024 13:36:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The test seems to be working fine then based on the output you noted. It catches the issue (by failing) when the source change proposed in this PR is absent and then verifies the change works as expected (by passing).

Yes. 
Passes when reverting back.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056916358

From jpai at openjdk.org  Mon Apr 15 14:01:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 15 Apr 2024 14:01:49 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
Message-ID: <UXT792rJReVuGjF-AniCOyLyTNDNlX0mhAa8EdrShGw=.2c1b7a29-d262-4d77-b97b-508e5d734e81@github.com>

On Mon, 15 Apr 2024 13:23:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy

I'll let Mandy and others familiar with this area and AIX do the formal review of this PR. My involvement here was merely general inputs.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056931120

From pminborg at openjdk.org  Mon Apr 15 14:02:56 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 14:02:56 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v4]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

  Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/e173ff09..fa86d837

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/18474

From mdoerr at openjdk.org  Mon Apr 15 14:11:50 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 15 Apr 2024 14:11:50 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
Message-ID: <td3uEuDe6GbPatRN4stD9q_o0BRC36OYLUFXZ-ZeCWo=.3b63222e-b874-4d68-9cb8-87d265a615be@github.com>

On Mon, 15 Apr 2024 13:23:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy

I think it's good. I only found minor nits.

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 57:

> 55:         // // launch a java application which calls System.loadLibrary and is passed
> 56:         // // the directory containing the native library archive file, through
> 57:         // // -Djava.library.path

Please avoid `// //`.

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 71:

> 69:         }
> 70:     }
> 71: }

I think files typically have a newline at the end.

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

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-2001218422
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1565859302
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1565860272

From mdoerr at openjdk.org  Mon Apr 15 14:11:52 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 15 Apr 2024 14:11:52 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v13]
In-Reply-To: <AJcRAHtgPJKk2-gCAtWH704Ud2oWdhQj61kY_stq_24=.75e6bb8d-598e-426c-8c9d-80fa0c3569a3@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
 <AJcRAHtgPJKk2-gCAtWH704Ud2oWdhQj61kY_stq_24=.75e6bb8d-598e-426c-8c9d-80fa0c3569a3@github.com>
Message-ID: <ysZR5ms_42NdHVLxm92gFNkM3NKHl7_5-HmHXg_M6qA=.4bc97c0a-a1de-4434-aabc-561cd3c192a6@github.com>

On Mon, 8 Apr 2024 10:27:40 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - update tests
>>  - update tests
>>  - update tests
>
> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 40:
> 
>> 38:     * This method returns false so that loading of shared library continues if
>> 39:     * libname.so is not present.
>> 40:     */
> 
> The '*' should be in the same column. Please compare to ClassLoaderHelper.java for other OSs.

'*' should are in the same column, now, but it is still not the same coding style as in other files. Why can't you do it exactly like https://github.com/openjdk/jdk/blob/273df6286a9cc4dcef4cd339234206b2ad922386/src/java.base/unix/classes/jdk/internal/loader/ClassLoaderHelper.java#L43 ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1565857910

From asotona at openjdk.org  Mon Apr 15 14:18:58 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 Apr 2024 14:18:58 GMT
Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v6]
In-Reply-To: <HnSlddnQJi47nmj_MTxi2SooHNzaI_JCAuLk68DuxzY=.25dcf5e9-657f-4225-8952-aa4c741edb08@github.com>
References: <HnSlddnQJi47nmj_MTxi2SooHNzaI_JCAuLk68DuxzY=.25dcf5e9-657f-4225-8952-aa4c741edb08@github.com>
Message-ID: <1OHkxgV-GooLoG-IzrlSWNhUy-pegG94AZ7ZRfQJto4=.ca2e9254-daea-4e35-995c-848223fb3770@github.com>

> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use.
> 
> This patch revisits the `CodeBuilder` API methods and introduces some changes.
> 
> For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067)
> 
> Please review.
> 
> Thank you,
> 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 14 commits:

 - Merge branch 'master' into JDK-8323058-CodeBuilder
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
   #	test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
 - added @since 23 tags for new CodeBuilder methods
 - fixed ClassFile API use in new tests
 - Merge branch 'master' into JDK-8323058-CodeBuilder
 - removed CodeBuilder::newObject methods
 - Merge branch 'master' into JDK-8323058-CodeBuilder
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
   #	src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
 - extended CodeBuilder::conversion functionality
 - removed CodeBuilder::newPrimitiveArray, newReferenceArray, newMultidimensionalArray and operator methods
 - fixed tests
 - fixed jdk/classfile tests
 - ... and 4 more: https://git.openjdk.org/jdk/compare/273df628...62d4f9f4

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

Changes: https://git.openjdk.org/jdk/pull/17282/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17282&range=05
  Stats: 931 lines in 52 files changed: 56 ins; 207 del; 668 mod
  Patch: https://git.openjdk.org/jdk/pull/17282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17282/head:pull/17282

PR: https://git.openjdk.org/jdk/pull/17282

From pminborg at openjdk.org  Mon Apr 15 14:21:23 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 14:21:23 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v3]
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <oaT-mm9gtGgDNKoFC-9fOHvJUL4Cg8--UJYEB_lbUqc=.c81f87fa-38aa-42b2-a1e7-869dce5f6c20@github.com>

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

Per Minborg 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 ten additional commits since the last revision:

 - Update after comments
 - Merge branch 'master' into ms-reinterpret2
 - Update src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Fix imports and copyright
 - Update maxByteAlignment docs
 - Improve doc and tests
 - Add a MS::maxByteAlignment method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18779/files
  - new: https://git.openjdk.org/jdk/pull/18779/files/89bb916b..7b45ad5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=01-02

  Stats: 4996 lines in 212 files changed: 1382 ins; 1604 del; 2010 mod
  Patch: https://git.openjdk.org/jdk/pull/18779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18779/head:pull/18779

PR: https://git.openjdk.org/jdk/pull/18779

From sgibbons at openjdk.org  Mon Apr 15 14:30:15 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 15 Apr 2024 14:30:15 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v15]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <G5jbAOgJ3mF1IN_hySy4cD3J3yaxT2izPmDoomJujys=.0230ad6f-c98a-4c11-a906-a4725b0f365a@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Change fill routines
  
  * Even more review comments
  
  * Re-write of atomic copy loops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/6e731c86..405e4e05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=13-14

  Stats: 251 lines in 1 file changed: 103 ins; 117 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From mcimadamore at openjdk.org  Mon Apr 15 14:43:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 14:43:45 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v3]
In-Reply-To: <oaT-mm9gtGgDNKoFC-9fOHvJUL4Cg8--UJYEB_lbUqc=.c81f87fa-38aa-42b2-a1e7-869dce5f6c20@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <oaT-mm9gtGgDNKoFC-9fOHvJUL4Cg8--UJYEB_lbUqc=.c81f87fa-38aa-42b2-a1e7-869dce5f6c20@github.com>
Message-ID: <J1bOcfHQiUeg2ZD4mT7JwMW7N9uvc10Dnzf6lSXiS3c=.f11bfea0-2ad3-4055-a072-f920e43e37ec@github.com>

On Mon, 15 Apr 2024 14:21:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
>> 
>> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).
>
> Per Minborg 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 ten additional commits since the last revision:
> 
>  - Update after comments
>  - Merge branch 'master' into ms-reinterpret2
>  - Update src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Fix imports and copyright
>  - Update maxByteAlignment docs
>  - Improve doc and tests
>  - Add a MS::maxByteAlignment method

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 100:

> 98:  * expressed as a {@code long} value. The maximum alignment is always a power of two,
> 99:  * derived from the segment address, and the segment type, as explained in more detail
> 100:  * (see <a href="#segment-alignment">below</a>).

Suggestion:

 * <a href="#segment-alignment">below</a>.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 610:

> 608:      * The returned alignment is always a power of two and is derived from:
> 609:      * <ul>
> 610:      *     <li>Heap:

Suggestion:

     *     <li>Heap segments:

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 612:

> 610:      *     <li>Heap:
> 611:             derived from the segment {@linkplain #address() address()}
> 612:             and the type of the <a href="#segment-alignment">backing heap storage</a>.

Shoudn't the link point to `MemorySegment::heapObject` ?

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 613:

> 611:             derived from the segment {@linkplain #address() address()}
> 612:             and the type of the <a href="#segment-alignment">backing heap storage</a>.
> 613:      *     <li>Native:

Suggestion:

     *     <li>Native segments:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565907165
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565909731
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565909449
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565910025

From redestad at openjdk.org  Mon Apr 15 14:44:00 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 15 Apr 2024 14:44:00 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v3]
In-Reply-To: <Jig3lPKwypZSDvjHE10IltvPChHUIyTL3UWvs6wZ4SI=.463b84d8-19b3-4ee7-9cce-8e1f7765af86@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <jzadfmnWmt_23bDh0YfmnKbywrelgVpL20RHnUJv3o8=.73ed8ced-3798-45a8-92e3-83616ddfefdb@github.com>
 <w_Q5asfvbEoeI-QJfh92FJ2sPKFhXuQCPyPm6XvHxww=.fee8131b-4f8b-45e7-99dd-854c79354c0a@github.com>
 <Jig3lPKwypZSDvjHE10IltvPChHUIyTL3UWvs6wZ4SI=.463b84d8-19b3-4ee7-9cce-8e1f7765af86@github.com>
Message-ID: <lR3B644GnkHCWwMfqSO-L_9YEnWnwQdQcCQKaFP0xEY=.494192ae-e20f-4626-bfc3-26b82b058725@github.com>

On Fri, 12 Apr 2024 15:06:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I'd prefer considering such optimizations as follow-ups. We need to think about where to define such shared classes in a way that considers the full lifecycle, facilitates class unloading (one cache per classloader?) while still getting good reuse.
>
> I think `Invokers` might be a good place. Its lifetime is bound to its MT, and MT already handles class unloading well. If we are doing erased then a plain array suffices.

I think we should be wary about adding things that are strongly kept alive by the MT. While the MTs themselves are weakly referenced and can be unloaded if all usage goes aways, many oft-used MTs might be kept effectively forever.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1565912250

From mcimadamore at openjdk.org  Mon Apr 15 14:43:46 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 14:43:46 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v3]
In-Reply-To: <J1bOcfHQiUeg2ZD4mT7JwMW7N9uvc10Dnzf6lSXiS3c=.f11bfea0-2ad3-4055-a072-f920e43e37ec@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <oaT-mm9gtGgDNKoFC-9fOHvJUL4Cg8--UJYEB_lbUqc=.c81f87fa-38aa-42b2-a1e7-869dce5f6c20@github.com>
 <J1bOcfHQiUeg2ZD4mT7JwMW7N9uvc10Dnzf6lSXiS3c=.f11bfea0-2ad3-4055-a072-f920e43e37ec@github.com>
Message-ID: <mgvFs7TFinghOCupJIjsOE7qWzLErCxoniv7YssC25M=.a566309e-4810-49ba-af5a-7dea943e7f93@github.com>

On Mon, 15 Apr 2024 14:39:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg 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 ten additional commits since the last revision:
>> 
>>  - Update after comments
>>  - Merge branch 'master' into ms-reinterpret2
>>  - Update src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>>  - Fix imports and copyright
>>  - Update maxByteAlignment docs
>>  - Improve doc and tests
>>  - Add a MS::maxByteAlignment method
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 612:
> 
>> 610:      *     <li>Heap:
>> 611:             derived from the segment {@linkplain #address() address()}
>> 612:             and the type of the <a href="#segment-alignment">backing heap storage</a>.
> 
> Shoudn't the link point to `MemorySegment::heapObject` ?

I suggest you generate the javadoc and look at this method - my feeling is that it won't be very readable. The sentence "a power of two and is derived from" is left a bit suspended - and you have a bullet list which starts with "Native Segment" which is not a valid "next token" for the sentence above. After which, we say again "derived from" hence repeating.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1565913273

From mcimadamore at openjdk.org  Mon Apr 15 14:48:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 14:48:01 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v4]
In-Reply-To: <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
Message-ID: <yaXPZJz7zNPigYlPVl6JraAAIWWmGd8KE_9umn-m71U=.3e0367fd-f66d-4689-a593-3778a7a6730c@github.com>

On Mon, 15 Apr 2024 14:02:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2001319293

From ihse at openjdk.org  Mon Apr 15 14:52:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 14:52:04 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
Message-ID: <CQ0bUI3dJrLCJrbZMbKe147DI6j_cl-IQ3qrNxqQxaM=.8236fa8b-84bc-4fe5-a231-1182628aadb3@github.com>

On Mon, 15 Apr 2024 13:23:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files copy

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 42:

> 40:     */
> 41:     static boolean loadLibraryOnlyIfPresent() {
> 42:         return true;

I've been following this PR to and fro for a while, so I might have missed something. But it looks like the code and the documentation is completely at odds -- the documentation claims the function should return `false`, but in reality it returns `true`. If the code is correct, the documentation needs to be fixed or clarified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1565925292

From redestad at openjdk.org  Mon Apr 15 15:01:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 15 Apr 2024 15:01:02 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v4]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <_ecuscRjaJ_WxqDhFMQuNuZ-Mt9x9tCU0Bqs5Ub2pAo=.2a0ddce8-137b-499b-ad7c-15d2c7e6f101@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

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

  Dump using the hidden class name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18690/files
  - new: https://git.openjdk.org/jdk/pull/18690/files/796d968b..9eed6609

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/18690

From darcy at openjdk.org  Mon Apr 15 15:14:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Apr 2024 15:14:49 GMT
Subject: Integrated: 8330196: Make java/lang/invoke/defineHiddenClass/BasicTest
 release agnostic
In-Reply-To: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
References: <BF5DAQKB5wyikwtEQIy2vGNnPYQr2M6eNQsEm3SLilQ=.b9194e15-de89-4924-80a5-191fe2c1049d@github.com>
Message-ID: <ser-41m7zo2NNUFE_vimpEBC2QtxOnB3arQXzlEB98M=.ed2c98b8-ea86-4a6a-b210-a4bb2631e3eb@github.com>

On Fri, 12 Apr 2024 23:55:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Straightforward test update so it doesn't have to be trivially updated for each JDK version.

This pull request has now been integrated.

Changeset: da75e015
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da75e015b54f4ff011837995cacf80850411bb74
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8330196: Make java/lang/invoke/defineHiddenClass/BasicTest release agnostic

Reviewed-by: liach, mchung, jkuhn

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

PR: https://git.openjdk.org/jdk/pull/18769

From sroy at openjdk.org  Mon Apr 15 16:01:35 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 16:01:35 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v26]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <P8drYlB-swof5zB73mdy9AMcCMKpEHrRNPpTvgOfktQ=.d4481dfc-7a03-497a-8747-69615bc9ce4e@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

  coding style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/f0672e76..de7f3a72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=24-25

  Stats: 23 lines in 2 files changed: 0 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Mon Apr 15 16:01:36 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 16:01:36 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <CQ0bUI3dJrLCJrbZMbKe147DI6j_cl-IQ3qrNxqQxaM=.8236fa8b-84bc-4fe5-a231-1182628aadb3@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
 <CQ0bUI3dJrLCJrbZMbKe147DI6j_cl-IQ3qrNxqQxaM=.8236fa8b-84bc-4fe5-a231-1182628aadb3@github.com>
Message-ID: <YcUofhTLQlEWjK_vdCzPVtWBAc03jWCkxvEArxo1CQA=.1e063441-35b6-45b1-ac9e-6454d3d42dc2@github.com>

On Mon, 15 Apr 2024 14:48:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Files copy
>
> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 42:
> 
>> 40:     */
>> 41:     static boolean loadLibraryOnlyIfPresent() {
>> 42:         return true;
> 
> I've been following this PR to and fro for a while, so I might have missed something. But it looks like the code and the documentation is completely at odds -- the documentation claims the function should return `false`, but in reality it returns `true`. If the code is correct, the documentation needs to be fixed or clarified.

It was a wrong push. Sorry. The autocomplete command was causing some troubles. I had changed it in local to see if the jtreg test fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566023166

From duke at openjdk.org  Mon Apr 15 16:06:59 2024
From: duke at openjdk.org (wolfseifert)
Date: Mon, 15 Apr 2024 16:06:59 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v2]
In-Reply-To: <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>
Message-ID: <0ZTIq4PDjgYaIiLA6ZJNnRA-nHD8O2kvp0kC3QE6aQs=.93c2d31d-a673-4990-b2f1-43cd45236b2b@github.com>

On Mon, 15 Apr 2024 07:36:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class MainClass {
>>     public MainClass() {
>>         System.out.println("Constructor called!");
>>     }
>>     public static void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> and compile and run it, with preview enabled, like:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> Constructor called!
>> main called!
>> 
>> 
>> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
>> 
>> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
>> 
>> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
>> 
>> There is also a relatively closely related problem: what happens when the constructor throws an exception?
>> 
>> public class MainClass {
>>     public MainClass() {
>>         if (true) throw new RuntimeException();
>>     }
>>     public void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> 
>> when compiled an run, this produces no output whatsoever:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> $
>> 
>> 
>> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
>> 
>> $ java --enable-preview -classpath /tmp/ MainClass 
>> Exception in thread "main" java.lang.RuntimeException
>>         at MainClass.<init>(MainClass.java:3)
>> 
>> 
>> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Does this also fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581)?

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

PR Comment: https://git.openjdk.org/jdk/pull/18753#issuecomment-2057206293

From jvernee at openjdk.org  Mon Apr 15 16:10:04 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 15 Apr 2024 16:10:04 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v4]
In-Reply-To: <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
Message-ID: <pZ7FQ20nyd2zTFvoqQxM9u4IvW6tzkk7AuGFacJfHv4=.4812ae1c-db82-4be6-923e-2fe40931d2c8@github.com>

On Mon, 15 Apr 2024 14:02:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2001521250

From sroy at openjdk.org  Mon Apr 15 16:10:38 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 16:10:38 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v27]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <EKyawoFgA1Yx9kLdw8lIXLYIQmC0ZYIk0hQ-zerCzaE=.57387714-7fac-4ee1-8fb4-c4232294da9f@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

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

 - new line
 - spaces fix
 - spaces fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/de7f3a72..12270d06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=25-26

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

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Mon Apr 15 16:10:39 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 16:10:39 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v13]
In-Reply-To: <ysZR5ms_42NdHVLxm92gFNkM3NKHl7_5-HmHXg_M6qA=.4bc97c0a-a1de-4434-aabc-561cd3c192a6@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ID20PaXtMX7LUESmHepE_2c_YQKt4-tIZuq-8WF1FcU=.055e17ac-a726-4c39-924d-2e5bfe4fb83e@github.com>
 <AJcRAHtgPJKk2-gCAtWH704Ud2oWdhQj61kY_stq_24=.75e6bb8d-598e-426c-8c9d-80fa0c3569a3@github.com>
 <ysZR5ms_42NdHVLxm92gFNkM3NKHl7_5-HmHXg_M6qA=.4bc97c0a-a1de-4434-aabc-561cd3c192a6@github.com>
Message-ID: <DlpioVEh0OWXvdptVucEsjUeg454Ish2nTQ186-g0Kw=.bd395553-f72e-4d5d-880e-2f9d57daacf8@github.com>

On Mon, 15 Apr 2024 14:05:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 40:
>> 
>>> 38:     * This method returns false so that loading of shared library continues if
>>> 39:     * libname.so is not present.
>>> 40:     */
>> 
>> The '*' should be in the same column. Please compare to ClassLoaderHelper.java for other OSs.
>
> '*' should are in the same column, now, but it is still not the same coding style as in other files. Why can't you do it exactly like https://github.com/openjdk/jdk/blob/273df6286a9cc4dcef4cd339234206b2ad922386/src/java.base/unix/classes/jdk/internal/loader/ClassLoaderHelper.java#L43 ?

Thanks. I didn't notice the one extra space.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566037541

From sroy at openjdk.org  Mon Apr 15 16:10:41 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 15 Apr 2024 16:10:41 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <td3uEuDe6GbPatRN4stD9q_o0BRC36OYLUFXZ-ZeCWo=.3b63222e-b874-4d68-9cb8-87d265a615be@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
 <td3uEuDe6GbPatRN4stD9q_o0BRC36OYLUFXZ-ZeCWo=.3b63222e-b874-4d68-9cb8-87d265a615be@github.com>
Message-ID: <VTwCG6CpkaHwdOcJFcxpTlgvcam2jZvcf6QmZpYZmJk=.a7d7f30a-2417-4240-8296-2937382a0e6f@github.com>

On Mon, 15 Apr 2024 14:06:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Files copy
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 71:
> 
>> 69:         }
>> 70:     }
>> 71: }
> 
> I think files typically have a newline at the end.

In ClassLoader i didnt see it. Put newline at end for both files now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566037066

From psandoz at openjdk.org  Mon Apr 15 16:38:44 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 15 Apr 2024 16:38:44 GMT
Subject: RFR: 8196106: Support nested infinite or recursive flat mapped
 streams [v8]
In-Reply-To: <JHRGHRtl4aDBeWbQAqHbBBt9FNPBhbRf_fHpnM57-Gc=.449c730b-6270-4fb4-8988-337f1069604d@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
 <JHRGHRtl4aDBeWbQAqHbBBt9FNPBhbRf_fHpnM57-Gc=.449c730b-6270-4fb4-8988-337f1069604d@github.com>
Message-ID: <2e6Qxa4j5ulUxdsJTtDdrk0hUx4OPKh7dj7o52a0UfY=.5b920a06-0763-4d65-a077-4e22fff54ffa@github.com>

On Sat, 13 Apr 2024 14:27:12 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
>> 
>> Below is the performance of `Stream::flatMap` (for reference types):
>> 
>> Before this PR (on my MacBook, aarch64):
>> 
>> Non-short-circuiting:
>> 
>> Benchmark                 (size)   Mode  Cnt        Score       Error  Units
>> FlatMap.par_array             10  thrpt   12   257582,480 ? 31360,242  ops/s
>> FlatMap.par_array            100  thrpt   12    55202,015 ? 14011,668  ops/s
>> FlatMap.par_array           1000  thrpt   12     6546,252 ?  3675,764  ops/s
>> FlatMap.par_doublestream      10  thrpt   12   267423,410 ? 37338,089  ops/s
>> FlatMap.par_doublestream     100  thrpt   12    27140,703 ?  4979,878  ops/s
>> FlatMap.par_doublestream    1000  thrpt   12     2978,178 ?  1890,250  ops/s
>> FlatMap.par_intstream         10  thrpt   12   268194,530 ? 37295,092  ops/s
>> FlatMap.par_intstream        100  thrpt   12    30897,034 ?  5388,245  ops/s
>> FlatMap.par_intstream       1000  thrpt   12     3969,043 ?  2494,641  ops/s
>> FlatMap.par_longstream        10  thrpt   12   279756,861 ? 19519,497  ops/s
>> FlatMap.par_longstream       100  thrpt   12    45733,955 ? 18385,144  ops/s
>> FlatMap.par_longstream      1000  thrpt   12     5115,615 ?  4147,237  ops/s
>> FlatMap.seq_array             10  thrpt   12  2937192,934 ? 58605,583  ops/s
>> FlatMap.seq_array            100  thrpt   12    41859,462 ?   139,021  ops/s
>> FlatMap.seq_array           1000  thrpt   12      442,677 ?     1,041  ops/s
>> FlatMap.seq_doublestream      10  thrpt   12  4972651,093 ? 35997,267  ops/s
>> FlatMap.seq_doublestream     100  thrpt   12    99265,005 ?   193,497  ops/s
>> FlatMap.seq_doublestream    1000  thrpt   12     1037,030 ?     3,254  ops/s
>> FlatMap.seq_intstream         10  thrpt   12  5133751,888 ? 23516,294  ops/s
>> FlatMap.seq_intstream        100  thrpt   12   145166,206 ?   399,263  ops/s
>> FlatMap.seq_intstream       1000  thrpt   12     1565,004 ?     3,207  ops/s
>> FlatMap.seq_longstream        10  thrpt   12  5047029,363 ? 24742,300  ops/s
>> FlatMap.seq_longstream       100  thrpt   12   233225,307 ?  7162,604  ops/s
>> FlatMap.seq_longstream      1000  thrpt   12     2999,926 ?     9,945  ops/s
>> 
>> // Short-circuiting:
>> 
>> Benchmark                   (size)   Mode  Cnt       Score       Error  Units
>> FlatMap.par_iterate_double      10  thrpt   12   46336,834 ?  6803,751  ops/s
>> FlatMap.par_iterate_double     100 ...
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review feedback

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18625#pullrequestreview-2001623065

From jvernee at openjdk.org  Mon Apr 15 17:02:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 15 Apr 2024 17:02:46 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v3]
In-Reply-To: <oaT-mm9gtGgDNKoFC-9fOHvJUL4Cg8--UJYEB_lbUqc=.c81f87fa-38aa-42b2-a1e7-869dce5f6c20@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <oaT-mm9gtGgDNKoFC-9fOHvJUL4Cg8--UJYEB_lbUqc=.c81f87fa-38aa-42b2-a1e7-869dce5f6c20@github.com>
Message-ID: <LggfdCF8gVlZ_G0T9XNS-7RH0yzUUvf-8VfoXb7zAe8=.f7cf5cb8-49a7-4209-a604-491fa7542c7b@github.com>

On Mon, 15 Apr 2024 14:21:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
>> 
>> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).
>
> Per Minborg 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 ten additional commits since the last revision:
> 
>  - Update after comments
>  - Merge branch 'master' into ms-reinterpret2
>  - Update src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Fix imports and copyright
>  - Update maxByteAlignment docs
>  - Improve doc and tests
>  - Add a MS::maxByteAlignment method

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18779#pullrequestreview-2001722291

From naoto at openjdk.org  Mon Apr 15 17:49:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 Apr 2024 17:49:01 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
In-Reply-To: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
Message-ID: <8XB7WchTfZ4cEDoe5bKLnUxO-FL-X3cru824WZ3DzY4=.6c8a8ca8-00fa-480f-baac-f0ae36337a04@github.com>

On Wed, 10 Apr 2024 20:16:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
> 
> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
> 
> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
> 
> I will update the CSR once the wording is finalized.

Comments for the `CompactNumberFormat`.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 50:

> 48:  * <p>
> 49:  * {@code CompactNumberFormat} is a concrete subclass of {@code NumberFormat}
> 50:  * that formats a decimal number in a {@link Locale localized} compact form.

Same as in the NumberFormat

src/java.base/share/classes/java/text/CompactNumberFormat.java line 63:

> 61:  * <ul>
> 62:  * <li> Use {@link NumberFormat#getCompactNumberInstance()}
> 63:  * to obtain a {@code CompactNumberFormat} for the default locale.

Might add `Style.SHORT` as the default too

src/java.base/share/classes/java/text/CompactNumberFormat.java line 74:

> 72:  * <small>Note: It is recommended to use one of the NumberFormat factory methods
> 73:  * which is tailored to the conventions of the given locale to retrieve a
> 74:  * CompactNumberFormat.</small>

Not sure using the small font would make any significance here. Also, I'd make this a conditional sentence, i.e, if the user wants the standard formatting for a locale and a style, to avoid blind recommendation.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 98:

> 96:  * The {@code compactPatterns} in {@link
> 97:  * CompactNumberFormat#CompactNumberFormat(String, DecimalFormatSymbols, String[])
> 98:  * CompactNumberFormat(decimalPattern, symbols, compactPatterns}} are represented

Nit: `}` -> `)`

src/java.base/share/classes/java/text/CompactNumberFormat.java line 103:

> 101:  *
> 102:  * <p><b>For those planning to only use the factory methods, the pattern syntax may
> 103:  * not be relevant. If this is the case, continue reading at the {@link ##formatting

Instead of adding reading suggestions like this in bold text, how about moving this `Compact Number Patterns` section to the very end of the class description, as it is less important for normal usage?

src/java.base/share/classes/java/text/CompactNumberFormat.java line 129:

> 127:  * minimum integer digits, and suffix. The negative subpattern
> 128:  * is optional, if absent, then the positive subpattern prefixed with the
> 129:  * minus sign ({@code '-'}) is used as the negative

The code point and its name should be preserved. "minus sign" can be ambiguous, as "MINUS SIGN" code point is actually `U+2212`

src/java.base/share/classes/java/text/CompactNumberFormat.java line 142:

> 140:  * {@linkplain DecimalFormat##special_pattern_character Special characters},
> 141:  * on the other hand, stand for other characters, strings, or classes of
> 142:  * characters. These characters must be quoted using single quotes ({@code '})

Same as above

src/java.base/share/classes/java/text/CompactNumberFormat.java line 154:

> 152:  * </sup>) in the US locale can be specified as the SimplePattern: {@code "0 Million"}, for the
> 153:  * German locale it can be specified as the PluralPattern:
> 154:  * {@code "{one:0' 'Million other:0' 'Millionen}"}.

I like the German example, however, I think the original explanation for the pattern should be preserved (wording might be better though)

src/java.base/share/classes/java/text/CompactNumberFormat.java line 207:

> 205:  * {@link java.math.RoundingMode} for formatting.  By default, it uses
> 206:  * {@link java.math.RoundingMode#HALF_EVEN RoundingMode.HALF_EVEN}.
> 207:  *

Any reason for this part to move before the `Parsing` section?

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

PR Review: https://git.openjdk.org/jdk/pull/18731#pullrequestreview-1998701154
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563335521
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563346260
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563343344
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563354139
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563353485
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563355976
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1563356745
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566208653
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566221378

From sgibbons at openjdk.org  Mon Apr 15 18:00:27 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 15 Apr 2024 18:00:27 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v16]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <rbBwiswWopqq54mqApEMPcVshEWlEl8pZN15qjIRVNQ=.621539d7-ec86-4f2c-b194-fd2ba429a7df@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Rename UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark} (#19)
  
  * Even more review comments
  
  * Re-write of atomic copy loops
  
  * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/405e4e05..95b0a345

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=14-15

  Stats: 359 lines in 18 files changed: 0 ins; 184 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Mon Apr 15 18:14:28 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 15 Apr 2024 18:14:28 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v17]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <x8QxOQmycFwgIzHPucdzQ6Gj7tyfoWE900g6SZClNt8=.6cf45c61-3c83-4f1f-b5cb-da6800734de4@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

 - Set memory test (#22)
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill
 - Set memory test (#21)
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill
 - Only add a memory mark for byte unaligned fill
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/95b0a345..80b5a0ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Mon Apr 15 18:26:29 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 15 Apr 2024 18:26:29 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v18]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <2VVnuafwN24kMcJV42NKZNskaYtefC4tqKLf6So5D_E=.2f46075b-a5f1-4f09-80fa-60f0aa28511c@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Set memory test (#23)
  
  * Even more review comments
  
  * Re-write of atomic copy loops
  
  * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
  
  * Only add a memory mark for byte unaligned fill
  
  * Remove MUSL_LIBC ifdef
  
  * Remove MUSL_LIBC ifdef

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/80b5a0ca..856464e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=16-17

  Stats: 50 lines in 1 file changed: 0 ins; 49 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From mchung at openjdk.org  Mon Apr 15 18:38:05 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 15 Apr 2024 18:38:05 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v27]
In-Reply-To: <EKyawoFgA1Yx9kLdw8lIXLYIQmC0ZYIk0hQ-zerCzaE=.57387714-7fac-4ee1-8fb4-c4232294da9f@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <EKyawoFgA1Yx9kLdw8lIXLYIQmC0ZYIk0hQ-zerCzaE=.57387714-7fac-4ee1-8fb4-c4232294da9f@github.com>
Message-ID: <P6RMo8GpoYCB-4tKWh520JW1awLxaXrapi7n8_82sV4=.be6e09c0-1f97-4ac9-bc47-d816420b8071@github.com>

On Mon, 15 Apr 2024 16:10:38 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - new line
>  - spaces fix
>  - spaces fix

Copying the library from JDK and renamed as `.a` is not the best idea.  I am not sure how much work to execute the tool chain on AIX to generate a proper archive for a shared object.    It's okay with me with this approach provided that the AIX Reviewer approves it.

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 43:

> 41:     // launches a java application passing this directory through "-Djava.library.path".
> 42:     // the java application then attempts to load the library using System.loadLibrary()
> 43:     public static void main(final String[] args) throws Exception {

Suggestion:

    public static void main(String[] args) throws Exception {


You can drop `final` in the method signature and local variables below in the method body.

test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 53:

> 51:         final Path testNativeLibDir = Path.of("native").toAbsolutePath();
> 52:         Files.createDirectories(testNativeLibDir);
> 53:         final Path libDummyArchive = testNativeLibDir.resolve(archiveFileName);

Suggestion:

       Path libFooBarArchive = testNativeLibDir.resolve(archiveFileName);


Nit: match the expected library name.

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

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-2001874277
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566259916
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566262563

From mdoerr at openjdk.org  Mon Apr 15 18:38:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 15 Apr 2024 18:38:06 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <VTwCG6CpkaHwdOcJFcxpTlgvcam2jZvcf6QmZpYZmJk=.a7d7f30a-2417-4240-8296-2937382a0e6f@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
 <td3uEuDe6GbPatRN4stD9q_o0BRC36OYLUFXZ-ZeCWo=.3b63222e-b874-4d68-9cb8-87d265a615be@github.com>
 <VTwCG6CpkaHwdOcJFcxpTlgvcam2jZvcf6QmZpYZmJk=.a7d7f30a-2417-4240-8296-2937382a0e6f@github.com>
Message-ID: <afgIlZXhNfpHR7bWnA0J807hKX3u8SMgy_i5j8PV5nk=.98223c58-51ee-47dc-be3f-3276ae2cf84f@github.com>

On Mon, 15 Apr 2024 16:07:14 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java line 71:
>> 
>>> 69:         }
>>> 70:     }
>>> 71: }
>> 
>> I think files typically have a newline at the end.
>
> In ClassLoader i didnt see it. Put newline at end for both files now

Now, you have an empty line. I only requested a newline after the last non-empty line. But, ok. (It was shown by a red '-' by GitHub.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566271248

From mdoerr at openjdk.org  Mon Apr 15 18:38:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 15 Apr 2024 18:38:06 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v27]
In-Reply-To: <EKyawoFgA1Yx9kLdw8lIXLYIQmC0ZYIk0hQ-zerCzaE=.57387714-7fac-4ee1-8fb4-c4232294da9f@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <EKyawoFgA1Yx9kLdw8lIXLYIQmC0ZYIk0hQ-zerCzaE=.57387714-7fac-4ee1-8fb4-c4232294da9f@github.com>
Message-ID: <g2TMVZSRTlBV2iHy7UbDPP-RyANQGHgIX6VTCtfXX54=.ab7f5c32-6043-4c17-a1f0-0b5d1386a2b9@github.com>

On Mon, 15 Apr 2024 16:10:38 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - new line
>  - spaces fix
>  - spaces fix

LGTM, now. A 2nd review is needed, especially for the test.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-2001896452

From sgibbons at openjdk.org  Mon Apr 15 18:39:20 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 15 Apr 2024 18:39:20 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v19]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <79C5LoXMAaCUiL1OY41eVXLxm_ZCDzoLoeIeNXjLo6s=.f5264a33-de11-4b51-8fa5-2455b314224d@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Merge branch 'openjdk:master' into setMemory
 - Set memory test (#23)
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill
   
   * Remove MUSL_LIBC ifdef
   
   * Remove MUSL_LIBC ifdef
 - Set memory test (#22)
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill
 - Set memory test (#21)
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill
 - Only add a memory mark for byte unaligned fill
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill
 - Rename UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark} (#19)
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
 - Change fill routines
   
   * Even more review comments
   
   * Re-write of atomic copy loops
 - Even more review comments
   
 - Addressing yet more review comments
 - Addressing more review comments
 - ... and 20 more: https://git.openjdk.org/jdk/compare/140f5671...116d7dd6

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

Changes: https://git.openjdk.org/jdk/pull/18555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=18
  Stats: 635 lines in 37 files changed: 418 ins; 6 del; 211 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Mon Apr 15 18:43:24 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 15 Apr 2024 18:43:24 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v20]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <SHMxXg2ysHqQLw8KpGeYy0WgS4RByABRGLn2RoKL1XM=.2c1a51e8-9cc9-4bf5-b2bd-c51df651f188@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Fix memory mark after sync to upstream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/116d7dd6..113aa90f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=18-19

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

PR: https://git.openjdk.org/jdk/pull/18555

From naoto at openjdk.org  Mon Apr 15 18:46:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 Apr 2024 18:46:01 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
In-Reply-To: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
Message-ID: <E7XC5Wc93mMgCdpHq02EnvBpV6AENnkLdLfd8xvjI4w=.d80bb1f8-11e0-4d99-b8e2-2b1dbbf60709@github.com>

On Wed, 10 Apr 2024 20:16:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
> 
> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
> 
> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
> 
> I will update the CSR once the wording is finalized.

Here's the last part of the comments for `DecimalFormat`

src/java.base/share/classes/java/text/DecimalFormat.java line 58:

> 56: /**
> 57:  * {@code DecimalFormat} is a concrete subclass of
> 58:  * {@code NumberFormat} that formats decimal numbers in a {@link Locale localized} manner.

Same as the other two classes.

src/java.base/share/classes/java/text/DecimalFormat.java line 93:

> 91:  * for example, {@link #getIntegerInstance(Locale)}. {@link
> 92:  * NumberFormat#getAvailableLocales()} can be used to determine if the desired
> 93:  * locale is supported.

I don't think this section is helpful, or rather, may mislead the users. As the original text explains, factory methods in `NumberFormat` do not guarantee to return `DecimalFormat` instances by design.

src/java.base/share/classes/java/text/DecimalFormat.java line 116:

> 114:  * <p><b>For those planning to only use the factory methods, the pattern syntax may
> 115:  * not be relevant. If this is the case, continue reading at the {@link ##formatting Formatting and Parsing}
> 116:  * section.</b>

As in the `CompactNumberFormat`, I suggest moving the `DecimalFormat Pattern` section at the end.

src/java.base/share/classes/java/text/DecimalFormat.java line 168:

> 166:  * localized symbol.
> 167:  * When {@link #applyLocalizedPattern(String)} is called, the default symbols lose their
> 168:  * syntactical meaning, and vice versa with {@link #applyPattern(String)} with exception

Retain the original wording that explains localized and non-localized patterns at the beginning. Using the method example for the localized patterns might be a bit jump in the context.

src/java.base/share/classes/java/text/DecimalFormat.java line 255:

> 253:  * integer digits will be derived from the pattern. This derivation is detailed
> 254:  * in the {@link ##scientific_notation Scientific Notation} section. This behavior
> 255:  * is the typical end-user desire; {@link #setMaximumIntegerDigits(int)} can be

"This behavior ... desire" can be removed.

src/java.base/share/classes/java/text/DecimalFormat.java line 263:

> 261:  * subpattern has a prefix, numeric part, and suffix. The negative subpattern
> 262:  * is optional; if absent, then the positive subpattern prefixed with the
> 263:  * minus sign ({@code '-'}) is used as the

Keep the code point/name for hyphen-minus

src/java.base/share/classes/java/text/DecimalFormat.java line 398:

> 396:  * <h3>Special Values</h3>
> 397:  * <ul>
> 398:  * <li><p><b>Not a Number</b> ({@code NaN}) is successfully formatted as a string,

I'd not add `successfully` here.

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

PR Review: https://git.openjdk.org/jdk/pull/18731#pullrequestreview-2001855368
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566248166
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566260898
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566263120
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566272248
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566279017
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566280153
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1566266870

From darcy at openjdk.org  Mon Apr 15 19:07:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Apr 2024 19:07:31 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
Message-ID: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>

Get JDK 24 underway.

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

Commit messages:
 - JDK-8330182: Start of release updates for JDK 24

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330182
  Stats: 101 lines in 37 files changed: 43 ins; 3 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From darcy at openjdk.org  Mon Apr 15 19:09:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Apr 2024 19:09:59 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <qZnKYgjUvvMiD9WCCV0lbTTyFKAymG1KEVKRZWkhIW4=.ef7a12de-81a5-48cd-af70-78a6f4253d4e@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

This initial version of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see.

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

PR Comment: https://git.openjdk.org/jdk/pull/18787#issuecomment-2057615983

From naoto at openjdk.org  Mon Apr 15 19:45:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 Apr 2024 19:45:27 GMT
Subject: RFR: 8330279: Typo in `java.text.Bidi` class description
Message-ID: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>

Fixing a typo in the javadoc

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

Commit messages:
 - initial commit

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

PR: https://git.openjdk.org/jdk/pull/18788

From iris at openjdk.org  Mon Apr 15 20:00:41 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 15 Apr 2024 20:00:41 GMT
Subject: RFR: 8330279: Typo in `java.text.Bidi` class description
In-Reply-To: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>
References: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>
Message-ID: <hCrkdPcm0Tik2hjPoOTQmmFrBEy9_FUZGKKWQ-eKpdY=.4aeacfc7-b793-4e97-b1b2-4574a611bcb3@github.com>

On Mon, 15 Apr 2024 19:39:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a typo in the javadoc

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18788#pullrequestreview-2002041316

From iris at openjdk.org  Mon Apr 15 20:00:43 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 15 Apr 2024 20:00:43 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.bffedb51-7144-4706-a4a8-34460959534a@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

The copyright year was  not updated in all files *14.java.  I assume that's intentional. 

I've also Reviewed the associated CSRs.

make/conf/version-numbers.conf line 36:

> 34: DEFAULT_VERSION_EXTRA2=0
> 35: DEFAULT_VERSION_EXTRA3=0
> 36: DEFAULT_VERSION_DATE=2024-03-17

"2024-03-17"?  I thought that the expected date was "2025-03-18"?

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2002002355
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1566336599

From joehw at openjdk.org  Mon Apr 15 20:03:40 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 15 Apr 2024 20:03:40 GMT
Subject: RFR: 8330279: Typo in `java.text.Bidi` class description
In-Reply-To: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>
References: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>
Message-ID: <jae_hEXPmdiywP2vPHk909dsFwwvbmu8FQyvuz3tOZE=.f7822a2e-5087-4423-bf0f-05e997bf7bd2@github.com>

On Mon, 15 Apr 2024 19:39:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a typo in the javadoc

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18788#pullrequestreview-2002045355

From darcy at openjdk.org  Mon Apr 15 20:23:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Apr 2024 20:23:41 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.bffedb51-7144-4706-a4a8-34460959534a@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.bffedb51-7144-4706-a4a8-34460959534a@github.com>
Message-ID: <TfadiV_C_pOGf2x7nI1pH2xU5UlQUF05uhZoD0bnCLg=.12de8d7a-cc14-4e63-a7ad-142da183d3b2@github.com>

On Mon, 15 Apr 2024 19:57:49 GMT, Iris Clark <iris at openjdk.org> wrote:

> The copyright year was not updated in all files *14.java. I assume that's intentional.

I'll run my copyright update script before pushing.

> I've also Reviewed the associated CSRs.

Thanks.

> make/conf/version-numbers.conf line 36:
> 
>> 34: DEFAULT_VERSION_EXTRA2=0
>> 35: DEFAULT_VERSION_EXTRA3=0
>> 36: DEFAULT_VERSION_DATE=2024-03-17
> 
> "2024-03-17"?  I thought that the expected date was "2025-03-18"?

Thanks for catching that; yes, I'll correct and double-check the expected GA date in the next push.

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

PR Comment: https://git.openjdk.org/jdk/pull/18787#issuecomment-2057735741
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1566383373

From tprinzing at openjdk.org  Mon Apr 15 20:44:16 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 15 Apr 2024 20:44:16 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v3]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <Givs1GzHovxqZGXwDIZfuCAclLZPlhnVAe7Zw-DmWXQ=.07b177dd-a641-4992-a00e-33999ff05719@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/8e20527e..6903c823

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=01-02

  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542

From tprinzing at openjdk.org  Mon Apr 15 20:44:17 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 15 Apr 2024 20:44:17 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
 <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
Message-ID: <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>

On Tue, 2 Apr 2024 04:48:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for AsynchronousFileChannel.force().
>
> src/java.base/share/classes/jdk/internal/event/FileForceEvent.java line 35:
> 
>> 33:  * {@link #commit(long, long, String, boolean)} method
>> 34:  * must be the same as the order of the fields.
>> 35:  */
> 
> You may have to re-word this comment to avoid confusion with the metaData parameter. That is, there is event meta data and there is file metaData, if you see what I mean.

I see what you mean.  I reworded the javadoc.

> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 50:
> 
>> 48: 
>> 49:     public static void main(String[] args) throws Throwable {
>> 50:         File blah = File.createTempFile("blah", null);
> 
> Can you change this to use the tests's scratch rather that /tmp, meaning `Files.createTempFile(Path.of("."), "blah", "jfr")`. That way the recording is available in the event that the test fails.

I'm not sure what you mean about the recording.  The file is the AsynchronousFileChannel under test and does not contain the event recording.

> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 64:
> 
>> 62: 
>> 63:             data.flip();
>> 64:             ch.write(data, 0);
> 
> This just initiates the write operation, it doesn't wait until it completes. It returns a Future so adding .get() will ensure that it waits and that there is potentially data to write back to the file system.

I do realize the write doesn't wait.  I was under the impression that flush() does wait until everything has been flushed to disk.  I went ahead and added .get() as requested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1566405842
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1566413683
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1566409791

From szaldana at openjdk.org  Mon Apr 15 21:15:08 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Mon, 15 Apr 2024 21:15:08 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
Message-ID: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>

Hi folks, 

This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 

I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 

In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.

Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 

Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 

Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 

I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 

Cheers, 
Sonia

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

Commit messages:
 - 8329581: Java launcher no longer prints a stack trace

Changes: https://git.openjdk.org/jdk/pull/18786/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329581
  Stats: 53 lines in 2 files changed: 45 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786

PR: https://git.openjdk.org/jdk/pull/18786

From duke at openjdk.org  Mon Apr 15 21:22:01 2024
From: duke at openjdk.org (Andrey Kuleshov)
Date: Mon, 15 Apr 2024 21:22:01 GMT
Subject: RFR: 8329948: Remove string template feature [v5]
In-Reply-To: <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
Message-ID: <EMJ8ppBhQWWzp9ZWwzWCIbkM0WvVwbl5lHdQQJAJnTE=.168b3b2c-1d26-40b8-9269-512087a7ca04@github.com>

On Thu, 11 Apr 2024 10:15:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
>> 
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop spurious jshell test change

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

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

PR Review: https://git.openjdk.org/jdk/pull/18688#pullrequestreview-2002188648

From vromero at openjdk.org  Mon Apr 15 21:26:02 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Apr 2024 21:26:02 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v10]
In-Reply-To: <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>
Message-ID: <LT3WcKs7Ad4ZCVttofKzOGQwSbvaZT0CuJkweYo7jyM=.fb2f6940-90cf-45fb-87f8-5e861836a247@github.com>

On Tue, 9 Apr 2024 09:28:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback:
>   - reverting unnecessary changes in TransPatterns
>   - moving the patters/withers/Model test to a more appropriate place

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18509#pullrequestreview-2002193598

From tprinzing at openjdk.org  Mon Apr 15 21:37:15 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 15 Apr 2024 21:37:15 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v7]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <b2td9S009wlsZCvjFRuodbTtrt6on3H5miCCwuK_qmo=.4491bab8-096e-4dc5-9864-66a8d45bb150@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

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

  cleanup of annotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/d10be83e..9ece2ff5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/16710

From duke at openjdk.org  Mon Apr 15 22:12:30 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 15 Apr 2024 22:12:30 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v3]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <-64Xlhk6ln43-xTmlv_cvloS-gzDrKMyiPUdPbMNlIM=.2b524654-ca5b-4a7a-a7da-316e99cfea35@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

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

  Comments from Jatin and Tony

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/82b6dae7..6f9ac046

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=01-02

  Stats: 97 lines in 20 files changed: 4 ins; 36 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

PR: https://git.openjdk.org/jdk/pull/18583

From duke at openjdk.org  Mon Apr 15 22:12:30 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 15 Apr 2024 22:12:30 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <48md2WEAhqPyuVf4AYOxBQDykUiOaEL0PQb-ki0_TYM=.6c25bf41-b0ae-49ec-b606-236deb4561e3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <YwzqZOEDfuKsay4D10uJVN77llZhRvIZxRApbPiAHz8=.a9e83ea8-7e18-437b-bc2d-3e2759558a25@github.com>
 <48md2WEAhqPyuVf4AYOxBQDykUiOaEL0PQb-ki0_TYM=.6c25bf41-b0ae-49ec-b606-236deb4561e3@github.com>
Message-ID: <XEY4YpVaEt2VGufXuBwQt9_vvdHclehli7dbyIIuoGo=.b7cb8fb3-45e6-42a3-b8f5-1ee00caf6d13@github.com>

On Wed, 10 Apr 2024 23:56:52 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Few early comments.
> 
> Please update the copyright year of all the modified files.
> 
> You can even consider splitting this into two patches, Java side changes in one and x86 optimized intrinsic in next one.

Fixed all copyright years

git diff da8a095a19c90e7ee2b45fab9b533a1092887023 | lsdiff -p1 | while read line; do echo $line =========================; grep Copyright $line | grep -v 2024; done | less

Re splitting.. probably too late for that now.. (did consider it initially.. got hard to manage two changes while developing. And easier to justify the change when the entire patch is presented? but yes, far more code to review.. )

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2057892691

From duke at openjdk.org  Mon Apr 15 22:12:30 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 15 Apr 2024 22:12:30 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <njm7imXx1Ls7Jt7nZ2mCyOR5UfCPiiT14EA8c7OAX2w=.899bdb80-6d3b-4354-99d6-e126f47a682e@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <n3KbSNXmQjwZZDFqbnehqVryLJ9FYQZzh4_bOLxymec=.4bc5a417-81e5-4dbc-819a-65924bcd2543@github.com>
 <k-S63XajUKQKl9lZkp_UzlhDjVJ6shdpqMYwTZLRPNA=.332a8e42-b4c4-4bb8-b642-df1478eda176@github.com>
 <njm7imXx1Ls7Jt7nZ2mCyOR5UfCPiiT14EA8c7OAX2w=.899bdb80-6d3b-4354-99d6-e126f47a682e@github.com>
Message-ID: <R1clBMO1jIdNiGyiC14r7oHnjNBt6JKVIC4NLdVBayU=.f208f4d0-ac2d-47a7-8fd4-ee3bd2867094@github.com>

On Thu, 11 Apr 2024 17:15:21 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>>> In `ECOperations.java`, if I understand this correctly, it is to replace the existing `PointMultiplier` with montgomery-based PointMuliplier. But when I look at the code, I see both are still options. If I read this correctly, it checks for the old `IntegerFieldModuloP`, then looks for the new `IntegerMontgomeryFieldModuloP`. It appears to use the new one always. Why doesn't it just replace the old implementation entry in the `fields` Map? Is there a reason to keep it around?
>> 
>> Hmm, thats a good point I haven't fully considered; i.e. (if I read correctly) "for `CurveDB.P_256` remove the fallback path to non-montgomery entirely".. that might also help in cleaning a few things up in the construction. Maybe even get rid of this nested ECOperations inside ECOperations.. Perhaps nesting isnt a big deal, but all attempts to make the ECC stack clearer is positive!
>> 
>> One functional reason that might justify keeping it as-is, is fuzz-testing; with the fallback available, I am able to write the included Fuzz tests and have them check the values against the existing implementation. While I also included a few KAT tests using openssl-generated values, the fuzz tests check millions of values and it does add a lot more certainty about correctness of this code.
>> 
>> Can it be removed? For the operations that do not involve multiplication (i.e. `setSum(*)`), montgomery is expensive. I think I did go through the uses of this code some time back (i.e. ECDHE, ECDSA and KeyGeneration) and existing IntegerPolynomialP256 is no longer used (I should verify that again) and only P256OrderField remains non-montgomery. So removing references to IntegerPolynomialP256 in ECOperations should be possible and cleaner. Removing IntegerPolynomialP256 from MontgomeryIntegerPolynomialP256 is harder (fromMontgomery() uses IntegerPolynomialP256) but perhaps also worth some thought..
>> 
>> I tend to like `ECOperationsFuzzTest.java` and would prefer to keep it, but it could also be chucked up as part of 'scaffolding' and removed in name of code quality?
>> 
>> Thanks @ascarpino 
>> 
>> PS: Perhaps there is some middle ground, remove the `ECOperations montgomeryOps` nesting, and construct (somehow?? singleton makes most things inaccessible..) the reference ECOperations in the fuzz test instead.. not sure how yet, but perhaps worth a further thought..
>
>> > In `ECOperations.java`, if I understand this correctly, it is to replace the existing `PointMultiplier` with montgomery-based PointMuliplier. But when I look at the code, I see both are still options. If I read this correctly, it checks for the old `IntegerFieldModuloP`, then looks for the new `IntegerMontgomeryFieldModuloP`. It appears to use the new one always. Why doesn't it just replace the old implementation entry in the `fields` Map? Is there a reason to keep it around?
>> 
>> Hmm, thats a good point I haven't fully considered; i.e. (if I read correctly) "for `CurveDB.P_256` remove the fallback path to non-montgomery entirely".. that might also help in cleaning a few things up in the construction. Maybe even get rid of this nested ECOperations inside ECOperations.. Perhaps nesting isnt a big deal, but all attempts to make the ECC stack clearer is positive!
>> 
>> One functional reason that might justify keeping it as-is, is fuzz-testing; with the fallback available, I am able to write the included Fuzz tests and have them check the values against the existing implementation. While I also included a few KAT tests using openssl-generated values, the fuzz tests check millions of values and it does add a lot more certainty about correctness of this code.
> 
> I hadn't looked at your fuzz test until you mentioned it.  I see you are using reflection to change the values.  Is that what you mean by "fallback"?  I'm assuming there is no to access the older implementation without reflection.
> 
>> 
>> Can it be removed? For the operations that do not involve multiplication (i.e. `setSum(*)`), montgomery is expensive. I think I did go through the uses of this code some time back (i.e. ECDHE, ECDSA and KeyGeneration) and existing IntegerPolynomialP256 is no longer used (I should verify that again) and only P256OrderField remains non-montgomery. So removing references to IntegerPolynomialP256 in ECOperations should be possible and cleaner. Removing IntegerPolynomialP256 from MontgomeryIntegerPolynomialP256 is harder (fromMontgomery() uses IntegerPolynomialP256) but perhaps also worth some thought..
>> 
>> I tend to like `ECOperationsFuzzTest.java` and would prefer to keep it, but it could also be chucked up as part of 'scaffolding' and removed in name of code quality?
> 
> I wouldn't rip out the old implementation.  I have been wondering if we should make the older implementation available, maybe by security property.  I was looking at the static Maps at the top of `ECOperatio...

@ascarpino Fixed as suggested... actually.. that was _waaay_ easier then I thought it would be 

(I saw singleton and assumed private constructor.. nope, ECOperations() is public, no reflection required!! Ended up with cleaner implementation _and_ cleaner tests! Thanks!)

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2057895950

From duke at openjdk.org  Mon Apr 15 22:12:31 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 15 Apr 2024 22:12:31 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <YwzqZOEDfuKsay4D10uJVN77llZhRvIZxRApbPiAHz8=.a9e83ea8-7e18-437b-bc2d-3e2759558a25@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <YwzqZOEDfuKsay4D10uJVN77llZhRvIZxRApbPiAHz8=.a9e83ea8-7e18-437b-bc2d-3e2759558a25@github.com>
Message-ID: <If_Wx-2kNpOPUBiyjADlyB1OjeEULjJ3kB8o_5NY-TQ=.ee2de277-f0b1-4121-8e31-6ae467e84d8d@github.com>

On Fri, 5 Apr 2024 07:19:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove use of jdk.crypto.ec
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 39:
> 
>> 37: };
>> 38: static address modulus_p256() {
>> 39:   return (address)MODULUS_P256;
> 
> Long constants should have UL suffix.

Properly ULL, but good point, fixed

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 386:
> 
>> 384:   __ jcc(Assembler::equal, L_Length19);
>> 385: 
>> 386:   // Default copy loop
> 
> Please add appropriate loop entry alignment.

This is actually a 'switch statement default'. The default should never happen (See "Known Length comment on line 335"), but added because java code has that behavior. (i.e. in the unlikely case NIST adds a new elliptic curve to the existing standard?)

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 394:
> 
>> 392:   __ lea(aLimbs, Address(aLimbs,8));
>> 393:   __ lea(bLimbs, Address(bLimbs,8));
>> 394:   __ jmp(L_DefaultLoop);
> 
> Both sub and cmp are flag affecting instructions and are macro-fusible. 
> By doing a loop rotation i.e. moving the length <= 0 check outside the loop and pushing the loop exit check at bottom you can save additional compare checks.

Per-above, this is a switch statement (`UNLIKELY`) fallback. I can still add alignment and loop rotation, but being a fallback figured its more important to keep it small&readable...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1566486768
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1566486717
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1566486848

From acobbs at openjdk.org  Mon Apr 15 22:15:24 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 15 Apr 2024 22:15:24 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v4]
In-Reply-To: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
Message-ID: <jrS7n6o0TKJY0RzRghI8TNcMjJVe41GV54VxEJPUd4s=.16821a69-2fd1-4f2a-96f6-74ada0a727f4@github.com>

> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
> 
> There are several issues with this:
> 
> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
> 
> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
> 
> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.

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

  Relabel "trailing garbage" as "extra bytes" to sound less accusatory.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18385/files
  - new: https://git.openjdk.org/jdk/pull/18385/files/32ff1abd..df302a62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=02-03

  Stats: 31 lines in 2 files changed: 0 ins; 0 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/18385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385

PR: https://git.openjdk.org/jdk/pull/18385

From sviswanathan at openjdk.org  Mon Apr 15 22:35:02 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 15 Apr 2024 22:35:02 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v20]
In-Reply-To: <SHMxXg2ysHqQLw8KpGeYy0WgS4RByABRGLn2RoKL1XM=.2c1a51e8-9cc9-4bf5-b2bd-c51df651f188@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <SHMxXg2ysHqQLw8KpGeYy0WgS4RByABRGLn2RoKL1XM=.2c1a51e8-9cc9-4bf5-b2bd-c51df651f188@github.com>
Message-ID: <C6MBexEv0aVUxIFD7WQVrS4x6n8JJTswLLL0Czkc6Dc=.1c443863-da55-4d21-96d7-288ecdf8c67a@github.com>

On Mon, 15 Apr 2024 18:43:24 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix memory mark after sync to upstream

These are my last set of comments. Rest looks good to me.

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2588:

> 2586:   StubCodeMark mark(this, "StubRoutines", name);
> 2587:   address start = __ pc();
> 2588: 

We are missing the __ enter() here?

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2680:

> 2678:     __ BIND(L_fillBytes);
> 2679:     {
> 2680:       const Register byteVal = rdx;

This could be removed.

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2686:

> 2684:       __ movq(rdx, rsi);
> 2685:       restore_arg_regs();
> 2686: #endif

This is stubGenerator_x86_64.cpp 64bit specific, so WIN32 portion could be removed?

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

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-1998540097
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1566504104
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1566498612
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1566498342

From sviswanathan at openjdk.org  Mon Apr 15 22:35:02 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 15 Apr 2024 22:35:02 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v14]
In-Reply-To: <SOE8BOnQndoHd-1208dollgry40e2h0BL-69QhF9aUA=.6e897576-33bf-4a01-84c8-512abac97e74@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <SOE8BOnQndoHd-1208dollgry40e2h0BL-69QhF9aUA=.6e897576-33bf-4a01-84c8-512abac97e74@github.com>
Message-ID: <w2oAD-o6QxhIq1-M5ohBq2vl6U5q4lgXsF9TRbuOfd0=.426ee8d1-7c76-4545-bd7a-d642bc9ba6fe@github.com>

On Fri, 12 Apr 2024 16:47:58 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more review comments

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2692:

> 2690:       __ BIND(L_fillBytes);
> 2691:     }
> 2692: #ifdef MUSL_LIBC

The code in #Ifdef MUSL_LIBC can be removed as we are not using the libc call in the #else path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1563287878

From jvernee at openjdk.org  Mon Apr 15 23:04:02 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 15 Apr 2024 23:04:02 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v20]
In-Reply-To: <C6MBexEv0aVUxIFD7WQVrS4x6n8JJTswLLL0Czkc6Dc=.1c443863-da55-4d21-96d7-288ecdf8c67a@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <SHMxXg2ysHqQLw8KpGeYy0WgS4RByABRGLn2RoKL1XM=.2c1a51e8-9cc9-4bf5-b2bd-c51df651f188@github.com>
 <C6MBexEv0aVUxIFD7WQVrS4x6n8JJTswLLL0Czkc6Dc=.1c443863-da55-4d21-96d7-288ecdf8c67a@github.com>
Message-ID: <yTXNIpY4jR8GexEPqbuGrlB5fFeavEB1ifaD9fkvyOk=.a39dd037-5d91-4db4-86ed-a9c5d2f4e9c1@github.com>

On Mon, 15 Apr 2024 22:22:38 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix memory mark after sync to upstream
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2686:
> 
>> 2684:       __ movq(rdx, rsi);
>> 2685:       restore_arg_regs();
>> 2686: #endif
> 
> This is stubGenerator_x86_64.cpp 64bit specific, so WIN32 portion could be removed?

`_WIN32` is also defined for 64 bit Windows

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1566523189

From sviswanathan at openjdk.org  Mon Apr 15 23:09:01 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 15 Apr 2024 23:09:01 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v20]
In-Reply-To: <yTXNIpY4jR8GexEPqbuGrlB5fFeavEB1ifaD9fkvyOk=.a39dd037-5d91-4db4-86ed-a9c5d2f4e9c1@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <SHMxXg2ysHqQLw8KpGeYy0WgS4RByABRGLn2RoKL1XM=.2c1a51e8-9cc9-4bf5-b2bd-c51df651f188@github.com>
 <C6MBexEv0aVUxIFD7WQVrS4x6n8JJTswLLL0Czkc6Dc=.1c443863-da55-4d21-96d7-288ecdf8c67a@github.com>
 <yTXNIpY4jR8GexEPqbuGrlB5fFeavEB1ifaD9fkvyOk=.a39dd037-5d91-4db4-86ed-a9c5d2f4e9c1@github.com>
Message-ID: <q_IIEKWCSDIxlJ9tXTpjB0d78m6ncHus-bSXejWw7zo=.07ead1dd-480b-4d17-b037-f6799ec7a4ed@github.com>

On Mon, 15 Apr 2024 23:01:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2686:
>> 
>>> 2684:       __ movq(rdx, rsi);
>>> 2685:       restore_arg_regs();
>>> 2686: #endif
>> 
>> This is stubGenerator_x86_64.cpp 64bit specific, so WIN32 portion could be removed?
>
> `_WIN32` is also defined for 64 bit Windows

Thanks, I missed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1566525698

From sgibbons at openjdk.org  Mon Apr 15 23:16:01 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 15 Apr 2024 23:16:01 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v20]
In-Reply-To: <q_IIEKWCSDIxlJ9tXTpjB0d78m6ncHus-bSXejWw7zo=.07ead1dd-480b-4d17-b037-f6799ec7a4ed@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <SHMxXg2ysHqQLw8KpGeYy0WgS4RByABRGLn2RoKL1XM=.2c1a51e8-9cc9-4bf5-b2bd-c51df651f188@github.com>
 <C6MBexEv0aVUxIFD7WQVrS4x6n8JJTswLLL0Czkc6Dc=.1c443863-da55-4d21-96d7-288ecdf8c67a@github.com>
 <yTXNIpY4jR8GexEPqbuGrlB5fFeavEB1ifaD9fkvyOk=.a39dd037-5d91-4db4-86ed-a9c5d2f4e9c1@github.com>
 <q_IIEKWCSDIxlJ9tXTpjB0d78m6ncHus-bSXejWw7zo=.07ead1dd-480b-4d17-b037-f6799ec7a4ed@github.com>
Message-ID: <hjNo1UPecEVaCqMDDb4HZv7YkSTZB8c3AKa7psluJUo=.0ff4a8a1-f4ec-4e5e-9da9-823d8cdfd0ef@github.com>

On Mon, 15 Apr 2024 23:06:11 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> `_WIN32` is also defined for 64 bit Windows
>
> Thanks, I missed that.

I'm changing the scheme here to c_rargX, so no need for any windows-specific stuff.  I added it when I needed 4 scratch registers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1566529530

From mchung at openjdk.org  Mon Apr 15 23:40:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 15 Apr 2024 23:40:59 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <VWsAd0aB_OM8x_sOAZySRM5DGIowggjtDyb8g9LglSc=.d0e419d7-ffc9-49ac-985e-f4ab6719d858@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 954:

> 952: 
> 953:         int mods = mainMethod.getModifiers();
> 954:         boolean isStatic = Modifier.isStatic(mods);

Can get the value for `isStatic` and `noArgs` from the main type.

src/java.base/share/native/libjli/java.c line 645:

> 643:         res = invokeInstanceMainWithoutArgs(env, mainClass);
> 644:         break;
> 645:     }

Only one of invokeXXXMainYYYArgs is called.   Looks like `CHECK_EXCEPTION_FAIL` and `CHECK_EXCEPTION_NULL_FAIL` are not needed and can use `CHECK_EXCEPTION_LEAVE` and `CHECK_EXCEPTION_NULL_LEAVE` instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1566502390
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1566545886

From sgibbons at openjdk.org  Tue Apr 16 00:04:15 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 16 Apr 2024 00:04:15 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

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

  Add enter() and leave(); remove Windows-specific register stuff

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/113aa90f..7a1d67e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=19-20

  Stats: 38 lines in 1 file changed: 1 ins; 20 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From tprinzing at openjdk.org  Tue Apr 16 00:05:33 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 16 Apr 2024 00:05:33 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v4]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <hNgZeptMgkWYNe3gJhtLygsAJ-KCcsCss-I7dLn3Le8=.6316cbb9-c745-49fb-bedd-93369665f22a@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  fix windows build issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/6903c823..70815943

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/18542

From jbhateja at openjdk.org  Tue Apr 16 02:31:02 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 16 Apr 2024 02:31:02 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <If_Wx-2kNpOPUBiyjADlyB1OjeEULjJ3kB8o_5NY-TQ=.ee2de277-f0b1-4121-8e31-6ae467e84d8d@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <YwzqZOEDfuKsay4D10uJVN77llZhRvIZxRApbPiAHz8=.a9e83ea8-7e18-437b-bc2d-3e2759558a25@github.com>
 <If_Wx-2kNpOPUBiyjADlyB1OjeEULjJ3kB8o_5NY-TQ=.ee2de277-f0b1-4121-8e31-6ae467e84d8d@github.com>
Message-ID: <LVQPV5Qrqx33ddDPJqvnFNhBj1Qmn7SV95tQE9Zvt0E=.ba94ddda-fa4c-473d-9811-365168b1a0db@github.com>

On Mon, 15 Apr 2024 22:04:14 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 394:
>> 
>>> 392:   __ lea(aLimbs, Address(aLimbs,8));
>>> 393:   __ lea(bLimbs, Address(bLimbs,8));
>>> 394:   __ jmp(L_DefaultLoop);
>> 
>> Both sub and cmp are flag affecting instructions and are macro-fusible. 
>> By doing a loop rotation i.e. moving the length <= 0 check outside the loop and pushing the loop exit check at bottom you can save additional compare checks.
>
> Per-above, this is a switch statement (`UNLIKELY`) fallback. I can still add alignment and loop rotation, but being a fallback figured its more important to keep it small&readable...

It's all part of intrinsic, no harm in polishing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1566630667

From duke at openjdk.org  Tue Apr 16 04:03:04 2024
From: duke at openjdk.org (wolfseifert)
Date: Tue, 16 Apr 2024 04:03:04 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <wdaOJZ9PAEaSZ3CBsfip2joh_AL0uapdqoBTuAq7i4U=.339f6871-ee1d-4b0d-b784-40651111a9e3@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Isn't this already fixed by https://github.com/openjdk/jdk/pull/18753?

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2058185032

From sviswanathan at openjdk.org  Tue Apr 16 04:30:02 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 16 Apr 2024 04:30:02 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
Message-ID: <Ew_EhnqVoiQ6z3LsyWmnmpFYfMfpZq2k2X0GBbIx_fc=.80c81863-de34-4111-a086-84592a0170c4@github.com>

On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add enter() and leave(); remove Windows-specific register stuff

PR looks good to me now. Thanks a lot for considering all the inputs.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-2002553946

From jpai at openjdk.org  Tue Apr 16 06:11:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 06:11:01 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v3]
In-Reply-To: <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
Message-ID: <mccvYpNsEMjpiXZk-Y-2EtDWw3mkVpJ_a4Nw3IpPr4I=.bfaf133d-022c-4460-b3ed-04be0c6d72b2@github.com>

On Wed, 10 Apr 2024 16:17:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need for {@code} in javadoc

The CSR for this has been approved. I'll integrate this PR tomorrow (around 24 hours from now).

Naoto, Roger, should we consider a release note for this change or is the CSR itself enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/18674#issuecomment-2058299189

From alanb at openjdk.org  Tue Apr 16 06:33:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 06:33:59 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <UF9P6jnNhvxYbOwWTxrJkR8N_QUAEySsOP1aTOXsA4M=.16ecc6e4-251d-4fbf-8661-e63e67f761ce@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Yes, it would be good to try the changes in pull/18753 first.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2058328338

From alanb at openjdk.org  Tue Apr 16 06:34:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 06:34:59 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
 <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
 <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
Message-ID: <R3CAyklgZnD8Oyoq8bOz5JB6RMfPm4YEFdDItA6sUa4=.36d763b8-5f78-45c7-8e55-a0158c90f7ca@github.com>

On Mon, 15 Apr 2024 20:39:26 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 64:
>> 
>>> 62: 
>>> 63:             data.flip();
>>> 64:             ch.write(data, 0);
>> 
>> This just initiates the write operation, it doesn't wait until it completes. It returns a Future so adding .get() will ensure that it waits and that there is potentially data to write back to the file system.
>
> I do realize the write doesn't wait.  I was under the impression that flush() does wait until everything has been flushed to disk.  I went ahead and added .get() as requested.

In this API, the read/write methods are asynchronous, the force method is synchronous.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1566784789

From pminborg at openjdk.org  Tue Apr 16 07:15:10 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 16 Apr 2024 07:15:10 GMT
Subject: RFR: 8330272: Fix javadocs for ValueLayout.(JAVA_LONG|JAVA_DOUBLE)
Message-ID: <32HOlXXjhG6GZvb6PsSq9hUB_Y-HOGrBZsGb9R5vlTg=.d7412e68-9675-422b-bf75-ecb8412550fb@github.com>

This PR proposes to update the javadocs for `ValueLayout.JAVA_LONG` and `ValueLayout.JAVA_DOUBLE` to reflect the changes made in https://bugs.openjdk.org/browse/JDK-8326172  (we forgot to update the docs when that issue was fixed)

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

Commit messages:
 - Update copyright year
 - Fix javadocs for ValueLayout.(JAVA_LONG|JAVA_DOUBLE)

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

PR: https://git.openjdk.org/jdk/pull/18791

From pminborg at openjdk.org  Tue Apr 16 07:43:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 16 Apr 2024 07:43:08 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v4]
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <FqEoZ6EWf2u80h0xup9vYqN2qZYBWygWB0GhDNxYRFk=.0c9353c7-c9e4-457c-979f-6caba44813ad@github.com>

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

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

 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18779/files
  - new: https://git.openjdk.org/jdk/pull/18779/files/7b45ad5c..eaf6832e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/18779

From pminborg at openjdk.org  Tue Apr 16 07:49:26 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 16 Apr 2024 07:49:26 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v5]
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <S2YcFbpgsnixJa9-TchZZazPmerVXWTKslG62JnJ0_8=.785f1539-18f7-45a9-9138-9438ceb233ad@github.com>

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

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

  Update JavaDoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18779/files
  - new: https://git.openjdk.org/jdk/pull/18779/files/eaf6832e..e971e7f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=03-04

  Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18779/head:pull/18779

PR: https://git.openjdk.org/jdk/pull/18779

From stuefe at openjdk.org  Tue Apr 16 08:04:02 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 Apr 2024 08:04:02 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <gNA1giBBLP0CTFWt-ArROqB0B34_5VAv77nbVOZW3Mk=.1e26bfc4-fc9f-4fe1-b75b-1b996de759ab@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Good find.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 912:

> 910:     private static final int MAIN_WITHOUT_ARGS = 1;
> 911:     private static final int MAIN_NONSTATIC = 2;
> 912:     private static int mainType = 0;

Nit: transferring information from java to C in this way is usually done, AFAICS, by accessing static fields directly (GetStaticFieldID+GetStaticXXXField). There is also a helper function that wraps this, see JNU_GetStaticFieldByName. Not sure if you have that available in libjli though. There are many examples for both patterns.

I also would consider just declaring two booleans here, isStatic and hasArgs, which that would be a bit clearer to read instead of combining both into a single flag variable, and no need to keep flag values synced across java/C.

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

PR Review: https://git.openjdk.org/jdk/pull/18786#pullrequestreview-2002891641
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1566896963

From alanb at openjdk.org  Tue Apr 16 08:12:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 08:12:45 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v2]
In-Reply-To: <xS9K67Z8jHZw0kpxWe33CzhQQBpJ3EX2W183pbCQqxA=.8877bbe1-0a62-42e8-83da-2f1214abefc0@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ykUHh71hzDHZPZl4_Pp0ZUC94c0HZeXiqu0FDY9OkSI=.9d98a8b1-8b46-45a7-b799-715fa3d7d0fe@github.com>
 <cllaSnL5ysKqFUGUVec3sz3WR8tuQUgy0YhKYhCsq4A=.72d15d51-a7ab-4441-8ca8-14e9e773f42e@github.com>
 <xS9K67Z8jHZw0kpxWe33CzhQQBpJ3EX2W183pbCQqxA=.8877bbe1-0a62-42e8-83da-2f1214abefc0@github.com>
Message-ID: <XKOsWkXgkV5uyIMZKTmAB0ok8UAvXVYy8JokHoG5OlY=.ed2412fc-b7ed-47fc-8d14-14a57f4e4cf9@github.com>

On Mon, 26 Feb 2024 14:17:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44:
>> 
>>> 42:     @Label("SelectionKey Count")
>>> 43:     @Description("Number of channels ready for I/O or added to ready set")
>>> 44:     public int selectionKeyCount;
>> 
>> same here
>
> Thanks for adding the timeout.

I think the description should be changed to say that it's the number of unique keys updated, nothing more. This covers the selection operations that add or update keys to the selected key set, and also the selection operations that update keys and invoke an action to consume.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1566922400

From asotona at openjdk.org  Tue Apr 16 08:27:07 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 16 Apr 2024 08:27:07 GMT
Subject: Integrated: 8329099: Undocumented exception thrown by Instruction
 factory methods accepting Opcode
In-Reply-To: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
References: <xmvQwjUPOkAbXkAsAW-LdyGN_v_Gv5WRRj3fWESlNJE=.af55d203-4a85-4bdc-8bd5-33905021f1c8@github.com>
Message-ID: <4R-Un9tGQPc4qRXh6EMyDRKmQx_Xaw0dz-hP_JxHw_0=.191d69e0-4802-4e4e-a523-691fd36e46d0@github.com>

On Tue, 2 Apr 2024 09:37:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented:
> 
> - `ArrayLoadInstruction`
> - `ArrayStoreInstruction`
> - `BranchInstruction`
> - `ConvertInstruction`
> - `DiscontinuedInstruction`
> - `FieldInstruction`
> - `InvokeInstruction`
> - `LoadInstruction`
> - `MonitorInstruction`
> - `NewPrimitiveArrayInstruction`
> - `OperatorInstruction`
> - `ReturnInstruction`
> - `StackInstruction`
> - `StoreInstruction`
> - `TypeCheckInstruction`
> 
> `NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument.
> 
> This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 97c18089
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97c180892b62ccba0041fb4480ecd2191aea0032
Stats:     48 lines in 17 files changed: 48 ins; 0 del; 0 mod

8329099: Undocumented exception thrown by Instruction factory methods accepting Opcode

Reviewed-by: briangoetz

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

PR: https://git.openjdk.org/jdk/pull/18578

From stuefe at openjdk.org  Tue Apr 16 08:28:06 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 Apr 2024 08:28:06 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <gNA1giBBLP0CTFWt-ArROqB0B34_5VAv77nbVOZW3Mk=.1e26bfc4-fc9f-4fe1-b75b-1b996de759ab@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <gNA1giBBLP0CTFWt-ArROqB0B34_5VAv77nbVOZW3Mk=.1e26bfc4-fc9f-4fe1-b75b-1b996de759ab@github.com>
Message-ID: <p_OvrmxiUNSaZPa-fjVeFcB2NLZN5ySTTD11Cx7-XgI=.5ac9300d-29eb-45bb-8a66-541cde70ee3e@github.com>

On Tue, 16 Apr 2024 07:55:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 912:
> 
>> 910:     private static final int MAIN_WITHOUT_ARGS = 1;
>> 911:     private static final int MAIN_NONSTATIC = 2;
>> 912:     private static int mainType = 0;
> 
> Nit: transferring information from java to C in this way is usually done, AFAICS, by accessing static fields directly (GetStaticFieldID+GetStaticXXXField). There is also a helper function that wraps this, see JNU_GetStaticFieldByName. Not sure if you have that available in libjli though. There are many examples for both patterns.
> 
> I also would consider just declaring two booleans here, isStatic and hasArgs, which that would be a bit clearer to read instead of combining both into a single flag variable, and no need to keep flag values synced across java/C.

Thinking about this some more, would it not be possible to just use the mainMethod directly down in C?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1566948449

From stuefe at openjdk.org  Tue Apr 16 08:28:03 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 Apr 2024 08:28:03 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <smlVvtw9AaBNUQyc0sB3IpfW58EXy9Ng-ijrIaLvyk4=.ebd62ad7-6239-45d0-9135-8963520d3e89@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

> Isn't this already fixed by #18753?

> Yes, it would be good to try the changes in pull/18753 first.

I still like @SoniaZaldana 's variant better.

AFAIU, in the original variant, we choose the main method via MethodFinder.findMainMethod, but then down in JavaMain in C we just try to invoke all variants in succession (static,args->instance,args->static,noargs->instance,noargs). Does that no mean we ignore the decision of findMainMethod?

Apart from that, it means fewer exceptions are thrown when starting the JVM if we avoid calling methods we know don't work.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2058521084

From pminborg at openjdk.org  Tue Apr 16 08:36:26 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 16 Apr 2024 08:36:26 GMT
Subject: RFR: 8329532: Add an internal MemoryLayout transformer
Message-ID: <T2o8-ydusVWV-j-_mXmqnQEQ62b4JeAdgDCyX7-uNhA=.42fad3ee-75ff-44ab-bb89-a5c374dc63d4@github.com>

This PR proposes to add an internal layout transformer that could be used to transform MemoryLayout entities. For example, it would be possible to convert a struct layout to use network order ((big-endian) instead of native byte order (often little-endian). Another application is to remove naming recursively for composite layouts when caching shapes etc.

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

Commit messages:
 - Merge branch 'master' into layout-transformer
 - Merge branch 'master' into layout-transformer
 - Make classes internal
 - Start restricting general functionality
 - Add tests
 - Add copyright headers
 - Add an internal MemoryLayout transformer

Changes: https://git.openjdk.org/jdk/pull/18582/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18582&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329532
  Stats: 358 lines in 3 files changed: 348 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18582/head:pull/18582

PR: https://git.openjdk.org/jdk/pull/18582

From clanger at openjdk.org  Tue Apr 16 09:12:44 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 16 Apr 2024 09:12:44 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <9yl5glod4xr1tHQtbwdx11ySJHlOeWgDvShpchddGCY=.e3ce9655-9946-4d0a-80f9-e34632c5cc50@github.com>

On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

To me this looks useful, although maybe the overall JLI tracing could be revisited.

src/java.base/windows/native/libjli/java_md.c line 326:

> 324:     }
> 325: 
> 326:     JLI_TraceLauncher("GetJREPath - attempt to get JRE location from shared lib of the image\n");

Maybe add a trace also in the USE_REGISTRY_LOOKUP section

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18699#pullrequestreview-2003079325
PR Review Comment: https://git.openjdk.org/jdk/pull/18699#discussion_r1567018779

From clanger at openjdk.org  Tue Apr 16 09:17:20 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 16 Apr 2024 09:17:20 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <XS1zHh8AAiKNuOatVXGN0M1ODH33IJHjbd9nhCfTN5U=.24796af3-5600-455b-b05e-d2690596135f@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <1OgWz9GmBNCQM98Kxh_mSKrlJohlYallG3rrV8hfC5A=.ffd723bb-fb67-4d9b-a7ba-1438cfa2d54e@github.com>
 <XRZWaILXsubG85zvogxU1Zp8J9uUA299IAF3Nyvkdgs=.84e18304-115f-415a-9027-eb9ef41f0322@github.com>
 <XS1zHh8AAiKNuOatVXGN0M1ODH33IJHjbd9nhCfTN5U=.24796af3-5600-455b-b05e-d2690596135f@github.com>
Message-ID: <ogl5wVzbC6u7RLZcyEFagKEFN2kWfgGxIOfEXkpk40o=.a203be94-ebf2-48f5-8dc7-7b5a24ac14e6@github.com>

On Mon, 15 Apr 2024 12:47:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > If we expand the tracing then I think it should be consistent with the existing tracing.
> 
> What exactly do you see as inconsistent ?

Maybe the output of the tracing should look similar to other traces done through `JLI_TraceLauncher`? E.g. not mention method names but just tell what the program is doing... ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2058621283

From mbaesken at openjdk.org  Tue Apr 16 09:20:59 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 16 Apr 2024 09:20:59 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <ogl5wVzbC6u7RLZcyEFagKEFN2kWfgGxIOfEXkpk40o=.a203be94-ebf2-48f5-8dc7-7b5a24ac14e6@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <1OgWz9GmBNCQM98Kxh_mSKrlJohlYallG3rrV8hfC5A=.ffd723bb-fb67-4d9b-a7ba-1438cfa2d54e@github.com>
 <XRZWaILXsubG85zvogxU1Zp8J9uUA299IAF3Nyvkdgs=.84e18304-115f-415a-9027-eb9ef41f0322@github.com>
 <XS1zHh8AAiKNuOatVXGN0M1ODH33IJHjbd9nhCfTN5U=.24796af3-5600-455b-b05e-d2690596135f@github.com>
 <ogl5wVzbC6u7RLZcyEFagKEFN2kWfgGxIOfEXkpk40o=.a203be94-ebf2-48f5-8dc7-7b5a24ac14e6@github.com>
Message-ID: <KXlA2Jjwx7d1drO8myB8gQgmlyqSP3m3bL8GL0f-xxA=.9398183b-6179-433f-8fab-86451ba5d88d@github.com>

On Tue, 16 Apr 2024 09:14:50 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > What exactly do you see as inconsistent ?
> 
> Maybe the output of the tracing should look similar to other traces done through `JLI_TraceLauncher`? E.g. not mention method names but just tell what the program is doing... ?

Okay, makes sense !  I will change that to make the output similar to existing traces.

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

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2058627174

From mcimadamore at openjdk.org  Tue Apr 16 09:43:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 Apr 2024 09:43:02 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v5]
In-Reply-To: <S2YcFbpgsnixJa9-TchZZazPmerVXWTKslG62JnJ0_8=.785f1539-18f7-45a9-9138-9438ceb233ad@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <S2YcFbpgsnixJa9-TchZZazPmerVXWTKslG62JnJ0_8=.785f1539-18f7-45a9-9138-9438ceb233ad@github.com>
Message-ID: <KQ7iO-Jf5NCdKEwmZn7oLIv8KG9Kf7CT8QKeEh7riMQ=.3d02abca-0b24-4a14-8343-be3d29cf3480@github.com>

On Tue, 16 Apr 2024 07:49:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
>> 
>> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update JavaDoc

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 612:

> 610:      * the type of the {@linkplain #heapBase() backing heap storage}.
> 611:      * <p>
> 612:      * This method can be used to ensure, a {@code segment} is sufficiently aligned

I would drop the use of code blocks for `segment` and layout. Also remove the comma after "ensure"

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

PR Review: https://git.openjdk.org/jdk/pull/18779#pullrequestreview-2003148028
PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1567059979

From mcimadamore at openjdk.org  Tue Apr 16 09:43:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 Apr 2024 09:43:02 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v5]
In-Reply-To: <KQ7iO-Jf5NCdKEwmZn7oLIv8KG9Kf7CT8QKeEh7riMQ=.3d02abca-0b24-4a14-8343-be3d29cf3480@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
 <S2YcFbpgsnixJa9-TchZZazPmerVXWTKslG62JnJ0_8=.785f1539-18f7-45a9-9138-9438ceb233ad@github.com>
 <KQ7iO-Jf5NCdKEwmZn7oLIv8KG9Kf7CT8QKeEh7riMQ=.3d02abca-0b24-4a14-8343-be3d29cf3480@github.com>
Message-ID: <9RHtK20XWJtXXESE8HgTh7hA2Ab9ZXCRJuCch1VA4Q8=.aa1b1d5a-506f-441d-8732-f9496bc92caf@github.com>

On Tue, 16 Apr 2024 09:39:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update JavaDoc
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 612:
> 
>> 610:      * the type of the {@linkplain #heapBase() backing heap storage}.
>> 611:      * <p>
>> 612:      * This method can be used to ensure, a {@code segment} is sufficiently aligned
> 
> I would drop the use of code blocks for `segment` and layout. Also remove the comma after "ensure"

Also, "ensure _that_ a memory segment is ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18779#discussion_r1567060697

From mcimadamore at openjdk.org  Tue Apr 16 09:43:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 Apr 2024 09:43:42 GMT
Subject: RFR: 8330272: Wrong javadoc for ValueLayout.JAVA_LONG/JAVA_DOUBLE
 on x86 32bit
In-Reply-To: <32HOlXXjhG6GZvb6PsSq9hUB_Y-HOGrBZsGb9R5vlTg=.d7412e68-9675-422b-bf75-ecb8412550fb@github.com>
References: <32HOlXXjhG6GZvb6PsSq9hUB_Y-HOGrBZsGb9R5vlTg=.d7412e68-9675-422b-bf75-ecb8412550fb@github.com>
Message-ID: <kUzsfKLPgEouQaI-b--0DKAy36ytJDVpvnAbt8sf_dY=.dfd1d51c-d6e8-41fe-be42-66954fe7c59b@github.com>

On Tue, 16 Apr 2024 07:09:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to update the javadocs for `ValueLayout.JAVA_LONG` and `ValueLayout.JAVA_DOUBLE` to reflect the changes made in https://bugs.openjdk.org/browse/JDK-8326172  (we forgot to update the docs when that issue was fixed)

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18791#pullrequestreview-2003149464

From egahlin at openjdk.org  Tue Apr 16 09:57:43 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 16 Apr 2024 09:57:43 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v7]
In-Reply-To: <b2td9S009wlsZCvjFRuodbTtrt6on3H5miCCwuK_qmo=.4491bab8-096e-4dc5-9864-66a8d45bb150@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <b2td9S009wlsZCvjFRuodbTtrt6on3H5miCCwuK_qmo=.4491bab8-096e-4dc5-9864-66a8d45bb150@github.com>
Message-ID: <2e7U55ctKvbrJFOR7c4eVqBMQSQZUKDeyCI-3cl7cHg=.9acd2a67-a426-4db5-83ae-2642423b1f61@github.com>

On Mon, 15 Apr 2024 21:37:15 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup of annotations

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 43:

> 41: 
> 42:     @Label("Timeout Value")
> 43:     @Description("time to block, or zero to block indefinitely")

Sentence should start with a capital letter. I think "Timeout" is sufficient, no need to have "Value" in the label.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1567082204

From dholmes at openjdk.org  Tue Apr 16 10:05:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Apr 2024 10:05:43 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v2]
In-Reply-To: <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>
Message-ID: <60QWkeHKhL_dpiRpz_ftvPDPG2K2LzvF90s3GcecgrA=.3845b0c8-d83b-4cb6-9d38-54079f27cf17@github.com>

On Mon, 15 Apr 2024 07:36:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class MainClass {
>>     public MainClass() {
>>         System.out.println("Constructor called!");
>>     }
>>     public static void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> and compile and run it, with preview enabled, like:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> Constructor called!
>> main called!
>> 
>> 
>> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
>> 
>> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
>> 
>> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
>> 
>> There is also a relatively closely related problem: what happens when the constructor throws an exception?
>> 
>> public class MainClass {
>>     public MainClass() {
>>         if (true) throw new RuntimeException();
>>     }
>>     public void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> 
>> when compiled an run, this produces no output whatsoever:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> $
>> 
>> 
>> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
>> 
>> $ java --enable-preview -classpath /tmp/ MainClass 
>> Exception in thread "main" java.lang.RuntimeException
>>         at MainClass.<init>(MainClass.java:3)
>> 
>> 
>> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

src/java.base/share/native/libjli/java.c line 419:

> 417: invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs) {
> 418:     jmethodID constructor = (*env)->GetMethodID(env, mainClass, "<init>", "()V");
> 419:     CHECK_EXCEPTION_FAIL();

Shouldn't this also not be checked until you know you have an instance method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18753#discussion_r1567092479

From alanb at openjdk.org  Tue Apr 16 10:22:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 10:22:42 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <usYxk8PzNPW_UkywGlH3zM4r9kdbYW7Y0Ly6Kd0QL0U=.2c412f7d-2fb5-4d80-905e-0e7f32ac7e05@github.com>

On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

I think this is way too ad hoc and looks like lefts over from a debugging session. So I don't think it should be integrated without stepping back and thinking more about what this tracing option is intended for.

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

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2058746338

From mcimadamore at openjdk.org  Tue Apr 16 10:26:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 Apr 2024 10:26:00 GMT
Subject: RFR: 8329532: Add an internal MemoryLayout transformer
In-Reply-To: <T2o8-ydusVWV-j-_mXmqnQEQ62b4JeAdgDCyX7-uNhA=.42fad3ee-75ff-44ab-bb89-a5c374dc63d4@github.com>
References: <T2o8-ydusVWV-j-_mXmqnQEQ62b4JeAdgDCyX7-uNhA=.42fad3ee-75ff-44ab-bb89-a5c374dc63d4@github.com>
Message-ID: <92sii2QMer0he6534Q9lqHeawPj3gvgMsM-K8LrasGE=.7c77a424-bce8-486e-8915-256b23f86e60@github.com>

On Tue, 2 Apr 2024 15:04:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add an internal layout transformer that could be used to transform MemoryLayout entities. For example, it would be possible to convert a struct layout to use network order ((big-endian) instead of native byte order (often little-endian). Another application is to remove naming recursively for composite layouts when caching shapes etc.

src/java.base/share/classes/jdk/internal/foreign/layout/LayoutTransformers.java line 83:

> 81:          * @param layout to transform
> 82:          */
> 83:         MemoryLayout transform(T layout);

Not too sure about having a distinction between transform and deepTransform, at least not for the use cases we have so far. I'd say just keep the semantics of deepTransform, so that this becomes a functional interface?

src/java.base/share/classes/jdk/internal/foreign/layout/LayoutTransformers.java line 179:

> 177:         private static <T extends MemoryLayout> MemoryLayout transformFlat(LayoutTransformer<T> transformer, MemoryLayout l) {
> 178:             LayoutTransformerImpl<T> t = (LayoutTransformerImpl<T>) transformer;
> 179:             return switch (t.type) {

Why the big switch here? Aren't all arms just passing the layouts to the transform? As the method is already unchecked, perhaps simplifying the code and using e.g. raw types might be a better option, as it would make the code more readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18582#discussion_r1567116664
PR Review Comment: https://git.openjdk.org/jdk/pull/18582#discussion_r1567114126

From alanb at openjdk.org  Tue Apr 16 10:33:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 10:33:00 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <p_OvrmxiUNSaZPa-fjVeFcB2NLZN5ySTTD11Cx7-XgI=.5ac9300d-29eb-45bb-8a66-541cde70ee3e@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <gNA1giBBLP0CTFWt-ArROqB0B34_5VAv77nbVOZW3Mk=.1e26bfc4-fc9f-4fe1-b75b-1b996de759ab@github.com>
 <p_OvrmxiUNSaZPa-fjVeFcB2NLZN5ySTTD11Cx7-XgI=.5ac9300d-29eb-45bb-8a66-541cde70ee3e@github.com>
Message-ID: <IGTiiJu4jiDizPEcJEgQUhKuQA_MgPSZ0p7HYR3JR9c=.0e2fd0dd-7297-4c39-9924-0119691e725b@github.com>

On Tue, 16 Apr 2024 08:25:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 912:
>> 
>>> 910:     private static final int MAIN_WITHOUT_ARGS = 1;
>>> 911:     private static final int MAIN_NONSTATIC = 2;
>>> 912:     private static int mainType = 0;
>> 
>> Nit: transferring information from java to C in this way is usually done, AFAICS, by accessing static fields directly (GetStaticFieldID+GetStaticXXXField). There is also a helper function that wraps this, see JNU_GetStaticFieldByName. Not sure if you have that available in libjli though. There are many examples for both patterns.
>> 
>> I also would consider just declaring two booleans here, isStatic and hasArgs, which that would be a bit clearer to read instead of combining both into a single flag variable, and no need to keep flag values synced across java/C.
>
> Thinking about this some more, would it not be possible to just use the mainMethod directly down in C?

The changes JEP 463 went through many iterations, it was a fine balance of avoiding too many transitions and upscales, and at the same time, have something that can be maintained. There are several JBS issues on this issue now, probably because there just wasn't enough tests introduced with the JEP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1567124485

From mcimadamore at openjdk.org  Tue Apr 16 10:35:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 Apr 2024 10:35:41 GMT
Subject: RFR: 8329532: Add an internal MemoryLayout transformer
In-Reply-To: <T2o8-ydusVWV-j-_mXmqnQEQ62b4JeAdgDCyX7-uNhA=.42fad3ee-75ff-44ab-bb89-a5c374dc63d4@github.com>
References: <T2o8-ydusVWV-j-_mXmqnQEQ62b4JeAdgDCyX7-uNhA=.42fad3ee-75ff-44ab-bb89-a5c374dc63d4@github.com>
Message-ID: <XM2eY32D2c2jbDqXnwb64OAYUfLiIB-JBrFYstbwAwM=.d2e94385-2444-4783-9dd2-5e134a3b19ac@github.com>

On Tue, 2 Apr 2024 15:04:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add an internal layout transformer that could be used to transform MemoryLayout entities. For example, it would be possible to convert a struct layout to use network order ((big-endian) instead of native byte order (often little-endian). Another application is to remove naming recursively for composite layouts when caching shapes etc.

src/java.base/share/classes/jdk/internal/foreign/layout/LayoutTransformers.java line 46:

> 44:  * A JDK-internal utility class that provides useful layout transformations.
> 45:  */
> 46: public final class LayoutTransformers {

In my experience when thinking about this problem, I always found that writing a layout transformer as a method implemented by pattern matching is almost always a better choice. The problem with going down that path is that it's a little verbose in cases where no transform needs to occur. Let's consider the endianness case:


MemoryLayout setEndianness(MemoryLayout layout, ByteOrder order) {
     return switch (layout) {
           case ValueLayout vl -> yield vl.order(order);
           case SequenceLayout sl -> yield MemoryLayout.sequenceLayout(sl.elementCount(), setEndianness(sl.elementLayout(), order);
           case StructLayout stl -> yield MemoryLayout.structLayout(stl.memberLayouts().stream().map(e -> setEndianness(e, order));
           ...
}


The problem with this is that the arms where "nothing" happens need to draw a lot of attention, as they need to contain the code which recursively propagates the transform.

But what if we had a single utility like this:


MemoryLayout adaptContents(MemoryLayout, UnaryOperator<MemoryLayout>)


Which takes care of applying a transform recursively on the _contents_ of a nested layout (e.g. sequence layout element, or the members of a group layout). Then the above becomes:


MemoryLayout setEndianness(MemoryLayout layout, ByteOrder order) {
     return switch (layout) {
           case ValueLayout vl -> yield vl.order(order);
           default -> yield layout.adaptContents(e -> setEndianness(e, order));
     }
}


Which is quite simple.

And, the remove names transform can be even simpler:


MemoryLayout removeNames(MemoryLayout layout) {
     return layout.adaptContents(this::removeNames).withoutName();
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18582#discussion_r1567127736

From vklang at openjdk.org  Tue Apr 16 11:13:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 16 Apr 2024 11:13:05 GMT
Subject: Integrated: 8196106: Support nested infinite or recursive flat mapped
 streams
In-Reply-To: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
References: <ZSn6MWILVgLHG8R-ijfEr6GtdrQ1QFHODcjz367dC1w=.eafd50d5-90d6-4804-bf8b-749d76d8bf4c@github.com>
Message-ID: <dNvA2gXHb3ifmC6ke449xGY6rndNxtSgQGGyFJpPkVw=.42861311-c07d-4496-801d-24b1c2a2ae71@github.com>

On Thu, 4 Apr 2024 12:18:07 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it is both competitive performance-wise as well as improve correctness.
> 
> Below is the performance of `Stream::flatMap` (for reference types):
> 
> Before this PR (on my MacBook, aarch64):
> 
> Non-short-circuiting:
> 
> Benchmark                 (size)   Mode  Cnt        Score       Error  Units
> FlatMap.par_array             10  thrpt   12   257582,480 ? 31360,242  ops/s
> FlatMap.par_array            100  thrpt   12    55202,015 ? 14011,668  ops/s
> FlatMap.par_array           1000  thrpt   12     6546,252 ?  3675,764  ops/s
> FlatMap.par_doublestream      10  thrpt   12   267423,410 ? 37338,089  ops/s
> FlatMap.par_doublestream     100  thrpt   12    27140,703 ?  4979,878  ops/s
> FlatMap.par_doublestream    1000  thrpt   12     2978,178 ?  1890,250  ops/s
> FlatMap.par_intstream         10  thrpt   12   268194,530 ? 37295,092  ops/s
> FlatMap.par_intstream        100  thrpt   12    30897,034 ?  5388,245  ops/s
> FlatMap.par_intstream       1000  thrpt   12     3969,043 ?  2494,641  ops/s
> FlatMap.par_longstream        10  thrpt   12   279756,861 ? 19519,497  ops/s
> FlatMap.par_longstream       100  thrpt   12    45733,955 ? 18385,144  ops/s
> FlatMap.par_longstream      1000  thrpt   12     5115,615 ?  4147,237  ops/s
> FlatMap.seq_array             10  thrpt   12  2937192,934 ? 58605,583  ops/s
> FlatMap.seq_array            100  thrpt   12    41859,462 ?   139,021  ops/s
> FlatMap.seq_array           1000  thrpt   12      442,677 ?     1,041  ops/s
> FlatMap.seq_doublestream      10  thrpt   12  4972651,093 ? 35997,267  ops/s
> FlatMap.seq_doublestream     100  thrpt   12    99265,005 ?   193,497  ops/s
> FlatMap.seq_doublestream    1000  thrpt   12     1037,030 ?     3,254  ops/s
> FlatMap.seq_intstream         10  thrpt   12  5133751,888 ? 23516,294  ops/s
> FlatMap.seq_intstream        100  thrpt   12   145166,206 ?   399,263  ops/s
> FlatMap.seq_intstream       1000  thrpt   12     1565,004 ?     3,207  ops/s
> FlatMap.seq_longstream        10  thrpt   12  5047029,363 ? 24742,300  ops/s
> FlatMap.seq_longstream       100  thrpt   12   233225,307 ?  7162,604  ops/s
> FlatMap.seq_longstream      1000  thrpt   12     2999,926 ?     9,945  ops/s
> 
> // Short-circuiting:
> 
> Benchmark                   (size)   Mode  Cnt       Score       Error  Units
> FlatMap.par_iterate_double      10  thrpt   12   46336,834 ?  6803,751  ops/s
> FlatMap.par_iterate_double     100  thrpt   12   15365,884 ?  2750,656  ops/s
> FlatMap.par_iterate_double    1000 ...

This pull request has now been integrated.

Changeset: 8a5b86c5
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a5b86c52954f6917acfda11df183691beb07f56
Stats:     609 lines in 9 files changed: 422 ins; 69 del; 118 mod

8196106: Support nested infinite or recursive flat mapped streams

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/jdk/pull/18625

From alanb at openjdk.org  Tue Apr 16 11:37:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 11:37:06 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
Message-ID: <2oYovRHOXaq7f1-_yuHOx8Q65i_Z5HVse63hkRyE0Ek=.aacaf8e9-defc-4dc7-a9d3-d0260755dfba@github.com>

On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move CreateLinkableRuntimePlugin to build folder
>>   
>>   Keep runtime link supporting classes in package
>>   jdk.tools.jlink.internal.runtimelink
>
> Thanks for the investigation w.r.t. extending jimage.  It does not seem worth the effort in pursuing the support of adding resources to an existing jimage file.   To me, putting the diff data under `lib` directory as a private file is a simpler and acceptable solution.   It allows the second jlink invocation to avoid the plugin pipeline if the per-module metadata is generated in normal jlink invocation.
> 
> (An observation: The current implementation requires the diffs to be generated as a plugin.  For this approach, it may be possible to implement with a separate main class that calls JLink API and generates the diffs.)

> @mlchung @AlanBateman Any thoughts on this latest version? Is this going into the direction you had envisioned? Any more blockers? The CSR should be up-to-date and is open for review as well. If no more blockers I'll go over this patch once more and clean it up to prepare for integration. Thanks!

Thanks for all the efforts on this. I've looked through the latest version. I'm a little bit comfortable with LinkDeltaProducer. One reason it's build tool that is tied tied to code in the jdk.jlink module, and secondly is that it copies runtime-image-link.delta into the run-time image. Our long standing position is that the run-time image is created by jlink rather than a combination of jlink and extra stuff copied in by the build.

The part that I like with the current proposal is lib/runtime-image-link.delta as it's less complicated that previous iterations that added a resource into the jimage container.

What would you (and @mlchung) think of having jlink generate lib/runtime-image-link.delta as a step between the pipeline and image generation?

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2058876568

From sgehwolf at openjdk.org  Tue Apr 16 12:01:51 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 16 Apr 2024 12:01:51 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
Message-ID: <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>

On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move CreateLinkableRuntimePlugin to build folder
>>   
>>   Keep runtime link supporting classes in package
>>   jdk.tools.jlink.internal.runtimelink
>
> Thanks for the investigation w.r.t. extending jimage.  It does not seem worth the effort in pursuing the support of adding resources to an existing jimage file.   To me, putting the diff data under `lib` directory as a private file is a simpler and acceptable solution.   It allows the second jlink invocation to avoid the plugin pipeline if the per-module metadata is generated in normal jlink invocation.
> 
> (An observation: The current implementation requires the diffs to be generated as a plugin.  For this approach, it may be possible to implement with a separate main class that calls JLink API and generates the diffs.)

> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going into the direction you had envisioned? Any more blockers? The CSR should be up-to-date and is open for review as well. If no more blockers I'll go over this patch once more and clean it up to prepare for integration. Thanks!
> 
> Thanks for all the efforts on this.

Thanks for looking at this, Alan!

> I've looked through the latest version. I'm a little bit comfortable with LinkDeltaProducer. One reason it's build tool that is tied tied to code in the jdk.jlink module, and secondly is that it copies runtime-image-link.delta into the run-time image. Our long standing position is that the run-time image is created by jlink rather than a combination of jlink and extra stuff copied in by the build.
> 
> The part that I like with the current proposal is lib/runtime-image-link.delta as it's less complicated that previous iterations that added a resource into the jimage container.
> 
> What would you (and @mlchung) think of having jlink generate lib/runtime-image-link.delta as a step between the pipeline and image generation?

If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2058919838

From tprinzing at openjdk.org  Tue Apr 16 12:17:57 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 16 Apr 2024 12:17:57 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v8]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <_ul2bqHU83nbOfCRBRRMtOYwohfbdbuPelFYmCGXJDU=.50e0eea5-a0e1-4258-bb40-054d0b1d6012@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

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

  more annotation fixup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/9ece2ff5..e896c4ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/16710

From jvernee at openjdk.org  Tue Apr 16 12:45:59 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 16 Apr 2024 12:45:59 GMT
Subject: RFR: 8330272: Wrong javadoc for ValueLayout.JAVA_LONG/JAVA_DOUBLE
 on x86 32bit
In-Reply-To: <32HOlXXjhG6GZvb6PsSq9hUB_Y-HOGrBZsGb9R5vlTg=.d7412e68-9675-422b-bf75-ecb8412550fb@github.com>
References: <32HOlXXjhG6GZvb6PsSq9hUB_Y-HOGrBZsGb9R5vlTg=.d7412e68-9675-422b-bf75-ecb8412550fb@github.com>
Message-ID: <2ncPDJOaHerutBxF8OR6n4WJ5pEoL0D7eGX-mbRlJNE=.1b4a15f2-0bb0-4040-bfe2-6c351c3f83c3@github.com>

On Tue, 16 Apr 2024 07:09:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to update the javadocs for `ValueLayout.JAVA_LONG` and `ValueLayout.JAVA_DOUBLE` to reflect the changes made in https://bugs.openjdk.org/browse/JDK-8326172  (we forgot to update the docs when that issue was fixed)

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18791#pullrequestreview-2003521381

From jlahoda at openjdk.org  Tue Apr 16 13:30:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 16 Apr 2024 13:30:00 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v2]
In-Reply-To: <60QWkeHKhL_dpiRpz_ftvPDPG2K2LzvF90s3GcecgrA=.3845b0c8-d83b-4cb6-9d38-54079f27cf17@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>
 <60QWkeHKhL_dpiRpz_ftvPDPG2K2LzvF90s3GcecgrA=.3845b0c8-d83b-4cb6-9d38-54079f27cf17@github.com>
Message-ID: <n5excUnMvX63LJUltd6q6KF0ENgDG0dlbJ7Sm08GFyg=.58982933-f494-4c01-a004-6c72b4171cb6@github.com>

On Tue, 16 Apr 2024 10:03:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/java.base/share/native/libjli/java.c line 419:
> 
>> 417: invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs) {
>> 418:     jmethodID constructor = (*env)->GetMethodID(env, mainClass, "<init>", "()V");
>> 419:     CHECK_EXCEPTION_FAIL();
> 
> Shouldn't this also not be checked until you know you have an instance method?

You mean to first check whether the method exists, and only then try to lookup the constructor? Not sure if that has observable effects, but I can do that.

I missed [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581) before, my plan is to adjust this "check for exception and clear it" check to only work for `NoSuchMethodError`, and let the exception pass for any other exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18753#discussion_r1567361164

From alanb at openjdk.org  Tue Apr 16 13:57:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 13:57:51 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
 <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>
Message-ID: <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>

On Tue, 16 Apr 2024 11:59:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?

I think it continues to build time, it's just using some hidden jlink option. So yes, it similar to a previous iteration except that it doesn't run as a plugin the pipeline and the delta goes to the lib directory.

Let's see what @mlchung says. You've put a lot of work into this so let's see if we can converge to avoid too many more rounds.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2059157584

From jvernee at openjdk.org  Tue Apr 16 14:14:03 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 16 Apr 2024 14:14:03 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v4]
In-Reply-To: <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
Message-ID: <OvTATV03nGgwnaa2FAkfK1fbWIbbq-XvpqvzDsgH7rU=.477dd0bd-ab01-41d3-9b0c-57cd82e9ab1c@github.com>

On Mon, 15 Apr 2024 14:02:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

src/java.base/share/classes/java/lang/foreign/package-info.java line 114:

> 112:  *
> 113:  * Here, we obtain a {@linkplain java.lang.foreign.Linker#nativeLinker() native linker}
> 114:  * and we use it to {@linkplain java.lang.foreign.SymbolLookup#findOrThrow(java.lang.String)}

Looks like the plain text was dropped here:
Suggestion:

 * and we use it to {@linkplain java.lang.foreign.SymbolLookup#findOrThrow(java.lang.String) look up}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1567435862

From szaldana at openjdk.org  Tue Apr 16 14:30:02 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 16 Apr 2024 14:30:02 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <UF9P6jnNhvxYbOwWTxrJkR8N_QUAEySsOP1aTOXsA4M=.16ecc6e4-251d-4fbf-8661-e63e67f761ce@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <UF9P6jnNhvxYbOwWTxrJkR8N_QUAEySsOP1aTOXsA4M=.16ecc6e4-251d-4fbf-8661-e63e67f761ce@github.com>
Message-ID: <SwCP0KCYY2LWE9WqKRUJcJxNMzHtkekBKpL6Y_bTuY4=.2986868a-bca9-40bf-b7ee-29462ce27718@github.com>

On Tue, 16 Apr 2024 06:30:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Yes, it would be good to try the changes in pull/18753 first.

@AlanBateman  @wolfseifert  Thanks for the comments!

Just wanted to note that I tried out https://github.com/openjdk/jdk/pull/18753 and the issue is not resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2059229527

From mbaesken at openjdk.org  Tue Apr 16 14:32:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 16 Apr 2024 14:32:01 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <9yl5glod4xr1tHQtbwdx11ySJHlOeWgDvShpchddGCY=.e3ce9655-9946-4d0a-80f9-e34632c5cc50@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <9yl5glod4xr1tHQtbwdx11ySJHlOeWgDvShpchddGCY=.e3ce9655-9946-4d0a-80f9-e34632c5cc50@github.com>
Message-ID: <fJ1ohG-TqLas634eWxwSbIcwox4Tqyy6cRJZniDeoto=.f0b70d67-0f83-407d-a97b-1334a5da1099@github.com>

On Tue, 16 Apr 2024 09:09:00 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> src/java.base/windows/native/libjli/java_md.c line 326:
> 
>> 324:     }
>> 325: 
>> 326:     JLI_TraceLauncher("GetJREPath - attempt to get JRE location from shared lib of the image\n");
> 
> Maybe add a trace also in the USE_REGISTRY_LOOKUP section

Hi Christoph, seems the USE_REGISTRY_LOOKUP is currently unused  (at least without additional defines that are not present usually) 

src/java.base/windows/native/libjli/java_md.c:52:#ifdef USE_REGISTRY_LOOKUP
src/java.base/windows/native/libjli/java_md.c:333:#ifdef USE_REGISTRY_LOOKUP


I am not sure if this even works any more.  Maybe Alan could comment on this ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18699#discussion_r1567466784

From mbaesken at openjdk.org  Tue Apr 16 14:39:00 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 16 Apr 2024 14:39:00 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <usYxk8PzNPW_UkywGlH3zM4r9kdbYW7Y0Ly6Kd0QL0U=.2c412f7d-2fb5-4d80-905e-0e7f32ac7e05@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <usYxk8PzNPW_UkywGlH3zM4r9kdbYW7Y0Ly6Kd0QL0U=.2c412f7d-2fb5-4d80-905e-0e7f32ac7e05@github.com>
Message-ID: <uI_uAHjoo_Dnb0jAzAj-7NL_uqBM0gnAtVtDp4GTnss=.170e00c4-03f3-4946-bf18-09b07a1efa1e@github.com>

On Tue, 16 Apr 2024 10:20:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think this is way too ad hoc and looks like lefts over from a debugging session. So I don't think it should be integrated without stepping back and thinking more about what this tracing option is intended for.

Currently there seem to be two (with the unused registry stuff 3, if it is still valid ?) approaches to find the 'JRE'  location  (should this better be named image location?)  -  using the launcher exe location  and using the location of the libjli shared lib.
Unfortunately those approaches are not well supported by JLI-traces , this is what the change is about.
We could probably adjust/reduce the added tracing code but I would like to know a bit more about the concerns raised.

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

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2059252352

From jkratochvil at openjdk.org  Tue Apr 16 14:44:07 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 16 Apr 2024 14:44:07 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
Message-ID: <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - Make find_ro static and local to compilation unit
>  - 8261242: [Linux] OSContainer::is_containerized() returns true

IMHO `is_containerized()` is OK to return `false` even when running in a container but with no limitations set.

Container detection is IIUC/AFAIK being used to maximize resource usage by OpenJDK. But if OpenJDK runs in a container with the same limits as the hardware box OpenJDK should still use reduced resources as it is sharing them with other processes on the hardware box.

[is-containerized.patch.txt](https://github.com/openjdk/jdk/files/14998503/is-containerized.patch.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2059261807

From jpai at openjdk.org  Tue Apr 16 14:59:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 14:59:44 GMT
Subject: RFR: 8329596: Add test for virtual threads invoking synchronized
 native methods
In-Reply-To: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
References: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
Message-ID: <dAWcZeAlmhOMCJJkfVCJPdKkofFryIStBddjNQE4MNU=.1a2cbd9d-d0cc-4304-a592-002f1e257a45@github.com>

On Wed, 3 Apr 2024 10:52:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only addition to add a test for virtual threads invoking a synchronized native method and invoking a native method that enter/exits a monitor with JNI MonitorEnter/MonitorExit. The test has been in the loom repo for some time, it can move to the main line in advance of changes to the object monitor implementation.

The java side of this test looks OK to me.

I see that for testing concurrent/contended access we aren't doing nested monitor enters. Does it deserve to be tested?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18600#pullrequestreview-2003899439

From sgehwolf at openjdk.org  Tue Apr 16 15:19:41 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 16 Apr 2024 15:19:41 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
Message-ID: <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>

On Tue, 16 Apr 2024 14:40:46 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> IMHO `is_containerized()` is OK to return `false` even when running in a container but with no limitations set.

The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints. In order to do this, we need a reliable way to distinguish that vs. non-containerized setup. If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2059344194

From alanb at openjdk.org  Tue Apr 16 15:50:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 15:50:59 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <fJ1ohG-TqLas634eWxwSbIcwox4Tqyy6cRJZniDeoto=.f0b70d67-0f83-407d-a97b-1334a5da1099@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <9yl5glod4xr1tHQtbwdx11ySJHlOeWgDvShpchddGCY=.e3ce9655-9946-4d0a-80f9-e34632c5cc50@github.com>
 <fJ1ohG-TqLas634eWxwSbIcwox4Tqyy6cRJZniDeoto=.f0b70d67-0f83-407d-a97b-1334a5da1099@github.com>
Message-ID: <epgrFzLmSDn6hDbb9CuGw-63a_mBWtzzkgrzd4SJuo0=.b2f0bd16-772c-404c-be69-7179f57492e8@github.com>

On Tue, 16 Apr 2024 14:29:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I am not sure if this even works any more. Maybe Alan could comment on this ?

The GetPublicJREHome function was removed at some point, I think JDK 9, as it didn't make sense to have in the OpenJDK project. However, Oracle installer did depend on it and will require a bit of effort to see if removing it now will cause an issue now or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18699#discussion_r1567595933

From dfuchs at openjdk.org  Tue Apr 16 15:52:01 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 16 Apr 2024 15:52:01 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
 <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
 <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
Message-ID: <Hir2Q2tiv3y9Kqp1KN3RcqjApN7NgFkxfXZFbX0BWkU=.546adb1f-094c-4ad6-bffb-4294c0dde3e5@github.com>

On Mon, 15 Apr 2024 20:41:10 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 50:
>> 
>>> 48: 
>>> 49:     public static void main(String[] args) throws Throwable {
>>> 50:         File blah = File.createTempFile("blah", null);
>> 
>> Can you change this to use the tests's scratch rather that /tmp, meaning `Files.createTempFile(Path.of("."), "blah", "jfr")`. That way the file is available in the event that the test fails.
>
> I'm not sure what you mean about the recording.  The file is the AsynchronousFileChannel under test and does not contain the event recording.

It's anyway better to create temporary files in the test scratch directory rather than in /tmp. This way the temp files get cleaned up with the test, and there less chances of conflicts if several tests are running concurrently (and less chances on slowly filling up /tmp onthe machine if clean up actions fail)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1567596755

From duke at openjdk.org  Tue Apr 16 15:59:27 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 16 Apr 2024 15:59:27 GMT
Subject: RFR: 8326951: Missing `@since` tags [v6]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <I2ZFj5-LA3hPsv2Z7cfc4FbNWeH5MV3Wjp73HdoPrsU=.3ca00bb7-e692-4127-aff7-294229ba9f58@github.com>

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

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

  removed change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/97f4c946..390a21f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/18055

From naoto at openjdk.org  Tue Apr 16 16:08:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Apr 2024 16:08:00 GMT
Subject: RFR: 8330279: Typo in `java.text.Bidi` class description
In-Reply-To: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>
References: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>
Message-ID: <Vsir8GvKvKK4-ODdDL0ogkb5pFI5OYWmzk1xGWjPiVU=.43de1f7c-bf88-441b-8e62-ecc7c30c0cbe@github.com>

On Mon, 15 Apr 2024 19:39:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a typo in the javadoc

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/18788#issuecomment-2059441642

From naoto at openjdk.org  Tue Apr 16 16:08:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Apr 2024 16:08:01 GMT
Subject: Integrated: 8330279: Typo in `java.text.Bidi` class description
In-Reply-To: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>
References: <Cu4IK9hl-Fey4A19EZ9PRUnyOXQF64LEHUSn5gAWIjc=.56a4a29a-adc1-4cae-a385-31af5280e129@github.com>
Message-ID: <onLvLJ22z48RJ4Wd2vkaT4ekKA_pVAXBXVlFw_CsF4s=.361755e6-6696-4658-a575-2ab11115c11a@github.com>

On Mon, 15 Apr 2024 19:39:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a typo in the javadoc

This pull request has now been integrated.

Changeset: 2ede1433
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ede14335a2c9133bf4f356189cfbd5839361d17
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8330279: Typo in `java.text.Bidi` class description

Reviewed-by: iris, joehw

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

PR: https://git.openjdk.org/jdk/pull/18788

From jlu at openjdk.org  Tue Apr 16 16:21:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Apr 2024 16:21:06 GMT
Subject: Integrated: 8327640: Allow NumberFormat strict parsing
In-Reply-To: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
Message-ID: <fUZBCw_pmtd2nDPlMD2QbqA5AQf8QKzzvPVgRQxXxLY=.793c3768-771c-402a-97ba-e924c9ae4eae@github.com>

On Mon, 18 Mar 2024 06:24:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
> 
> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
> 
> Below is an example of the change, the CSR can be viewed for further detail.
> 
> 
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
> 
> 
> The associated tests are all localized, and the data is converted properly during runtime.

This pull request has now been integrated.

Changeset: 941bee19
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/941bee197ff679e9b8755cad117f5172e3508ef2
Stats:     1603 lines in 12 files changed: 1499 ins; 33 del; 71 mod

8327640: Allow NumberFormat strict parsing

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/18339

From naoto at openjdk.org  Tue Apr 16 16:51:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Apr 2024 16:51:00 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v3]
In-Reply-To: <mccvYpNsEMjpiXZk-Y-2EtDWw3mkVpJ_a4Nw3IpPr4I=.bfaf133d-022c-4460-b3ed-04be0c6d72b2@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
 <mccvYpNsEMjpiXZk-Y-2EtDWw3mkVpJ_a4Nw3IpPr4I=.bfaf133d-022c-4460-b3ed-04be0c6d72b2@github.com>
Message-ID: <2VPOo9c-eNE30mZY-bx3Agh_4YaSRU4FRJoKIDtUJR4=.4469bb77-15c2-4117-8fc3-e63dd1d15ba7@github.com>

On Tue, 16 Apr 2024 06:08:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Naoto, Roger, should we consider a release note for this change or is the CSR itself enough?

I think CSR is enough, as users' chance of encountering any issue is very slim. My $0.02

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

PR Comment: https://git.openjdk.org/jdk/pull/18674#issuecomment-2059524742

From jlu at openjdk.org  Tue Apr 16 17:12:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Apr 2024 17:12:06 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v2]
In-Reply-To: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
Message-ID: <Qxmjk3F-nKo5nnWOW4mAwcl_KNB9a_6sPSrCkj7NphI=.d2505e28-88fc-4334-8521-552b479b1355@github.com>

> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
> 
> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
> 
> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
> 
> I will update the CSR once the wording is finalized.

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

 - merge master and add setStrict() to nFmt class spec
 - implement suggestions from dFmt review
 - implement suggestions from cnFmt review
 - implement suggestions from nFmt review
 - init

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

Changes: https://git.openjdk.org/jdk/pull/18731/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18731&range=01
  Stats: 597 lines in 3 files changed: 233 ins; 204 del; 160 mod
  Patch: https://git.openjdk.org/jdk/pull/18731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18731/head:pull/18731

PR: https://git.openjdk.org/jdk/pull/18731

From jlu at openjdk.org  Tue Apr 16 17:12:07 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Apr 2024 17:12:07 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v2]
In-Reply-To: <E7XC5Wc93mMgCdpHq02EnvBpV6AENnkLdLfd8xvjI4w=.d80bb1f8-11e0-4d99-b8e2-2b1dbbf60709@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
 <E7XC5Wc93mMgCdpHq02EnvBpV6AENnkLdLfd8xvjI4w=.d80bb1f8-11e0-4d99-b8e2-2b1dbbf60709@github.com>
Message-ID: <zoMrPd4Y3KqpqYwOdJQwoskWdD98bZyXaqo13T3Q0fY=.d3fab3ae-7b7b-4ae4-9615-4f4fdd360bb6@github.com>

On Mon, 15 Apr 2024 18:43:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - merge master and add setStrict() to nFmt class spec
>>  - implement suggestions from dFmt review
>>  - implement suggestions from cnFmt review
>>  - implement suggestions from nFmt review
>>  - init
>
> Here's the last part of the comments for `DecimalFormat`

@naotoj The latest commits should implement your batch of suggestions. I have also re-built the docs and specdiff with these changes.

> src/java.base/share/classes/java/text/CompactNumberFormat.java line 154:
> 
>> 152:  * </sup>) in the US locale can be specified as the SimplePattern: {@code "0 Million"}, for the
>> 153:  * German locale it can be specified as the PluralPattern:
>> 154:  * {@code "{one:0' 'Million other:0' 'Millionen}"}.
> 
> I like the German example, however, I think the original explanation for the pattern should be preserved (wording might be better though)

I originally removed it because the syntax already covered proper usage. But I can see how it can be confusing at first to understand. I re-inserted the original wording, but modified it IMO to be easier to understand.

> src/java.base/share/classes/java/text/CompactNumberFormat.java line 207:
> 
>> 205:  * {@link java.math.RoundingMode} for formatting.  By default, it uses
>> 206:  * {@link java.math.RoundingMode#HALF_EVEN RoundingMode.HALF_EVEN}.
>> 207:  *
> 
> Any reason for this part to move before the `Parsing` section?

I moved it before `Parsing` as it is related to formatting, so its better under the `Formatting` section.

All the other CompactNumberFormat comments should be implemented as well.

> src/java.base/share/classes/java/text/DecimalFormat.java line 93:
> 
>> 91:  * for example, {@link #getIntegerInstance(Locale)}. {@link
>> 92:  * NumberFormat#getAvailableLocales()} can be used to determine if the desired
>> 93:  * locale is supported.
> 
> I don't think this section is helpful, or rather, may mislead the users. As the original text explains, factory methods in `NumberFormat` do not guarantee to return `DecimalFormat` instances by design.

OK, that's a good point. In all 3 of these classes, I adjusted the wording to recommend using the factory methods for a locale's standard formatting. However, I made it apparent that the resultant Object can be any subclass of NumberFormat, and that if users want to cast, (so that they have access to the subclass instance methods), they should do appropriate type checking first.

All the other DecimalFormat comments you left should be implemented as well.

> src/java.base/share/classes/java/text/NumberFormat.java line 118:
> 
>> 116:  *
>> 117:  * <h2>Customizing NumberFormat</h2>
>> 118:  * {@code NumberFormat} provides API to customize formatting and parsing behavior,
> 
> Could make this PR a dependent PR of the leniency PR, and add `setStrict()` here as well.

The leniency PR was integrated, I directly added setStrict() to this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/18731#issuecomment-2059552391
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567700054
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567696852
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567696727
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567698329

From jlu at openjdk.org  Tue Apr 16 17:12:07 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Apr 2024 17:12:07 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v2]
In-Reply-To: <Qxmjk3F-nKo5nnWOW4mAwcl_KNB9a_6sPSrCkj7NphI=.d2505e28-88fc-4334-8521-552b479b1355@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
 <Qxmjk3F-nKo5nnWOW4mAwcl_KNB9a_6sPSrCkj7NphI=.d2505e28-88fc-4334-8521-552b479b1355@github.com>
Message-ID: <RsOeSz70WJPm23cA4TKmijtiLdasFk_nxzlnDXNjuI8=.86c06542-2004-43fa-86b0-e14056d3db43@github.com>

On Tue, 16 Apr 2024 17:09:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
>> 
>> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
>> 
>> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
>> 
>> I will update the CSR once the wording is finalized.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - merge master and add setStrict() to nFmt class spec
>  - implement suggestions from dFmt review
>  - implement suggestions from cnFmt review
>  - implement suggestions from nFmt review
>  - init

src/java.base/share/classes/java/text/NumberFormat.java line 115:

> 113:  * attributes or key/type pairs.
> 114:  * <p>Below is an example of a "US" locale currency format with accounting style,
> 115:  * <blockquote>{@code NumberFormat.getInstance(Locale.forLanguageTag("en-US-u-cf-account"));}</blockquote>

I replaced the previous Thai digits example with an account currency format style, as it is probably a more common use case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567697780

From mchung at openjdk.org  Tue Apr 16 17:48:06 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 16 Apr 2024 17:48:06 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
Message-ID: <s_uOH8IjNFwQeoQb4AUbEF5eBvxvGAOWjXHmRc0VmBc=.941dd182-8341-44d7-82b2-13708867c514@github.com>

On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move CreateLinkableRuntimePlugin to build folder
>>   
>>   Keep runtime link supporting classes in package
>>   jdk.tools.jlink.internal.runtimelink
>
> Thanks for the investigation w.r.t. extending jimage.  It does not seem worth the effort in pursuing the support of adding resources to an existing jimage file.   To me, putting the diff data under `lib` directory as a private file is a simpler and acceptable solution.   It allows the second jlink invocation to avoid the plugin pipeline if the per-module metadata is generated in normal jlink invocation.
> 
> (An observation: The current implementation requires the diffs to be generated as a plugin.  For this approach, it may be possible to implement with a separate main class that calls JLink API and generates the diffs.)

> What would you (and @mlchung) think of having jlink generate lib/runtime-image-link.delta as a step between the pipeline and image generation?

I have similar thought before I went on vacation last week and also think that this would allow this be further simplified to one single jlink invocation to produce a linkable image.

In `ImageFileCreator::generateJImage`, after the plugin pipeline, it already adds a step to record the per-module meta information as additional resources.   The delta file can be generated after that comparing the original resource pool with the transformed resource pool.  I believe `allContent` has the original content. 

If it is a single jlink step to produce a linkable image (generate the delta file after the plugin pipeline before generating the image), we might be able to get rid of `--ignore-modified-runtime` by storing a copy of conf files in the delta file and the original conf files will be used when the linkable image is used to create a new runtime image. 

[An observation from the above, it might be possible to generate the delta file and insert in the jimage :-)  This might be a bonus.  ]

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2059631414

From sgibbons at openjdk.org  Tue Apr 16 17:50:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 16 Apr 2024 17:50:45 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
Message-ID: <zI7Vj3a51Vbf_Q7YFlier1sBygt2tkKbnLXg_KbFauk=.79558adb-81f5-49f8-874a-f21562f5f1a1@github.com>

On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add enter() and leave(); remove Windows-specific register stuff

I ran the benchmark again using a branch from openjdk today against this modification.  Performance increased an average of 4.98x (max - 7.52x (unsafe 64-byte aligned), min - 3.02x (panama 255-byte aligned), stddev - 0.94x).

I'll integrate after a second review has been done.  Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2059637042

From vromero at openjdk.org  Tue Apr 16 18:17:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Apr 2024 18:17:42 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <8gjzk6jIhtLXgFgNO4udYRJaCCZkto2IE9ETZYZeSig=.04b09b83-0299-440f-bffa-b6da681fb462@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2004323374

From stuefe at openjdk.org  Tue Apr 16 18:29:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 Apr 2024 18:29:04 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
Message-ID: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - Make find_ro static and local to compilation unit
>  - 8261242: [Linux] OSContainer::is_containerized() returns true

I am not enough of a container expert to judge if the basic approach is right - I trust you on this. This is just a technical code review.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 170:

> 168:     }
> 169:   }
> 170:   return false;

An alternative, simpler, no need for modifying source string:

static bool find_ro_opt(const char* o) {
  return strcmp(o, "ro") || strstr(o, ",ro") || strstr(o, "ro,");
}

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 351:

> 349:     //
> 350:     // We collect the read only mount option in the cgroup infos so as to have that
> 351:     // info ready when determining is_containerized().

Here, and in other places: a comment indicating the line format we scan would be appreciated, possibly with argument numbers. Saves the casual code reader from looking into proc man page. Even just pasting the example line for proc manpage would be fine (https://man7.org/linux/man-pages/man5/proc.5.html) (but with order adapted to your scanf call, they count major:minor as one)

src/hotspot/os/linux/osContainer_linux.cpp line 78:

> 76:   const char *reason;
> 77:   bool any_mem_cpu_limit_present = false;
> 78:   bool ctrl_ro = cgroup_subsystem->is_containerized();

nit: naming? what does ctrl mean in this case? Maybe use "cgroup_is_containerized"?

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 375:

> 373:         if (!c.isContainerized()) {
> 374:             ostream.println(INDENT + "System not containerized.");
> 375:             return;

Why return here? Would this not cut the output short in the non-containerized case?

And if this not intended, the not-containerized-`-XshowSettings:system` test below should test and catch this (e.g. scan for CPU set)

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

PR Review: https://git.openjdk.org/jdk/pull/18201#pullrequestreview-1999328503
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1564182879
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567756663
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567774124
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567779248

From stuefe at openjdk.org  Tue Apr 16 18:29:05 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 Apr 2024 18:29:05 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
Message-ID: <HrCfJ_QTcggLdq-EC_tT7bfoAeDxjxYxzjONnP_RkA4=.5e5a2271-f25e-4eb1-a844-0bb2079149bb@github.com>

On Sat, 13 Apr 2024 18:29:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf 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 ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - jcheck fixes
>>  - Fix tests
>>  - Implement Metrics.isContainerized()
>>  - Some clean-up
>>  - Drop cgroups testing on plain Linux
>>  - Implement fall-back logic for non-ro controller mounts
>>  - Make find_ro static and local to compilation unit
>>  - 8261242: [Linux] OSContainer::is_containerized() returns true
>
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 170:
> 
>> 168:     }
>> 169:   }
>> 170:   return false;
> 
> An alternative, simpler, no need for modifying source string:
> 
> static bool find_ro_opt(const char* o) {
>   return strcmp(o, "ro") || strstr(o, ",ro") || strstr(o, "ro,");
> }

Please disregard my comment. Albeit longer, your version is clearer to read and more fault tolerant.

> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 351:
> 
>> 349:     //
>> 350:     // We collect the read only mount option in the cgroup infos so as to have that
>> 351:     // info ready when determining is_containerized().
> 
> Here, and in other places: a comment indicating the line format we scan would be appreciated, possibly with argument numbers. Saves the casual code reader from looking into proc man page. Even just pasting the example line for proc manpage would be fine (https://man7.org/linux/man-pages/man5/proc.5.html) (but with order adapted to your scanf call, they count major:minor as one)

Trying to parse the `%s%*[^-]-`

So, %s parses the mount options, until we encounter whitespace. Then %*[^-]- parses everything that is not a dash, until we encounter the dash? Then we eat the dash? This is to skip the optionals?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567754861
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567767209

From rriggs at openjdk.org  Tue Apr 16 19:21:44 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Apr 2024 19:21:44 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v3]
In-Reply-To: <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
Message-ID: <OO8zBu-aSWPtUR2L_H1kwGyDYqHj_eC2R-NES0dYObg=.6b36fe29-cd72-402a-bc15-23a44ae86b23@github.com>

On Wed, 10 Apr 2024 16:17:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need for {@code} in javadoc

Marked as reviewed by rriggs (Reviewer).

The CSR is enough, no-one else except the filer will even notice.

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

PR Review: https://git.openjdk.org/jdk/pull/18674#pullrequestreview-2004434418
PR Comment: https://git.openjdk.org/jdk/pull/18674#issuecomment-2059771876

From rriggs at openjdk.org  Tue Apr 16 19:49:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Apr 2024 19:49:07 GMT
Subject: RFR: 8329805: Deprecate for removal ObjectOutputStream.PutField.write
Message-ID: <jJX_F7zdz-XzBzmPjHkq3sOxW3N-I9Pff1vKO2TIn1M=.5d0b6e21-2614-44b0-b1d6-a6c9d57b9b4d@github.com>

The method `java.io.ObjectOutputStream.PutField.write` has been deprecated since 1.4 and should be deprecated for removal. The Deprecation annotation is updated to indicate the intention to remov the method.

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

Commit messages:
 - 8329805: Deprecate for removal ObjectOutputStream.PutField.write

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

PR: https://git.openjdk.org/jdk/pull/18802

From liach at openjdk.org  Tue Apr 16 21:24:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Apr 2024 21:24:59 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.e279fc9e-895a-4b17-85c8-f79635539145@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:

> 1479:     int JAVA_23_VERSION = 67;
> 1480: 
> 1481:     /** 68 */

We need `@since 24` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1567955182

From naoto at openjdk.org  Tue Apr 16 21:38:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Apr 2024 21:38:03 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v2]
In-Reply-To: <Qxmjk3F-nKo5nnWOW4mAwcl_KNB9a_6sPSrCkj7NphI=.d2505e28-88fc-4334-8521-552b479b1355@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
 <Qxmjk3F-nKo5nnWOW4mAwcl_KNB9a_6sPSrCkj7NphI=.d2505e28-88fc-4334-8521-552b479b1355@github.com>
Message-ID: <hpOvPSQI_gAU2anRJ8HAIWO3od_AC0Idktj8nxt349E=.930b3184-f916-404a-b65e-3fc391cf715b@github.com>

On Tue, 16 Apr 2024 17:12:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
>> 
>> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
>> 
>> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
>> 
>> I will update the CSR once the wording is finalized.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - merge master and add setStrict() to nFmt class spec
>  - implement suggestions from dFmt review
>  - implement suggestions from cnFmt review
>  - implement suggestions from nFmt review
>  - init

Thanks for the changes. Looks much better.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 78:

> 76:  * installed. Thus, to use an instance method defined by {@code CompactNumberFormat},
> 77:  * the {@code NumberFormat} returned by the factory method should first be type
> 78:  * checked before cast to {@code CompactNumberFormat}. If the installed locale-sensitive

Since `CompactNumberFormat` does not provide its own instance methods (i.e., instance methods are exactly the same as the parent NumberFormat), "instance methods defined by CompactNF" does not make much sense, which is different for `DecimalFormat`.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 80:

> 78:  * checked before cast to {@code CompactNumberFormat}. If the installed locale-sensitive
> 79:  * service implementation does not support the given locale, {@link Locale#ROOT}
> 80:  * will be used as a fallback.

Same with `NumberFormat`.

src/java.base/share/classes/java/text/DecimalFormat.java line 88:

> 86:  * NumberFormat nFmt = NumberFormat.getCurrencyInstance(Locale.US);
> 87:  * if (nFmt instanceof DecimalFormat dFmt) {
> 88:  *     // cast to DecimalFormat to use setPositiveSuffix(String)

This comment seems incorrect. No casting is made here.

src/java.base/share/classes/java/text/DecimalFormat.java line 421:

> 419:  * @see          DecimalFormatSymbols
> 420:  * @see          ParsePosition
> 421:  * @see          Locale

Can be removed

src/java.base/share/classes/java/text/NumberFormat.java line 91:

> 89:  * for example, {@link #getIntegerInstance(Locale)}. If the installed locale-sensitive
> 90:  * service implementation does not support the given {@code Locale}, {@link Locale#ROOT}
> 91:  * will be used as the fallback {@code Locale}.

The fallback traverses the parent locales, and checks if it is supported or not. So it may or may not reach Locale.ROOT. How about "it looks up the parent locale chain and uses the one that is supported" or something along the lines?

src/java.base/share/classes/java/text/NumberFormat.java line 235:

> 233:  * @see          ChoiceFormat
> 234:  * @see          CompactNumberFormat
> 235:  * @see          Locale

Could be removed as the link is now gone

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

PR Review: https://git.openjdk.org/jdk/pull/18731#pullrequestreview-2004548849
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567948678
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567949084
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567963269
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567966048
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567910502
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567937751

From naoto at openjdk.org  Tue Apr 16 21:38:04 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Apr 2024 21:38:04 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v2]
In-Reply-To: <RsOeSz70WJPm23cA4TKmijtiLdasFk_nxzlnDXNjuI8=.86c06542-2004-43fa-86b0-e14056d3db43@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
 <Qxmjk3F-nKo5nnWOW4mAwcl_KNB9a_6sPSrCkj7NphI=.d2505e28-88fc-4334-8521-552b479b1355@github.com>
 <RsOeSz70WJPm23cA4TKmijtiLdasFk_nxzlnDXNjuI8=.86c06542-2004-43fa-86b0-e14056d3db43@github.com>
Message-ID: <m3tqkwcc_zE-O-_acOqrxtBeQj9dNXYGRJFi9YYau08=.6a22c986-755b-46b3-93dc-9c2d0fafda3c@github.com>

On Tue, 16 Apr 2024 17:06:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - merge master and add setStrict() to nFmt class spec
>>  - implement suggestions from dFmt review
>>  - implement suggestions from cnFmt review
>>  - implement suggestions from nFmt review
>>  - init
>
> src/java.base/share/classes/java/text/NumberFormat.java line 115:
> 
>> 113:  * attributes or key/type pairs.
>> 114:  * <p>Below is an example of a "US" locale currency format with accounting style,
>> 115:  * <blockquote>{@code NumberFormat.getInstance(Locale.forLanguageTag("en-US-u-cf-account"));}</blockquote>
> 
> I replaced the previous Thai digits example with an account currency format style, as it is probably a more common use case.

Good. I think adding the expectation would be more helpful, such as, "accounting style, that is, a negative value is enclosed in parentheses instead of a prepended minus sign."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1567934872

From naoto at openjdk.org  Tue Apr 16 22:03:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Apr 2024 22:03:03 GMT
Subject: RFR: 8329805: Deprecate for removal
 ObjectOutputStream.PutField.write
In-Reply-To: <jJX_F7zdz-XzBzmPjHkq3sOxW3N-I9Pff1vKO2TIn1M=.5d0b6e21-2614-44b0-b1d6-a6c9d57b9b4d@github.com>
References: <jJX_F7zdz-XzBzmPjHkq3sOxW3N-I9Pff1vKO2TIn1M=.5d0b6e21-2614-44b0-b1d6-a6c9d57b9b4d@github.com>
Message-ID: <9nUnGVbzawr3ksTIz9A_VcYPo7pZ5VvOhswkv7gSiqM=.36e3fe2e-ee0c-4b08-98d2-783b37a2a979@github.com>

On Tue, 16 Apr 2024 19:44:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The method `java.io.ObjectOutputStream.PutField.write` has been deprecated since 1.4 and should be deprecated for removal. The Deprecation annotation is updated to indicate the intention to remov the method.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18802#pullrequestreview-2004666210

From jlu at openjdk.org  Tue Apr 16 22:34:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Apr 2024 22:34:10 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v3]
In-Reply-To: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
Message-ID: <zNufwihi1VH94YzZFAqiH9Kux-lGQIa-1NBiIOZnnT4=.b793245a-ade0-4966-8043-ce93cee9775b@github.com>

> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
> 
> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
> 
> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
> 
> I will update the CSR once the wording is finalized.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  implement further feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18731/files
  - new: https://git.openjdk.org/jdk/pull/18731/files/477970a4..95626d94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18731&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18731&range=01-02

  Stats: 10 lines in 3 files changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18731/head:pull/18731

PR: https://git.openjdk.org/jdk/pull/18731

From jlu at openjdk.org  Tue Apr 16 22:34:12 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Apr 2024 22:34:12 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v2]
In-Reply-To: <hpOvPSQI_gAU2anRJ8HAIWO3od_AC0Idktj8nxt349E=.930b3184-f916-404a-b65e-3fc391cf715b@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
 <Qxmjk3F-nKo5nnWOW4mAwcl_KNB9a_6sPSrCkj7NphI=.d2505e28-88fc-4334-8521-552b479b1355@github.com>
 <hpOvPSQI_gAU2anRJ8HAIWO3od_AC0Idktj8nxt349E=.930b3184-f916-404a-b65e-3fc391cf715b@github.com>
Message-ID: <OibvVo0qSlVXOZwhZELdta1vqk8lKTxVOHBHliZBoqI=.e511d50f-5920-4fc0-88b3-2441b7df1ccb@github.com>

On Tue, 16 Apr 2024 21:14:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - merge master and add setStrict() to nFmt class spec
>>  - implement suggestions from dFmt review
>>  - implement suggestions from cnFmt review
>>  - implement suggestions from nFmt review
>>  - init
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 78:
> 
>> 76:  * installed. Thus, to use an instance method defined by {@code CompactNumberFormat},
>> 77:  * the {@code NumberFormat} returned by the factory method should first be type
>> 78:  * checked before cast to {@code CompactNumberFormat}. If the installed locale-sensitive
> 
> Since `CompactNumberFormat` does not provide its own instance methods (i.e., instance methods are exactly the same as the parent NumberFormat), "instance methods defined by CompactNF" does not make much sense, which is different for `DecimalFormat`.

`CompactNumberFormat` does define its own instance methods such as `setParseBigDecimal`, `setGroupingSize`, etc, so I think that this wording should still be included.

> src/java.base/share/classes/java/text/NumberFormat.java line 91:
> 
>> 89:  * for example, {@link #getIntegerInstance(Locale)}. If the installed locale-sensitive
>> 90:  * service implementation does not support the given {@code Locale}, {@link Locale#ROOT}
>> 91:  * will be used as the fallback {@code Locale}.
> 
> The fallback traverses the parent locales, and checks if it is supported or not. So it may or may not reach Locale.ROOT. How about "it looks up the parent locale chain and uses the one that is supported" or something along the lines?

Thanks for the clarification, updated the wording.

> src/java.base/share/classes/java/text/NumberFormat.java line 235:
> 
>> 233:  * @see          ChoiceFormat
>> 234:  * @see          CompactNumberFormat
>> 235:  * @see          Locale
> 
> Could be removed as the link is now gone

As this is a localized class, and the class description mentions `Locale` in various places, I feel like `Locale` should still be included as a `see` tag, (even though I removed the locale link). I am fine either way, what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1568004434
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1568004370
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1568004906

From naoto at openjdk.org  Tue Apr 16 23:02:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Apr 2024 23:02:00 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v2]
In-Reply-To: <OibvVo0qSlVXOZwhZELdta1vqk8lKTxVOHBHliZBoqI=.e511d50f-5920-4fc0-88b3-2441b7df1ccb@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
 <Qxmjk3F-nKo5nnWOW4mAwcl_KNB9a_6sPSrCkj7NphI=.d2505e28-88fc-4334-8521-552b479b1355@github.com>
 <hpOvPSQI_gAU2anRJ8HAIWO3od_AC0Idktj8nxt349E=.930b3184-f916-404a-b65e-3fc391cf715b@github.com>
 <OibvVo0qSlVXOZwhZELdta1vqk8lKTxVOHBHliZBoqI=.e511d50f-5920-4fc0-88b3-2441b7df1ccb@github.com>
Message-ID: <S_858RTwx5W0tQdreL5OG0u2HKji8gBM2uPd34PsDLo=.b9ae0a6b-e3b9-4e35-9034-dd12722492a2@github.com>

On Tue, 16 Apr 2024 22:30:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/CompactNumberFormat.java line 78:
>> 
>>> 76:  * installed. Thus, to use an instance method defined by {@code CompactNumberFormat},
>>> 77:  * the {@code NumberFormat} returned by the factory method should first be type
>>> 78:  * checked before cast to {@code CompactNumberFormat}. If the installed locale-sensitive
>> 
>> Since `CompactNumberFormat` does not provide its own instance methods (i.e., instance methods are exactly the same as the parent NumberFormat), "instance methods defined by CompactNF" does not make much sense, which is different for `DecimalFormat`.
>
> `CompactNumberFormat` does define its own instance methods such as `setParseBigDecimal`, `setGroupingSize`, etc, so I think that this wording should still be included.

My bad, you're correct. The confusion I had was probably this wording: "These factory methods may not always return a CompactNumberFormat". I believe it *does* return a CNF (in terms of `instanceof`), because as the factory methods names imply. However, in the case of DecimalFormat, the factory methods are simply, for example, "NumberFormat.getInstance()" and the implementation may return a different class instance, which does not even offer methods on DecimalFormat class. The difference needs to be described somehow IMO.

>> src/java.base/share/classes/java/text/NumberFormat.java line 235:
>> 
>>> 233:  * @see          ChoiceFormat
>>> 234:  * @see          CompactNumberFormat
>>> 235:  * @see          Locale
>> 
>> Could be removed as the link is now gone
>
> As this is a localized class, and the class description mentions `Locale` in various places, I feel like `Locale` should still be included as a `see` tag, (even though I removed the locale link). I am fine either way, what do you think?

OK, let's keep them then

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1568018900
PR Review Comment: https://git.openjdk.org/jdk/pull/18731#discussion_r1568020362

From mchung at openjdk.org  Tue Apr 16 23:29:06 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 16 Apr 2024 23:29:06 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v5]
In-Reply-To: <pYTdp794pxHiv-RrNVd2EukvPltYiFBCiAY0Y92WOt4=.7016d790-c6f4-4326-9669-4f4b6ba19925@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <pYTdp794pxHiv-RrNVd2EukvPltYiFBCiAY0Y92WOt4=.7016d790-c6f4-4326-9669-4f4b6ba19925@github.com>
Message-ID: <d1BTcI99xYAXOgcHulvOOFUGks75GK7Lfr6e4Y4fKI0=.e471e479-1235-49e4-a3f3-db6d3b45f227@github.com>

On Thu, 4 Apr 2024 09:20:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> 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 10 additional commits since the last revision:
> 
>  - Reversion of ClassBuilder changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - added missing comment
>  - fixed InnerClassLambdaMetafactory for hidden caller classes
>  - performance improvements
>  - consolidation of descriptors handling
>  - InvokerBytecodeGenerator::emit... improvements
>  - 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handlers

Overall looks good to me.   How is the performance result compared to using ASM?

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 32:

> 30: import java.lang.classfile.attribute.SourceFileAttribute;
> 31: import java.lang.constant.ClassDesc;
> 32: import static java.lang.constant.ConstantDescs.*;

Nit: this static imports can be moved to line 50 grouped with other static imports.

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 53:

> 51: import static java.lang.invoke.MethodHandleStatics.*;
> 52: import static java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP;
> 53: import static java.lang.classfile.ClassFile.*;

Nit: nice to sort these in alphabetical order - this before line 50.

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 606:

> 604:             TRANSFORM_MODS = List.of(tms.toArray(new Integer[0]));
> 605:         }
> 606:         private static final MethodTypeDesc MTD_transformHelper = MethodTypeDesc.of(CD_MethodHandle, CD_int);

Suggestion:

        private static final MethodTypeDesc MTD_TRANFORM_HELPER = MethodTypeDesc.of(CD_MethodHandle, CD_int);

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 72:

> 70:     static final String INVOKERS_HOLDER_CLASS_NAME = INVOKERS_HOLDER.replace('/', '.');
> 71:     static final String BMH_SPECIES_PREFIX = "java.lang.invoke.BoundMethodHandle$Species_";
> 72:     private static final ClassFile CC = ClassFile.of();

`ClassFile.of()` returns the ClassFile with default context which is a singleton object.  Is this static variable needed?

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 526:

> 524:             clb.withFlags(ACC_PRIVATE | ACC_FINAL | ACC_SUPER)
> 525:                .withSuperclass(InvokerBytecodeGenerator.INVOKER_SUPER_DESC)
> 526:                .with(SourceFileAttribute.of(clb.constantPool().utf8Entry(className.substring(className.lastIndexOf('/') + 1))));

Is it because of performance reason to use `SourceFileAttribute.of(Utf8Entry)` rather than `SourceFileAttribute.of(String)`?   If so, a comment to explain would help.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 36:

> 34: import java.lang.classfile.ClassBuilder;
> 35: import java.lang.classfile.ClassFile;
> 36: import static java.lang.classfile.ClassFile.*;

Nit: group static imports in line 52 following this file convention.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 41:

> 39: import java.lang.constant.ClassDesc;
> 40: import java.lang.constant.ConstantDesc;
> 41: import static java.lang.constant.ConstantDescs.*;

Nit: group static imports following this file convention

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 57:

> 55: import java.lang.classfile.constantpool.FieldRefEntry;
> 56: import java.lang.classfile.constantpool.InterfaceMethodRefEntry;
> 57: import java.lang.classfile.constantpool.MethodRefEntry;

Nit: group these imports with the above import java.lang.classfile...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 28:

> 26: package java.lang.invoke;
> 27: 
> 28: import static java.lang.classfile.ClassFile.*;

Nit: move this static import to line 64 following this file convention.

src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java line 75:

> 73:                                         UNBOX_DOUBLE  = unbox(CD_Number, "doubleValue", CD_double);
> 74: 
> 75:     static private TypeKind primitiveTypeKindFromClass(Class<?> type) {

Suggestion:

    private static TypeKind primitiveTypeKindFromClass(Class<?> type) {

-------------

PR Review: https://git.openjdk.org/jdk/pull/17108#pullrequestreview-2004669143
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1568015336
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1568015888
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1568016797
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1568013634
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1567990362
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1568022324
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1568034426
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1568034885
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1567986889
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1568031735

From iris at openjdk.org  Tue Apr 16 23:37:59 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 16 Apr 2024 23:37:59 GMT
Subject: RFR: 8329805: Deprecate for removal
 ObjectOutputStream.PutField.write
In-Reply-To: <jJX_F7zdz-XzBzmPjHkq3sOxW3N-I9Pff1vKO2TIn1M=.5d0b6e21-2614-44b0-b1d6-a6c9d57b9b4d@github.com>
References: <jJX_F7zdz-XzBzmPjHkq3sOxW3N-I9Pff1vKO2TIn1M=.5d0b6e21-2614-44b0-b1d6-a6c9d57b9b4d@github.com>
Message-ID: <W2Mp2hriDwVa_WqCZwL1MNjJHfBiwgNiHRDsB2kPl3M=.7ff70aad-87e2-40d7-8ea9-30668bd8775a@github.com>

On Tue, 16 Apr 2024 19:44:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The method `java.io.ObjectOutputStream.PutField.write` has been deprecated since 1.4 and should be deprecated for removal. The Deprecation annotation is updated to indicate the intention to remov the method.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18802#pullrequestreview-2004749149

From jkratochvil at openjdk.org  Wed Apr 17 01:09:46 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 17 Apr 2024 01:09:46 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
 <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>
Message-ID: <AyhwTYv3k8rFJ2k4nQT93fwyO_1gXMALMmmckLwrfpw=.2994f76e-ca36-4013-b03b-d4006349ad38@github.com>

On Tue, 16 Apr 2024 15:17:33 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints.

The in-container tuning means to use all the available resources. Containers in the real world have some memory limits set which is where my modified patch still correctly identifies it as a container to use all the available resources of the node which is the whole goal of the container detection code.

> In order to do this, we need a reliable way to distinguish that vs. non-containerized setup.

I expect it should have been written "We need a reliable way to distinguish real world in-container vs. non-containerized setup. We do not mind behavior for artificial containers on OpenJDK development machines.". Which is what my patch does in an easier and less error-prone way.

> If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.

That behaves still the same with my patch.

Could you give a countercase where my patch behaves wrongly?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2060158409

From tprinzing at openjdk.org  Wed Apr 17 01:34:07 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 17 Apr 2024 01:34:07 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  test file local to test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/70815943..366fca19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=03-04

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542

From tprinzing at openjdk.org  Wed Apr 17 01:37:04 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 17 Apr 2024 01:37:04 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <Hir2Q2tiv3y9Kqp1KN3RcqjApN7NgFkxfXZFbX0BWkU=.546adb1f-094c-4ad6-bffb-4294c0dde3e5@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
 <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
 <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
 <Hir2Q2tiv3y9Kqp1KN3RcqjApN7NgFkxfXZFbX0BWkU=.546adb1f-094c-4ad6-bffb-4294c0dde3e5@github.com>
Message-ID: <jiZV9LPAaKdne7ejuuUUwMEg1x6jyR88pWVSAg6Og1I=.1f6ff88a-6f76-4e50-b262-115f5f96a57c@github.com>

On Tue, 16 Apr 2024 15:49:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I'm not sure what you mean about the recording.  The file is the AsynchronousFileChannel under test and does not contain the event recording.
>
> It's anyway better to create temporary files in the test scratch directory rather than in /tmp. This way the temp files get cleaned up with the test, and there less chances of conflicts if several tests are running concurrently (and less chances on slowly filling up /tmp onthe machine if clean up actions fail)

I moved it to the tests scratch area

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1568102079

From darcy at openjdk.org  Wed Apr 17 05:27:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 05:27:59 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.e279fc9e-895a-4b17-85c8-f79635539145@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.e279fc9e-895a-4b17-85c8-f79635539145@github.com>
Message-ID: <fWBlbS1URCHC3BnuvEYl2Z3OXrbnkEFeGtQgUEW5MuQ=.6037d137-015a-46de-b1ef-4fb44c9d95f5@github.com>

On Tue, 16 Apr 2024 21:21:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:
> 
>> 1479:     int JAVA_23_VERSION = 67;
>> 1480: 
>> 1481:     /** 68 */
> 
> We need `@since 24` here.

Ah, good catch; looks like I was treating that as an internal API element when it is indeed a public API element. I've filed JDK-8330458 to fix-up the Java 23 constant as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1568231344

From darcy at openjdk.org  Wed Apr 17 05:43:12 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 05:43:12 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Correct release date as observed in review feedback.
 - Improve javadoc of class file update.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18787/files
  - new: https://git.openjdk.org/jdk/pull/18787/files/dcec9e96..dc488f21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=00-01

  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From jlahoda at openjdk.org  Wed Apr 17 06:34:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 06:34:25 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v3]
In-Reply-To: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
Message-ID: <k4OjYcNOr8nWMswbZyxHrtkmdKCfTmd0eXFQNMkZC-M=.e63da45b-4616-4d09-8aa2-766e45b1cc18@github.com>

> Consider code like:
> 
> public class MainClass {
>     public MainClass() {
>         System.out.println("Constructor called!");
>     }
>     public static void main() {
>         System.out.println("main called!");
>     }
> }
> 
> and compile and run it, with preview enabled, like:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> Constructor called!
> main called!
> 
> 
> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
> 
> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
> 
> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
> 
> There is also a relatively closely related problem: what happens when the constructor throws an exception?
> 
> public class MainClass {
>     public MainClass() {
>         if (true) throw new RuntimeException();
>     }
>     public void main() {
>         System.out.println("main called!");
>     }
> }
> 
> 
> when compiled an run, this produces no output whatsoever:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> $
> 
> 
> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
> 
> $ java --enable-preview -classpath /tmp/ MainClass 
> Exception in thread "main" java.lang.RuntimeException
>         at MainClass.<init>(MainClass.java:3)
> 
> 
> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Reflecting code formatting suggestion.
 - First lookup the main method, and only then the constructor.
 - Attempting to solve JDK-8329581 by only ignoring j.l.NoSuchMethodError

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18753/files
  - new: https://git.openjdk.org/jdk/pull/18753/files/2022aa5a..c007f61e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18753&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18753&range=01-02

  Stats: 117 lines in 2 files changed: 73 ins; 5 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/18753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18753/head:pull/18753

PR: https://git.openjdk.org/jdk/pull/18753

From jlahoda at openjdk.org  Wed Apr 17 06:38:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 06:38:02 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v3]
In-Reply-To: <k4OjYcNOr8nWMswbZyxHrtkmdKCfTmd0eXFQNMkZC-M=.e63da45b-4616-4d09-8aa2-766e45b1cc18@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <k4OjYcNOr8nWMswbZyxHrtkmdKCfTmd0eXFQNMkZC-M=.e63da45b-4616-4d09-8aa2-766e45b1cc18@github.com>
Message-ID: <VLuShZQ8q-24EnDET3VP-XEj2sWkYkhAvoiclTFMwQQ=.32bcd805-373a-499f-9572-ebd7f572d117@github.com>

On Wed, 17 Apr 2024 06:34:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class MainClass {
>>     public MainClass() {
>>         System.out.println("Constructor called!");
>>     }
>>     public static void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> and compile and run it, with preview enabled, like:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> Constructor called!
>> main called!
>> 
>> 
>> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
>> 
>> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
>> 
>> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
>> 
>> There is also a relatively closely related problem: what happens when the constructor throws an exception?
>> 
>> public class MainClass {
>>     public MainClass() {
>>         if (true) throw new RuntimeException();
>>     }
>>     public void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> 
>> when compiled an run, this produces no output whatsoever:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> $
>> 
>> 
>> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
>> 
>> $ java --enable-preview -classpath /tmp/ MainClass 
>> Exception in thread "main" java.lang.RuntimeException
>>         at MainClass.<init>(MainClass.java:3)
>> 
>> 
>> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Reflecting code formatting suggestion.
>  - First lookup the main method, and only then the constructor.
>  - Attempting to solve JDK-8329581 by only ignoring j.l.NoSuchMethodError

So, I've pushed an update that:
- attemps to solve [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581) by only ignoring `NoSuchMethodError` when looking up methods. Hence any other problem will lead to an error to be printed out, as usually.
https://github.com/openjdk/jdk/pull/18753/commits/dd447e898785a3d7e2def47dd1efcca3db41dd46
- changed the code to first lookup the `main` method, and only then constructors, which is what I think @dholmes-ora was suggesting.
https://github.com/openjdk/jdk/pull/18753/commits/83fabec6e5e8bf6deb9efce22ef6ace408cf3d26
- fixed the comment formatting, as suggested by @AlanBateman
https://github.com/openjdk/jdk/pull/18753/commits/c007f61ebc0660cc6f93e29e71dc635aa50ba538

Please let me know what you think. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18753#issuecomment-2060481245

From dholmes at openjdk.org  Wed Apr 17 07:42:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Apr 2024 07:42:00 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v2]
In-Reply-To: <n5excUnMvX63LJUltd6q6KF0ENgDG0dlbJ7Sm08GFyg=.58982933-f494-4c01-a004-6c72b4171cb6@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <eaTBGwTBGsghIoNFR1lfH_wsXlIhzfJkKEZXORDm20M=.4149ab99-2010-47fc-a5c3-e0fadd0c62d5@github.com>
 <60QWkeHKhL_dpiRpz_ftvPDPG2K2LzvF90s3GcecgrA=.3845b0c8-d83b-4cb6-9d38-54079f27cf17@github.com>
 <n5excUnMvX63LJUltd6q6KF0ENgDG0dlbJ7Sm08GFyg=.58982933-f494-4c01-a004-6c72b4171cb6@github.com>
Message-ID: <N4HJpbqDdbsfIRa8usp4ZjzHKEO-Z_hzZPG-W953CIU=.c946eac8-b77f-43d3-ad7b-80f573eb3a50@github.com>

On Tue, 16 Apr 2024 13:26:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 419:
>> 
>>> 417: invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs) {
>>> 418:     jmethodID constructor = (*env)->GetMethodID(env, mainClass, "<init>", "()V");
>>> 419:     CHECK_EXCEPTION_FAIL();
>> 
>> Shouldn't this also not be checked until you know you have an instance method?
>
> You mean to first check whether the method exists, and only then try to lookup the constructor? Not sure if that has observable effects, but I can do that.
> 
> I missed [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581) before, my plan is to adjust this "check for exception and clear it" check to only work for `NoSuchMethodError`, and let the exception pass for any other exception.

Yes that is what I meant. If the main method is static then the class need not have any such constructor (unless that is part of the spec for this functionality?).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18753#discussion_r1568370439

From dholmes at openjdk.org  Wed Apr 17 07:46:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Apr 2024 07:46:00 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v3]
In-Reply-To: <k4OjYcNOr8nWMswbZyxHrtkmdKCfTmd0eXFQNMkZC-M=.e63da45b-4616-4d09-8aa2-766e45b1cc18@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <k4OjYcNOr8nWMswbZyxHrtkmdKCfTmd0eXFQNMkZC-M=.e63da45b-4616-4d09-8aa2-766e45b1cc18@github.com>
Message-ID: <T0awyJnGChAjf50GqPdnbTgvBzkGZfPI48dsbso0twA=.bf46ec5e-596b-460f-8ac3-cf77ddecef6a@github.com>

On Wed, 17 Apr 2024 06:34:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class MainClass {
>>     public MainClass() {
>>         System.out.println("Constructor called!");
>>     }
>>     public static void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> and compile and run it, with preview enabled, like:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> Constructor called!
>> main called!
>> 
>> 
>> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
>> 
>> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
>> 
>> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
>> 
>> There is also a relatively closely related problem: what happens when the constructor throws an exception?
>> 
>> public class MainClass {
>>     public MainClass() {
>>         if (true) throw new RuntimeException();
>>     }
>>     public void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> 
>> when compiled an run, this produces no output whatsoever:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> $
>> 
>> 
>> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
>> 
>> $ java --enable-preview -classpath /tmp/ MainClass 
>> Exception in thread "main" java.lang.RuntimeException
>>         at MainClass.<init>(MainClass.java:3)
>> 
>> 
>> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Reflecting code formatting suggestion.
>  - First lookup the main method, and only then the constructor.
>  - Attempting to solve JDK-8329581 by only ignoring j.l.NoSuchMethodError

Okay on the update I suggested. Can't comment on the overall exception behaviour - not sure what is expected/specified.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18753#pullrequestreview-2005279615

From sgehwolf at openjdk.org  Wed Apr 17 08:29:09 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 17 Apr 2024 08:29:09 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
 <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>
 <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
Message-ID: <G6VjZRh5hT0AgoNnNY360lkVtxoH5uB_hJKSgNiyiJg=.8b1b090b-3188-4254-b5d1-31315ee32e5d@github.com>

On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think it continues to build time, it's just using some hidden jlink option. So yes, it similar to a previous iteration except that it doesn't run as a plugin the pipeline and the delta goes to the lib directory.

OK. If a hidden jlink option is good enough, then this works for me. I hope to have time to update the patch in the coming days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2060691122

From asotona at openjdk.org  Wed Apr 17 08:52:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 08:52:23 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden class
Message-ID: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>

Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.

This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8330467: NoClassDefFoundError when lambda is in a hidden class

Changes: https://git.openjdk.org/jdk/pull/18810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330467
  Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18810/head:pull/18810

PR: https://git.openjdk.org/jdk/pull/18810

From jpai at openjdk.org  Wed Apr 17 08:55:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 08:55:02 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v3]
In-Reply-To: <k4OjYcNOr8nWMswbZyxHrtkmdKCfTmd0eXFQNMkZC-M=.e63da45b-4616-4d09-8aa2-766e45b1cc18@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <k4OjYcNOr8nWMswbZyxHrtkmdKCfTmd0eXFQNMkZC-M=.e63da45b-4616-4d09-8aa2-766e45b1cc18@github.com>
Message-ID: <IyTWyHviXHXaLdiFPilbs98a9BNfIJ6FlfcxspTWFk4=.59634d26-0f46-4f04-aa3b-d14b464b5f14@github.com>

On Wed, 17 Apr 2024 06:34:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class MainClass {
>>     public MainClass() {
>>         System.out.println("Constructor called!");
>>     }
>>     public static void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> and compile and run it, with preview enabled, like:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> Constructor called!
>> main called!
>> 
>> 
>> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
>> 
>> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
>> 
>> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
>> 
>> There is also a relatively closely related problem: what happens when the constructor throws an exception?
>> 
>> public class MainClass {
>>     public MainClass() {
>>         if (true) throw new RuntimeException();
>>     }
>>     public void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> 
>> when compiled an run, this produces no output whatsoever:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> $
>> 
>> 
>> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
>> 
>> $ java --enable-preview -classpath /tmp/ MainClass 
>> Exception in thread "main" java.lang.RuntimeException
>>         at MainClass.<init>(MainClass.java:3)
>> 
>> 
>> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Reflecting code formatting suggestion.
>  - First lookup the main method, and only then the constructor.
>  - Attempting to solve JDK-8329581 by only ignoring j.l.NoSuchMethodError

src/java.base/share/native/libjli/java.c line 477:

> 475:         // and don't continue with the next variant;
> 476:         // leave any exception pending, so that it is visible to the caller:
> 477:         return 1;

Hello Jan, the comment says "don't continue", yet this returns `1` which represents "continue". Should this return `0` instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18753#discussion_r1568470228

From liach at openjdk.org  Wed Apr 17 09:18:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Apr 2024 09:18:01 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class
In-Reply-To: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
Message-ID: <qA60h5N1soPU2KXPuzgWTPf47LaEUBhIDvxKFD5JwQs=.8b1cb8a5-8e6a-46d7-a12d-e8c3cdde2020@github.com>

On Wed, 17 Apr 2024 08:46:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
> 
> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
> 
> Please review.
> 
> Thanks,
> Adam

I wonder if we should only support invokeStatic refs for hidden classes, as instance call lambdas will always require receiver which can't be represented outside of hidden classes.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 186:

> 184:                                !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
> 185:                                implKind == H_INVOKESPECIAL ||
> 186:                                implInfo.getDeclaringClass().isHidden();

Might need to check the difference between `implInfo.getDeclaringClass()` and `implClass`

-------------

PR Review: https://git.openjdk.org/jdk/pull/18810#pullrequestreview-2005483864
PR Review Comment: https://git.openjdk.org/jdk/pull/18810#discussion_r1568505421

From jlahoda at openjdk.org  Wed Apr 17 09:20:24 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 09:20:24 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v4]
In-Reply-To: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
Message-ID: <-2mCabXRtUPnuhrF3gxztTj-fpuROUnXjs2Dev9eLR4=.c32fae3e-edea-450f-9ce4-5f1f4ffb2f06@github.com>

> Consider code like:
> 
> public class MainClass {
>     public MainClass() {
>         System.out.println("Constructor called!");
>     }
>     public static void main() {
>         System.out.println("main called!");
>     }
> }
> 
> and compile and run it, with preview enabled, like:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> Constructor called!
> main called!
> 
> 
> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
> 
> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
> 
> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
> 
> There is also a relatively closely related problem: what happens when the constructor throws an exception?
> 
> public class MainClass {
>     public MainClass() {
>         if (true) throw new RuntimeException();
>     }
>     public void main() {
>         System.out.println("main called!");
>     }
> }
> 
> 
> when compiled an run, this produces no output whatsoever:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> $
> 
> 
> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
> 
> $ java --enable-preview -classpath /tmp/ MainClass 
> Exception in thread "main" java.lang.RuntimeException
>         at MainClass.<init>(MainClass.java:3)
> 
> 
> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing typo (should not continue after an exception from a constructor).

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18753/files
  - new: https://git.openjdk.org/jdk/pull/18753/files/c007f61e..aadfb380

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18753&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18753&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18753/head:pull/18753

PR: https://git.openjdk.org/jdk/pull/18753

From jlahoda at openjdk.org  Wed Apr 17 09:20:24 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 09:20:24 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v3]
In-Reply-To: <IyTWyHviXHXaLdiFPilbs98a9BNfIJ6FlfcxspTWFk4=.59634d26-0f46-4f04-aa3b-d14b464b5f14@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <k4OjYcNOr8nWMswbZyxHrtkmdKCfTmd0eXFQNMkZC-M=.e63da45b-4616-4d09-8aa2-766e45b1cc18@github.com>
 <IyTWyHviXHXaLdiFPilbs98a9BNfIJ6FlfcxspTWFk4=.59634d26-0f46-4f04-aa3b-d14b464b5f14@github.com>
Message-ID: <wLrLVXyJG3RKN_ClAsI3nqjKC-zR54uMF0-dq_EiUCI=.f1b2d690-8566-4f51-be5f-bc8224fb1016@github.com>

On Wed, 17 Apr 2024 08:51:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Reflecting code formatting suggestion.
>>  - First lookup the main method, and only then the constructor.
>>  - Attempting to solve JDK-8329581 by only ignoring j.l.NoSuchMethodError
>
> src/java.base/share/native/libjli/java.c line 477:
> 
>> 475:         // and don't continue with the next variant;
>> 476:         // leave any exception pending, so that it is visible to the caller:
>> 477:         return 1;
> 
> Hello Jan, the comment says "don't continue", yet this returns `1` which represents "continue". Should this return `0` instead?

Uh, you are right of course. Thanks for noticing! Fixed. (I believe the difference here is not currently observable, as this is the last step in the cascade, but may become observable if the order changes.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18753#discussion_r1568511740

From asotona at openjdk.org  Wed Apr 17 09:23:42 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 09:23:42 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
Message-ID: <nOjs6B6AtCkTvGxO2FN_89dFz4vA9d5Od9_gzq0X7p4=.d903e6fa-1774-4ff0-b676-86ac53df3449@github.com>

On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.

ClassFile changes are OK.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2005504192

From pminborg at openjdk.org  Wed Apr 17 09:28:46 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 17 Apr 2024 09:28:46 GMT
Subject: Integrated: 8330272: Wrong javadoc for
 ValueLayout.JAVA_LONG/JAVA_DOUBLE on x86 32bit
In-Reply-To: <32HOlXXjhG6GZvb6PsSq9hUB_Y-HOGrBZsGb9R5vlTg=.d7412e68-9675-422b-bf75-ecb8412550fb@github.com>
References: <32HOlXXjhG6GZvb6PsSq9hUB_Y-HOGrBZsGb9R5vlTg=.d7412e68-9675-422b-bf75-ecb8412550fb@github.com>
Message-ID: <FJrWf7i9v23z2zlMB3YK3oeqGTFjSul7JW2c5vVy0ig=.83e5cb1e-6203-438c-8a67-7737e9521d81@github.com>

On Tue, 16 Apr 2024 07:09:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to update the javadocs for `ValueLayout.JAVA_LONG` and `ValueLayout.JAVA_DOUBLE` to reflect the changes made in https://bugs.openjdk.org/browse/JDK-8326172  (we forgot to update the docs when that issue was fixed)

This pull request has now been integrated.

Changeset: e4021adb
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4021adb287381a6c7775234b401429380075e0f
Stats:     5 lines in 1 file changed: 0 ins; 2 del; 3 mod

8330272: Wrong javadoc for ValueLayout.JAVA_LONG/JAVA_DOUBLE on x86 32bit

Reviewed-by: mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/18791

From mdoerr at openjdk.org  Wed Apr 17 10:46:04 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 Apr 2024 10:46:04 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v27]
In-Reply-To: <EKyawoFgA1Yx9kLdw8lIXLYIQmC0ZYIk0hQ-zerCzaE=.57387714-7fac-4ee1-8fb4-c4232294da9f@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <EKyawoFgA1Yx9kLdw8lIXLYIQmC0ZYIk0hQ-zerCzaE=.57387714-7fac-4ee1-8fb4-c4232294da9f@github.com>
Message-ID: <G-4NI85l3AD_Eyzd-hvYxE-qdHVVQVwTNkqdOXKFHdo=.85c3ff43-d2ab-4988-8a75-30d2992cc749@github.com>

On Mon, 15 Apr 2024 16:10:38 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - new line
>  - spaces fix
>  - spaces fix

Please take a look at Mandy's suggestions. I think they make sense.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2060963452

From sroy at openjdk.org  Wed Apr 17 10:55:22 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 17 Apr 2024 10:55:22 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v28]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <hEQnid3acuxN6lA5HU1PLnWswuZ0BosY-mBpEKnd2Ek=.fb6e8909-3602-4cb2-aa0b-b6a5516e9bd0@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
   
   remove final
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
   
   remove final
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/12270d06..2b729673

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=26-27

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From sroy at openjdk.org  Wed Apr 17 10:55:22 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 17 Apr 2024 10:55:22 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v27]
In-Reply-To: <G-4NI85l3AD_Eyzd-hvYxE-qdHVVQVwTNkqdOXKFHdo=.85c3ff43-d2ab-4988-8a75-30d2992cc749@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <EKyawoFgA1Yx9kLdw8lIXLYIQmC0ZYIk0hQ-zerCzaE=.57387714-7fac-4ee1-8fb4-c4232294da9f@github.com>
 <G-4NI85l3AD_Eyzd-hvYxE-qdHVVQVwTNkqdOXKFHdo=.85c3ff43-d2ab-4988-8a75-30d2992cc749@github.com>
Message-ID: <-MQd-Zl3460ToF9tXB7eaFCx2yPaGGC0YvmVjKno014=.e5e3807d-58cb-4a70-8f71-5032fdb7911d@github.com>

On Wed, 17 Apr 2024 10:42:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Please take a look at Mandy's suggestions. I think they make sense.

Done. Sorry i missed it. I got notified that the patch had got approved so i went ahead with integrate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2060978059

From jvernee at openjdk.org  Wed Apr 17 11:02:00 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 17 Apr 2024 11:02:00 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class
In-Reply-To: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
Message-ID: <kzyOnCjugsLwVxkxz1sfvg7bWX82SjWADov2nsoNUEk=.a77b6755-96d5-42bb-9d3c-80e861ab3436@github.com>

On Wed, 17 Apr 2024 08:46:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
> 
> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
> 
> Please review.
> 
> Thanks,
> Adam

Do we also need to check if the parameters or return type are hidden classes? I suppose if we compile a direct bytecode reference to the target method, all of them need to be referenceable from bytecode, not just the holder.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18810#pullrequestreview-2005733945

From jpai at openjdk.org  Wed Apr 17 11:02:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 11:02:02 GMT
Subject: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant [v3]
In-Reply-To: <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
 <i2nnlmB_Km3f074v6g-4SRk4xLdHEYFCXAg0E60fKBI=.17af55b5-9314-426f-8899-f1d68da69ac6@github.com>
Message-ID: <EZa8haJrmNlAEbtcyUM6sUneSFjT27ZFUISvE5SuD0g=.190d1142-b328-437b-8f05-2ba6c625852a@github.com>

On Wed, 10 Apr 2024 16:17:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need for {@code} in javadoc

Thank you Naoto and Roger for the inputs and the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18674#issuecomment-2060988355

From jpai at openjdk.org  Wed Apr 17 11:02:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 11:02:02 GMT
Subject: Integrated: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match
 the range of Instant
In-Reply-To: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
References: <CZIUh8GQNV9g8KVwP4nM0oWqmZGccUQ21RUy7Vk5NFc=.b91baeb4-cc1c-460d-b42f-aef31be06810@github.com>
Message-ID: <PnanjNA_Rc0VCvRrZSp99BZ0w4vHeuZ-bKUVVfiNi2Q=.6040573f-c4b1-4363-bf7f-91d76cfda829@github.com>

On Mon, 8 Apr 2024 09:52:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
> 
> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
> 
> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.

This pull request has now been integrated.

Changeset: 89129e3f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89129e3f672d8af9613ad2a72e64322661836c96
Stats:     17 lines in 2 files changed: 14 ins; 0 del; 3 mod

8212895: ChronoField.INSTANT_SECONDS's range doesn't match the range of Instant

Reviewed-by: rriggs, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18674

From sroy at openjdk.org  Wed Apr 17 11:20:24 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 17 Apr 2024 11:20:24 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v29]
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <1LdURqPLqPqn4wPCppk-8RBA-xq9RgGoMEZ9-7GiFN8=.db965de7-9350-4677-9007-72153c64f9d2@github.com>

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Update LoadAIXLibraryFromArchiveObject.java
  
  Nits,coding style and variable name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/2b729673..53343781

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=27-28

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945

PR: https://git.openjdk.org/jdk/pull/17945

From pminborg at openjdk.org  Wed Apr 17 11:24:28 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 17 Apr 2024 11:24:28 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v5]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <nG3gW3IfgyIcZuOq6igDvfWcW2T3D4QCl3EcCYnDMzs=.dccd37db-c186-49e3-9245-50a90c17db64@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/foreign/package-info.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/fa86d837..2ebac9fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18474/head:pull/18474

PR: https://git.openjdk.org/jdk/pull/18474

From yzheng at openjdk.org  Wed Apr 17 12:11:14 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 17 Apr 2024 12:11:14 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v4]
In-Reply-To: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
Message-ID: <VOt-yFEgOq6OrS2c8MG7KzTpnq5HbH7ehdbAFn3sLvc=.333dd07b-85a3-455a-a0e1-b22fcea88879@github.com>

> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  address comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18226/files
  - new: https://git.openjdk.org/jdk/pull/18226/files/870a6127..c5d521dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=02-03

  Stats: 53 lines in 10 files changed: 3 ins; 6 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/18226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18226/head:pull/18226

PR: https://git.openjdk.org/jdk/pull/18226

From pminborg at openjdk.org  Wed Apr 17 12:21:12 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 17 Apr 2024 12:21:12 GMT
Subject: RFR: 8329997: Add provisions for checking memory segment alignment
 constraints [v6]
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <I_I8OlgKxKHxwJdAjfMdvOZCu7bu_-PKP4A-AVxBUM4=.133bb6e7-b5ee-47f5-ac42-272b78d4c1ce@github.com>

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update docs for maxByteAlignment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18779/files
  - new: https://git.openjdk.org/jdk/pull/18779/files/e971e7f6..8b944a35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18779&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18779/head:pull/18779

PR: https://git.openjdk.org/jdk/pull/18779

From yzheng at openjdk.org  Wed Apr 17 12:35:54 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 17 Apr 2024 12:35:54 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]
In-Reply-To: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
Message-ID: <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>

> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  address comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18226/files
  - new: https://git.openjdk.org/jdk/pull/18226/files/c5d521dc..72ba58ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18226/head:pull/18226

PR: https://git.openjdk.org/jdk/pull/18226

From yzheng at openjdk.org  Wed Apr 17 12:40:01 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 17 Apr 2024 12:40:01 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v3]
In-Reply-To: <IEbiW8OAUyzLJ9NWnSZEI_iOYBfJrsIy-wc8KF-R92I=.72f6c6e6-af4f-495e-8612-f1bb6318ec67@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <zMKT2cOKMHo76IFkz5uh8NOa07lp1NhleOJFKDi_v8c=.b5605b07-077e-4cf8-9014-f9a169b0af46@github.com>
 <IEbiW8OAUyzLJ9NWnSZEI_iOYBfJrsIy-wc8KF-R92I=.72f6c6e6-af4f-495e-8612-f1bb6318ec67@github.com>
Message-ID: <pJ7EHSw1QUoVy60dGjR81GdoPzlibyDv-kZ-FmfRvt4=.9bdab17c-0e27-4ba7-a68b-9a2307641244@github.com>

On Tue, 26 Mar 2024 15:59:33 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comment.
>
> `multiply_to_len` seems to be used by `generate_squareToLen` as well for aarch64 and riscv but `zlen` is still passed in a register.
> 
> https://github.com/openjdk/jdk/blob/870a6127cf54264c691f7322d775b202705c3bfa/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L4710
> https://github.com/openjdk/jdk/blob/870a6127cf54264c691f7322d775b202705c3bfa/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp#L2881
> 
> I think it might work anyway but it might be better to adapt them if only for completeness.

@dafedafe @dean-long please take a look and let me know if there are further issues, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2061162283

From asotona at openjdk.org  Wed Apr 17 12:47:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 12:47:00 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class
In-Reply-To: <qA60h5N1soPU2KXPuzgWTPf47LaEUBhIDvxKFD5JwQs=.8b1cb8a5-8e6a-46d7-a12d-e8c3cdde2020@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <qA60h5N1soPU2KXPuzgWTPf47LaEUBhIDvxKFD5JwQs=.8b1cb8a5-8e6a-46d7-a12d-e8c3cdde2020@github.com>
Message-ID: <7g6l2NTOby5-ITNzUiXgApjFxcDGy3-XDsViZWfNWjs=.65269fb1-0242-4d13-a287-786d754717d1@github.com>

On Wed, 17 Apr 2024 09:14:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>> 
>> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
>> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 186:
> 
>> 184:                                !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
>> 185:                                implKind == H_INVOKESPECIAL ||
>> 186:                                implInfo.getDeclaringClass().isHidden();
> 
> Might need to check the difference between `implInfo.getDeclaringClass()` and `implClass`

Yes, we should support only invoke static refs for hidden classes and `implClass == implInfo.getDeclaringClass()` in that case.
Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18810#discussion_r1568782761

From asotona at openjdk.org  Wed Apr 17 12:51:55 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 12:51:55 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v2]
In-Reply-To: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
Message-ID: <2i86OD4MCDX0V3fU-5Es90sPuih1w574HI3Sm0cqGl4=.e3d89c18-30d2-485f-8e07-87706e15e356@github.com>

> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
> 
> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  applied suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18810/files
  - new: https://git.openjdk.org/jdk/pull/18810/files/4a53389d..c637ab90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18810&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18810&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18810/head:pull/18810

PR: https://git.openjdk.org/jdk/pull/18810

From duke at openjdk.org  Wed Apr 17 12:55:45 2024
From: duke at openjdk.org (wolfseifert)
Date: Wed, 17 Apr 2024 12:55:45 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <4MPAvzQMqMQG4nLdhopssTphnhgWD12wo_OnLlb3vRQ=.4f77e44e-1aea-40b5-9aec-f0b676b6c07f@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Just tried to avoid unnecessary duplication of work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2061191285

From mcimadamore at openjdk.org  Wed Apr 17 12:59:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Apr 2024 12:59:44 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v10]
In-Reply-To: <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>
Message-ID: <5bFbFOp51jPYrMgvk5AfQ4Zh7YMn5dU8pURyaL_MfFc=.13663ea3-1300-4d6b-b52c-78e140b71bca@github.com>

On Tue, 9 Apr 2024 09:28:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback:
>   - reverting unnecessary changes in TransPatterns
>   - moving the patters/withers/Model test to a more appropriate place

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18509#pullrequestreview-2005974556

From mdoerr at openjdk.org  Wed Apr 17 13:22:46 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 Apr 2024 13:22:46 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v29]
In-Reply-To: <1LdURqPLqPqn4wPCppk-8RBA-xq9RgGoMEZ9-7GiFN8=.db965de7-9350-4677-9007-72153c64f9d2@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <1LdURqPLqPqn4wPCppk-8RBA-xq9RgGoMEZ9-7GiFN8=.db965de7-9350-4677-9007-72153c64f9d2@github.com>
Message-ID: <tQb9V2pzT8PPPBXrBXO7AZ9Ch4ABTO4aj9_WbL5rbco=.d4cfcbbb-999a-4275-b310-2cbfaf39be05@github.com>

On Wed, 17 Apr 2024 11:20:24 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update LoadAIXLibraryFromArchiveObject.java
>   
>   Nits,coding style and variable name

Update looks good.
Thanks everybody for all the discussions!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-2006028030

From liach at openjdk.org  Wed Apr 17 13:30:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Apr 2024 13:30:00 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v2]
In-Reply-To: <kzyOnCjugsLwVxkxz1sfvg7bWX82SjWADov2nsoNUEk=.a77b6755-96d5-42bb-9d3c-80e861ab3436@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <kzyOnCjugsLwVxkxz1sfvg7bWX82SjWADov2nsoNUEk=.a77b6755-96d5-42bb-9d3c-80e861ab3436@github.com>
Message-ID: <zF4Oxo_i8nYM06bHSnpTMK0SYCrEbd6vpd7lLq9u8og=.92d182d7-bcdc-4958-8b86-e86d16ab6c55@github.com>

On Wed, 17 Apr 2024 10:58:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Do we also need to check if the parameters or return type are hidden classes?

I think this is already failing and will continue to fail. Don't think we need special error messages for this case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18810#issuecomment-2061260710

From redestad at openjdk.org  Wed Apr 17 13:31:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 Apr 2024 13:31:07 GMT
Subject: RFR: 8316493: Remove the caching fields in AbstractMap [v11]
In-Reply-To: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com>
References: <DpNRZsCvDmDfEZ0X-xTKRnwpr3vhgmFTr9IWoveGFbs=.bf85bf6c-97eb-44af-977b-b9909956fa95@github.com>
 <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com>
Message-ID: <5gtBfNMVPeMpvx7Aj-FwKH7MVVjE-eKwr3TbHsVksPM=.1e51d835-98d0-4f80-9e37-341e681e1d32@github.com>

On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
>> 
>> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
>> 
>> We need to benchmark this solution to better understand its implications.
>
> Per Minborg 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 vb-map2
>  - Fix formatting
>  - Remove caching in TreeMap
>  - Remove caching from CHM and CSLM
>  - Move back clone to original position
>  - Reintroduce AbstractMap::clone
>  - Add 'fresh' to implSpec
>  - Remove AbstractMap::clone
>  - Merge master
>  - Merge branch 'master' into vb-map2
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/9cce9fe0...b1bfcd17

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15614#pullrequestreview-2006046097

From liach at openjdk.org  Wed Apr 17 13:31:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Apr 2024 13:31:07 GMT
Subject: RFR: 8316493: Remove the caching fields in AbstractMap [v11]
In-Reply-To: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com>
References: <DpNRZsCvDmDfEZ0X-xTKRnwpr3vhgmFTr9IWoveGFbs=.bf85bf6c-97eb-44af-977b-b9909956fa95@github.com>
 <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com>
Message-ID: <0HpohAEqT2tpI1XQsVTAEYfdMem1w8Q-HyPmayGkggA=.8065442a-16e4-4a75-bf54-e7cac0fd3997@github.com>

On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
>> 
>> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
>> 
>> We need to benchmark this solution to better understand its implications.
>
> Per Minborg 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 vb-map2
>  - Fix formatting
>  - Remove caching in TreeMap
>  - Remove caching from CHM and CSLM
>  - Move back clone to original position
>  - Reintroduce AbstractMap::clone
>  - Add 'fresh' to implSpec
>  - Remove AbstractMap::clone
>  - Merge master
>  - Merge branch 'master' into vb-map2
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/9cce9fe0...b1bfcd17

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15614#pullrequestreview-2006050183

From sroy at openjdk.org  Wed Apr 17 13:40:05 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 17 Apr 2024 13:40:05 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v25]
In-Reply-To: <UXT792rJReVuGjF-AniCOyLyTNDNlX0mhAa8EdrShGw=.2c1b7a29-d262-4d77-b97b-508e5d734e81@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <63taT5KlpoDODGPpE3RsV5AXafhtd6ljxSx3Vg0GaRc=.1ff8d51f-8918-4dfa-81e0-651de7624b1d@github.com>
 <UXT792rJReVuGjF-AniCOyLyTNDNlX0mhAa8EdrShGw=.2c1b7a29-d262-4d77-b97b-508e5d734e81@github.com>
Message-ID: <--8NV87KocLFhsiL65ynl-txclacJvLKrbruWikdZ_o=.962c5085-6fa2-40dd-8946-dc6bce07e05b@github.com>

On Mon, 15 Apr 2024 13:58:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Files copy
>
> I'll let Mandy and others familiar with this area and AIX do the formal review of this PR. My involvement here was merely general inputs.

Thank you @jaikiran @mlchung @TheRealMDoerr  Got to learn about new ways to test and learnt about the classloader functionalities better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2061282909

From duke at openjdk.org  Wed Apr 17 13:49:04 2024
From: duke at openjdk.org (wolfseifert)
Date: Wed, 17 Apr 2024 13:49:04 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <wTG7VZN0_tZ1Y-R7OgLK4MKPPBk0o9xAY6Z71NchtE8=.932ff147-880c-4318-ba81-d3987abad183@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

I tested now pull/18753 and pull/18786: both solve both issues JDK-8329420 and JDK-8329581

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2061302794

From dfenacci at openjdk.org  Wed Apr 17 13:49:05 2024
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Apr 2024 13:49:05 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v3]
In-Reply-To: <IEbiW8OAUyzLJ9NWnSZEI_iOYBfJrsIy-wc8KF-R92I=.72f6c6e6-af4f-495e-8612-f1bb6318ec67@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <zMKT2cOKMHo76IFkz5uh8NOa07lp1NhleOJFKDi_v8c=.b5605b07-077e-4cf8-9014-f9a169b0af46@github.com>
 <IEbiW8OAUyzLJ9NWnSZEI_iOYBfJrsIy-wc8KF-R92I=.72f6c6e6-af4f-495e-8612-f1bb6318ec67@github.com>
Message-ID: <MfiDZeL70YefZV93HLOtDDFaKQPud32PNmW5rtmIkIA=.a9984d8d-8b95-4b9d-bd3e-9a778859228f@github.com>

On Tue, 26 Mar 2024 15:59:33 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comment.
>
> `multiply_to_len` seems to be used by `generate_squareToLen` as well for aarch64 and riscv but `zlen` is still passed in a register.
> 
> https://github.com/openjdk/jdk/blob/870a6127cf54264c691f7322d775b202705c3bfa/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L4710
> https://github.com/openjdk/jdk/blob/870a6127cf54264c691f7322d775b202705c3bfa/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp#L2881
> 
> I think it might work anyway but it might be better to adapt them if only for completeness.

> @dafedafe @dean-long please take a look and let me know if there are further issues, thanks!

Thanks @mur47x111! I noticed that you found even a few more `zlen` usages ? 

Did you test the change against all affected platforms?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2061301421

From duke at openjdk.org  Wed Apr 17 13:49:05 2024
From: duke at openjdk.org (wolfseifert)
Date: Wed, 17 Apr 2024 13:49:05 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v4]
In-Reply-To: <-2mCabXRtUPnuhrF3gxztTj-fpuROUnXjs2Dev9eLR4=.c32fae3e-edea-450f-9ce4-5f1f4ffb2f06@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <-2mCabXRtUPnuhrF3gxztTj-fpuROUnXjs2Dev9eLR4=.c32fae3e-edea-450f-9ce4-5f1f4ffb2f06@github.com>
Message-ID: <j6phS8vPkRYXTqie9w91h0ZuF9zj1OyX3TOA-Apf-CE=.ea77d94e-d256-414e-9a9f-be40cdb7bcfd@github.com>

On Wed, 17 Apr 2024 09:20:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class MainClass {
>>     public MainClass() {
>>         System.out.println("Constructor called!");
>>     }
>>     public static void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> and compile and run it, with preview enabled, like:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> Constructor called!
>> main called!
>> 
>> 
>> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
>> 
>> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
>> 
>> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
>> 
>> There is also a relatively closely related problem: what happens when the constructor throws an exception?
>> 
>> public class MainClass {
>>     public MainClass() {
>>         if (true) throw new RuntimeException();
>>     }
>>     public void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> 
>> when compiled an run, this produces no output whatsoever:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> $
>> 
>> 
>> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
>> 
>> $ java --enable-preview -classpath /tmp/ MainClass 
>> Exception in thread "main" java.lang.RuntimeException
>>         at MainClass.<init>(MainClass.java:3)
>> 
>> 
>> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing typo (should not continue after an exception from a constructor).

I tested now pull/18753 and pull/18786: both solve both issues JDK-8329420 and JDK-8329581

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18753#issuecomment-2061301645

From mcimadamore at openjdk.org  Wed Apr 17 14:13:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Apr 2024 14:13:04 GMT
Subject: Integrated: 8329948: Remove string template feature
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <rmBDb3IR8plIXZHBlJcUKN5WpnXKYbaPBH3NsnpW9I8=.da4f79cf-7ce8-4a25-9872-1faa0bd86e35@github.com>

On Tue, 9 Apr 2024 11:34:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

This pull request has now been integrated.

Changeset: 03e84178
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03e84178ebfd2ca48b89d65d8f3c291e0c622fb5
Stats:     7400 lines in 66 files changed: 122 ins; 7217 del; 61 mod

8329948: Remove string template feature

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/18688

From david.lloyd at redhat.com  Wed Apr 17 14:13:29 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 17 Apr 2024 09:13:29 -0500
Subject: Vector (and integer) API: unsigned min/max
Message-ID: <CANghgrRXdbQJHQN8FfPqEVy9x7PyWUOzVqu+SEYxf033OoQf-A@mail.gmail.com>

I've been trying the the incubating Vector API and one thing I've missed on
integer-typed vectors is having unsigned min/max operations. There is a
signed min/max operation, and unsigned comparison, but no unsigned min/max.

I guess this is for symmetry with `Math`, which only has signed
`min`/`max`. However, I would point out that while it's not very hard to
implement one's own unsigned min/max for integer types using
`compareUnsigned`, it is a bit harder to do so with vectors. The best I've
come up with is to take one of two approaches:

1. Zero-extend the vector to the next-larger size, perform the min/max, and
reduce it back down again, or
2. Add <IntType>.MIN_VALUE, min/max with a value or vector also offset by
<IntType>.MIN_VALUE, and then subtract the offset again

I guess a third approach could be to do a comparison using unsigned
compares, and then use the resultant vector mask to select items from the
original two vectors, but I didn't bother to work out this solution given I
already had the other two options.

Would it be feasible to add unsigned min/max operations for vectors? It
looks like at least AArch64 has support for this as a single instruction,
so it doesn't seem too outlandish.

And as a separate (but related) question, what about
`Math.minUnsigned`/`Math.maxUnsigned` of `int` and `long` for symmetry?

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240417/32894e44/attachment-0001.htm>

From jlahoda at openjdk.org  Wed Apr 17 14:45:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 14:45:13 GMT
Subject: RFR: 8328481: Implement Module Imports [v6]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Pzfi6LRqRSvUmAhqepfBUhXdEQfahOOHhadOqRvQndY=.b1f3db3d-8d9e-414e-9a13-f256072a1642@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into module-imports
 - Including current module name as suggested.
 - Adding more tests for ambiguities.
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - ... and 10 more: https://git.openjdk.org/jdk/compare/03e84178...c75b8b7a

-------------

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=05
  Stats: 1198 lines in 29 files changed: 1130 ins; 9 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From asotona at openjdk.org  Wed Apr 17 15:21:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 15:21:32 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v6]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> 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 12 additional commits since the last revision:

 - applied suggested changes
 - Merge branch 'master' into JDK-8294960-invoke
 - Reversion of ClassBuilder changes
 - Merge branch 'master' into JDK-8294960-invoke
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - added missing comment
 - fixed InnerClassLambdaMetafactory for hidden caller classes
 - performance improvements
 - consolidation of descriptors handling
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5270f351...304054b9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/500bb8f0..304054b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=04-05

  Stats: 34095 lines in 899 files changed: 18206 ins; 9917 del; 5972 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From asotona at openjdk.org  Wed Apr 17 15:21:41 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 15:21:41 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v5]
In-Reply-To: <d1BTcI99xYAXOgcHulvOOFUGks75GK7Lfr6e4Y4fKI0=.e471e479-1235-49e4-a3f3-db6d3b45f227@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <pYTdp794pxHiv-RrNVd2EukvPltYiFBCiAY0Y92WOt4=.7016d790-c6f4-4326-9669-4f4b6ba19925@github.com>
 <d1BTcI99xYAXOgcHulvOOFUGks75GK7Lfr6e4Y4fKI0=.e471e479-1235-49e4-a3f3-db6d3b45f227@github.com>
Message-ID: <h9M0h7nPXfftn7qtQnjcHOnQyVsgnDC-dWME0CGCVks=.0acb7329-69a7-4dcf-9938-666cfbff3e13@github.com>

On Tue, 16 Apr 2024 22:49:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 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 10 additional commits since the last revision:
>> 
>>  - Reversion of ClassBuilder changes
>>  - Merge branch 'master' into JDK-8294960-invoke
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>>  - added missing comment
>>  - fixed InnerClassLambdaMetafactory for hidden caller classes
>>  - performance improvements
>>  - consolidation of descriptors handling
>>  - InvokerBytecodeGenerator::emit... improvements
>>  - 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handlers
>
> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 32:
> 
>> 30: import java.lang.classfile.attribute.SourceFileAttribute;
>> 31: import java.lang.constant.ClassDesc;
>> 32: import static java.lang.constant.ConstantDescs.*;
> 
> Nit: this static imports can be moved to line 50 grouped with other static imports.

Fixed, thank you.

> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 53:
> 
>> 51: import static java.lang.invoke.MethodHandleStatics.*;
>> 52: import static java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP;
>> 53: import static java.lang.classfile.ClassFile.*;
> 
> Nit: nice to sort these in alphabetical order - this before line 50.

Fixed, thank you.

> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 606:
> 
>> 604:             TRANSFORM_MODS = List.of(tms.toArray(new Integer[0]));
>> 605:         }
>> 606:         private static final MethodTypeDesc MTD_transformHelper = MethodTypeDesc.of(CD_MethodHandle, CD_int);
> 
> Suggestion:
> 
>         private static final MethodTypeDesc MTD_TRANFORM_HELPER = MethodTypeDesc.of(CD_MethodHandle, CD_int);

Fixed, thank you.

> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 72:
> 
>> 70:     static final String INVOKERS_HOLDER_CLASS_NAME = INVOKERS_HOLDER.replace('/', '.');
>> 71:     static final String BMH_SPECIES_PREFIX = "java.lang.invoke.BoundMethodHandle$Species_";
>> 72:     private static final ClassFile CC = ClassFile.of();
> 
> `ClassFile.of()` returns the ClassFile with default context which is a singleton object.  Is this static variable needed?

Right, it is no more necessary.

> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 526:
> 
>> 524:             clb.withFlags(ACC_PRIVATE | ACC_FINAL | ACC_SUPER)
>> 525:                .withSuperclass(InvokerBytecodeGenerator.INVOKER_SUPER_DESC)
>> 526:                .with(SourceFileAttribute.of(clb.constantPool().utf8Entry(className.substring(className.lastIndexOf('/') + 1))));
> 
> Is it because of performance reason to use `SourceFileAttribute.of(Utf8Entry)` rather than `SourceFileAttribute.of(String)`?   If so, a comment to explain would help.

It is redundant relic. Removed, thank you.

> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 36:
> 
>> 34: import java.lang.classfile.ClassBuilder;
>> 35: import java.lang.classfile.ClassFile;
>> 36: import static java.lang.classfile.ClassFile.*;
> 
> Nit: group static imports in line 52 following this file convention.

Fixed, thank you.

> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 41:
> 
>> 39: import java.lang.constant.ClassDesc;
>> 40: import java.lang.constant.ConstantDesc;
>> 41: import static java.lang.constant.ConstantDescs.*;
> 
> Nit: group static imports following this file convention

Fixed, thank you.

> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 57:
> 
>> 55: import java.lang.classfile.constantpool.FieldRefEntry;
>> 56: import java.lang.classfile.constantpool.InterfaceMethodRefEntry;
>> 57: import java.lang.classfile.constantpool.MethodRefEntry;
> 
> Nit: group these imports with the above import java.lang.classfile...

Fixed, thank you.

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 28:
> 
>> 26: package java.lang.invoke;
>> 27: 
>> 28: import static java.lang.classfile.ClassFile.*;
> 
> Nit: move this static import to line 64 following this file convention.

Fixed, thank you.

> src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java line 75:
> 
>> 73:                                         UNBOX_DOUBLE  = unbox(CD_Number, "doubleValue", CD_double);
>> 74: 
>> 75:     static private TypeKind primitiveTypeKindFromClass(Class<?> type) {
> 
> Suggestion:
> 
>     private static TypeKind primitiveTypeKindFromClass(Class<?> type) {

Fixed, thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569024148
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569024311
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569024488
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569023878
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569023198
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569024574
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569024826
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569024982
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569022391
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1569024668

From mbaesken at openjdk.org  Wed Apr 17 15:33:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 Apr 2024 15:33:12 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v2]
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <77KM-XECiKNVyvpW7BwVJLhXdRc8PBR6xXULb-NAFkE=.ae61a3dd-9416-4347-b889-83c4165e81cf@github.com>

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust trace messages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18699/files
  - new: https://git.openjdk.org/jdk/pull/18699/files/128300a0..344d1b89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=00-01

  Stats: 10 lines in 3 files changed: 0 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18699/head:pull/18699

PR: https://git.openjdk.org/jdk/pull/18699

From mbaesken at openjdk.org  Wed Apr 17 15:33:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 Apr 2024 15:33:13 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <udcTUU4SutBxRQ9KrajtkfQAM6bqG63cFd4upYprYXg=.8c43e0cf-9649-419c-82d2-cfad086a0290@github.com>

On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

I adjusted the trace messages a bit to make the coding more consistent to the existing Jli trace code,
I removed the print of the function name because this is usually avoided in the existing cases.
I removed the  'did not succeed' Jli trace messages in GetJREPath because in case of success we would getJli trace  output  ('JRE path is <this-path>')  so missing success output means it failed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2061561008

From jlahoda at openjdk.org  Wed Apr 17 15:36:01 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 15:36:01 GMT
Subject: RFR: 8328481: Implement Module Imports [v7]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <4Vd-LkZgxXvfoTGWJrlYVbIW-k1NCU3-HgCoa_y5MTU=.480aeb7e-e73e-4ab1-bdc4-4b5fb8ae9b5e@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/c75b8b7a..27f9cfb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=05-06

  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From psandoz at openjdk.org  Wed Apr 17 15:42:01 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 Apr 2024 15:42:01 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v2]
In-Reply-To: <2i86OD4MCDX0V3fU-5Es90sPuih1w574HI3Sm0cqGl4=.e3d89c18-30d2-485f-8e07-87706e15e356@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <2i86OD4MCDX0V3fU-5Es90sPuih1w574HI3Sm0cqGl4=.e3d89c18-30d2-485f-8e07-87706e15e356@github.com>
Message-ID: <12PGOrDNqCO_ZOS2WRX7C5qsVqoeev5TJdqCf1kKv5A=.0bc18549-81c4-41dc-a8aa-882c224f6280@github.com>

On Wed, 17 Apr 2024 12:51:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>> 
>> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
>> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied suggested changes

test/jdk/java/lang/invoke/defineHiddenClass/src/Lambda.java line 28:

> 26: public class Lambda implements HiddenTest {
> 27:      public void test() {
> 28:          Function<Object, String> f = o -> o.toString();

Recommend you retain the existing method reference e.g.:

         Function<Object, String> fmref = Object::toString;
         Function<Object, String> flexp = o -> o.toString();
         String s = fmref.apply(this) + flexp.apply(this);
         ...

Or split them out into two tests (easier to debug if case fails).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18810#discussion_r1569060714

From asotona at openjdk.org  Wed Apr 17 15:50:48 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 15:50:48 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v6]
In-Reply-To: <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>
Message-ID: <Wrjlk_NcOJTrzphWCwnw4Y9_T7lsC2UKnaf7uE1MSkk=.c8821b20-d1be-4eda-ad1a-54b46c18933a@github.com>

On Wed, 17 Apr 2024 15:21:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> 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 12 additional commits since the last revision:
> 
>  - applied suggested changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Reversion of ClassBuilder changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - added missing comment
>  - fixed InnerClassLambdaMetafactory for hidden caller classes
>  - performance improvements
>  - consolidation of descriptors handling
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/ee3b164d...304054b9

Thank you for the review.

> How is the performance result compared to using ASM?

I've actually triggered a large set of benchmarks to see the impact. Any hint which benchmarks to focus on would be welcome.

Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17108#issuecomment-2061616868

From asotona at openjdk.org  Wed Apr 17 16:08:31 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 16:08:31 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v3]
In-Reply-To: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
Message-ID: <oQdT5Pr67Ln_4GQBlvjpMrBcQBWQVjN_1AiYRbHmeU8=.c1a7ec6f-d104-4544-b17d-8d3cf3da2d52@github.com>

> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
> 
> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - typo in comment fix
 - applied suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18810/files
  - new: https://git.openjdk.org/jdk/pull/18810/files/c637ab90..e8eb1752

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18810&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18810&range=01-02

  Stats: 18 lines in 3 files changed: 15 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18810/head:pull/18810

PR: https://git.openjdk.org/jdk/pull/18810

From asotona at openjdk.org  Wed Apr 17 16:08:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 16:08:32 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v2]
In-Reply-To: <12PGOrDNqCO_ZOS2WRX7C5qsVqoeev5TJdqCf1kKv5A=.0bc18549-81c4-41dc-a8aa-882c224f6280@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <2i86OD4MCDX0V3fU-5Es90sPuih1w574HI3Sm0cqGl4=.e3d89c18-30d2-485f-8e07-87706e15e356@github.com>
 <12PGOrDNqCO_ZOS2WRX7C5qsVqoeev5TJdqCf1kKv5A=.0bc18549-81c4-41dc-a8aa-882c224f6280@github.com>
Message-ID: <YwrzF1LYJvGcIPEf0qhaMtikux2hoKk3DzWx54ZyM0Y=.7df5af7d-27ed-42e4-a194-03b72b22f19c@github.com>

On Wed, 17 Apr 2024 15:39:11 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied suggested changes
>
> test/jdk/java/lang/invoke/defineHiddenClass/src/Lambda.java line 28:
> 
>> 26: public class Lambda implements HiddenTest {
>> 27:      public void test() {
>> 28:          Function<Object, String> f = o -> o.toString();
> 
> Recommend you retain the existing method reference e.g.:
> 
>          Function<Object, String> fmref = Object::toString;
>          Function<Object, String> flexp = o -> o.toString();
>          String s = fmref.apply(this) + flexp.apply(this);
>          ...
> 
> Or split them out into two tests (easier to debug if case fails).

I've split the tests, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18810#discussion_r1569099751

From mchung at openjdk.org  Wed Apr 17 16:24:50 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 17 Apr 2024 16:24:50 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v29]
In-Reply-To: <1LdURqPLqPqn4wPCppk-8RBA-xq9RgGoMEZ9-7GiFN8=.db965de7-9350-4677-9007-72153c64f9d2@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <1LdURqPLqPqn4wPCppk-8RBA-xq9RgGoMEZ9-7GiFN8=.db965de7-9350-4677-9007-72153c64f9d2@github.com>
Message-ID: <AfEl7hlCTpZcYGqI6rwRH2_VbYWI6YjUgp4FkzGxQu8=.b14ad263-dc95-43d0-af87-78042c051d4a@github.com>

On Wed, 17 Apr 2024 11:20:24 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update LoadAIXLibraryFromArchiveObject.java
>   
>   Nits,coding style and variable name

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-2006514775

From mchung at openjdk.org  Wed Apr 17 16:35:03 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 17 Apr 2024 16:35:03 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v6]
In-Reply-To: <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>
Message-ID: <08y8aRNYtCIvWpS8ST_RCbjjr2uXGu2_AXyBpS0cCj8=.b6e6890c-96e3-4719-a58b-34b019d3b9c0@github.com>

On Wed, 17 Apr 2024 15:21:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> 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 12 additional commits since the last revision:
> 
>  - applied suggested changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Reversion of ClassBuilder changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - added missing comment
>  - fixed InnerClassLambdaMetafactory for hidden caller classes
>  - performance improvements
>  - consolidation of descriptors handling
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/6af94676...304054b9

@cl4es and @kuksenko can you advice what performance benchmarks to run to approve this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17108#issuecomment-2061720876

From iris at openjdk.org  Wed Apr 17 16:51:43 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 17 Apr 2024 16:51:43 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
Message-ID: <zb0rhfphJD1OpHKxYZM7uCUs18_TVM-0N0lyFxvHgj0=.5bd1fb4c-09e1-49b3-b314-dfaee73d85fc@github.com>

On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2006604933

From mdoerr at openjdk.org  Wed Apr 17 17:06:07 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 Apr 2024 17:06:07 GMT
Subject: RFR: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object [v29]
In-Reply-To: <1LdURqPLqPqn4wPCppk-8RBA-xq9RgGoMEZ9-7GiFN8=.db965de7-9350-4677-9007-72153c64f9d2@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <1LdURqPLqPqn4wPCppk-8RBA-xq9RgGoMEZ9-7GiFN8=.db965de7-9350-4677-9007-72153c64f9d2@github.com>
Message-ID: <2bHMJOE57JfbAqAZLbEYZ0s8Cx2NgVBwuX7e1WYHmJg=.be75b3e5-9840-46e1-bf43-e1a504a12069@github.com>

On Wed, 17 Apr 2024 11:20:24 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update LoadAIXLibraryFromArchiveObject.java
>   
>   Nits,coding style and variable name

Thanks! Let's ship it!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2061781048

From sroy at openjdk.org  Wed Apr 17 17:06:08 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 17 Apr 2024 17:06:08 GMT
Subject: Integrated: 8319516: AIX System::loadLibrary needs support to load a
 shared library from an archive object
In-Reply-To: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
Message-ID: <8fmsOZFGHWQM2dVgcsdRzt3dTkpRq4XjwK3Cqa7xJVQ=.7f110a13-6104-4455-be27-795d5dacffab@github.com>

On Wed, 21 Feb 2024 11:32:41 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> Allow support for both .a and .so files in AIX.
> If .so file is not found, allow fallback to .a extension.
> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)

This pull request has now been integrated.

Changeset: 4895a15a
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4895a15a779fab70290b4df3b464d79a14937e28
Stats:     149 lines in 2 files changed: 149 ins; 0 del; 0 mod

8319516: AIX System::loadLibrary needs support to load a shared library from an archive object

Reviewed-by: mdoerr, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/17945

From bchristi at openjdk.org  Wed Apr 17 17:14:49 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 17 Apr 2024 17:14:49 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v22]
In-Reply-To: <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>
Message-ID: <fa0Mqk6azF75mkiKAwMZHmtC5Lsw4KqcTAMZb3bIJWo=.16abf539-e6c6-4ab5-a937-a0505522d802@github.com>

On Fri, 5 Apr 2024 23:13:39 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another update to reachabilityFence() @apiNote

AFAICT, all review feedback on this change has been addressed. I would love to have some reviewers take another look. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16644#issuecomment-2061795930

From jlu at openjdk.org  Wed Apr 17 17:16:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 17 Apr 2024 17:16:55 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v4]
In-Reply-To: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
Message-ID: <TYf-08-44S6-yGE2RvoAH1ts7JZrGBDTHOlR_PyrYyQ=.86eac5f6-2ca4-4847-8dfb-9a5c56c19fb4@github.com>

> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
> 
> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
> 
> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
> 
> I will update the CSR once the wording is finalized.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Make apparent the distinction of cnFmt and dFmt for factory methods.
  Loosen wording from cast to convert.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18731/files
  - new: https://git.openjdk.org/jdk/pull/18731/files/95626d94..33b02f00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18731&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18731&range=02-03

  Stats: 10 lines in 3 files changed: 0 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18731/head:pull/18731

PR: https://git.openjdk.org/jdk/pull/18731

From psandoz at openjdk.org  Wed Apr 17 18:55:00 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 Apr 2024 18:55:00 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v3]
In-Reply-To: <oQdT5Pr67Ln_4GQBlvjpMrBcQBWQVjN_1AiYRbHmeU8=.c1a7ec6f-d104-4544-b17d-8d3cf3da2d52@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <oQdT5Pr67Ln_4GQBlvjpMrBcQBWQVjN_1AiYRbHmeU8=.c1a7ec6f-d104-4544-b17d-8d3cf3da2d52@github.com>
Message-ID: <ZblulYMJdZZbky-tSANUGskbRQMV3uqR6At6wZ2FOK4=.da3a28b9-fa09-4f18-876c-b23f5dfab98d@github.com>

On Wed, 17 Apr 2024 16:08:31 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>> 
>> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
>> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - typo in comment fix
>  - applied suggested changes

Looks good to me. I conservatively bumped the review count to 2.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18810#pullrequestreview-2006903761

From jlahoda at openjdk.org  Wed Apr 17 19:33:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 19:33:09 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing ListModuleDeps test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/27f9cfb5..7fa0ad51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=06-07

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From dlong at openjdk.org  Wed Apr 17 19:36:01 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 19:36:01 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]
In-Reply-To: <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
Message-ID: <EYByM73-dAJnDr1feKyeIBHK8ydoHh24wgn1opwTX0s=.c6e64958-7cf3-47de-a5a8-ec4a18c21ad0@github.com>

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4670:

> 4668:     const Register tmp5  = r15;
> 4669:     const Register tmp6  = r16;
> 4670:     const Register tmp7  = r17;

Why not minimize changes and continue to use r5 for tmp0?  I see no need for r17 or to reassign all the other tmp registers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569401544

From dlong at openjdk.org  Wed Apr 17 19:48:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 19:48:02 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]
In-Reply-To: <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
Message-ID: <RywPZn8_CwtUApnpLn0XHGYM2n2Vwi8jGuHPaRoCyFE=.0341cdcf-b655-4bdf-bc1f-759bc301a38c@github.com>

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693:

> 4691:     const Register xlen  = r1;
> 4692:     const Register z     = r2;
> 4693:     const Register zlen  = r3;

LibraryCallKit::inline_squareToLen() is still computing zlen and passing it as the 4th arg, even though the value is unused.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4702:

> 4700:     const Register tmp5  = r15;
> 4701:     const Register tmp6  = r16;
> 4702:     const Register tmp7  = r17;

No need for r17 or sorting tmps.  Make tmp0 r3, or r6, r7, etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569419199
PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569420732

From dlong at openjdk.org  Wed Apr 17 19:52:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 19:52:03 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]
In-Reply-To: <RywPZn8_CwtUApnpLn0XHGYM2n2Vwi8jGuHPaRoCyFE=.0341cdcf-b655-4bdf-bc1f-759bc301a38c@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
 <RywPZn8_CwtUApnpLn0XHGYM2n2Vwi8jGuHPaRoCyFE=.0341cdcf-b655-4bdf-bc1f-759bc301a38c@github.com>
Message-ID: <4ghKQMWdpqPyMQzdFJH-IFlAwyoicv7CjNwub7XsvT8=.d8419240-b77b-4410-9da4-f1e0df9c022a@github.com>

On Wed, 17 Apr 2024 19:45:02 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comment.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4702:
> 
>> 4700:     const Register tmp5  = r15;
>> 4701:     const Register tmp6  = r16;
>> 4702:     const Register tmp7  = r17;
> 
> No need for r17 or sorting tmps.  Make tmp0 r3, or r6, r7, etc.

Also, I don't see why the code below saves and restores r4/r5.  Maybe @theRealAph knows?  Aren't all these registers killed across a runtime call?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569427241

From mchung at openjdk.org  Wed Apr 17 19:55:00 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 17 Apr 2024 19:55:00 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v3]
In-Reply-To: <oQdT5Pr67Ln_4GQBlvjpMrBcQBWQVjN_1AiYRbHmeU8=.c1a7ec6f-d104-4544-b17d-8d3cf3da2d52@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <oQdT5Pr67Ln_4GQBlvjpMrBcQBWQVjN_1AiYRbHmeU8=.c1a7ec6f-d104-4544-b17d-8d3cf3da2d52@github.com>
Message-ID: <5msjWSuhsREY4qVCoqvMmwvxExV8grwv6uHmoGyach4=.bcd1dd8a-cdca-4292-93ea-5295b34e8274@github.com>

On Wed, 17 Apr 2024 16:08:31 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>> 
>> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
>> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - typo in comment fix
>  - applied suggested changes

Looks fine to me.   A hidden class cannot be resolved by name.   I tweaked the comment to make it clear.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 182:

> 180:         // live implementation method handle to the proxy class to invoke
> 181:         // directly. (javac prefers to avoid this situation by generating
> 182:         // bridges in the target class)

Suggestion:

        // lambda class has no access to the resolved method, or does
        // 'invokestatic' on a hidden class which cannot be resolved by name.
        // Instead, we need to pass the live implementation method handle to
        // the proxy class to invoke directly. (javac prefers to avoid this
        // situation by generating bridges in the target class)

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18810#pullrequestreview-2007006920
PR Review Comment: https://git.openjdk.org/jdk/pull/18810#discussion_r1569431448

From naoto at openjdk.org  Wed Apr 17 19:55:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 Apr 2024 19:55:44 GMT
Subject: RFR: 8329222: java.text.NumberFormat (and subclasses) spec updates
 [v4]
In-Reply-To: <TYf-08-44S6-yGE2RvoAH1ts7JZrGBDTHOlR_PyrYyQ=.86eac5f6-2ca4-4847-8dfb-9a5c56c19fb4@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
 <TYf-08-44S6-yGE2RvoAH1ts7JZrGBDTHOlR_PyrYyQ=.86eac5f6-2ca4-4847-8dfb-9a5c56c19fb4@github.com>
Message-ID: <ogOD5zYvkdUTaYVsSvi7WM8c_sR1k_xgVlnmQCogKrA=.dfcaf5fe-d9e1-43ac-bbfc-689dfc86f613@github.com>

On Wed, 17 Apr 2024 17:16:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
>> 
>> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
>> 
>> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
>> 
>> I will update the CSR once the wording is finalized.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make apparent the distinction of cnFmt and dFmt for factory methods.
>   Loosen wording from cast to convert.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18731#pullrequestreview-2007009092

From dlong at openjdk.org  Wed Apr 17 20:08:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 20:08:00 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]
In-Reply-To: <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
Message-ID: <HhvLM3UiMNXYqVgcFf0qPe8R3Fx6X1gdJEgtbf_p7h8=.38a8fa93-de8a-4478-82de-ab939e537927@github.com>

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6662:

> 6660:   push(tmp5);
> 6661: 
> 6662:   push(xlen);

There may be an opportunity here (separate RFE?) to get rid of the save/restore for these.  I don't think it's necessary if this is called as part of a C2 stub.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569452818

From dlong at openjdk.org  Wed Apr 17 20:14:42 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 20:14:42 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]
In-Reply-To: <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
Message-ID: <R3IU15-K40lcvGEzIojc2CYQHberSItTBAltejI1vuI=.fefb47de-9045-4df5-a2c1-3508a5c1b0ca@github.com>

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comment.

I think you'll want to ask port maintainers for aarch64/arm/ppc/riscv/s390 to review and test those changes.
There may be some opportunities for minor improvements, but those could be done later.  For example, we are computing `zlen` for the squareToLen stub even though the value is unused.  And both x86 and aarch64 seem to have unneeded save/restore code, even though I think all these registers are killed when called by a C2 runtime stub.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2062138149

From darcy at openjdk.org  Wed Apr 17 20:57:14 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 20:57:14 GMT
Subject: RFR: 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
Message-ID: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>

8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION

-------------

Commit messages:
 - JDK-8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION

Changes: https://git.openjdk.org/jdk/pull/18828/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18828&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330458
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18828.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18828/head:pull/18828

PR: https://git.openjdk.org/jdk/pull/18828

From skuksenko at openjdk.org  Wed Apr 17 21:16:37 2024
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Wed, 17 Apr 2024 21:16:37 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v6]
In-Reply-To: <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>
Message-ID: <3z8eVC0Dylg4NfrV-CMOyH3ewHbf1DdZXDFewZC-EdM=.50a7ba3a-870a-44e7-99bf-e3ee781d0611@github.com>

On Wed, 17 Apr 2024 15:21:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> 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 12 additional commits since the last revision:
> 
>  - applied suggested changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Reversion of ClassBuilder changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - added missing comment
>  - fixed InnerClassLambdaMetafactory for hidden caller classes
>  - performance improvements
>  - consolidation of descriptors handling
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/983bd2da...304054b9

Sorry, but I am afraid we don't have benchmarks targeting lambdas startup.

________________________________________
From: Mandy Chung ***@***.***>
Sent: Wednesday, April 17, 2024 9:32 AM
To: openjdk/jdk
Cc: Sergey Kuksenko; Mention
Subject: [External] : Re: [openjdk/jdk] 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles (PR #17108)

@cl4es<https://urldefense.com/v3/__https://github.com/cl4es__;!!ACWV5N9M2RV99hQ!JX5yZ-c9NW3SFSXgKWYc1Kxk2V17ToAhlQI5UDK7A2MWjHAXtLYugARjgiqw_ohDi3CY7GPh1B2YJuwCbeQ-huf92_-fGQ$> and @kuksenko<https://urldefense.com/v3/__https://github.com/kuksenko__;!!ACWV5N9M2RV99hQ!JX5yZ-c9NW3SFSXgKWYc1Kxk2V17ToAhlQI5UDK7A2MWjHAXtLYugARjgiqw_ohDi3CY7GPh1B2YJuwCbeQ-hudN3iK0Ug$> can you advice what performance benchmarks to run to approve this change?

?
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/17108*issuecomment-2061720876__;Iw!!ACWV5N9M2RV99hQ!JX5yZ-c9NW3SFSXgKWYc1Kxk2V17ToAhlQI5UDK7A2MWjHAXtLYugARjgiqw_ohDi3CY7GPh1B2YJuwCbeQ-hudSbyeARA$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AA72M642PZCTBSXMJQ57543Y52P2NAVCNFSM6AAAAABAUY4GQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRRG4ZDAOBXGY__;!!ACWV5N9M2RV99hQ!JX5yZ-c9NW3SFSXgKWYc1Kxk2V17ToAhlQI5UDK7A2MWjHAXtLYugARjgiqw_ohDi3CY7GPh1B2YJuwCbeQ-hueMj9Y5wA$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17108#issuecomment-2062338565

From jjg at openjdk.org  Wed Apr 17 21:50:01 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 17 Apr 2024 21:50:01 GMT
Subject: RFR: 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
In-Reply-To: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>
References: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>
Message-ID: <2fei-Cs16hPkUXkvADz0S5RV0BOl8SOOEfPM2eTN8rk=.a8605f32-e112-412b-8d01-64ecfcc0e14d@github.com>

On Wed, 17 Apr 2024 20:46:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18828#pullrequestreview-2007300284

From redestad at openjdk.org  Wed Apr 17 23:17:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 Apr 2024 23:17:05 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v6]
In-Reply-To: <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <t9pmrlqpI_pgUwgynqddhyo_rgIECRuZ2jfN2FTktcM=.0337f4f5-4f6f-46cb-86c7-de707393da3b@github.com>
Message-ID: <WwUzWn3sJKIi6NY-XxAsQioV1RBnpceTlH-l3bkj0is=.c1237093-6660-47d9-b702-e8f940cdc997@github.com>

On Wed, 17 Apr 2024 15:21:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> 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 12 additional commits since the last revision:
> 
>  - applied suggested changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Reversion of ClassBuilder changes
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - added missing comment
>  - fixed InnerClassLambdaMetafactory for hidden caller classes
>  - performance improvements
>  - consolidation of descriptors handling
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9359450b...304054b9

There is a slew of internal benchmarks testing lambda initialization. Some focused, many indirect. I've given a few pointers offline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17108#issuecomment-2062633171

From iris at openjdk.org  Wed Apr 17 23:39:10 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 17 Apr 2024 23:39:10 GMT
Subject: RFR: 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
In-Reply-To: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>
References: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>
Message-ID: <l3vBpxHr1yKumWYekcgr3ItyGlBAJD5uQT3HLgunf3s=.196c3ccc-7002-4431-acdf-f27df4b978fe@github.com>

On Wed, 17 Apr 2024 20:46:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18828#pullrequestreview-2007547483

From joehw at openjdk.org  Wed Apr 17 23:52:16 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 17 Apr 2024 23:52:16 GMT
Subject: RFR: 8330542: Add two sample configuration files
Message-ID: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>

Add two sample configuration files:

  jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22

  jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

-------------

Commit messages:
 - fix whitespace
 - 8330542: Add two sample configuration files

Changes: https://git.openjdk.org/jdk/pull/18831/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330542
  Stats: 229 lines in 2 files changed: 229 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From alanb at openjdk.org  Thu Apr 18 05:45:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Apr 2024 05:45:58 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
Message-ID: <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>

On Wed, 17 Apr 2024 19:33:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing ListModuleDeps test.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 84:

> 82:         @JEP(number=461, title="Stream Gatherers", status="Preview")
> 83:         STREAM_GATHERERS,
> 84:         @JEP(number=0, title="Module Imports", status="Preview")

I see this has been assigned JEP 476 so I assume you can set the number for the first integration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570018046

From asotona at openjdk.org  Thu Apr 18 05:54:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 18 Apr 2024 05:54:17 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v4]
In-Reply-To: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
Message-ID: <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>

> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
> 
> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18810/files
  - new: https://git.openjdk.org/jdk/pull/18810/files/e8eb1752..091ee2af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18810&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18810&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18810/head:pull/18810

PR: https://git.openjdk.org/jdk/pull/18810

From asotona at openjdk.org  Thu Apr 18 05:54:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 18 Apr 2024 05:54:18 GMT
Subject: Integrated: 8330467: NoClassDefFoundError when lambda is in a hidden
 class
In-Reply-To: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
Message-ID: <9K20wwlbuVAnq9Rp8Xt-SYy8V6S6H5MhM3wTjaD8tnw=.3fa5d76d-886b-489e-9a08-22d985d90817@github.com>

On Wed, 17 Apr 2024 08:46:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
> 
> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 706b421c
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/706b421ccaff2129512ee3ea15ef1d6c264cbe01
Stats:     58 lines in 3 files changed: 53 ins; 0 del; 5 mod

8330467: NoClassDefFoundError when lambda is in a hidden class

Reviewed-by: psandoz, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/18810

From asotona at openjdk.org  Thu Apr 18 05:55:57 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 18 Apr 2024 05:55:57 GMT
Subject: RFR: 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
In-Reply-To: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>
References: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>
Message-ID: <g92XU44AHbW1m20wriYv8Xdxh9KtN1a-ACW5k7JXTLE=.538c4344-ecc2-4f0c-a33e-bf82750d1e65@github.com>

On Wed, 17 Apr 2024 20:46:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18828#pullrequestreview-2007907265

From asotona at openjdk.org  Thu Apr 18 06:14:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 18 Apr 2024 06:14:03 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v7]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <z2ge_Nn1egz1qvQS71fj2RZeP6iUGush8nzBI9YBs8s=.d8c5dfef-450d-4f4c-b16f-e819abfd769e@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> 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 13 commits:

 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
 - applied suggested changes
 - Merge branch 'master' into JDK-8294960-invoke
 - Reversion of ClassBuilder changes
 - Merge branch 'master' into JDK-8294960-invoke
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - added missing comment
 - fixed InnerClassLambdaMetafactory for hidden caller classes
 - performance improvements
 - ... and 3 more: https://git.openjdk.org/jdk/compare/706b421c...bae31c64

-------------

Changes: https://git.openjdk.org/jdk/pull/17108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=06
  Stats: 2094 lines in 9 files changed: 421 ins; 838 del; 835 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From alanb at openjdk.org  Thu Apr 18 06:33:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Apr 2024 06:33:56 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v2]
In-Reply-To: <fJ1ohG-TqLas634eWxwSbIcwox4Tqyy6cRJZniDeoto=.f0b70d67-0f83-407d-a97b-1334a5da1099@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <9yl5glod4xr1tHQtbwdx11ySJHlOeWgDvShpchddGCY=.e3ce9655-9946-4d0a-80f9-e34632c5cc50@github.com>
 <fJ1ohG-TqLas634eWxwSbIcwox4Tqyy6cRJZniDeoto=.f0b70d67-0f83-407d-a97b-1334a5da1099@github.com>
Message-ID: <aHlJc0b-zED439zaROOaHWJbeA7RQuoKBX6StMpjrXI=.813dfa89-da8c-4b22-bfb8-85cf611fc8a4@github.com>

On Tue, 16 Apr 2024 14:29:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.base/windows/native/libjli/java_md.c line 326:
>> 
>>> 324:     }
>>> 325: 
>>> 326:     JLI_TraceLauncher("GetJREPath - attempt to get JRE location from shared lib of the image\n");
>> 
>> Maybe add a trace also in the USE_REGISTRY_LOOKUP section
>
> Hi Christoph, seems the USE_REGISTRY_LOOKUP is currently unused  (at least without additional defines that are not present usually) 
> 
> src/java.base/windows/native/libjli/java_md.c:52:#ifdef USE_REGISTRY_LOOKUP
> src/java.base/windows/native/libjli/java_md.c:333:#ifdef USE_REGISTRY_LOOKUP
> 
> 
> I am not sure if this even works any more.  Maybe Alan could comment on this ?

@MBaesken I checked into the building with -DUSE_REGISTRY_LOOKUP as that compiled in code that the Oracle installer needed when it copied java.exe to somewhere. This is indeed left over code and can be removed from java_md.c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18699#discussion_r1570072071

From jlahoda at openjdk.org  Thu Apr 18 06:34:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 06:34:22 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Updating JEP number and caption.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/7fa0ad51..432393ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From jlahoda at openjdk.org  Thu Apr 18 06:34:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 06:34:22 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
 <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>
Message-ID: <G-3sx5-oNAcuWzF5Y26QXZuX_DvmgPJRqfMV6uF7ufI=.1fc21a6a-fa90-4f9f-baab-ba800a46a9e0@github.com>

On Thu, 18 Apr 2024 05:43:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing ListModuleDeps test.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 84:
> 
>> 82:         @JEP(number=461, title="Stream Gatherers", status="Preview")
>> 83:         STREAM_GATHERERS,
>> 84:         @JEP(number=0, title="Module Imports", status="Preview")
> 
> I see this has been assigned JEP 476 so I assume you can set the number for the first integration.

Done, thanks:
https://github.com/openjdk/jdk/pull/18614/commits/432393abb4ac1f5c4730d982a3911284fe866318

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570071215

From mbaesken at openjdk.org  Thu Apr 18 06:57:05 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Apr 2024 06:57:05 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v3]
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <Uqd7U25xxNtQASTKFDk8rgd-h4_NSeMxwgkEQ37ha_E=.f0bb484f-d9bc-4844-bd00-b93159cbbb07@github.com>

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove obsolete USE_REGISTRY_LOOKUP usages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18699/files
  - new: https://git.openjdk.org/jdk/pull/18699/files/344d1b89..ddb3e0fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=01-02

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18699/head:pull/18699

PR: https://git.openjdk.org/jdk/pull/18699

From mbaesken at openjdk.org  Thu Apr 18 06:58:57 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Apr 2024 06:58:57 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v3]
In-Reply-To: <aHlJc0b-zED439zaROOaHWJbeA7RQuoKBX6StMpjrXI=.813dfa89-da8c-4b22-bfb8-85cf611fc8a4@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <9yl5glod4xr1tHQtbwdx11ySJHlOeWgDvShpchddGCY=.e3ce9655-9946-4d0a-80f9-e34632c5cc50@github.com>
 <fJ1ohG-TqLas634eWxwSbIcwox4Tqyy6cRJZniDeoto=.f0b70d67-0f83-407d-a97b-1334a5da1099@github.com>
 <aHlJc0b-zED439zaROOaHWJbeA7RQuoKBX6StMpjrXI=.813dfa89-da8c-4b22-bfb8-85cf611fc8a4@github.com>
Message-ID: <J2RgMqm_aYtprMEFAAXBuY04xQYvoci8ZNaIONJKvTc=.1d0d4763-c6cf-4d1f-8e63-2d73b2769dfc@github.com>

On Thu, 18 Apr 2024 06:31:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Christoph, seems the USE_REGISTRY_LOOKUP is currently unused  (at least without additional defines that are not present usually) 
>> 
>> src/java.base/windows/native/libjli/java_md.c:52:#ifdef USE_REGISTRY_LOOKUP
>> src/java.base/windows/native/libjli/java_md.c:333:#ifdef USE_REGISTRY_LOOKUP
>> 
>> 
>> I am not sure if this even works any more.  Maybe Alan could comment on this ?
>
> @MBaesken I checked into the building with -DUSE_REGISTRY_LOOKUP as that compiled in code that the Oracle installer needed when it copied java.exe to somewhere. This is indeed left over code and can be removed from java_md.c.

Hi Alan, thanks for checking this !
I removed the USE_REGISTRY_LOOKUP usages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18699#discussion_r1570109527

From jlahoda at openjdk.org  Thu Apr 18 07:37:04 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 07:37:04 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <61FmMvHyAQXcl_ZWYGEWwLDU7O8a-vdHTlu56rnKzqo=.cd118172-6497-4963-ad3b-b8f865009638@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

My personal comments here:
- I am fine with a solution like this. In 18753, I wanted to avoid a change of dynamics between the Java helper and the native part. But if we can change that, it looks better. I would suggest to take the test from 18753 though - doing a change like this without a test may lead to hard-to-find regressions in the future. (Note the current test should guard against both JDK-8329420 and JDK-8329581.) Or write a different test.
- as Mandy points out, `LaucherHelper` already reads/has variables for "is-static" and "no-arguments" in `validateMainMethod`, so it should be possible to just use that values; also as Mandy points out, we can probably get rid of `CHECK_EXCEPTION_FAIL` and `CHECK_EXCEPTION_NULL_FAIL`, and use the `..._LEAVE` variants, no? (The `..._FAIL` variants where needed so that the launcher could continue with the next variant, but since we now only call the correct variant, we can just stop if something goes wrong?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2063217552

From alanb at openjdk.org  Thu Apr 18 09:53:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Apr 2024 09:53:05 GMT
Subject: RFR: 8330542: Add two sample configuration files
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <x1zstClHM3hSpRuc0ey6uLkpwi-TKaU7Z_uGSz7Xp0c=.87dec664-853f-461c-82f8-27fdf4060636@github.com>

On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Just some context here. The JDK has been on a path for many releases to make XML processing more secure by default. At some point there will be a proposal/JEP to flip the switch, something that may create an upgrade challenge for some applications and deployments that haven't embraced the various security features and configuration added over the last 10+ years. The addition of conf/jaxp-strict.properties allows deployments to test more the secure/strict behavior in preparation for a possible future where strict is the default. As examples: trying this out may help identify processing XML that (perhaps unknowingly) makes outbound network connections to fetch DTD, or processing XML that relies on extension functions. So I think very useful to have this configuration available in a shipping JDK but it may need a write-up/JEP before anyone knows about this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2063474370

From sgehwolf at openjdk.org  Thu Apr 18 09:54:56 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 18 Apr 2024 09:54:56 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <AyhwTYv3k8rFJ2k4nQT93fwyO_1gXMALMmmckLwrfpw=.2994f76e-ca36-4013-b03b-d4006349ad38@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
 <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>
 <AyhwTYv3k8rFJ2k4nQT93fwyO_1gXMALMmmckLwrfpw=.2994f76e-ca36-4013-b03b-d4006349ad38@github.com>
Message-ID: <ZRlHTb5Q36yCkO4GGADw-2sThIQzkW1zDiWAYyJ4Zkk=.14207e13-760e-4bb0-9a75-e4da303c22a8@github.com>

On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>>> IMHO `is_containerized()` is OK to return `false` even when running in a container but with no limitations set.
>> 
>> The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints. In order to do this, we need a reliable way to distinguish that vs. non-containerized setup. If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.
>
>> The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints.
> 
> The in-container tuning means to use all the available resources. Containers in the real world have some memory limits set which is where my modified patch still correctly identifies it as a container to use all the available resources of the node which is the whole goal of the container detection code.
> 
>> In order to do this, we need a reliable way to distinguish that vs. non-containerized setup.
> 
> I expect it should have been written "We need a reliable way to distinguish real world in-container vs. non-containerized setup. We do not mind behavior for artificial containers on OpenJDK development machines.". Which is what my patch does in an easier and less error-prone way.
> 
>> If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.
> 
> That behaves still the same with my patch.
> 
> Could you give a countercase where my patch behaves wrongly?

@jankratochvil I believe this boils down to what we actually want. Should `OSContainer::is_containerized()` return `false` when run *inside* a container? If so, when is it OK to do that? Should `OSContainer::is_containerized()` return `true` on a physical Linux deployment? IMO, the read-only property of the mount points was something that fit naturally since, we already scan those anyway for (cgv1 vs cgv2 detection). Therefore it was something to consider to make heuristics more accurate.

The truth table of the patch in this PR looks like this:
| `OSContainer::is_containerized()` value  | Actual deployment scenario |
| ------------- | ------------- |
| `true`  | OpenJDK runs in an unprivileged container **without** a cpu/memory limit |
| `true`  | OpenJDK runs in an unprivileged container **with** a cpu/memory limit |
| `true`  | OpenJDK runs in a privileged container **with** a cpu/memory limit |
| `false`  | OpenJDK runs in a privileged container **without** a cpu/memory limit |
| `false`  | OpenJDK runs in a systemd slice **without** a cpu/memory limit |
| `true`  | OpenJDK runs in a systemd slice **with** a cpu/memory limit |
| `false`  | OpenJDK runs on a physical Linux system (VM or bare metal) |

As you can see, the case of "OpenJDK runs in a privileged container *without* a cpu/memory limit" gives the wrong result. However, I consider this a fairly uncommon setup and there isn't really anything we can do to detect this kind of setup. Even if we did manage to detect it, why would we care? It's a question of probability.

> Could you give a countercase where my patch behaves wrongly?

Again, it's not a case of right or wrong IMO. Since we are in the land of heuristics, they will be wrong in some cases. We should make them so that we cover the common cases and, perhaps, are able to use those in serviceability tools to help guide diagnosis and/or further tuning. So far the existing capabilities were OK, but prevent further out-of-the-box tuning and/or accurate data collection.

Your proposed patch (it's one I had in a previous iteration too, fwiw) would also return `false` for the case of "OpenJDK runs in an unprivileged container **without** a cpu/memory limit", which seems counterintuitive if OpenJDK actually runs in a container! What's more, it seems a fairly common case. Also, there is a chance of the OpenJDK heuristics to fail memory/cpu limit detection because of bugs and new developments. It seems the safer option to know that OpenJDK is containerized (using other heuristics) in that case. Maybe that's just me.

Let's have that discussion more broadly and see if we can reach consensus!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2063477204

From mcimadamore at openjdk.org  Thu Apr 18 10:50:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 Apr 2024 10:50:04 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
Message-ID: <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>

On Thu, 18 Apr 2024 06:34:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating JEP number and caption.

Marked as reviewed by mcimadamore (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3541:

> 3539: # 0: symbol, 1: symbol
> 3540: compiler.err.import.module.does.not.read=\
> 3541:     {1} module does not read: {0}

shouldn't it be `module {1} does not read: {0}` ? Also, maybe worth reordering the params?

-------------

PR Review: https://git.openjdk.org/jdk/pull/18614#pullrequestreview-2008496026
PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570474076

From pminborg at openjdk.org  Thu Apr 18 11:26:02 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 18 Apr 2024 11:26:02 GMT
Subject: Integrated: 8329997: Add provisions for checking memory segment
 alignment constraints
In-Reply-To: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
References: <eDPGpOVMYLT6G7YUVfMFg6Q6W1GHCjdsyI1wMsbrOQs=.c5a6fa37-b6bd-4902-9367-609a09c5254d@github.com>
Message-ID: <tl8zBpTCDa3ZAWosvAwmXsVmGsRHq8NDpHsdSq0gKrs=.3affcd9b-6bda-4d43-a642-0687a9d2f97f@github.com>

On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that returns the maximum byte alignment of a segment (both heap and native segments).
> 
> Clients can then use this method to determine if a segment is properly aligned for any given layout (e.g. following a `MemorySegment::reinterpret` operation).

This pull request has now been integrated.

Changeset: b648ed0a
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b648ed0a08b5ed47c1a7d7cbca89d8f389b17013
Stats:     135 lines in 4 files changed: 129 ins; 2 del; 4 mod

8329997: Add provisions for checking memory segment alignment constraints

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/18779

From pminborg at openjdk.org  Thu Apr 18 11:32:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 18 Apr 2024 11:32:13 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v6]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Change exception type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/2ebac9fc..e2f6c4c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=04-05

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18474/head:pull/18474

PR: https://git.openjdk.org/jdk/pull/18474

From jlahoda at openjdk.org  Thu Apr 18 12:11:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 12:11:19 GMT
Subject: RFR: 8328481: Implement Module Imports [v10]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback - improving the 'module (current) does not read (target).

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/432393ab..846b038e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=08-09

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From jlahoda at openjdk.org  Thu Apr 18 12:11:20 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 12:11:20 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
 <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>
Message-ID: <w6eHmke7hUSdWcDyIABENw8qivz2txDkTEPDgq8uycw=.b0705162-0183-4840-89c0-259347ef83f8@github.com>

On Thu, 18 Apr 2024 10:47:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating JEP number and caption.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3541:
> 
>> 3539: # 0: symbol, 1: symbol
>> 3540: compiler.err.import.module.does.not.read=\
>> 3541:     {1} module does not read: {0}
> 
> shouldn't it be `module {1} does not read: {0}` ? Also, maybe worth reordering the params?

Thanks! Fixed:
https://github.com/openjdk/jdk/pull/18614/commits/846b038ed8145ede9c419daddedb794a429dafac

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570597292

From jvernee at openjdk.org  Thu Apr 18 12:21:58 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 18 Apr 2024 12:21:58 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v6]
In-Reply-To: <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
Message-ID: <ftS-TAS4lTtUvayLC83NpNpioHhv2W3ohZMkPKyAydY=.8d2decb3-19ed-4795-89b5-c1a44183a947@github.com>

On Thu, 18 Apr 2024 11:32:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception type

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2008729407

From jkratochvil at openjdk.org  Thu Apr 18 13:30:08 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 18 Apr 2024 13:30:08 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
Message-ID: <0gUVzigzVfEv1IWV9irog8S3hPme-Aux9fDUWjPO2wc=.fa1648a1-4714-4f74-acc0-22c4250490af@github.com>

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - Make find_ro static and local to compilation unit
>  - 8261242: [Linux] OSContainer::is_containerized() returns true

Could not we rename `is_containerized()` to `use_container_limit()` ? As that is the current only purpose of `is_containerized()`.

I did not test it but I expect the values will be:

| your patch | my trivial patch | Actual deployment scenario |
|--------|--------|--------|
| `true` | `false` |OpenJDK runs in an unprivileged container **without** a cpu/memory limit |
| `true` | `true` | OpenJDK runs in an unprivileged container **with** a cpu/memory limit |
| `false` | `false` | OpenJDK runs in a privileged container **without** a cpu/memory limit |
| `true` | `true` | OpenJDK runs in a privileged container **with** a cpu/memory limit |
| `false` | `false` | OpenJDK runs in a systemd slice **without** a cpu/memory limit |
| `true` | `true` | OpenJDK runs in a systemd slice **with** a cpu/memory limit |
| `false` | `false` | OpenJDK runs on a physical Linux system (VM or bare metal) |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2063868908

From alanb at openjdk.org  Thu Apr 18 13:42:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Apr 2024 13:42:05 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
Message-ID: <R_Vs8LUQUHD3EOqf8ZKHXCcwW1Sbgoeh2AoVgJudy0s=.ca8c7bed-e5da-4594-9424-e9e3d414b458@github.com>

On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test file local to test

My comments have been addressed and I don't have any else to add. I assume @egahlin will cast an eye over this too.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18542#pullrequestreview-2008938324

From dfuchs at openjdk.org  Thu Apr 18 14:36:05 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Apr 2024 14:36:05 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
Message-ID: <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>

On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test file local to test

Sorry - just noticed this comment has been pending for a few days...

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:

> 64:         FileWriteEvent.class,
> 65:         SocketReadEvent.class,
> 66:         SocketWriteEvent.class,

I'm guessing that this change which remove these two event classes is a drive-by-cleanup that should actually have been done with some previous fix in this area?
Just wanted to double check it was intended as it doesn't seem to be related to file events.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18542#pullrequestreview-2006152864
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1568907662

From egahlin at openjdk.org  Thu Apr 18 14:36:06 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 18 Apr 2024 14:36:06 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
 <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>
Message-ID: <mWvpzGy55Wcpt2mKkw1pjcskXHlnwt1cD-uokTaOvVQ=.779e0a1c-14c8-447f-91dd-997f052ade5f@github.com>

On Wed, 17 Apr 2024 14:05:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test file local to test
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:
> 
>> 64:         FileWriteEvent.class,
>> 65:         SocketReadEvent.class,
>> 66:         SocketWriteEvent.class,
> 
> I'm guessing that this change which remove these two event classes is a drive-by-cleanup that should actually have been done with some previous fix in this area?
> Just wanted to double check it was intended as it doesn't seem to be related to file events.

Yes, and I think it might be the cause for https://bugs.openjdk.org/browse/JDK-8329330 I will send out a PR to remove those separately (in 30 minutes) so a fix can be backported.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1570887596

From redestad at openjdk.org  Thu Apr 18 14:40:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 18 Apr 2024 14:40:15 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v5]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <ZOdpacc_KIde5NJdOCQjacJZQYzeYC1cA2iQrPcxaTI=.8aa19c74-96e4-440e-8dba-ee648e34320c@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

Claes Redestad 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 master, resolve conflicts due pr/18688
 - Dump using the hidden class name
 - Pre-size stringbuilders based on constant size and a small argument factor
 - @liach feedback
 - Bump threshold after experiments
 - Port ASM to CFA
 - Lower compilation overhead for large concat expressions, initial ASM-based version based on pre-existing implementation

-------------

Changes: https://git.openjdk.org/jdk/pull/18690/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=04
  Stats: 237 lines in 2 files changed: 229 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From redestad at openjdk.org  Thu Apr 18 14:50:30 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 18 Apr 2024 14:50:30 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v6]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <3m2NeLy-0IjoU414JSSzSSUaLfauwUAXbIQ8ueofgsE=.d2e3d01e-e580-4368-9bdb-8d7b4b54af01@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Minor SimpleStringBuilderStrategy::<clinit> overhead reduction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18690/files
  - new: https://git.openjdk.org/jdk/pull/18690/files/fd9c40d2..83f4048f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=04-05

  Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From lancea at openjdk.org  Thu Apr 18 15:08:57 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 18 Apr 2024 15:08:57 GMT
Subject: RFR: 8330542: Add two sample configuration files
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <ie_vNIzBd93BUcVq81idxjp5XUToFk4PRNdbftDm1a4=.a5c5c563-81f5-44d4-ae2e-204ab57f226c@github.com>

On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Hi Joe,

Overall this looks fine though we need to clarify more as to the differences between jaxp-compat.properties vs jaxp.properties  and also make it clearer why anyone would use jaxp.strict.properties

As part of the review, I would suggest that a Release Note is created which will hopefully clarify when to use which file.

Also when we actually change the defaults in a JDK release to be the equivalent of jaxp-strict.properties, that this file can be removed?  If so this should be documented in the Release Note and perhaps a comment in the properties file itself

src/java.xml/share/conf/jaxp-compat.properties line 10:

> 8: # configuration, properties that have more restrictive settings as in the
> 9: # strict configuration (jaxp-strict.properties) are reversed back to their
> 10: # defaults. In particular:

I think the above needs some more word smithing  as we have not articulated what a strict configuration is or how this differs from jaxp.properties

src/java.xml/share/conf/jaxp-compat.properties line 16:

> 14: #
> 15: # This configuration file can be used to reverse back to a working environment
> 16: # prior to any more restrictive configuration that may have been applied.

How does this differ from jaxp.properties for JDK 23?  I can understand for when we move to secure by default, we just need to be clear on the purpose of each jaxp properties files

-------------

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2009160577
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1570932404
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1570934511

From tprinzing at openjdk.org  Thu Apr 18 15:16:59 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 15:16:59 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <mWvpzGy55Wcpt2mKkw1pjcskXHlnwt1cD-uokTaOvVQ=.779e0a1c-14c8-447f-91dd-997f052ade5f@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
 <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>
 <mWvpzGy55Wcpt2mKkw1pjcskXHlnwt1cD-uokTaOvVQ=.779e0a1c-14c8-447f-91dd-997f052ade5f@github.com>
Message-ID: <Diw63vvC4QjixiAiro7K67dfv8j0A5GspEvK4CHDafY=.1941cf21-5988-466b-b94c-939041af49e5@github.com>

On Thu, 18 Apr 2024 14:32:28 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:
>> 
>>> 64:         FileWriteEvent.class,
>>> 65:         SocketReadEvent.class,
>>> 66:         SocketWriteEvent.class,
>> 
>> I'm guessing that this change which remove these two event classes is a drive-by-cleanup that should actually have been done with some previous fix in this area?
>> Just wanted to double check it was intended as it doesn't seem to be related to file events.
>
> I think it might be the cause for https://bugs.openjdk.org/browse/JDK-8329330 I have sent out a PR to remove those separately so the fix can be backported. https://github.com/openjdk/jdk/pull/18843

That's correct, it is an unrelated cleanup (other than it seems to cause tests to fail now).  @egahlin, do you want me to remove those from this PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1570953838

From egahlin at openjdk.org  Thu Apr 18 15:32:59 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 18 Apr 2024 15:32:59 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <Diw63vvC4QjixiAiro7K67dfv8j0A5GspEvK4CHDafY=.1941cf21-5988-466b-b94c-939041af49e5@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
 <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>
 <mWvpzGy55Wcpt2mKkw1pjcskXHlnwt1cD-uokTaOvVQ=.779e0a1c-14c8-447f-91dd-997f052ade5f@github.com>
 <Diw63vvC4QjixiAiro7K67dfv8j0A5GspEvK4CHDafY=.1941cf21-5988-466b-b94c-939041af49e5@github.com>
Message-ID: <LXvPcPy2C1C4H5_WM9rKdSQrOYdoYcpv7sbdgOWPDZ8=.fc06f0aa-5ffc-4afe-a633-7df36e703ed9@github.com>

On Thu, 18 Apr 2024 15:14:10 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> I think it might be the cause for https://bugs.openjdk.org/browse/JDK-8329330 I have sent out a PR to remove those separately so the fix can be backported. https://github.com/openjdk/jdk/pull/18843
>
> That's correct, it is an unrelated cleanup (other than it seems to cause tests to fail now).  @egahlin, do you want me to remove those from this PR?

Yes, it would be good if you could remove those changes, so it can be handled separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1570979943

From mcimadamore at openjdk.org  Thu Apr 18 15:46:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 Apr 2024 15:46:06 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <IGTiiJu4jiDizPEcJEgQUhKuQA_MgPSZ0p7HYR3JR9c=.0e2fd0dd-7297-4c39-9924-0119691e725b@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <gNA1giBBLP0CTFWt-ArROqB0B34_5VAv77nbVOZW3Mk=.1e26bfc4-fc9f-4fe1-b75b-1b996de759ab@github.com>
 <p_OvrmxiUNSaZPa-fjVeFcB2NLZN5ySTTD11Cx7-XgI=.5ac9300d-29eb-45bb-8a66-541cde70ee3e@github.com>
 <IGTiiJu4jiDizPEcJEgQUhKuQA_MgPSZ0p7HYR3JR9c=.0e2fd0dd-7297-4c39-9924-0119691e725b@github.com>
Message-ID: <aTX8scT_GIY0x0PCgdfFxQPYkEVKJ9WpqktMOzn6OOM=.01194c3c-2601-42e4-ba48-4b3ee5ce7eab@github.com>

On Tue, 16 Apr 2024 10:30:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thinking about this some more, would it not be possible to just use the mainMethod directly down in C?
>
> The changes JEP 463 went through many iterations, it was a fine balance of avoiding too many transitions and upcalls, and at the same time, have something that can be maintained. There are several JBS issues on this issue now, probably because there just wasn't enough tests introduced with the JEP.

FWIW, just ran into this as well. I was trying to do `System::loadLibrary` and had no clue why I could load non-existent libraries. Turns out I couldn't :-) but the error was never reported back to me. Confusing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1570997544

From darcy at openjdk.org  Thu Apr 18 16:16:25 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Apr 2024 16:16:25 GMT
Subject: Integrated: 8330458: Add missing @since tag to
 ClassFile.JAVA_23_VERSION
In-Reply-To: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>
References: <XXg4NgR20Ri2x6nU6uY-RADLYDRJXtM5kTyj06POZIQ=.8cd04971-ee98-433d-b8a6-581a75e7a063@github.com>
Message-ID: <Olyyj-enDPTId-3RIkHa7J0f12KAwzN09wL3zgr_1iA=.9f627014-3389-4526-87a8-0655cdc4d745@github.com>

On Wed, 17 Apr 2024 20:46:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION

This pull request has now been integrated.

Changeset: 235ba9a7
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/235ba9a7025964b1e43149c7102e26b82b2081ad
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION

Reviewed-by: jjg, iris, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/18828

From sgehwolf at openjdk.org  Thu Apr 18 16:38:56 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 18 Apr 2024 16:38:56 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <0gUVzigzVfEv1IWV9irog8S3hPme-Aux9fDUWjPO2wc=.fa1648a1-4714-4f74-acc0-22c4250490af@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <0gUVzigzVfEv1IWV9irog8S3hPme-Aux9fDUWjPO2wc=.fa1648a1-4714-4f74-acc0-22c4250490af@github.com>
Message-ID: <HtJgC1SfZtVLKBjtlK9s6BcZQu4pQYjhSAmqEuO1EnQ=.098a6603-10bb-4924-8d1c-5248f73d18d2@github.com>

On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Could not we rename `is_containerized()` to `use_container_limit()` ? As that is the current only purpose of `is_containerized()`.

I'm not sure. There is value to have `is_containerized()` like it would behave after this patch. Specifically the first table row difference in [your comment](https://github.com/openjdk/jdk/pull/18201#issuecomment-2063868908) concerns me. JVMs running in a container without limit wouldn't be detected as "containerized". That seems a large share of deployments to miss.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2064487567

From vromero at openjdk.org  Thu Apr 18 16:57:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Apr 2024 16:57:06 GMT
Subject: RFR: 8328481: Implement Module Imports [v10]
In-Reply-To: <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>
Message-ID: <EyeV6PzOrKSObimFKpPpHvzFyg14LXpQAnguXscbuNQ=.38261d09-3c7d-4652-a4e7-c83a758ce8a3@github.com>

On Thu, 18 Apr 2024 12:11:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - improving the 'module (current) does not read (target).

src/jdk.compiler/share/classes/com/sun/source/tree/ImportTree.java line 57:

> 55:      */
> 56:     @PreviewFeature(feature=PreviewFeature.Feature.MODULE_IMPORTS, reflective=true)
> 57:     boolean isModule();

we are not including any test that stresses this new method

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1571091780

From mcimadamore at openjdk.org  Thu Apr 18 17:35:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 Apr 2024 17:35:04 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v6]
In-Reply-To: <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
Message-ID: <UDD_yQgZ0kLqCklBpSu6Q-uIXxfH7Du9VrFCOWtsbVU=.76d48499-8973-433e-8684-1dcec989d154@github.com>

On Thu, 18 Apr 2024 11:32:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception type

We need a test for the new method, e.g. to check that the right exception is thrown, and the message is right. The fact that no test needed to be updated when you changed the exception type is a smell.

-------------

Changes requested by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2009500390

From prr at openjdk.org  Thu Apr 18 18:02:57 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 18 Apr 2024 18:02:57 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v6]
In-Reply-To: <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
Message-ID: <TwcBMY5juNZRirnFrvCpsIhPdKl28QKyc_RV2eHuZZo=.25b492f9-ee3d-49ca-bbfe-d85d299c106e@github.com>

On Thu, 18 Apr 2024 11:32:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception type

I'm OK with the minimal changes in the desktop code.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2009552015

From sviswanathan at openjdk.org  Thu Apr 18 18:29:00 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 18 Apr 2024 18:29:00 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
Message-ID: <qob2Ao_1HWCbIQbz0qhX99oZc_j4jL6v0NjvTeQR9UM=.16d09aa7-ab1e-4689-bf0c-fd2fa2902a7e@github.com>

On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add enter() and leave(); remove Windows-specific register stuff

@vnkozlov Could you please review this PR from @asgibbons? Looking forward to your inputs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2064852401

From paul.sandoz at oracle.com  Thu Apr 18 18:40:14 2024
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 18 Apr 2024 18:40:14 +0000
Subject: Vector (and integer) API: unsigned min/max
In-Reply-To: <CANghgrRXdbQJHQN8FfPqEVy9x7PyWUOzVqu+SEYxf033OoQf-A@mail.gmail.com>
References: <CANghgrRXdbQJHQN8FfPqEVy9x7PyWUOzVqu+SEYxf033OoQf-A@mail.gmail.com>
Message-ID: <25DABE0A-2805-4462-B475-3C45E41E2FBA@oracle.com>

Hi David,

It?s not at all outlandish, but would caution it's more work than one might initially think.

Could you describe a little more about your use case? that can be helpful to understand the larger picture and demand. Using unsigned comparison would be my recommended approach with the current API. CC'ing Sandhya for her opinion.

Generally when we add new Vector operations we also consider the impact on the scalar types and try to fill any gaps there, so the vector operation behavior is composed from the scalar operation behavior (so like you indicated regarding symmetry). 

We are seeing demand for saturated arithmetic primarily for vector (not ?vector? as in hardware vector) search, so we may do something there for specific integral types.

Paul.

> On Apr 17, 2024, at 7:13 AM, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> I've been trying the the incubating Vector API and one thing I've missed on integer-typed vectors is having unsigned min/max operations. There is a signed min/max operation, and unsigned comparison, but no unsigned min/max.
> 
> I guess this is for symmetry with `Math`, which only has signed `min`/`max`. However, I would point out that while it's not very hard to implement one's own unsigned min/max for integer types using `compareUnsigned`, it is a bit harder to do so with vectors. The best I've come up with is to take one of two approaches:
> 
> 1. Zero-extend the vector to the next-larger size, perform the min/max, and reduce it back down again, or
> 2. Add <IntType>.MIN_VALUE, min/max with a value or vector also offset by <IntType>.MIN_VALUE, and then subtract the offset again
> 
> I guess a third approach could be to do a comparison using unsigned compares, and then use the resultant vector mask to select items from the original two vectors, but I didn't bother to work out this solution given I already had the other two options.
> 
> Would it be feasible to add unsigned min/max operations for vectors? It looks like at least AArch64 has support for this as a single instruction, so it doesn't seem too outlandish.
> 
> And as a separate (but related) question, what about `Math.minUnsigned`/`Math.maxUnsigned` of `int` and `long` for symmetry?
> 
> -- 
> - DML ? he/him


From tprinzing at openjdk.org  Thu Apr 18 18:46:36 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 18:46:36 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v6]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <7NawxjXo9zY9pqD8kgVIziuap_YEzFyxZCl2CTHfvIA=.0097b568-8a89-4690-9ce7-0790905a4f35@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  undo fix being handled in JDK-8329330.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/366fca19..28bf429d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=04-05

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542

From tprinzing at openjdk.org  Thu Apr 18 18:53:01 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 18:53:01 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v6]
In-Reply-To: <7NawxjXo9zY9pqD8kgVIziuap_YEzFyxZCl2CTHfvIA=.0097b568-8a89-4690-9ce7-0790905a4f35@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <7NawxjXo9zY9pqD8kgVIziuap_YEzFyxZCl2CTHfvIA=.0097b568-8a89-4690-9ce7-0790905a4f35@github.com>
Message-ID: <hRGMlUMEH970DP4gjFdt54b3zCrjXawLM1N2iDGY38w=.d62b3b6f-2adb-4476-be89-af49a932c333@github.com>

On Thu, 18 Apr 2024 18:46:36 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo fix being handled in JDK-8329330.

Prior to the last commit, this passed all tests tier 1-3 on all platform.  It should be ready.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2064929545

From tprinzing at openjdk.org  Thu Apr 18 18:59:20 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 18:59:20 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v7]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <lUvx-v8l-jFO15FSfIOkX7HYqgYmf7fc7tIrj5E4Trk=.b048c6f3-b787-4004-95aa-995e2c9a2056@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  IntelliJ trying to help

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/28bf429d..17b0be7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542

From asemenyuk at openjdk.org  Thu Apr 18 20:03:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 18 Apr 2024 20:03:06 GMT
Subject: RFR: 8295111: dpkg appears to have problems resolving symbolically
 linked native libraries
Message-ID: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>

Pass a path with resolved symlinks to `dpkg -S` command. If it fails, try the original path if they differ.

Testing on Ubuntu 24.04 passed. Successfully created a .deb package from SwingSet2.jar with the not-empty list of dependencies. Before the fix the list of required packages was empty. In jpackage log:


[19:30:48.784] Running dpkg
[19:30:49.118] Command [PID: 244104]:
    dpkg -S /usr/lib/x86_64-linux-gnu/libm.so.6
[19:30:49.118] Output:
    libc6:amd64: /usr/lib/x86_64-linux-gnu/libm.so.6
[19:30:49.118] Returned: 0

[19:30:49.118] /lib/x86_64-linux-gnu/libm.so.6 is provided by [libc6]


It was looking for a package providing "/lib/x86_64-linux-gnu/libm.so.6" library, but the actual argument to "dpgk -S" command was "/usr/lib/x86_64-linux-gnu/libm.so.6".

-------------

Commit messages:
 - 8295111: dpkg appears to have problems resolving symbolically linked native libraries

Changes: https://git.openjdk.org/jdk/pull/18844/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18844&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295111
  Stats: 44 lines in 1 file changed: 19 ins; 3 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/18844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18844/head:pull/18844

PR: https://git.openjdk.org/jdk/pull/18844

From asemenyuk at openjdk.org  Thu Apr 18 20:03:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 18 Apr 2024 20:03:06 GMT
Subject: RFR: 8295111: dpkg appears to have problems resolving symbolically
 linked native libraries
In-Reply-To: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>
References: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>
Message-ID: <yh6eNffBRXLcx9GCbwUZgSGMCUBBeIshmraKvKY9PUc=.4afb561a-58b2-4729-a2e4-12c05f68f536@github.com>

On Thu, 18 Apr 2024 19:56:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Pass a path with resolved symlinks to `dpkg -S` command. If it fails, try the original path if they differ.
> 
> Testing on Ubuntu 24.04 passed. Successfully created a .deb package from SwingSet2.jar with the not-empty list of dependencies. Before the fix the list of required packages was empty. In jpackage log:
> 
> 
> [19:30:48.784] Running dpkg
> [19:30:49.118] Command [PID: 244104]:
>     dpkg -S /usr/lib/x86_64-linux-gnu/libm.so.6
> [19:30:49.118] Output:
>     libc6:amd64: /usr/lib/x86_64-linux-gnu/libm.so.6
> [19:30:49.118] Returned: 0
> 
> [19:30:49.118] /lib/x86_64-linux-gnu/libm.so.6 is provided by [libc6]
> 
> 
> It was looking for a package providing "/lib/x86_64-linux-gnu/libm.so.6" library, but the actual argument to "dpgk -S" command was "/usr/lib/x86_64-linux-gnu/libm.so.6".

@sashamatveev please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18844#issuecomment-2065166526

From david.lloyd at redhat.com  Thu Apr 18 20:08:30 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 18 Apr 2024 15:08:30 -0500
Subject: Vector (and integer) API: unsigned min/max
In-Reply-To: <25DABE0A-2805-4462-B475-3C45E41E2FBA@oracle.com>
References: <CANghgrRXdbQJHQN8FfPqEVy9x7PyWUOzVqu+SEYxf033OoQf-A@mail.gmail.com>
 <25DABE0A-2805-4462-B475-3C45E41E2FBA@oracle.com>
Message-ID: <CANghgrQU3PwN201TexrWNBPhJ6E4e4ca_xgzN9CGjCONiH3=Ag@mail.gmail.com>

Presently, I'm implementing operations for a WASM emulator/runtime, so it's
more a case of transitively acquiring use cases from WASM, though I'm also
doing this specifically to practice accomplishing useful things with the
vector API.

Regarding saturating arithmetic: WASM has operations for that as well (both
signed and unsigned), so on that basis alone it would be a welcome addition
as far as I'm concerned. FWIW, another simple use case for saturating
arithmetic is audio processing/mixing (when processing many channels at
once) because saturation closely matches analog clipping, and also perhaps
image compositing for similar reasons.

On Thu, Apr 18, 2024 at 1:40?PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi David,
>
> It?s not at all outlandish, but would caution it's more work than one
> might initially think.
>
> Could you describe a little more about your use case? that can be helpful
> to understand the larger picture and demand. Using unsigned comparison
> would be my recommended approach with the current API. CC'ing Sandhya for
> her opinion.
>
> Generally when we add new Vector operations we also consider the impact on
> the scalar types and try to fill any gaps there, so the vector operation
> behavior is composed from the scalar operation behavior (so like you
> indicated regarding symmetry).
>
> We are seeing demand for saturated arithmetic primarily for vector (not
> ?vector? as in hardware vector) search, so we may do something there for
> specific integral types.
>
> Paul.
>
> > On Apr 17, 2024, at 7:13 AM, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> > I've been trying the the incubating Vector API and one thing I've missed
> on integer-typed vectors is having unsigned min/max operations. There is a
> signed min/max operation, and unsigned comparison, but no unsigned min/max.
> >
> > I guess this is for symmetry with `Math`, which only has signed
> `min`/`max`. However, I would point out that while it's not very hard to
> implement one's own unsigned min/max for integer types using
> `compareUnsigned`, it is a bit harder to do so with vectors. The best I've
> come up with is to take one of two approaches:
> >
> > 1. Zero-extend the vector to the next-larger size, perform the min/max,
> and reduce it back down again, or
> > 2. Add <IntType>.MIN_VALUE, min/max with a value or vector also offset
> by <IntType>.MIN_VALUE, and then subtract the offset again
> >
> > I guess a third approach could be to do a comparison using unsigned
> compares, and then use the resultant vector mask to select items from the
> original two vectors, but I didn't bother to work out this solution given I
> already had the other two options.
> >
> > Would it be feasible to add unsigned min/max operations for vectors? It
> looks like at least AArch64 has support for this as a single instruction,
> so it doesn't seem too outlandish.
> >
> > And as a separate (but related) question, what about
> `Math.minUnsigned`/`Math.maxUnsigned` of `int` and `long` for symmetry?
> >
> > --
> > - DML ? he/him
>
>

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240418/85f36bf7/attachment-0001.htm>

From redestad at openjdk.org  Thu Apr 18 20:16:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 18 Apr 2024 20:16:24 GMT
Subject: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly
Message-ID: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>

Investigating a recent regression in mainline I realized we have an opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by using `invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This avoids generating type checking adapters and equates to a one-off startup win of around 5ms in any app that ever has the need to spin up a toString, equals or hashCode method on a record.

-------------

Commit messages:
 - 8330595: Invoke ObjectMethods::bootstrap method exactly

Changes: https://git.openjdk.org/jdk/pull/18845/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18845&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330595
  Stats: 17 lines in 1 file changed: 16 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18845.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18845/head:pull/18845

PR: https://git.openjdk.org/jdk/pull/18845

From egahlin at openjdk.org  Thu Apr 18 20:34:01 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 18 Apr 2024 20:34:01 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v7]
In-Reply-To: <lUvx-v8l-jFO15FSfIOkX7HYqgYmf7fc7tIrj5E4Trk=.b048c6f3-b787-4004-95aa-995e2c9a2056@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <lUvx-v8l-jFO15FSfIOkX7HYqgYmf7fc7tIrj5E4Trk=.b048c6f3-b787-4004-95aa-995e2c9a2056@github.com>
Message-ID: <4uMJ5_MknLkJoEaY8wE52Mf4K7zW1_ftcknW_zWUPzo=.edf4b3d9-8d82-4573-a33f-0d4dfdec9fca@github.com>

On Thu, 18 Apr 2024 18:59:20 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IntelliJ trying to help

Marked as reviewed by egahlin (Reviewer).

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 46:

> 44: import jdk.jfr.events.FileWriteEvent;
> 45: import jdk.jfr.events.InitialSecurityPropertyEvent;
> 46: 

Unnecessary blank line added.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18542#pullrequestreview-2009830262
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1571335968

From tprinzing at openjdk.org  Thu Apr 18 20:40:23 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 20:40:23 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v8]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <WT2hAeQyi2UTyGaTiqlWtpNLyzZExqt-8ZUPskVLgUI=.9f6c3614-ce7d-45e9-9c65-f6bedd57c9ae@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  remove unecessary blank line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/17b0be7b..f7859fc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542

From szaldana at openjdk.org  Thu Apr 18 20:40:57 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 18 Apr 2024 20:40:57 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <GQP3IAxsjFIrfPoJz4ihGn1f_cANcwVkWI2bO6J07zo=.c55087fb-e8c9-47e4-8066-72d913d3d1f9@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

hi all, thanks for the comments! Happy to make the updates based on the feedback. 

However, could someone please advice if we are proceeding with this PR or https://github.com/openjdk/jdk/pull/18753?

As @lahodaj noted, theirs avoids changing the dynamics between the Java helper and native code, so I just want to make sure we are on the same page.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2065279462

From szaldana at openjdk.org  Thu Apr 18 20:43:58 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 18 Apr 2024 20:43:58 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <61FmMvHyAQXcl_ZWYGEWwLDU7O8a-vdHTlu56rnKzqo=.cd118172-6497-4963-ad3b-b8f865009638@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <61FmMvHyAQXcl_ZWYGEWwLDU7O8a-vdHTlu56rnKzqo=.cd118172-6497-4963-ad3b-b8f865009638@github.com>
Message-ID: <Nvef5H6yg7TlYjDyCTYh1qTZoZB4B2nYvmV1d6BCnxs=.62b96873-a553-4c95-8a5a-eaf2fb6bc8a2@github.com>

On Thu, 18 Apr 2024 07:34:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> My personal comments here:
> - I am fine with a solution like this. In 18753, I wanted to avoid a change of dynamics between the Java helper and the native part. But if we can change that, it looks better. I would suggest to take the test from 18753 though - doing a change like this without a test may lead to hard-to-find regressions in the future. (Note the current test should guard against both JDK-8329420 and JDK-8329581.) Or write a different test.
> - as Mandy points out, `LaucherHelper` already reads/has variables for "is-static" and "no-arguments" in `validateMainMethod`, so it should be possible to just use that values; also as Mandy points out, we can probably get rid of `CHECK_EXCEPTION_FAIL` and `CHECK_EXCEPTION_NULL_FAIL`, and use the `..._LEAVE` variants, no? (The `..._FAIL` variants where needed so that the launcher could continue with the next variant, but since we now only call the correct variant, we can just stop if something goes wrong?)

@lahodaj 

> I would suggest to take the test from 18753 though - doing a change like this without a test may lead to hard-to-find regressions in the future. (Note the current test should guard against both JDK-8329420 and JDK-8329581.)

Agreed. I?ll add the test case if this PR proceeds (see my comment above). 

> as Mandy points out, `LaucherHelper` already reads/has variables for "is-static" and "no-arguments" in `validateMainMethod`, so it should be possible to just use that values; 

Just to clarify, this would still mean converting ?isStatic? and ?noArgs? from local variables to fields so I am able to read them on the C side of things. Did I understand this correctly?

> also as Mandy points out, we can probably get rid of `CHECK_EXCEPTION_FAIL` and `CHECK_EXCEPTION_NULL_FAIL`, and use the `..._LEAVE` variants, no? (The `..._FAIL` variants where needed so that the launcher could continue with the next variant, but since we now only call the correct variant, we can just stop if something goes wrong?)

Agreed, I?ve updated that on my side of things.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2065283183

From jjg at openjdk.org  Thu Apr 18 20:48:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:48:04 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`
Message-ID: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>

Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.

There are various categories of update:

* "Box comments" beginning with `/**`
* Misplaced doc comments before package or import statements
* Misplaced doc comments after the annotations for a declaration
* Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
* Use of `/**` for the legal header at or near the top of the file

In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

-------------

Commit messages:
 - JDK-8330178: Clean up non-standard use of /** comments in `java.base`

Changes: https://git.openjdk.org/jdk/pull/18846/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330178
  Stats: 134 lines in 23 files changed: 50 ins; 56 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/18846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18846/head:pull/18846

PR: https://git.openjdk.org/jdk/pull/18846

From jjg at openjdk.org  Thu Apr 18 20:52:29 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:52:29 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v4]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <p1Ldsyr_hNrd7LEhoThBxZzXEtMZk3siO_ZLFZp43vY=.c61e1870-2db1-4ee8-b157-f6f2b0be1715@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons 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:

 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3f745431..f3670e7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=02-03

  Stats: 42074 lines in 1058 files changed: 18282 ins; 15937 del; 7855 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From almatvee at openjdk.org  Thu Apr 18 21:06:55 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 18 Apr 2024 21:06:55 GMT
Subject: RFR: 8295111: dpkg appears to have problems resolving symbolically
 linked native libraries
In-Reply-To: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>
References: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>
Message-ID: <aZnkBE51424XT2BK70EDHwF2udQsQiTJ_V3MsJko_LA=.65fe92e3-260a-43b2-af53-bbf19accc23c@github.com>

On Thu, 18 Apr 2024 19:56:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Pass a path with resolved symlinks to `dpkg -S` command. If it fails, try the original path if they differ.
> 
> Testing on Ubuntu 24.04 passed. Successfully created a .deb package from SwingSet2.jar with the not-empty list of dependencies. Before the fix the list of required packages was empty. In jpackage log:
> 
> 
> [19:30:48.784] Running dpkg
> [19:30:49.118] Command [PID: 244104]:
>     dpkg -S /usr/lib/x86_64-linux-gnu/libm.so.6
> [19:30:49.118] Output:
>     libc6:amd64: /usr/lib/x86_64-linux-gnu/libm.so.6
> [19:30:49.118] Returned: 0
> 
> [19:30:49.118] /lib/x86_64-linux-gnu/libm.so.6 is provided by [libc6]
> 
> 
> It was looking for a package providing "/lib/x86_64-linux-gnu/libm.so.6" library, but the actual argument to "dpgk -S" command was "/usr/lib/x86_64-linux-gnu/libm.so.6".

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18844#pullrequestreview-2009895564

From mpowers at openjdk.org  Thu Apr 18 21:19:56 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 18 Apr 2024 21:19:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <dmHUQtRTvpmJO4yhZvDJFjFCxtZMXJcJb45ZQ-Lxdlw=.00c6c3b8-960f-4ddb-bb32-0848fc1bad83@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Should the copyright be updated?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2065339389

From jjg at openjdk.org  Thu Apr 18 21:34:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:34:13 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v5]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <Pw-vAt9fBf-s7YcdBbtzbYdcM49PkNcmvIfbSmYdjYI=.a94e6477-30de-463b-b509-d4cd38f26cd7@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  update test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/f3670e7a..8ad8b818

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=03-04

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From joehw at openjdk.org  Thu Apr 18 21:54:26 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 18 Apr 2024 21:54:26 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v2]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <7kkWrrqECaymEOOlg6Trzii3RRRf5J6IiL8FrTTtH_4=.876dc8e4-5eaa-46c8-8859-6187c44d0233@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add description of the three configuration files.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/e36e5fd4..98fcc3ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=00-01

  Stats: 44 lines in 2 files changed: 38 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From joehw at openjdk.org  Thu Apr 18 21:54:26 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 18 Apr 2024 21:54:26 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <sreqq5R78uDhjXofRkLVLi7JuFKyCJCLgmlU9osKEiI=.17510942-2fc2-4c94-acfa-25246650c3c9@github.com>

On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Thanks Alan, Lance! I added description of the three config files to both files so that readers can find answers reading any one of them. Also added a release note: https://bugs.openjdk.org/browse/JDK-8330605

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2065384541

From john.r.rose at oracle.com  Thu Apr 18 21:55:12 2024
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 18 Apr 2024 21:55:12 +0000
Subject: Vector (and integer) API: unsigned min/max
In-Reply-To: <CANghgrRXdbQJHQN8FfPqEVy9x7PyWUOzVqu+SEYxf033OoQf-A@mail.gmail.com>
References: <CANghgrRXdbQJHQN8FfPqEVy9x7PyWUOzVqu+SEYxf033OoQf-A@mail.gmail.com>
Message-ID: <5292F9EF-7C48-4A52-A5FE-35CED2EBEAD9@oracle.com>

On Apr 17, 2024, at 7:14?AM, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> 2. Add <IntType>.MIN_VALUE, min/max with a value or vector also offset by <IntType>.MIN_VALUE, and then subtract the offset again

I think that?s the path of least resistance. It?s just a vxor on each operand, with a constant mask. That can be done in Java code. CPU?s that implement native unsigned cmp can peephole optimize. 

From jjg at openjdk.org  Thu Apr 18 21:56:16 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:56:16 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v6]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <_EMQ8vgc0hQdgeWdnqirLLAN8Cj6jcxP0belwJffD8A=.2c536c2b-f0e1-49b4-8fc7-e3a9252e20e2@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons 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 with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

-------------

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=05
  Stats: 488 lines in 61 files changed: 389 ins; 3 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From duke at openjdk.org  Thu Apr 18 22:00:13 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:13 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
Message-ID: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>

**Subject**
Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`

**Motivation**
The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.

The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.

Here is a brief overview of the changes made in this pull request:

1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
3. Implemented these methods in all non-abstract classes that implement the `List` interface.

The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.

For example, consider the following test case:

List<String> list = new ArrayList<>();
list.add("Object one");
list.add("NotObject two");
list.add("NotObject three");

int index1 = list.indexOf(s -> s.contains("ct t"));
System.out.println(index1); // Expected output: 1
int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
System.out.println(index2); // Expected output: 2


Currently, to achieve the same result, we would have to use a more verbose approach:

int index1 = IntStream.range(0, list.size())
                     .filter(i -> list.get(i).contains("ct t"))
                     .findFirst()
                     .orElse(-1);
System.out.println(index1); // Output: 1
int index2 = IntStream.range(0, list.size())
                         .filter(i -> list.get(i).startsWith("NotObject"))
                         .reduce((first, second) -> second)
                         .orElse(-1);
System.out.println(index2); // Output: 2


I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.

Thank you for considering this proposal.

Best regards

-------------

Commit messages:
 - did some renaming of internal methods utilized by findIndex
 - fixed ReverseOrderLinkedListView
 - fixed javadocs in List and ArrayList
 - Merge remote-tracking branch 'origin/feature/indexOf-with-predicate' into feature/indexOf-with-predicate
 - Removed unused import in AbstractList
 - Also moved to List interface
 - Moved from AbstractList
 - Removed implementation from AbstractList, moving it to List
 - Renamed indexOf(Predicate) and lastIndexOf(Predicate) to findIndex(Predicate) and findLastIndex(Predicate) respectively
 - Merge remote-tracking branch 'origin/feature/indexOf-with-predicate' into feature/indexOf-with-predicate
 - ... and 25 more: https://git.openjdk.org/jdk/compare/16576b87...025bcf39

Changes: https://git.openjdk.org/jdk/pull/18639/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329760
  Stats: 882 lines in 13 files changed: 570 ins; 47 del; 265 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <LdKp00uLPajiG6bSky2nSSuPek7KAcJhij-QJRyXuiA=.af7c9303-4715-43f0-8107-42198df9d7d1@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

Newly?added?methods to?existing widely?implemented non?sealed and?non?preview interfaces in?`java.base` must?be?`default` to?avoid source?incompatibilities and?runtime?errors, so?move the?implementations from?`AbstractList` to?`List`:

I?m?in?favour of?using?`findIndex`, which?also?avoids the?issue with?`List<Predicate<?>>::indexOf` being?ambiguous and?having binary?incompatible bridge?methods.

src/java.base/share/classes/java/util/AbstractList.java line 29:

> 27: 
> 28: import java.util.function.Consumer;
> 29: import java.util.function.Predicate;

This?is now?unused:
Suggestion:

src/java.base/share/classes/java/util/AbstractList.java line 221:

> 219:         return -1;
> 220:     }
> 221: 

Suggestion:

src/java.base/share/classes/java/util/AbstractList.java line 269:

> 267:         return -1;
> 268:     }
> 269: 

Suggestion:

src/java.base/share/classes/java/util/List.java line 702:

> 700:      *         (<a href="Collection.html#optional-restrictions">optional</a>)
> 701:      */
> 702:     int lastIndexOf(Predicate<? super E> filter);

Suggestion:

    /**
     * Returns the index of the first occurrence of matching element
     * in this list, or -1 if this list does not contain the element.
     * More formally, returns the lowest index {@code i} such that
     * {@code filter.test(get(i))},
     * or -1 if there is no such index.
     *
     * @implSpec
     * This implementation first gets a list iterator (with
     * {@code listIterator()}).  Then, it iterates over the list until a
     * matching element is found or the beginning of the list is reached.
     *
     * @param filter a predicate to search for
     * @return the index of the first occurrence of the specified element in
     *         this list, or -1 if this list does not contain the element
     * @throws NullPointerException if passed filter is null
     */
    default int indexOf(Predicate<? super E> filter) {
        Objects.requireNonNull(filter);
        ListIterator<E> it = listIterator();
        while (it.hasNext()) {
            E e = it.next();
            if (filter.test(e)) {
                return it.previousIndex();
            }
        }
        return -1;
    }

    /**
     * Returns the index of the last occurrence of matching element
     * in this list, or -1 if this list does not contain the element.
     * More formally, returns the highest index {@code i} such that
     * {@code Objects.equals(o, get(i))},
     * or -1 if there is no such index.
     *
     * @implSpec
     * This implementation first gets a list iterator that points to the end
     * of the list (with {@code listIterator(size())}).  Then, it iterates
     * backwards over the list until the matching element is found, or the
     * beginning of the list is reached.
     *
     * @param filter a predicate to search for
     * @return the index of the last occurrence of the specified element in
     *         this list, or -1 if this list does not contain the element
     * @throws NullPointerException if passed filter is null
     */
    default int lastIndexOf(Predicate<? super E> filter) {
        Objects.requireNonNull(filter);
        ListIterator<E> it = listIterator(size());
        while (it.hasPrevious()) {
            E e = it.previous();
            if (filter.test(e)) {
                return it.nextIndex();
            }
        }
        return -1;
    }

-------------

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/18639#pullrequestreview-1985396823
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046339464
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1555586424
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1555192600
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1555192654
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1555194862

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

currently awaiting for initial issue triage to complete

side note: looks like this code have been reformated and some unused imports has been reformated. jdk compiles and works just fine, so i guess its not a big deal

> Won't this make some calls ambiguous? For example, passing `null`:
> 
> ```java
> List<String> l;
> l.indexOf(""); // Fine
> l.indexOf(null); // Now fails to compile
> ```
> 
> Edit: I'm not a reviewer, but I decided to point this out.

I`ve tested it. Now calling indexOf with null as literal calls indexOf(Predicate) instead, as Predicate is lower in class hierarchy than Object (ofc it does not apply to varibles that store null, those works just as usual)

If you want to call indexOf(Object) instead, you will have to cast null to desired type manually

> ```java
> List<String> l;
> l.indexOf(""); // Fine
> l.indexOf((String)null); // Will invoke indexOf(Object)
> ```

Question to reviewers: what do you think would be the best way to handle issue discussed above?

PS: converted PR to draft untill the issue is resolved

PPS: The idea I came up with is to possibly rename indexOf(Predicate) to something like findIndex(Predicate) or indexOfMatching(Predicate) as a way to both avoid unexpected behaviour and preserve source compatibility

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2038490998
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2038506989
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2045522079
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046196342

From liach at openjdk.org  Thu Apr 18 22:00:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>
Message-ID: <UlXEKecrn2AWrJ9RSHAuk0Ute-X8g2Al68WNzAWUtaI=.48d23f3e-a28b-49b3-9d9e-e33366cfbb58@github.com>

On Fri, 5 Apr 2024 00:31:22 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> side note: looks like this code have been reformated and some unused imports has been reformated. jdk compiles and works just fine, so i guess its not a big deal

Hello @Evemose, if we add an API we should also consider if implementation can efficiently implement it. How is this new API better than using a ListIterator directly so it's worth the additional methods?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2039920614

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>
Message-ID: <MWR9MEHsOXEwsrP4zm62PGkjhNVJAfdQGPk6eelU-Ns=.93e29b66-f70a-4dad-9603-495e9da40e59@github.com>

On Fri, 5 Apr 2024 00:31:22 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> side note: looks like this code have been reformated and some unused imports has been reformated. jdk compiles and works just fine, so i guess its not a big deal

> Hello @Evemose, if we add an API we should also consider if implementation can efficiently implement it. How is this new API better than using a ListIterator directly so it's worth the additional methods?

Hi, @liach ! The implementations i provided in this pull requests are pretty much imitating behaviour of indexOf(Object). Every class that has overriden indexOf(Object) recieved implementation of indexOf(Predicate) that works the same way except for search is based on predicate and not equality. Therefore, the effectiveness of implementation is straight up depends on effectiveness of indexOf(Object) for each separate java.util.List impl.

As for ListIterator, where suitable, it has already been used in implementations in classes where it was considered suitable for indexOf(Object) (to be more precise, in AbstractList). The main goal of this pull requst is to provide shorthand for developers as search for index of element that match predicate is very common task and providing way to do it as comfortable as possible should vastly enhance development expirience.

For ListIterator specifically: the main downside of its direct usage for developer is inability to use it fluently (as method call argument, for example), which forces to either implement method to find index separately or find it in same method as invocation but before invocation explicitly. Both cases are pretty frustraiting and, in my opinion, shouldn`t be neccessary for high-level language like Java.

Summarizing, its not that in current stdlib there are no ways to search for index of element based on condition, but this addition would be a great way to make Java development more comfortable and fast.

PS:
Also implementing indexOf with predicate is a common practice for many high level languages: C#/.NET has FindIndex, Kotlin has indexOfFirst, Swift has firstIndex etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2040025647

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <LdKp00uLPajiG6bSky2nSSuPek7KAcJhij-QJRyXuiA=.af7c9303-4715-43f0-8107-42198df9d7d1@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <LdKp00uLPajiG6bSky2nSSuPek7KAcJhij-QJRyXuiA=.af7c9303-4715-43f0-8107-42198df9d7d1@github.com>
Message-ID: <1yxDq6ci-69V6ti1JGa8sfc4qSl5h9Ute6UcARrQqIY=.c0eafeb2-6039-41d5-b801-a7132a9d0969@github.com>

On Mon, 8 Apr 2024 03:57:33 GMT, ExE Boss <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Newly?added?methods to?existing widely?implemented non?sealed and?non?preview interfaces in?`java.base` must?be?`default` to?avoid source?incompatibilities and?runtime?errors, so?move the?implementations from?`AbstractList` to?`List`:

@ExE-Boss Commited changes. Also, i see you have added not-null assertion at the beginning of methods inside List. If this is a desired behaviour, I could also add this to other impls

@ExE-Boss removed unused import

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2042094028
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2042910322

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (xxDark)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <6LsOn4MSuIs2TcuU5FCYKGM4bje2IEYxQl_PypZAbFg=.68f8fbd5-9609-4d40-9784-3d20905e35ef@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

Won't this make some calls ambiguous?
For example, passing `null`:

List<String> l;
l.indexOf(""); // Fine
l.indexOf(null); // Now fails to compile

Edit: I'm not a reviewer, but I decided to point this out.

src/java.base/share/classes/java/util/LinkedList.java line 1519:

> 1517: 
> 1518:         public int findIndex(Predicate<? super E> filter) {
> 1519:             return rlist.indexOf(filter);

Should be `findIndex`? Similarly with `findLastIndex`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2045324794
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1559268478

From liach at openjdk.org  Thu Apr 18 22:00:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

A few remarks:
1. The concern on `indexOf(Object)` and `indexOf(Predicate)` is valid; `Optional` has `orElse` vs. `orElseGet` to avoid these clashes. The behavior change of `indexOf(null)` is a source incompatibility.
2. Have you considered `indexOf(predicate/object, startIndex)` like the indexOf for `String`?

Also, a significant difference between String/arrays and `List` is that `List` is structurally modifiable; the index may be no longer valid after a modification. Thus the index is not as useful. 

For example, in an [unrolled linked list](https://en.wikipedia.org/wiki/Unrolled_linked_list) implementation, each block can be independently locked for read/write access, maybe like this:
`[1, 2, 3] -> [4, 5] -> [6, 7, 8, 9]`
An index would be useless if any part of this list updates, but if the position information is stored in a `ListIterator` and we add an `beforeNext(predicate)` that moves the cursor to right before the next element that matches the predicate (or the tail if there's no match), this would be much more useful.

Just a side note, this patch won't be reviewed by official JDK engineers until it has rfr tag (means this PR is not draft and the automatic checks of issue, whitespace, oca etc. are passed)

You should post on `core-libs-dev at openjdk.org` to get feedbacks on the API design, too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046023822
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2047602713

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>
Message-ID: <k8JkKsq8vLuBse-uluQbjlKEROI52Aw6jyN9cqNnMmI=.a7346c37-0cb5-412e-9c10-25e824eaea98@github.com>

On Tue, 9 Apr 2024 20:48:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> A few remarks:
> 
> 1. The concern on `indexOf(Object)` and `indexOf(Predicate)` is valid; `Optional` has `orElse` vs. `orElseGet` to avoid these clashes. The behavior change of `indexOf(null)` is a source incompatibility.
> 2. Have you considered `indexOf(predicate/object, startIndex)` like the indexOf for `String`?
> 
> Also, a significant difference between String/arrays and `List` is that `List` is structurally modifiable; the index may be no longer valid after a modification. Thus the index is not as useful.
> 
> For example, in an [unrolled linked list](https://en.wikipedia.org/wiki/Unrolled_linked_list) implementation, each block can be independently locked for read/write access, maybe like this: `[1, 2, 3] -> [4, 5] -> [6, 7, 8, 9]` An index would be useless if any part of this list updates, but if the position information is stored in a `ListIterator` and we add an `beforeNext(predicate)` that moves the cursor to right before the next element that matches the predicate (or the tail if there's no match), this would be much more useful.

The concern about change in behaviour of indexOf(null) is completely valid, although indexOf(null) is kind of exotic scenario. One possible workaround is to temporally (for an intermidiate period) or permanently delegate null value handing to indexOf(Object), which seems odd for me to me tbh, although it preserves source compatibility.

Regarding to indexOf(predicate/object, startIndex), i thought about this, but firstly I would like to have a final and approved version of indexOf(predicate) to have a reference I`m certain in.

As for beforeNext(Predicate) for ListIterator, I havent thought about that, but now that you`ve mentioned it, I could also consider implementing such thing. However, concern about possible index invalidation is more applicable to the nature of indexOf itself rather then this proposal. This method is primarly used when index is needed right here and now or passed to operation that is not supposed to modify list. I guess ListIterator.beforeNext and List.indexOf serve different, altough alike purpose, and therefore, in my opinion, there are place for both in Java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046103546

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (xxDark)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <k8JkKsq8vLuBse-uluQbjlKEROI52Aw6jyN9cqNnMmI=.a7346c37-0cb5-412e-9c10-25e824eaea98@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>
 <k8JkKsq8vLuBse-uluQbjlKEROI52Aw6jyN9cqNnMmI=.a7346c37-0cb5-412e-9c10-25e824eaea98@github.com>
Message-ID: <s2TwCBxX5fqo44tU9VLn8tMW09Q_cvun37Ekie_45t0=.1e3c7b44-0fb8-4fc0-b828-56b9ed114f2c@github.com>

On Tue, 9 Apr 2024 21:48:23 GMT, Evemose <duke at openjdk.org> wrote:

> One possible workaround is to temporally (for an intermidiate period) or permanently delegate null value handing to indexOf(Object), which seems odd for me to me tbh, although it preserves source compatibility.

This does not solve the problem though. Source compatibility would still be broken as one would still need to add casts everywhere, or am I misinterpreting something?
> he concern about change in behaviour of indexOf(null) is completely valid, although indexOf(null) is kind of exotic scenario.

See [this](https://github.com/search?q=%22indexOf%28null%29%22+language%3AJava+&type=code) and [that](https://github.com/search?q=%22lastIndexOf%28null%29%22+language%3AJava+&type=code) query.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046118678

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <s2TwCBxX5fqo44tU9VLn8tMW09Q_cvun37Ekie_45t0=.1e3c7b44-0fb8-4fc0-b828-56b9ed114f2c@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>
 <k8JkKsq8vLuBse-uluQbjlKEROI52Aw6jyN9cqNnMmI=.a7346c37-0cb5-412e-9c10-25e824eaea98@github.com>
 <s2TwCBxX5fqo44tU9VLn8tMW09Q_cvun37Ekie_45t0=.1e3c7b44-0fb8-4fc0-b828-56b9ed114f2c@github.com>
Message-ID: <5UyLqOV-5aORewjtxLQjiWBRRdhVXJ_LpdOffFOFpBI=.8ea655b6-100e-49df-970e-d6d5b3957d0a@github.com>

On Tue, 9 Apr 2024 22:02:56 GMT, xxDark <duke at openjdk.org> wrote:

> This does not solve the problem though. Source compatibility would still be broken as one would still need to add casts everywhere, or am I misinterpreting something?

The code you have provided in example is still valid and non-ambigous, even without cast. The default behaviour of java compiler is to choose method where parameter at corresponding position is closest type upwards in class hierarchy. null is considered "bottom" type, which means it is at the bottom of simultaneously every class hierarchy. Compiler looks upward in class hierarchy and first class it encounters is Predicate, as Object is superclass of Predicate, and chooses indexOf(Predicate) as method to invoke. When casting null to type, compiler treats null as object of casted type rather then bottom type. However, if changes are delivered as is, default behaviour of indexOf(null) will be changed, which is not desired, of course, and, although delegation to indexOf(Object) in case of null as passed value is counterintuitive, it will preserve the current state of things.

> See [this](https://github.com/search?q=%22indexOf%28null%29%22+language%3AJava+&type=code) and [that](https://github.com/search?q=%22lastIndexOf%28null%29%22+language%3AJava+&type=code) query.

Thats a valid point, haven`t though about qurying where null is valid value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046174903

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <6LsOn4MSuIs2TcuU5FCYKGM4bje2IEYxQl_PypZAbFg=.68f8fbd5-9609-4d40-9784-3d20905e35ef@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <6LsOn4MSuIs2TcuU5FCYKGM4bje2IEYxQl_PypZAbFg=.68f8fbd5-9609-4d40-9784-3d20905e35ef@github.com>
Message-ID: <v5LIszsyYVnq3CK0IzmdFHDuKQ0lWjZl8EkY0IYeEa8=.ea7829bd-7d92-43e1-97fd-84a3a8da9138@github.com>

On Wed, 10 Apr 2024 11:20:32 GMT, xxDark <duke at openjdk.org> wrote:

> Should be `findIndex`? Similarly with `findLastIndex`.

Yeah i guess IDE didnt do a great job with refactor. I will review aall changes manually a bit later

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1559373902

From asemenyuk at openjdk.org  Thu Apr 18 22:11:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 18 Apr 2024 22:11:59 GMT
Subject: Integrated: 8295111: dpkg appears to have problems resolving
 symbolically linked native libraries
In-Reply-To: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>
References: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>
Message-ID: <x0179lJHCGfQ3XrNpQ-yEgO0jZScVWwrfrHLyeqM9GI=.d5cdf25f-2493-4126-be9a-d46c40add14f@github.com>

On Thu, 18 Apr 2024 19:56:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Pass a path with resolved symlinks to `dpkg -S` command. If it fails, try the original path if they differ.
> 
> Testing on Ubuntu 24.04 passed. Successfully created a .deb package from SwingSet2.jar with the not-empty list of dependencies. Before the fix the list of required packages was empty. In jpackage log:
> 
> 
> [19:30:48.784] Running dpkg
> [19:30:49.118] Command [PID: 244104]:
>     dpkg -S /usr/lib/x86_64-linux-gnu/libm.so.6
> [19:30:49.118] Output:
>     libc6:amd64: /usr/lib/x86_64-linux-gnu/libm.so.6
> [19:30:49.118] Returned: 0
> 
> [19:30:49.118] /lib/x86_64-linux-gnu/libm.so.6 is provided by [libc6]
> 
> 
> It was looking for a package providing "/lib/x86_64-linux-gnu/libm.so.6" library, but the actual argument to "dpgk -S" command was "/usr/lib/x86_64-linux-gnu/libm.so.6".

This pull request has now been integrated.

Changeset: 32946e18
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32946e1882e9b22c983cbba3c6bda3cc7295946a
Stats:     44 lines in 1 file changed: 19 ins; 3 del; 22 mod

8295111: dpkg appears to have problems resolving symbolically linked native libraries

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/18844

From duke at openjdk.org  Thu Apr 18 22:21:11 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:21:11 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

Evemose has updated the pull request incrementally with one additional commit since the last revision:

  empty commit to trigger check rerun

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/025bcf39..21ce4892

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From darcy at openjdk.org  Thu Apr 18 22:50:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Apr 2024 22:50:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <CCg0siue0vsMT0R1LJ9Qgr5BN7eORlS-sqNih3qh2Tg=.8df332ee-d15a-4678-8bbd-9baf26c0e257@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2010059355

From iris at openjdk.org  Thu Apr 18 22:59:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Apr 2024 22:59:55 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <0ffUuhd3mqnGetQ_dn60M7NrftiL02UD7zbITanAuJc=.b4ac0b9d-01c0-47be-a315-903e9ed6424f@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2010068091

From naoto at openjdk.org  Thu Apr 18 23:43:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Apr 2024 23:43:56 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v2]
In-Reply-To: <7kkWrrqECaymEOOlg6Trzii3RRRf5J6IiL8FrTTtH_4=.876dc8e4-5eaa-46c8-8859-6187c44d0233@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <7kkWrrqECaymEOOlg6Trzii3RRRf5J6IiL8FrTTtH_4=.876dc8e4-5eaa-46c8-8859-6187c44d0233@github.com>
Message-ID: <BNhKmxtOBD7YVXHbdaMrhjP3Q4gYLaa_FOnw8swIMoU=.70329c23-571d-4a80-9456-c7567d102f48@github.com>

On Thu, 18 Apr 2024 21:54:26 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add description of the three configuration files.

src/java.xml/share/conf/jaxp-strict.properties line 2:

> 1: ################################################################################
> 2: #           JAXP String Configuration File

Nit: typo here: String -> Strict

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1571515112

From sandhya.viswanathan at intel.com  Fri Apr 19 01:05:29 2024
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Fri, 19 Apr 2024 01:05:29 +0000
Subject: Vector (and integer) API: unsigned min/max
In-Reply-To: <25DABE0A-2805-4462-B475-3C45E41E2FBA@oracle.com>
References: <CANghgrRXdbQJHQN8FfPqEVy9x7PyWUOzVqu+SEYxf033OoQf-A@mail.gmail.com>
 <25DABE0A-2805-4462-B475-3C45E41E2FBA@oracle.com>
Message-ID: <BYAPR11MB3543664060821EC012C60C26EF0D2@BYAPR11MB3543.namprd11.prod.outlook.com>

Using compare the unsigned max(va, vb) could be written as:

            var va =  IntVector.fromArray(ispecies, ia, i);
            var vb =  IntVector.fromArray(ispecies, ib, i);
            var vm =  va.compare(UNSIGNED_LT, vb);
            va.blend(vb, vm).intoArray(ir, i);

Where ia and ib are input integer arrays and ir is the output integer array.

For x86_64 platforms supporting AVX512 compare method could be faster than the add with offset method. 

Best Regards,
Sandhya


-----Original Message-----
From: Paul Sandoz <paul.sandoz at oracle.com> 
Sent: Thursday, April 18, 2024 11:40 AM
To: David Lloyd <david.lloyd at redhat.com>
Cc: core-libs-dev at openjdk.org; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
Subject: Re: Vector (and integer) API: unsigned min/max

Hi David,

It?s not at all outlandish, but would caution it's more work than one might initially think.

Could you describe a little more about your use case? that can be helpful to understand the larger picture and demand. Using unsigned comparison would be my recommended approach with the current API. CC'ing Sandhya for her opinion.

Generally when we add new Vector operations we also consider the impact on the scalar types and try to fill any gaps there, so the vector operation behavior is composed from the scalar operation behavior (so like you indicated regarding symmetry). 

We are seeing demand for saturated arithmetic primarily for vector (not ?vector? as in hardware vector) search, so we may do something there for specific integral types.

Paul.

> On Apr 17, 2024, at 7:13 AM, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> I've been trying the the incubating Vector API and one thing I've missed on integer-typed vectors is having unsigned min/max operations. There is a signed min/max operation, and unsigned comparison, but no unsigned min/max.
> 
> I guess this is for symmetry with `Math`, which only has signed `min`/`max`. However, I would point out that while it's not very hard to implement one's own unsigned min/max for integer types using `compareUnsigned`, it is a bit harder to do so with vectors. The best I've come up with is to take one of two approaches:
> 
> 1. Zero-extend the vector to the next-larger size, perform the 
> min/max, and reduce it back down again, or 2. Add <IntType>.MIN_VALUE, 
> min/max with a value or vector also offset by <IntType>.MIN_VALUE, and 
> then subtract the offset again
> 
> I guess a third approach could be to do a comparison using unsigned compares, and then use the resultant vector mask to select items from the original two vectors, but I didn't bother to work out this solution given I already had the other two options.
> 
> Would it be feasible to add unsigned min/max operations for vectors? It looks like at least AArch64 has support for this as a single instruction, so it doesn't seem too outlandish.
> 
> And as a separate (but related) question, what about `Math.minUnsigned`/`Math.maxUnsigned` of `int` and `long` for symmetry?
> 
> --
> - DML ? he/him


From liach at openjdk.org  Fri Apr 19 04:48:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Apr 2024 04:48:56 GMT
Subject: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly
In-Reply-To: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
References: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
Message-ID: <JXkl3TCGImZ9TGXNL1gc0P6rmNjawucgttX_l7USBEc=.bbc878f9-cf94-442d-8750-c3ab1ddc034f@github.com>

On Thu, 18 Apr 2024 20:11:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Investigating a recent regression in mainline I realized we have an opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by using `invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This avoids generating type checking adapters and equates to a one-off startup win of around 5ms in any app that ever has the need to spin up a toString, equals or hashCode method on a record.

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 150:

> 148:                 } else if (isObjectMethodsBootstrapBSM(bsmType)) {
> 149:                     MethodHandle[] methodHandles = new MethodHandle[argv.length - 2];
> 150:                     System.arraycopy(argv, 2, methodHandles, 0, argv.length - 2);

Are we avoiding `Arrays.copyOfRange(argv, 2, argv.length, MethodHandle.class)` because of the JIT? If JIT compiler can recognize `MethodHandle.class` constant and inline I recommend using copyOfRange like for string concat above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18845#discussion_r1571783566

From redestad at openjdk.org  Fri Apr 19 07:06:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 19 Apr 2024 07:06:22 GMT
Subject: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v2]
In-Reply-To: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
References: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
Message-ID: <kPrEQ5hpg8ZHCmy62PCwQtkxFSbd3oROlrnESwIBzvM=.d2c7dbee-d3a1-4aff-945e-ed0b3c79df57@github.com>

> Investigating a recent regression in mainline I realized we have an opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by using `invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This avoids generating type checking adapters and equates to a one-off startup win of around 5ms in any app that ever has the need to spin up a toString, equals or hashCode method on a record.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Use Arrays.copyOfRange

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18845/files
  - new: https://git.openjdk.org/jdk/pull/18845/files/31752237..86ccbbba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18845&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18845&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18845.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18845/head:pull/18845

PR: https://git.openjdk.org/jdk/pull/18845

From redestad at openjdk.org  Fri Apr 19 07:09:57 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 19 Apr 2024 07:09:57 GMT
Subject: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v2]
In-Reply-To: <JXkl3TCGImZ9TGXNL1gc0P6rmNjawucgttX_l7USBEc=.bbc878f9-cf94-442d-8750-c3ab1ddc034f@github.com>
References: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
 <JXkl3TCGImZ9TGXNL1gc0P6rmNjawucgttX_l7USBEc=.bbc878f9-cf94-442d-8750-c3ab1ddc034f@github.com>
Message-ID: <67dZ1tGLACSN-vWSmWf59wGe3qBiZYxinRDU6xQhCTQ=.c1178ce7-a17d-4b2e-b55f-168edbe478b8@github.com>

On Fri, 19 Apr 2024 04:45:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Arrays.copyOfRange
>
> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 150:
> 
>> 148:                 } else if (isObjectMethodsBootstrapBSM(bsmType)) {
>> 149:                     MethodHandle[] methodHandles = new MethodHandle[argv.length - 2];
>> 150:                     System.arraycopy(argv, 2, methodHandles, 0, argv.length - 2);
> 
> Are we avoiding `Arrays.copyOfRange(argv, 2, argv.length, MethodHandle.class)` because of the JIT? If JIT compiler can recognize `MethodHandle.class` constant and inline I recommend using copyOfRange like for string concat above.

No, I actually reached for the appropriate `copyOfRange` method, but my IDE hid it from view in favor of `copyOfRange(T[], int, int)` and all the others.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18845#discussion_r1571928355

From redestad at openjdk.org  Fri Apr 19 07:42:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 19 Apr 2024 07:42:19 GMT
Subject: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v3]
In-Reply-To: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
References: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
Message-ID: <RwSGiqh9MPNYmOtbI-pGXjyOFOajBh2xcQq5X9mdSh4=.cc7c1fbe-ad04-414a-8cf2-02e79c935d2a@github.com>

> Investigating a recent regression in mainline I realized we have an opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by using `invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This avoids generating type checking adapters and equates to a one-off startup win of around 5ms in any app that ever has the need to spin up a toString, equals or hashCode method on a record.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Copyright
 - Formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18845/files
  - new: https://git.openjdk.org/jdk/pull/18845/files/86ccbbba..b67ee397

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18845&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18845&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18845.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18845/head:pull/18845

PR: https://git.openjdk.org/jdk/pull/18845

From sgehwolf at openjdk.org  Fri Apr 19 09:00:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 19 Apr 2024 09:00:00 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
Message-ID: <7GjtMGXbf3rZWHSCnweq2vA_50PWZYL5aRslymkysP0=.fb73e955-0fe3-4a62-a428-ee63d9f819dd@github.com>

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - Make find_ro static and local to compilation unit
>  - 8261242: [Linux] OSContainer::is_containerized() returns true

Thanks for your input Larry!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2066136268

From clanger at openjdk.org  Fri Apr 19 09:23:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 19 Apr 2024 09:23:56 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing
In-Reply-To: <usYxk8PzNPW_UkywGlH3zM4r9kdbYW7Y0Ly6Kd0QL0U=.2c412f7d-2fb5-4d80-905e-0e7f32ac7e05@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <usYxk8PzNPW_UkywGlH3zM4r9kdbYW7Y0Ly6Kd0QL0U=.2c412f7d-2fb5-4d80-905e-0e7f32ac7e05@github.com>
Message-ID: <aFm7tS9jxWfpuqS9AtHOJcumQttXNSleZgz0WL5grTw=.2170bb5f-a216-45d7-ba2d-1f3845ef6cd7@github.com>

On Tue, 16 Apr 2024 10:20:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> I think this is way too ad hoc and looks like lefts over from a debugging session. So I don't think it should be integrated without stepping back and thinking more about what this tracing option is intended for.

Generally this looks more consistent now. Let's see what @AlanBateman thinks... ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2066177891

From clanger at openjdk.org  Fri Apr 19 09:23:58 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 19 Apr 2024 09:23:58 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v3]
In-Reply-To: <Uqd7U25xxNtQASTKFDk8rgd-h4_NSeMxwgkEQ37ha_E=.f0bb484f-d9bc-4844-bd00-b93159cbbb07@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <Uqd7U25xxNtQASTKFDk8rgd-h4_NSeMxwgkEQ37ha_E=.f0bb484f-d9bc-4844-bd00-b93159cbbb07@github.com>
Message-ID: <1iCzpt4KASYMokD6ISnWi-o6ZsF7jd3j57PVEFAjRXY=.84b397fb-b07d-45e5-b820-1a3225adca98@github.com>

On Thu, 18 Apr 2024 06:57:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove obsolete USE_REGISTRY_LOOKUP usages

src/java.base/unix/native/libjli/java_md_common.c line 85:

> 83:     const char *execname = GetExecName();
> 84:     if (execname != NULL) {
> 85:         JLI_TraceLauncher("Launcher executable path is %s\n", execname);

This trace seems a bit unsymmetric to its Windows counterpart. Maybe it should be left out here, too, since there is tracing in GetJREPath.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18699#discussion_r1572086726

From duke at openjdk.org  Fri Apr 19 09:27:22 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 19 Apr 2024 09:27:22 GMT
Subject: RFR: 8326836: Incorrect `@since` tags for ClassSignature methods
 [v4]
In-Reply-To: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
Message-ID: <NTjyehBl2R2N3yfBC2sYsmN1vfEHpPrtGECaJo_4rAM=.9a104f52-f65d-4909-aa38-e68c32066a00@github.com>

> # Issue
> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were made to the method signatures but this modification isn't reflected in the @ since tags. The @ since tags need to be updated.
> 
> I changed the `@since` tags to better accurately show when the methods were introduced. This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into fix-classfile-related-since-tag
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/ClassFile.java
 - Update full name
 - update the copyright year to 2024
 - added @ since 23 to ClassFile.JAVA_23_VERSION, it now matches the @ since of the enclosing element
 - added @ since tag for of methods as their signature changed in jdk 23

-------------

Changes: https://git.openjdk.org/jdk/pull/18030/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18030&range=03
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18030/head:pull/18030

PR: https://git.openjdk.org/jdk/pull/18030

From pminborg at openjdk.org  Fri Apr 19 09:42:02 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 19 Apr 2024 09:42:02 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
Message-ID: <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>

On Thu, 18 Apr 2024 22:21:11 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit to trigger check rerun

Adding (default) methods to `List` would have significant compatibility ramifications. Also, the PR needs to contain significant testing of the new proposed methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066206801

From mbaesken at openjdk.org  Fri Apr 19 10:07:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Apr 2024 10:07:22 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove launcher executable path trace output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18699/files
  - new: https://git.openjdk.org/jdk/pull/18699/files/ddb3e0fe..8b7a9d58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=02-03

  Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18699/head:pull/18699

PR: https://git.openjdk.org/jdk/pull/18699

From mbaesken at openjdk.org  Fri Apr 19 10:07:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Apr 2024 10:07:22 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v3]
In-Reply-To: <1iCzpt4KASYMokD6ISnWi-o6ZsF7jd3j57PVEFAjRXY=.84b397fb-b07d-45e5-b820-1a3225adca98@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <Uqd7U25xxNtQASTKFDk8rgd-h4_NSeMxwgkEQ37ha_E=.f0bb484f-d9bc-4844-bd00-b93159cbbb07@github.com>
 <1iCzpt4KASYMokD6ISnWi-o6ZsF7jd3j57PVEFAjRXY=.84b397fb-b07d-45e5-b820-1a3225adca98@github.com>
Message-ID: <EKGsxeCeI8TLMN6xGFrj8I5mHlNr5mceQfyXqfZwJuM=.b636a8d8-acee-43f6-91c2-a5cbf0782407@github.com>

On Fri, 19 Apr 2024 09:20:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This trace seems a bit unsymmetric to its Windows counterpart. Maybe it should be left out here, too, since there is tracing in GetJREPath.

I removed the JLI trace output for the launcher exe path.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18699#discussion_r1572140833

From aivanov at openjdk.org  Fri Apr 19 10:55:58 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 10:55:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

src/java.base/macosx/classes/apple/security/AppleProvider.java line 33:

> 31: /*
> 32:  * The Apple Security Provider.
> 33:  */

Does it make sense to incorporate this comment into the following javadoc comment?


/**
 * Defines the (an) Apple security provider.
 * ...
 */
@SuppressWarnings("serial") // JDK implementation class

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 37:

> 35: import static sun.security.util.SecurityProviderConstants.*;
> 36: 
> 37: /*

Should this be included in the main javadoc comment? The `@author` tags belong in the javadoc comment.

The javadoc itself is likely unreadable, when processed the entire comment becomes one very long paragraph.

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 38:

> 36: 
> 37: /**
> 38:  * Open an file input stream given a URL.

Suggestion:

 * Open a file input stream given a URL.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572192780
PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572184441
PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572189001

From aivanov at openjdk.org  Fri Apr 19 11:04:56 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 11:04:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <-ZdPijmlx_H98EC5meigkk-QBEQawMNWEQi-Y-dyHgo=.469f84c6-9897-49c3-ba55-872d13939555@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

It is somewhat off-topic. Yet I noticed javadoc comments in some files are followed a blank line, and others aren't. Out of my curiosity, is there a convention about the blank line between the javadoc comment and the class or interface declaration? Should there be one?


/**
 * This is a class.
 */
public class A {}


or


/**
 * This is a class.
 */

public class A {}


Which is the most common? Which is preferred?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2066337900

From dfuchs at openjdk.org  Fri Apr 19 11:29:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 11:29:57 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <c4-wxoGocaNumdyy8fUX4fVZBsSZxtJcKNmWXGbswiU=.d7e14e40-5057-473b-87af-fae5864be982@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Changes to networking code looks good. I didn't spot any issue with the rest but I'm usually not a reviewer there.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2011186056

From prappo at openjdk.org  Fri Apr 19 11:35:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Apr 2024 11:35:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

This comment is not a review. I simply use the opportunity provided by this PR to suggest that we stop making new `/** ... */` and separately fix old jtreg comments like this:

    /**
     * @test TestSmallHeap
     * @bug 8067438 8152239
     * @summary Verify that starting the VM with a small heap works
     * @library /test/lib
     * @modules java.base/jdk.internal.misc
     * @build jdk.test.whitebox.WhiteBox
     * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
     * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI     gc.TestSmallHeap
     */

I know that those comments only appear in tests, and that tests are never documented. Still, it is confusing to see such comments and IDEs might frown upon them too. Generally, it is a good rule of thumb that `/** ... */` should be reserved only for javadoc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2066383735

From duke at openjdk.org  Fri Apr 19 11:37:00 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 11:37:00 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
Message-ID: <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>

On Fri, 19 Apr 2024 09:39:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   empty commit to trigger check rerun
>
> Adding (default) methods to `List` would have significant compatibility ramifications. Also, the PR needs to contain significant testing of the new proposed methods.

@minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066385281

From liach at openjdk.org  Fri Apr 19 11:47:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Apr 2024 11:47:58 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
Message-ID: <WotAqbPlhMshNG_r0nj0USOKfcyYqCif4PnaDklbSqM=.40ff1445-ade4-4cff-ab58-f6ad665b91b6@github.com>

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose <duke at openjdk.org> wrote:

>> Adding (default) methods to `List` would have significant compatibility ramifications. Also, the PR needs to contain significant testing of the new proposed methods.
>
> @minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?

@Evemose CSR requests can only be filed by users who have a JBS account. I am glad to help you file one, but before that, you need to ensure that the API surface (the public method/fields' names, modifiers, types, and javadocs) are all finalized and won't change.

The CSR looks like this:
Summary: A concise summary about the changes, like "Add findIndex(Predicate) to List"
Problem: Description of the problem, as in why this CSR is needed
Solution: The solution to the said problem, i.e. what your task did
Specification: The git diff, but you only need to include changes to public method/field/classes' names, modifiers, types, and javadocs; you don't need to include any implementation code changes
Also, you might include things like "alternatives" describing alternative approaches and why you elect not to choose them, etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066402038

From duke at openjdk.org  Fri Apr 19 11:54:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 11:54:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v3]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <HF4w-OW5WeyXhFoVQzF1vsVXD5jcZOvT4rzhMJPTvjQ=.dacde753-a475-440d-bccf-f85e4bb98aa5@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with one additional commit since the last revision:

  Removed extra line from previous commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/21ce4892..5fcdfd87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Fri Apr 19 11:57:27 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 11:57:27 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v4]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <43ivjl5_vgCBp1dxypZ8s6xqhubFHu8BOdy8wttjsG0=.1050fc33-313e-43a7-b8e5-1e9a982d11e6@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with one additional commit since the last revision:

  Fixed javadocs in ArrayList

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/5fcdfd87..34b3695f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Fri Apr 19 12:04:26 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:04:26 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v5]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <RXaPyUqwCk0loiELpVFvGD3zNJpNzk6VFwRqbekljtw=.ba738ace-b766-41ce-aa83-f80cfe733c17@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with one additional commit since the last revision:

  Fixed javadocs in LinkedList.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/34b3695f..5beec920

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Fri Apr 19 12:32:19 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:32:19 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v6]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <kBLC_EIFpo96Bkhi3V2kSNRTdZeu7oZKgEDrEDdRsfo=.1edeab77-936d-42f0-8b28-e286ce8b9b3e@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with 14 additional commits since the last revision:

 - Update LinkedList.java
 - Update LinkedList.java
 - Reformat LinkedList.java
 - Removed trailing whitespace in Collections.java
 - Update CopyOnWriteArrayList.java
 - Reformated imports in Vector.java
 - Reformated imports in CopyOnWriteArrayList.java
 - Removed on-demand import from SpliteratorTraversingAndSplittingTest.java
 - Update ListFactories.java
 - Update ReverseOrderListView.java
 - ... and 4 more: https://git.openjdk.org/jdk/compare/5beec920...d7f5e97e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/5beec920..d7f5e97e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=04-05

  Stats: 59 lines in 7 files changed: 33 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From alanb at openjdk.org  Fri Apr 19 12:32:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Apr 2024 12:32:19 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
Message-ID: <dh7EZA0fPuyxngUs-RM9_S_i9ullQ41SIbZK4XMD-y8=.11ecf394-d815-4886-8deb-d7fa667e427d@github.com>

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose <duke at openjdk.org> wrote:

> but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?

I think you can ignore CSR for now, the first step when proposing an API in this area is to start a discussion on core-libs-dev to make the case and get support. The java.util.List interface dates from JDK 1.2 and there are many implementations. Even if the proposal has some merit, I think a big part of the work required will be doing analysis on implementations to see what compatibility issues might come up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066437418

From liach at openjdk.org  Fri Apr 19 12:32:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Apr 2024 12:32:19 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
Message-ID: <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose <duke at openjdk.org> wrote:

>> Adding (default) methods to `List` would have significant compatibility ramifications. Also, the PR needs to contain significant testing of the new proposed methods.
>
> @minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?

@Evemose Please revert formatting changes in existing classes. Unfortunately there's no single code style across all of JDK, but you shouldn't try to format code/methods that's not touched by your new method addition.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066439080

From duke at openjdk.org  Fri Apr 19 12:39:11 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:39:11 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v7]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <CJ_dERFrPCQEQFrHKQNd2oBMpxL8I2PTY0M1DGMoarU=.abe3f9d1-6ca1-44ac-97b0-33ac26f8f911@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with two additional commits since the last revision:

 - Update CopyOnWriteArrayList.java
 - Reformat LinkedList.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/d7f5e97e..625c5b46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=05-06

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Fri Apr 19 12:39:11 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:39:11 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
 <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>
Message-ID: <28cKraYF4xWkM_A32j3iwxTdaaNDRD1F9hI9EJRUFGI=.b94e4be6-4ffc-44ac-b3d0-5783f1918302@github.com>

On Fri, 19 Apr 2024 12:10:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?
>
> @Evemose Please revert formatting changes in existing classes. Unfortunately there's no single code style across all of JDK, but you shouldn't try to format code/methods that's not touched by your new method addition.

@liach i did revert changes where it was possible but in few files it will be just too resource-consuming to revert indentations to previous state. If this will be crucial, ill deal with it before merging

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066480208

From duke at openjdk.org  Fri Apr 19 12:47:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:47:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v8]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <9HprdOQ-TujeBVtMHLdDOYeIGMyeiHw6PsAm7siC5no=.beef0dc3-5a2f-4bcd-b188-85ad222befa4@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with two additional commits since the last revision:

 - Update SpliteratorTraversingAndSplittingTest.java
 - Update Arrays.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/625c5b46..49c4993b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=06-07

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Fri Apr 19 12:52:03 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:52:03 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v8]
In-Reply-To: <9HprdOQ-TujeBVtMHLdDOYeIGMyeiHw6PsAm7siC5no=.beef0dc3-5a2f-4bcd-b188-85ad222befa4@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <9HprdOQ-TujeBVtMHLdDOYeIGMyeiHw6PsAm7siC5no=.beef0dc3-5a2f-4bcd-b188-85ad222befa4@github.com>
Message-ID: <rneh9yXGZQCWiogRN58LBlBwv8zj27l0ypkfCiw0sTM=.18744eb7-4207-467a-beef-1d3bc104514c@github.com>

On Fri, 19 Apr 2024 12:47:12 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update SpliteratorTraversingAndSplittingTest.java
>  - Update Arrays.java

I requested post in core-libs-dev. I guess I will wait a week or two to gather feedback of community before filing for CSR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066509181

From duke at openjdk.org  Fri Apr 19 12:59:24 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:59:24 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v9]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <vjm5kqMml0JMATtkFoM1zAvriqn8jbhp0mwIx39qmyU=.d4768ef6-7551-41dc-a2c3-f9d6e195702d@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with one additional commit since the last revision:

  Update Vector.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/49c4993b..97b9bff4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From jlahoda at openjdk.org  Fri Apr 19 13:17:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 Apr 2024 13:17:18 GMT
Subject: RFR: 8328481: Implement Module Imports [v11]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adding test for ImportTree.isModule, as suggested.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/846b038e..cbc363ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=09-10

  Stats: 135 lines in 1 file changed: 135 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From redestad at openjdk.org  Fri Apr 19 13:30:27 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 19 Apr 2024 13:30:27 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs
Message-ID: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>

We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.

-------------

Commit messages:
 - Move typePairToName to TypePairs to make this lazy loaded
 - Explicit hashCode and equals for SwitchBootstraps

Changes: https://git.openjdk.org/jdk/pull/18865/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18865&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330681
  Stats: 18 lines in 1 file changed: 14 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18865.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18865/head:pull/18865

PR: https://git.openjdk.org/jdk/pull/18865

From jlahoda at openjdk.org  Fri Apr 19 13:30:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 Apr 2024 13:30:27 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs
In-Reply-To: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
Message-ID: <RTOEM4ggxo6laidGjNG5sEHQaXSld5NUV8hd0XDn6v0=.1d8c4242-cbde-419b-b7c7-a5218910ae89@github.com>

On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18865#pullrequestreview-2011427815

From jbhateja at openjdk.org  Fri Apr 19 13:38:01 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 19 Apr 2024 13:38:01 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
Message-ID: <Hg2Ihh1DAB5WApqV5PgpQi2-_v72LSp9aQ6upni03e8=.b95a6b98-5e07-49c5-856c-4993c84ceb70@github.com>

On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add enter() and leave(); remove Windows-specific register stuff

Hi @asgibbons Please add a new test / extend an existing test for SIGBUS violation testing test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2611:

> 2609:     // Propagate byte to full Register
> 2610:     __ movzbl(rScratch1, byteVal);
> 2611:     __ mov64(wide_value, 0x0101010101010101);

Long constant should be suffixed by ULL.

test/micro/org/openjdk/bench/java/lang/foreign/MemorySegmentZeroUnsafe.java line 1:

> 1: package org.openjdk.bench.java.lang.foreign;

Copyright header missing.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-2011247585
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572370327
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572267154

From jlahoda at openjdk.org  Fri Apr 19 13:44:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 Apr 2024 13:44:28 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v11]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <RUP3cDwtavZWUcF7V8Pq69_mJRwXfxxYiam3TBYRfpg=.9dec63e0-bb60-4e76-b0b4-ecaf068f198e@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Post-merge fixes.
 - Merge branch 'master' into wthexp
 - Reflecting review feedback:
   - reverting unnecessary changes in TransPatterns
   - moving the patters/withers/Model test to a more appropriate place
 - Adding tests as suggested.
 - Reflecting review feedback:
   - pre-generating the JCVarDecls in Attr, to aid Flow
   - adding a note on how the desugared code looks like
 - JavaCompiler cleanup
 - Improving the javax.lang.model for component local variables, by darcy.
 - Reflecting review feedback.
 - Merge branch 'master' into wthexp
 - Fixing tests.
 - ... and 25 more: https://git.openjdk.org/jdk/compare/177092b9...e8499df1

-------------

Changes: https://git.openjdk.org/jdk/pull/18509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=10
  Stats: 2023 lines in 51 files changed: 1965 ins; 19 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

PR: https://git.openjdk.org/jdk/pull/18509

From rriggs at openjdk.org  Fri Apr 19 14:14:00 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Apr 2024 14:14:00 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v9]
In-Reply-To: <vjm5kqMml0JMATtkFoM1zAvriqn8jbhp0mwIx39qmyU=.d4768ef6-7551-41dc-a2c3-f9d6e195702d@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <vjm5kqMml0JMATtkFoM1zAvriqn8jbhp0mwIx39qmyU=.d4768ef6-7551-41dc-a2c3-f9d6e195702d@github.com>
Message-ID: <RpCWwvirm7rTB8Nn2n1OUGDM3HqrMM5EkoSc3K0AWKo=.0ba483c5-7a4e-4f85-88fb-4278d9dfcb9f@github.com>

On Fri, 19 Apr 2024 12:59:24 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Vector.java

Please revert the formatting as soon as possible; its noise as far as reviewers are concerned. 
You want reviewers to focus on the suitability of the API and clarity of the specification first, then later on the implementation.  Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066673266

From sgibbons at openjdk.org  Fri Apr 19 14:58:05 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 14:58:05 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <Hg2Ihh1DAB5WApqV5PgpQi2-_v72LSp9aQ6upni03e8=.b95a6b98-5e07-49c5-856c-4993c84ceb70@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
 <Hg2Ihh1DAB5WApqV5PgpQi2-_v72LSp9aQ6upni03e8=.b95a6b98-5e07-49c5-856c-4993c84ceb70@github.com>
Message-ID: <WUCp2qPvLsFic3shPRTBCaZMjXTlxOo1HBzbi8PWMb8=.062ed5e0-5445-4ed3-bc46-5a37572946f5@github.com>

On Fri, 19 Apr 2024 13:25:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add enter() and leave(); remove Windows-specific register stuff
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2611:
> 
>> 2609:     // Propagate byte to full Register
>> 2610:     __ movzbl(rScratch1, byteVal);
>> 2611:     __ mov64(wide_value, 0x0101010101010101);
> 
> Long constant should be suffixed by ULL.

Fixed.

> test/micro/org/openjdk/bench/java/lang/foreign/MemorySegmentZeroUnsafe.java line 1:
> 
>> 1: package org.openjdk.bench.java.lang.foreign;
> 
> Copyright header missing.

Added

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572502532
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572502204

From duke at openjdk.org  Fri Apr 19 15:39:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 15:39:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v10]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <R4A9wZCFMqBKHw84nfreiL3FgJmpYWvqx6hS7ViieQI=.4ec286d8-fd7f-4626-82c8-7a015e850dec@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/feature/indexOf-with-predicate' into feature/indexOf-with-predicate
   
   # Conflicts:
   #	src/java.base/share/classes/java/util/LinkedList.java
   #	src/java.base/share/classes/java/util/ReverseOrderListView.java
   #	src/java.base/share/classes/java/util/Vector.java
   #	test/jdk/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
 - reverted code style changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/97b9bff4..2c37ecef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=08-09

  Stats: 210 lines in 6 files changed: 11 ins; 44 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Fri Apr 19 15:49:11 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 15:49:11 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v11]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with one additional commit since the last revision:

  reverted code style changes in Vector

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/2c37ecef..de6e18e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=09-10

  Stats: 145 lines in 1 file changed: 5 ins; 13 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Fri Apr 19 15:49:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 15:49:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v9]
In-Reply-To: <RpCWwvirm7rTB8Nn2n1OUGDM3HqrMM5EkoSc3K0AWKo=.0ba483c5-7a4e-4f85-88fb-4278d9dfcb9f@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <vjm5kqMml0JMATtkFoM1zAvriqn8jbhp0mwIx39qmyU=.d4768ef6-7551-41dc-a2c3-f9d6e195702d@github.com>
 <RpCWwvirm7rTB8Nn2n1OUGDM3HqrMM5EkoSc3K0AWKo=.0ba483c5-7a4e-4f85-88fb-4278d9dfcb9f@github.com>
Message-ID: <vDWzpdcJDAYK8PQyO4_JmueMnS_UuZ7_NRF7wIptRSc=.d12871a5-9b4c-48ef-bbcf-7545e11af51f@github.com>

On Fri, 19 Apr 2024 14:11:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Vector.java
>
> Please revert the formatting as soon as possible; its noise as far as reviewers are concerned. 
> You want reviewers to focus on the suitability of the API and clarity of the specification first, then later on the implementation.  Thanks

@RogerRiggs Been done. It turned out much easier then i though it would

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066838257

From duke at openjdk.org  Fri Apr 19 15:49:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 15:49:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v10]
In-Reply-To: <R4A9wZCFMqBKHw84nfreiL3FgJmpYWvqx6hS7ViieQI=.4ec286d8-fd7f-4626-82c8-7a015e850dec@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <R4A9wZCFMqBKHw84nfreiL3FgJmpYWvqx6hS7ViieQI=.4ec286d8-fd7f-4626-82c8-7a015e850dec@github.com>
Message-ID: <-tsyKK8DMn5A2zhkxWpei5eTnwRIeB4mDvkzKeg57pM=.8f59c9c9-623e-4878-a425-9ed2703d2cc3@github.com>

On Fri, 19 Apr 2024 15:39:12 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/feature/indexOf-with-predicate' into feature/indexOf-with-predicate
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/util/LinkedList.java
>    #	src/java.base/share/classes/java/util/ReverseOrderListView.java
>    #	src/java.base/share/classes/java/util/Vector.java
>    #	test/jdk/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
>  - reverted code style changes

Also regarding tests. Not sure if they are needed at all as implementations are no longer then 15 lines, but if it is mandatory step, I guess i will add them after I finished collecting feedback so I will have final version of what this methods behaviour should look like

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066841853

From rotan.olexandr at gmail.com  Fri Apr 19 15:59:39 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Fri, 19 Apr 2024 18:59:39 +0300
Subject: Addition of Predicate-based findIndex and findLastIndex methods to
 java.util.List
Message-ID: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>

Subject
Addition of Predicate-based findIndex and findLastIndex methods to
java.util.List

Motivation
The motivation behind this proposal is to enhance the functionality of the
List interface by providing a more flexible way to find the index of an
element. Currently, the indexOf and lastIndexOf methods only accept an
object as a parameter. This limits the flexibility of these methods as they
can only find the index of exact object matches.

Here I want to propose methods that would accept a Predicate as a
parameter, allowing users to define a condition that the desired element
must meet. This would provide a more flexible and powerful way to find the
index of an element in a list.

The changes I am proposing are implemented in this PR:
https://github.com/openjdk/jdk/pull/18639. Here is a brief overview of the
changes made in this pull request:

Added the findIndex  (Predicate<? super E> filter) method to the List
interface.
Added the findLastIndex  (Predicate<? super E> filter) method to the List
interface.
Implemented these methods in all non-abstract classes that implement the
List interface, as well as List itself (default impl).
The changes have been thoroughly tested to ensure they work as expected and
do not introduce any regressions. The test cases cover a variety of
scenarios to ensure the robustness of the implementation.

For example, consider the following test case:

List<String> list = new ArrayList<>();
list.add("Object one");
list.add("NotObject two");
list.add("NotObject three");

int index1 = list.findIndex(s -> s.contains("ct t"));
System.out.println(index1); // Expected output: 1
int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
System.out.println(index2); // Expected output: 2
Currently, to achieve the same result, we would have to use a more verbose
approach:

int index1 = IntStream.range(0, list.size())
                     .filter(i -> list.get(i).contains("ct t"))
                     .findFirst()
                     .orElse(-1);
System.out.println(index1); // Output: 1
int index2 = IntStream.range(0, list.size())
                         .filter(i -> list.get(i).startsWith("NotObject"))
                         .reduce((first, second) -> second)
                         .orElse(-1);
System.out.println(index2); // Output: 2

Or other approaches that require additional instructions and, therefore,
can`t be used in all scopes (like passing argument to method).

I believe these additions would greatly enhance the functionality and
flexibility of the List interface, making it more powerful and
user-friendly. I look forward to your feedback and am open to making any
necessary changes based on your suggestions.

The main reason I am publishing this proposal in the mailing system is to
gather feedback from the Java developers community, especially about
possible caveats related to backward compatibility of your projects. Would
appreciate every opinion!

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/852c7a35/attachment-0001.htm>

From sgibbons at openjdk.org  Fri Apr 19 16:25:28 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 16:25:28 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <QbEDTfAKut-P9Efx4Xd2JzR0ljYxsqXTABO822bpBCM=.5f269ba6-b40b-4a0a-a851-90201dac7d01@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments; update copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/7a1d67e5..dccf6b6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=20-21

  Stats: 37 lines in 13 files changed: 23 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From mchung at openjdk.org  Fri Apr 19 16:28:56 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 19 Apr 2024 16:28:56 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs
In-Reply-To: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
Message-ID: <Z5UEYxMKQSfsQ_4CVkKfAzNG2UcZjP_DdDkZHh9RLIY=.68ef2c61-2f02-4bff-aadd-7e0c2680adbb@github.com>

On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18865#pullrequestreview-2011881379

From mchung at openjdk.org  Fri Apr 19 17:06:57 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 19 Apr 2024 17:06:57 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Nvef5H6yg7TlYjDyCTYh1qTZoZB4B2nYvmV1d6BCnxs=.62b96873-a553-4c95-8a5a-eaf2fb6bc8a2@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <61FmMvHyAQXcl_ZWYGEWwLDU7O8a-vdHTlu56rnKzqo=.cd118172-6497-4963-ad3b-b8f865009638@github.com>
 <Nvef5H6yg7TlYjDyCTYh1qTZoZB4B2nYvmV1d6BCnxs=.62b96873-a553-4c95-8a5a-eaf2fb6bc8a2@github.com>
Message-ID: <JGexro9ukP8dyTCTNxYkhnde73SLC7def5rZBIFIuzg=.9ce10baf-a892-4b85-a570-f614978ef729@github.com>

On Thu, 18 Apr 2024 20:41:05 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Just to clarify, this would still mean converting ?isStatic? and ?noArgs? from local variables to fields so I am able to read them on the C side of things. Did I understand this correctly?

I'm okay with adding static boolean fields and read by the native code and the name can be explicit like `isStaticMain` and `mainWithNoArg`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2066958511

From mchung at openjdk.org  Fri Apr 19 17:15:57 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 19 Apr 2024 17:15:57 GMT
Subject: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v3]
In-Reply-To: <RwSGiqh9MPNYmOtbI-pGXjyOFOajBh2xcQq5X9mdSh4=.cc7c1fbe-ad04-414a-8cf2-02e79c935d2a@github.com>
References: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
 <RwSGiqh9MPNYmOtbI-pGXjyOFOajBh2xcQq5X9mdSh4=.cc7c1fbe-ad04-414a-8cf2-02e79c935d2a@github.com>
Message-ID: <LjId-PCknsIymgWqIT9fP_tm86zwmSyF4V22eBEyMpo=.9841a3bd-5e4e-42d8-9aab-a85156bdfc39@github.com>

On Fri, 19 Apr 2024 07:42:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Investigating a recent regression in mainline I realized we have an opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by using `invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This avoids generating type checking adapters and equates to a one-off startup win of around 5ms in any app that ever has the need to spin up a toString, equals or hashCode method on a record.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Copyright
>  - Formatting

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18845#pullrequestreview-2011967709

From vromero at openjdk.org  Fri Apr 19 17:20:59 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Apr 2024 17:20:59 GMT
Subject: RFR: 8328481: Implement Module Imports [v11]
In-Reply-To: <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>
Message-ID: <ep0BYQNQSPvUeV-zPB0MGvuIWrdSc3huoK0IXhuU3Uc=.e531e4bf-d2f5-4956-b07f-51f292308600@github.com>

On Fri, 19 Apr 2024 13:17:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test for ImportTree.isModule, as suggested.

lgtm, thanks!

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18614#pullrequestreview-2011974781

From joehw at openjdk.org  Fri Apr 19 17:39:30 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 19 Apr 2024 17:39:30 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v3]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <wlYQgLflc_7I-YGEweSqKNXQDUf-bDuCq_SdXXq0XT0=.1ac198be-3e7f-4b7c-a290-d46a8b1ee0fb@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/98fcc3ef..e6386015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From joehw at openjdk.org  Fri Apr 19 17:39:31 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 19 Apr 2024 17:39:31 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v2]
In-Reply-To: <BNhKmxtOBD7YVXHbdaMrhjP3Q4gYLaa_FOnw8swIMoU=.70329c23-571d-4a80-9456-c7567d102f48@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <7kkWrrqECaymEOOlg6Trzii3RRRf5J6IiL8FrTTtH_4=.876dc8e4-5eaa-46c8-8859-6187c44d0233@github.com>
 <BNhKmxtOBD7YVXHbdaMrhjP3Q4gYLaa_FOnw8swIMoU=.70329c23-571d-4a80-9456-c7567d102f48@github.com>
Message-ID: <PkkV4hiLK2ttIixqZ1dlJiWMUNG1AqMrsnNnM30DFDw=.fa21bdca-1cb4-448b-9736-4c224fdf50d0@github.com>

On Thu, 18 Apr 2024 23:40:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add description of the three configuration files.
>
> src/java.xml/share/conf/jaxp-strict.properties line 2:
> 
>> 1: ################################################################################
>> 2: #           JAXP String Configuration File
> 
> Nit: typo here: String -> Strict

Thanks!  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1572705283

From forax at univ-mlv.fr  Fri Apr 19 17:47:21 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 19 Apr 2024 19:47:21 +0200 (CEST)
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
Message-ID: <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>

Hello, 
for me, it seems what you want is Collector on Stream which is able to short-circuit, 
so you can write 
list.stream().collect(Collectors.findFirst(s -> s.contains("o"))) 
and in reverse 
list.reversed().stream().collect(Collectors.findFirst(s -> s.contains("o"))) 

Using a Stream here is more general and will work with other collections like a LinkedHashSet for example. 
Sadly, there is no way to define a short-circuiting collector :( 

You can have a short-circuiting Gatherer like this 
<T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) { 
return Gatherer.ofSequential( 
() -> new Object() { int index; }, 
Integrtor.ofGreedy((state, element, downstream) -> { 
var index = state.index++; 
if (predicate.test(element)) { 
return downstream.push(index); 
} 
return true; 
})); 
} 

and use it like this: 
list.stream().gather(findIndex(s -> s.contains("o"))).findFirst().orElse(-1); 

But it's more verbose. 

I wonder if at the same time that the Gatherer API is introduced, the Collector API should be enhanced to support short-circuiting collectors ? 

regards, 
R?mi 

> From: "??-24 ????????? ??????" <rotan.olexandr at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Friday, April 19, 2024 5:59:39 PM
> Subject: Addition of Predicate-based findIndex and findLastIndex methods to
> java.util.List

> Subject
> Addition of Predicate-based findIndex and findLastIndex methods to
> java.util.List

> Motivation
> The motivation behind this proposal is to enhance the functionality of the List
> interface by providing a more flexible way to find the index of an element.
> Currently, the indexOf and lastIndexOf methods only accept an object as a
> parameter. This limits the flexibility of these methods as they can only find
> the index of exact object matches.

> Here I want to propose methods that would accept a Predicate as a parameter,
> allowing users to define a condition that the desired element must meet. This
> would provide a more flexible and powerful way to find the index of an element
> in a list.

> The changes I am proposing are implemented in this PR: [
> https://github.com/openjdk/jdk/pull/18639 |
> https://github.com/openjdk/jdk/pull/18639 ] . Here is a brief overview of the
> changes made in this pull request:

> Added the findIndex (Predicate<? super E> filter) method to the List interface.
> Added the findLastIndex (Predicate<? super E> filter) method to the List
> interface.
> Implemented these methods in all non-abstract classes that implement the List
> interface, as well as List itself (default impl).
> The changes have been thoroughly tested to ensure they work as expected and do
> not introduce any regressions. The test cases cover a variety of scenarios to
> ensure the robustness of the implementation.

> For example, consider the following test case:

> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");

> int index1 = list.findIndex(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> Currently, to achieve the same result, we would have to use a more verbose
> approach:

> int index1 = IntStream.range(0, list.size())
> .filter(i -> list.get(i).contains("ct t"))
> .findFirst()
> .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
> .filter(i -> list.get(i).startsWith("NotObject"))
> .reduce((first, second) -> second)
> .orElse(-1);
> System.out.println(index2); // Output: 2
> Or other approaches that require additional instructions and, therefore, can`t
> be used in all scopes (like passing argument to method).

> I believe these additions would greatly enhance the functionality and
> flexibility of the List interface, making it more powerful and user-friendly. I
> look forward to your feedback and am open to making any necessary changes based
> on your suggestions.

> The main reason I am publishing this proposal in the mailing system is to gather
> feedback from the Java developers community, especially about possible caveats
> related to backward compatibility of your projects. Would appreciate every
> opinion!

> Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/58dfc53a/attachment-0001.htm>

From jvernee at openjdk.org  Fri Apr 19 17:50:01 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 19 Apr 2024 17:50:01 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]
In-Reply-To: <QbEDTfAKut-P9Efx4Xd2JzR0ljYxsqXTABO822bpBCM=.5f269ba6-b40b-4a0a-a851-90201dac7d01@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <QbEDTfAKut-P9Efx4Xd2JzR0ljYxsqXTABO822bpBCM=.5f269ba6-b40b-4a0a-a851-90201dac7d01@github.com>
Message-ID: <1e63Ivvo2ZkyuP3U-RHrnZaUxv1PiKa2UnR5b2H9vpc=.290efaf8-6067-4e92-b7ae-932f6284b4cb@github.com>

On Fri, 19 Apr 2024 16:25:28 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments; update copyright years

I'm not really qualified as a compiler code reviewer, but I've left some comments to try and help this along.

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2523:

> 2521:   // Number of (8*X)-byte chunks into rScratch1
> 2522:   __ movq(tmp, size);
> 2523:   __ shrq(tmp, 3);

`shr` [sets the zero flag][1], so I think you can just move the jump to after the shift and avoid a separate comparison?

```suggestion  
  // Number of (8*X)-byte chunks into rScratch1
  __ movq(tmp, size);
  __ shrq(tmp, 3);
  __ jccb(Assembler::zero, L_Tail);


[1]: https://www.felixcloutier.com/x86/sal:sar:shl:shr#flags-affected

-------------

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-2011751831
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572712233

From jvernee at openjdk.org  Fri Apr 19 17:50:06 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 19 Apr 2024 17:50:06 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
Message-ID: <JfR0MnyCHELyxLLQJmDRIr0zhFdcSjvTs4sBuC6KUxI=.25a7e4fd-a696-4c1a-b22c-1110291dc494@github.com>

On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add enter() and leave(); remove Windows-specific register stuff

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4013:

> 4011:   // Initialize table for unsafe copy memeory check.
> 4012:   if (UnsafeMemoryAccess::_table == nullptr) {
> 4013:     UnsafeMemoryAccess::create_table(26);

How did you arrive at a table size of 26?

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2603:

> 2601:     const Register wide_value = rax;
> 2602:     const Register rScratch1 = r10;
> 2603: 

Maybe put an `assert_different_registers` here for the above registers, just to be sure. (I see you are avoiding the existing `rscratch1` already, because of a conflict with `c_rarg2`)

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2674:

> 2672:     // Parameter order is (ptr, byteVal, size)
> 2673:     __ xchgq(c_rarg1, c_rarg2);
> 2674:     __ pop(rbp);    // Clear effect of enter()

Why not just use `leave()` here?

src/hotspot/share/opto/library_call.cpp line 4959:

> 4957:   if (stopped())  return true;
> 4958: 
> 4959:   if (StubRoutines::unsafe_setmemory() == nullptr) return false;

I don't see why this check is needed here, since we already check whether the stub is there in `is_intrinsic_supported`.

Note that `inline_unsafe_copyMemory` also doesn't have this check. I think it would be good to keep consistency between the two.

src/hotspot/share/opto/runtime.cpp line 780:

> 778: const TypeFunc* OptoRuntime::make_setmemory_Type() {
> 779:   // create input type (domain)
> 780:   int num_args      = 4;

This variable seems redundant.

src/hotspot/share/opto/runtime.cpp line 786:

> 784:   fields[argp++] = TypePtr::NOTNULL;    // dest
> 785:   fields[argp++] = TypeLong::LONG;      // size
> 786:   fields[argp++] = Type::HALF;          // size

Since the size is a `size_t`, I don't think this is correct on 32-bit platforms. I think here we want `TypeX_X`, and then add the extra `HALF` only on 64-bit platforms. Similar to what we do in `make_arraycopy_Type`: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/runtime.cpp#L799-L802

(Note that you will also have to adjust `argcnt` for this)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572570842
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572578437
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572593795
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572556648
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572564382
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572562058

From duke at openjdk.org  Fri Apr 19 18:10:04 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 19 Apr 2024 18:10:04 GMT
Subject: Withdrawn: 8327429: String Template FMT built-in optimization for
 DateTimes
In-Reply-To: <oOeZZrsycU5QG-QuxIzh-TEaS4F5vHAzu7-wyd3sC1g=.7e37116d-36f7-4e01-ad58-9b67004e4b0e@github.com>
References: <oOeZZrsycU5QG-QuxIzh-TEaS4F5vHAzu7-wyd3sC1g=.7e37116d-36f7-4e01-ad58-9b67004e4b0e@github.com>
Message-ID: <k2dS7C0QBdw4aO7qQBpXseOfRLoPutq53HhxPam4ZME=.4a1f5855-e600-48a9-8dc2-cbe78efe9a1d@github.com>

On Wed, 4 Oct 2023 22:30:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> # Goal
> Improve String Template FMT's processing performance of date types. Currently, FMT processes date types by toString and then calls j.u.Formatter#print. Because there is less parse processing than String.format, the performance is improved, but it is still not good enough. There is an intermediate String object allocation, and the print performance of j.u.Formatter is not as good as The StringConcat.prepend method is great.
> 
> This patch allows String Template FMT to handle Date/Instant/LocalDate/LocalTime/LocalDateTime/OffsetTime/OffsetDateTime/ZonedDateTime/Instant types with optimization, just like int/long/float/double/String.
> 
> # Optimized type and Specifier combinations
> * java.util.Date
> 
> %s
> %tc (Sat Nov 04 12:02:33 EST 1999)
> %tD DATE (mm/dd/yy)
> %tF ISO_STANDARD_DATE (%Y-%m-%d)
> %tT TIME (24 hour hh:mm:ss)
> %tR TIME_24_HOUR hh:mm same as %H:%M
> %tr TIME_12_HOUR (hh:mm:ss [AP]M)
> 
> 
> * LocalDate
> 
> %s
> %tD DATE (mm/dd/yy)
> %tF ISO_STANDARD_DATE (%Y-%m-%d)
> 
> 
> * LocalDateTime
> 
> %s
> %tD DATE (mm/dd/yy)
> %tF ISO_STANDARD_DATE (%Y-%m-%d)
> %tT TIME (24 hour hh:mm:ss)
> %tR TIME_24_HOUR hh:mm same as %H:%M
> %tr TIME_12_HOUR (hh:mm:ss [AP]M)
> 
> 
> * OffsetDateTime
> 
> %s
> %tD DATE (mm/dd/yy)
> %tF ISO_STANDARD_DATE (%Y-%m-%d)
> %tT TIME (24 hour hh:mm:ss)
> %tR TIME_24_HOUR hh:mm same as %H:%M
> %tr TIME_12_HOUR (hh:mm:ss [AP]M)
> 
> 
> * ZonedDateTime
> 
> %s
> %tD DATE (mm/dd/yy)
> %tF ISO_STANDARD_DATE (%Y-%m-%d)
> %tT TIME (24 hour hh:mm:ss)
> %tR TIME_24_HOUR hh:mm same as %H:%M
> %tr TIME_12_HOUR (hh:mm:ss [AP]M)
> 
> 
> * LocalTime
> 
> %s
> %tT TIME (24 hour hh:mm:ss)
> %tR TIME_24_HOUR hh:mm same as %H:%M
> %tr TIME_12_HOUR (hh:mm:ss [AP]M)
> 
> 
> * OffsetTime
> 
> %s
> %tT TIME (24 hour hh:mm:ss)
> %tR TIME_24_HOUR hh:mm same as %H:%M
> %tr TIME_12_HOUR (hh:mm:ss [AP]M)
> 
> 
> * Instant
> 
> %s
> 
> 
> # Performance Numbers
> run on MacBook M1 Pro
> 
> -Benchmark                               Mode  Cnt    Score   Error  Units (baseline)
> -StringTemplateFMT.dateFormat            avgt   15   66.601 ? 0.863  ns/op
> -StringTemplateFMT.instantFormat         avgt   15  198.284 ? 5.804  ns/op
> -StringTemplateFMT.ldtFormat             avgt   15  103.625 ? 6.315  ns/op
> -StringTemplateFMT.localTimeFormat       avgt   15   44.750 ? 0.219  ns/op
> -StringTemplateFMT.zdtFormat             avgt   15  179.140 ? 8.379  ns/op
> 
> +Benchmark                               Mode  Cnt    Score    Error  Units (optimized)
> +StringTemplateFMT.dateFormat            avgt   15   29.425 ?  0.510  ns/op (+126.35)
> +StringTemplateFMT.instantFormat         avgt   15   36.467 ?  0.114  ns/op ...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16044

From duke at openjdk.org  Fri Apr 19 18:11:07 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 19 Apr 2024 18:11:07 GMT
Subject: Withdrawn: 8327425: String Template FMT Refactor use call direct
 instead of MethodHandle
In-Reply-To: <xKwdFc_9-CPdbH4J1FHUFlLEgzlh_yxgZ-1HbtnzLCQ=.da068c07-6337-450d-bcc3-433bb194f3a4@github.com>
References: <xKwdFc_9-CPdbH4J1FHUFlLEgzlh_yxgZ-1HbtnzLCQ=.da068c07-6337-450d-bcc3-433bb194f3a4@github.com>
Message-ID: <WTsCzNm5tG7-f50hNc3oaE3FI1sbs5sze7fXVqTgQmU=.6f86a0e5-313e-4feb-854f-b38d57fa6612@github.com>

On Tue, 3 Oct 2023 06:19:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Currently FormatItem uses MethodHandler to handle latin1 and utf16, which is not readable. This PR uses direct calls instead of MethodHandle.
> 
> Please review and don't hesitate to critique my approach and patch.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16021

From duke at openjdk.org  Fri Apr 19 18:11:08 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 19 Apr 2024 18:11:08 GMT
Subject: Withdrawn: 8326617: String Template FMT removes unnecessary int to
 long type cast
In-Reply-To: <OVHqFGT9bzKfyJvEa7YwuLmZwRWMBOKrpJbUjR9cPNQ=.c71d50a1-8b3d-4a6d-a169-2929d35309f5@github.com>
References: <OVHqFGT9bzKfyJvEa7YwuLmZwRWMBOKrpJbUjR9cPNQ=.c71d50a1-8b3d-4a6d-a169-2929d35309f5@github.com>
Message-ID: <0hjo490vQOiwB_sgBGGFF5GLOFnu5t3W2fx5ggFWnTY=.551ff55c-7969-4352-be68-b381b87e0548@github.com>

On Mon, 2 Oct 2023 23:05:29 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In the current version, FMT."v =%d{1}" will call the StringConcatHelper.prepend(long/byte[]/long) method, which should behave the same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int), should not convert int to long
> 
> Please review and don't hesitate to critique my approach and patch.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16017

From mik3hall at gmail.com  Fri Apr 19 18:13:48 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 19 Apr 2024 13:13:48 -0500
Subject: Integrated: 8295111: dpkg appears to have problems resolving
 symbolically linked native libraries
In-Reply-To: <x0179lJHCGfQ3XrNpQ-yEgO0jZScVWwrfrHLyeqM9GI=.d5cdf25f-2493-4126-be9a-d46c40add14f@github.com>
References: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>
 <x0179lJHCGfQ3XrNpQ-yEgO0jZScVWwrfrHLyeqM9GI=.d5cdf25f-2493-4126-be9a-d46c40add14f@github.com>
Message-ID: <3D9EEBDB-3CBE-4A01-8509-313BE57DC437@gmail.com>

I don?t know what flavors you are looking to support but there seems to be somewhat different issues on a Raspberry Pi. I was just trying to use jpackage there.

I am getting errors like the command

dpkg -S /lib/aarch64-linux-gnu/libXau.so <http://libxau.so/>.6 
The file isn?t found

These actually appear to have entries in

/usr/lib/aarch64-linux-gnu

Which in turn appear to be symbolic links like?

/usr/lib/aarch64-linux-gnu/libXau.so <http://libxau.so/>.6 -> libXau.so <http://libxau.so/>.6.0.0

I am thinking I could try making symbolic links as a workaround myself.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/9a54a55a/attachment.htm>

From kvn at openjdk.org  Fri Apr 19 18:17:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 19 Apr 2024 18:17:01 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <JfR0MnyCHELyxLLQJmDRIr0zhFdcSjvTs4sBuC6KUxI=.25a7e4fd-a696-4c1a-b22c-1110291dc494@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
 <JfR0MnyCHELyxLLQJmDRIr0zhFdcSjvTs4sBuC6KUxI=.25a7e4fd-a696-4c1a-b22c-1110291dc494@github.com>
Message-ID: <6BzGvaMr42tgUlEeHinsh7jGrvjBMIuNFijfMWhOSI0=.c65b5638-e247-4b09-9b63-1bf377668947@github.com>

On Fri, 19 Apr 2024 15:43:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add enter() and leave(); remove Windows-specific register stuff
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4013:
> 
>> 4011:   // Initialize table for unsafe copy memeory check.
>> 4012:   if (UnsafeMemoryAccess::_table == nullptr) {
>> 4013:     UnsafeMemoryAccess::create_table(26);
> 
> How did you arrive at a table size of 26?

This needs comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572744077

From kvn at openjdk.org  Fri Apr 19 18:28:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 19 Apr 2024 18:28:01 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]
In-Reply-To: <QbEDTfAKut-P9Efx4Xd2JzR0ljYxsqXTABO822bpBCM=.5f269ba6-b40b-4a0a-a851-90201dac7d01@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <QbEDTfAKut-P9Efx4Xd2JzR0ljYxsqXTABO822bpBCM=.5f269ba6-b40b-4a0a-a851-90201dac7d01@github.com>
Message-ID: <W66aJDkjey9ba_mYxAg2Fs_tlEH9o3JaDnEbHbJ04So=.a0188eaa-eb75-43ed-a554-cb0d754c4a8e@github.com>

On Fri, 19 Apr 2024 16:25:28 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments; update copyright years

General comment/suggestion before I dive into review.
Can we do renaming `UnsafeCopyMemory*` -> `UnsafeMemory*` in follow up RFE. This change hides the real change.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 8336:

> 8334:     // Initialize table for copy memory (arraycopy) check.
> 8335:     if (UnsafeMemoryAccess::_table == nullptr) {
> 8336:       UnsafeMemoryAccess::create_table(18);

Needs comment explaining 18 number

src/hotspot/share/utilities/copy.hpp line 303:

> 301:   inline static void shared_disjoint_words_atomic(const HeapWord* from,
> 302:                                                   HeapWord* to, size_t count) {
> 303: 

I don't think this justify to change the file.

-------------

Changes requested by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-2012077574
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572750449
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572746349

From jjg at openjdk.org  Fri Apr 19 19:10:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:10:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <ed4aAlPaZnpFM_HVp75esTjXxSCzwKem2HqiWHPwcvM=.8264f272-6ffe-453f-940c-f0db3225adb1@github.com>

On Fri, 19 Apr 2024 10:53:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> src/java.base/macosx/classes/apple/security/AppleProvider.java line 33:
> 
>> 31: /*
>> 32:  * The Apple Security Provider.
>> 33:  */
> 
> Does it make sense to incorporate this comment into the following javadoc comment?
> 
> 
> /**
>  * Defines the (an) Apple security provider.
>  * ...
>  */
> @SuppressWarnings("serial") // JDK implementation class

Maybe, but only maybe, and if so, it would be out of scope for this work. That would be up to the relevant component team.

That being said, neither comment is part of any public API, and this comment is effectively already present in the first sentence of the actual doc comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572813320

From jjg at openjdk.org  Fri Apr 19 19:14:59 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:14:59 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <EyFdhhhVPa0ZjxN9MNwl--5bvRDGYrZJR8miOOgOBZ0=.513db9e4-6a6f-49b2-a0c8-3baa05cf5cf0@github.com>

On Fri, 19 Apr 2024 10:44:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 37:
> 
>> 35: import static sun.security.util.SecurityProviderConstants.*;
>> 36: 
>> 37: /*
> 
> Should this be included in the main javadoc comment? The `@author` tags belong in the javadoc comment.
> 
> The javadoc itself is likely unreadable, when processed the entire comment becomes one very long paragraph.

That would be up to the relevant component to decide how to improve these comments. The goal here is proactively fix any warnings that may be generated about multiple doc comments on a declaration.

I note that neither comment contributes to the public API, and that `@author` tags are generally obsolete these days. The VCS metadata is a more accurate reflection of individual contributions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572818078

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

> It is somewhat off-topic. Yet I noticed javadoc comments in some files are followed a blank line, and others aren't. Out of my curiosity, is there a convention about the blank line between the javadoc comment and the class or interface declaration? Should there be one?
> 
> ```java
> /**
>  * This is a class.
>  */
> public class A {}
> ```
> 
> or
> 
> ```java
> /**
>  * This is a class.
>  */
> 
> public class A {}
> ```
> 
> Which is the most common? Which is preferred?

We do not have an overall style guide.   The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067156407

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <plSw9jOH-0xxK5ZFqpYVa_RdLe0jGTIrrmOije3GV2c=.8c3f6569-fdfb-4fe8-b501-78f5da7fdf74@github.com>

On Fri, 19 Apr 2024 10:49:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>>   
>>   Fix grammatical typo
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 38:
> 
>> 36: 
>> 37: /**
>> 38:  * Open an file input stream given a URL.
> 
> Suggestion:
> 
>  * Open a file input stream given a URL.

OK, I'll accept this as a minor typo mixup, that does not in itself need a CSR. But generally, it is not a goal to fix issues in the content of doc comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572821973

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
  
  Fix grammatical typo
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18846/files
  - new: https://git.openjdk.org/jdk/pull/18846/files/fcbe02d5..d7b46a85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18846&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18846&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18846/head:pull/18846

PR: https://git.openjdk.org/jdk/pull/18846

From jjg at openjdk.org  Fri Apr 19 19:27:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:27:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>
Message-ID: <-fG_aheP9IBZLBq6GVU_1peVxqhpa7cQB0cpYK7cdDY=.b81305e0-56d5-4df2-9ac2-ca73e6433177@github.com>

On Fri, 19 Apr 2024 11:32:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This comment is not a review. I simply use the opportunity provided by this PR to suggest that we stop making new `/** ... */` and separately fix old jtreg comments like this:
> 
> ```
> /**
>  * @test TestSmallHeap
>  * @bug 8067438 8152239
>  * @summary Verify that starting the VM with a small heap works
>  * @library /test/lib
>  * @modules java.base/jdk.internal.misc
>  * @build jdk.test.whitebox.WhiteBox
>  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>  * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI     gc.TestSmallHeap
>  */
> ```
> 
> I know that those comments only appear in tests, and that tests are never documented. Still, it is confusing to see such comments and IDEs might frown upon them too. Generally, it is a good rule of thumb that `/** ... */` should be reserved only for javadoc.

I agree we should not be using `/**` for test description comments.
IntelliJ tells me there are 103+ matches in 97+ files, so this would be a non-trivial cleanup. 
I note there are 22 issues in `test/langtools/jdk` tests (i.e. javadoc tests), so let's start there ;-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067164929

From aivanov at openjdk.org  Fri Apr 19 19:32:57 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 19:32:57 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <Lq-Q7ZUwaTVlfO51UDbEwlePabsWtebfX4r-DIObVwU=.fd2569b7-0595-4661-a841-aa890b9c3daa@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2012219677

From aivanov at openjdk.org  Fri Apr 19 19:32:58 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 19:32:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
Message-ID: <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>

On Fri, 19 Apr 2024 19:18:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> We do not have an overall style guide. The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.

That's what I do.

I saw either style used in JDK. Yet I didn't check which style is more common? to decide which style I should use when creating new files with javadoc comments. [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) doesn't have a blank line between the javadoc comment and class declaration; nor do javadoc comments for fields and methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067169319

From szaldana at openjdk.org  Fri Apr 19 19:34:13 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Fri, 19 Apr 2024 19:34:13 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v2]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <Z4M6XZ9Bj-xSRdD_-Hreu_uFuiLpQGeQ1tWeV_1-nXM=.83f12587-5c48-46a1-8e19-d12aa645acfc@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with three additional commits since the last revision:

 - Adding test case
 - Removing the need to call mainType method and adding static fields to java launcher
 - Removing CHECK_EXCEPTION_FAIL in favour of CHECK_EXCEPTION_LEAVE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/2ed5a93b..97a5f53f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=00-01

  Stats: 289 lines in 3 files changed: 188 ins; 41 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/18786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786

PR: https://git.openjdk.org/jdk/pull/18786

From szaldana at openjdk.org  Fri Apr 19 19:34:13 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Fri, 19 Apr 2024 19:34:13 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <W1aVeeTd_537B_V5Po2SJZ1Acl3TxF6r86jW4aGs96g=.bf01c808-2970-4fdf-9741-214eb6bc5431@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

I made the updates based on feedback. Just a few things to note: 

* I included the test case from https://github.com/openjdk/jdk/pull/18753 and verified it passes with this PR.  
* Replacing ```CHECK_EXCEPTION_FAIL``` with ```CHECK_EXCEPTION_LEAVE``` looks a bit similar to my original proposed change. Calling ```CHECK_EXCEPTION_LEAVE``` directly in the JavaMain function causes the function to return early, whereas calling it inside the helpers (invokeStatic?) doesn?t quite have the same effect so I need to catch the result and then return.  

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2067171396

From szaldana at openjdk.org  Fri Apr 19 19:39:09 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Fri, 19 Apr 2024 19:39:09 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v3]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <PlXx7PbugqeUyTpSkSJRLmSLRSDUeXdrMSMjjB90JxI=.3be92706-6b4b-41bd-a859-8c5579212bed@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:

  Fixing space formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/97a5f53f..79c70343

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786

PR: https://git.openjdk.org/jdk/pull/18786

From naoto at openjdk.org  Fri Apr 19 19:51:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Apr 2024 19:51:06 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Unless it is absolutely necessary, I would not fix comments in `jdk.internal.icu` sources, as they are in the upstream code, and would like to minimize the merging effort.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067190364

From sgibbons at openjdk.org  Fri Apr 19 20:13:03 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 20:13:03 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <jn4GRdVc97_RFzrGKbDHE7lzgtNdEUAVccZWF9KkHoM=.c92a1950-57ae-4e63-a4c5-ca581a6e4760@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/dccf6b6c..dd0094ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=21-22

  Stats: 175 lines in 21 files changed: 4 ins; 5 del; 166 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Fri Apr 19 20:13:05 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 20:13:05 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]
In-Reply-To: <W66aJDkjey9ba_mYxAg2Fs_tlEH9o3JaDnEbHbJ04So=.a0188eaa-eb75-43ed-a554-cb0d754c4a8e@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <QbEDTfAKut-P9Efx4Xd2JzR0ljYxsqXTABO822bpBCM=.5f269ba6-b40b-4a0a-a851-90201dac7d01@github.com>
 <W66aJDkjey9ba_mYxAg2Fs_tlEH9o3JaDnEbHbJ04So=.a0188eaa-eb75-43ed-a554-cb0d754c4a8e@github.com>
Message-ID: <Xw9i3nhKeOhXHaDdr4kfKnAA_-TvCJzCoJgGgz9np54=.6523b6b4-d21e-4f3a-98ff-994bca3b5b29@github.com>

On Fri, 19 Apr 2024 18:25:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments; update copyright years
>
> General comment/suggestion before I dive into review.
> Can we do renaming `UnsafeCopyMemory*` -> `UnsafeMemory*` in follow up RFE. This change hides the real change.

@vnkozlov I un-did the name change and will submit a separate request for re-naming.  Thanks.

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 8336:
> 
>> 8334:     // Initialize table for copy memory (arraycopy) check.
>> 8335:     if (UnsafeMemoryAccess::_table == nullptr) {
>> 8336:       UnsafeMemoryAccess::create_table(18);
> 
> Needs comment explaining 18 number

Hmmm...  There was no comment explaining the 8 number :-).  I added 10 to the table size because I knew I was going to add 7 places where a mark was required.  I left 3 for safety.

The algorithm has since changed, so I changed this to:

`UnsafeCopyMemory::create_table(8 + 4); // 8 for copyMemory; 4 for setMemory`

I did a similar change to all other table creation numbers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2067197605
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572840222

From sgibbons at openjdk.org  Fri Apr 19 20:13:05 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 20:13:05 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <6BzGvaMr42tgUlEeHinsh7jGrvjBMIuNFijfMWhOSI0=.c65b5638-e247-4b09-9b63-1bf377668947@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
 <JfR0MnyCHELyxLLQJmDRIr0zhFdcSjvTs4sBuC6KUxI=.25a7e4fd-a696-4c1a-b22c-1110291dc494@github.com>
 <6BzGvaMr42tgUlEeHinsh7jGrvjBMIuNFijfMWhOSI0=.c65b5638-e247-4b09-9b63-1bf377668947@github.com>
Message-ID: <MFiypENkuCcBzSujTvoD19ey-BRpCP77wcAlQ0TrlOU=.931cfc14-f679-4cb3-84f2-823837e88ff6@github.com>

On Fri, 19 Apr 2024 18:14:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4013:
>> 
>>> 4011:   // Initialize table for unsafe copy memeory check.
>>> 4012:   if (UnsafeMemoryAccess::_table == nullptr) {
>>> 4013:     UnsafeMemoryAccess::create_table(26);
>> 
>> How did you arrive at a table size of 26?
>
> This needs comment

I added 10 to the table size because I knew I was going to add 7 places where a mark was required for setMemory.  I left 3 for safety.  The algorithm changed so only 4 are needed.

The algorithm has since changed, so I changed this to:

`UnsafeCopyMemory::create_table(16 + 4); // 16 for copyMemory; 4 for setMemory`

I did a similar change to all other table creation numbers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572841521

From sgibbons at openjdk.org  Fri Apr 19 20:13:06 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 20:13:06 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]
In-Reply-To: <1e63Ivvo2ZkyuP3U-RHrnZaUxv1PiKa2UnR5b2H9vpc=.290efaf8-6067-4e92-b7ae-932f6284b4cb@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <QbEDTfAKut-P9Efx4Xd2JzR0ljYxsqXTABO822bpBCM=.5f269ba6-b40b-4a0a-a851-90201dac7d01@github.com>
 <1e63Ivvo2ZkyuP3U-RHrnZaUxv1PiKa2UnR5b2H9vpc=.290efaf8-6067-4e92-b7ae-932f6284b4cb@github.com>
Message-ID: <dl6ELQZBJyuUioWahGqC0T0jaP6dyFud_Zml2cJ45xY=.49a3ccbe-c9bf-4751-858c-b106b519377b@github.com>

On Fri, 19 Apr 2024 17:42:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments; update copyright years
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2523:
> 
>> 2521:   // Number of (8*X)-byte chunks into rScratch1
>> 2522:   __ movq(tmp, size);
>> 2523:   __ shrq(tmp, 3);
> 
> `shr` [sets the zero flag][1], so I think you can just move the jump to after the shift and avoid a separate comparison
> 
> ```suggestion  
>   // Number of (8*X)-byte chunks into rScratch1
>   __ movq(tmp, size);
>   __ shrq(tmp, 3);
>   __ jccb(Assembler::zero, L_Tail);
> 
> 
> [1]: https://www.felixcloutier.com/x86/sal:sar:shl:shr#flags-affected

Good catch.  Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572794443

From sgibbons at openjdk.org  Fri Apr 19 20:13:07 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 20:13:07 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <JfR0MnyCHELyxLLQJmDRIr0zhFdcSjvTs4sBuC6KUxI=.25a7e4fd-a696-4c1a-b22c-1110291dc494@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
 <JfR0MnyCHELyxLLQJmDRIr0zhFdcSjvTs4sBuC6KUxI=.25a7e4fd-a696-4c1a-b22c-1110291dc494@github.com>
Message-ID: <L6rAA29stouwBq6S2wa7sCTDYdKqdkQ1Lfpq-jHjcI0=.2c57b223-b1e2-4574-83ae-135d09ff5892@github.com>

On Fri, 19 Apr 2024 15:50:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add enter() and leave(); remove Windows-specific register stuff
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2603:
> 
>> 2601:     const Register wide_value = rax;
>> 2602:     const Register rScratch1 = r10;
>> 2603: 
> 
> Maybe put an `assert_different_registers` here for the above registers, just to be sure. (I see you are avoiding the existing `rscratch1` already, because of a conflict with `c_rarg2`)

Done.

> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2674:
> 
>> 2672:     // Parameter order is (ptr, byteVal, size)
>> 2673:     __ xchgq(c_rarg1, c_rarg2);
>> 2674:     __ pop(rbp);    // Clear effect of enter()
> 
> Why not just use `leave()` here?

No special reason.  I've changed it since it seems to provide more clarity.

> src/hotspot/share/opto/library_call.cpp line 4959:
> 
>> 4957:   if (stopped())  return true;
>> 4958: 
>> 4959:   if (StubRoutines::unsafe_setmemory() == nullptr) return false;
> 
> I don't see why this check is needed here, since we already check whether the stub is there in `is_intrinsic_supported`.
> 
> Note that `inline_unsafe_copyMemory` also doesn't have this check. I think it would be good to keep consistency between the two.

Removed.

> src/hotspot/share/opto/runtime.cpp line 780:
> 
>> 778: const TypeFunc* OptoRuntime::make_setmemory_Type() {
>> 779:   // create input type (domain)
>> 780:   int num_args      = 4;
> 
> This variable seems redundant.

It is.  It is there due to copy/paste from the other 10 places that also have the same redundant variable declaration.  I've removed it from here, but I think I'll be asked to submit a separate PR if I remove it from the other locations.

Note that it's also redundant in `make_arraycopy_Type()`.

> src/hotspot/share/opto/runtime.cpp line 786:
> 
>> 784:   fields[argp++] = TypePtr::NOTNULL;    // dest
>> 785:   fields[argp++] = TypeLong::LONG;      // size
>> 786:   fields[argp++] = Type::HALF;          // size
> 
> Since the size is a `size_t`, I don't think this is correct on 32-bit platforms. I think here we want `TypeX_X`, and then add the extra `HALF` only on 64-bit platforms. Similar to what we do in `make_arraycopy_Type`: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/runtime.cpp#L799-L802
> 
> (Note that you will also have to adjust `argcnt` for this)

I don't understand this well enough to be confident in the change.  Can you please verify that I've changed it properly?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572797332
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572800059
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572804660
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572815040
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572823468

From sgibbons at openjdk.org  Fri Apr 19 20:13:08 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 20:13:08 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <W66aJDkjey9ba_mYxAg2Fs_tlEH9o3JaDnEbHbJ04So=.a0188eaa-eb75-43ed-a554-cb0d754c4a8e@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <QbEDTfAKut-P9Efx4Xd2JzR0ljYxsqXTABO822bpBCM=.5f269ba6-b40b-4a0a-a851-90201dac7d01@github.com>
 <W66aJDkjey9ba_mYxAg2Fs_tlEH9o3JaDnEbHbJ04So=.a0188eaa-eb75-43ed-a554-cb0d754c4a8e@github.com>
Message-ID: <2jYlnjJmp3oI89OC8iPF3UIFDeabAOAD51VhipzQDE8=.7d126e34-0c72-4e3e-8de4-957cd7f8dc8b@github.com>

On Fri, 19 Apr 2024 18:16:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add enter() and leave(); remove Windows-specific register stuff
>
> src/hotspot/share/utilities/copy.hpp line 303:
> 
>> 301:   inline static void shared_disjoint_words_atomic(const HeapWord* from,
>> 302:                                                   HeapWord* to, size_t count) {
>> 303:     switch (count) {
> 
> I don't think this justify to change the file.

Reverted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572824249

From jvernee at openjdk.org  Fri Apr 19 20:21:32 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 19 Apr 2024 20:21:32 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]
In-Reply-To: <L6rAA29stouwBq6S2wa7sCTDYdKqdkQ1Lfpq-jHjcI0=.2c57b223-b1e2-4574-83ae-135d09ff5892@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <LHGTUs6B8oBM7nZwoFSC7A-GHyDr3XAsuW4uGI3daDc=.5103f986-c8fc-4467-99af-5751ace07ef8@github.com>
 <JfR0MnyCHELyxLLQJmDRIr0zhFdcSjvTs4sBuC6KUxI=.25a7e4fd-a696-4c1a-b22c-1110291dc494@github.com>
 <L6rAA29stouwBq6S2wa7sCTDYdKqdkQ1Lfpq-jHjcI0=.2c57b223-b1e2-4574-83ae-135d09ff5892@github.com>
Message-ID: <CTqi_i0RsN25DMdQNA_WU_Fa5JR4AYKjOAjS7-TBEGI=.adaa9478-0c74-46d6-b00b-ef2980da04f3@github.com>

On Fri, 19 Apr 2024 19:18:13 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/share/opto/runtime.cpp line 786:
>> 
>>> 784:   fields[argp++] = TypePtr::NOTNULL;    // dest
>>> 785:   fields[argp++] = TypeLong::LONG;      // size
>>> 786:   fields[argp++] = Type::HALF;          // size
>> 
>> Since the size is a `size_t`, I don't think this is correct on 32-bit platforms. I think here we want `TypeX_X`, and then add the extra `HALF` only on 64-bit platforms. Similar to what we do in `make_arraycopy_Type`: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/runtime.cpp#L799-L802
>> 
>> (Note that you will also have to adjust `argcnt` for this)
>
> I don't understand this well enough to be confident in the change.  Can you please verify that I've changed it properly?

Your latest version looks good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572909435

From jjg at openjdk.org  Fri Apr 19 20:36:30 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 20:36:30 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
 <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>
Message-ID: <H9YDeHC1vbzTbg9fB2HdGaLMDU1BuKqekRT-kLMyGKU=.2d7b6fc4-b059-4944-89b3-67004dac6ea0@github.com>

On Fri, 19 Apr 2024 19:47:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Unless it is absolutely necessary, I would not fix comments in `jdk.internal.icu` sources, as they are in the upstream code, and would like to minimize the merging effort.

@naotoj Given the policy and strong desire to compile `java.base` with all lint warnings enabled and `-Werror`, all of the proposed changes in this PR will each individually break the build if/when the warning is added to `javac` and we continue to compile `java.base` with the current build settings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067246948

From naoto at openjdk.org  Fri Apr 19 20:40:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Apr 2024 20:40:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

OK, fair enough. Approving for the `icu` part

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2012372872

From lancea at openjdk.org  Fri Apr 19 20:48:36 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 19 Apr 2024 20:48:36 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v3]
In-Reply-To: <wlYQgLflc_7I-YGEweSqKNXQDUf-bDuCq_SdXXq0XT0=.1ac198be-3e7f-4b7c-a290-d46a8b1ee0fb@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <wlYQgLflc_7I-YGEweSqKNXQDUf-bDuCq_SdXXq0XT0=.1ac198be-3e7f-4b7c-a290-d46a8b1ee0fb@github.com>
Message-ID: <59xH2JBfcqMYYrwSrH9svvrlAPLEHFD3rsB7pjzBIEU=.31c651d5-a68c-4bce-b19c-eb5c13f4a0e0@github.com>

On Fri, 19 Apr 2024 17:39:30 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

src/java.xml/share/conf/jaxp-compat.properties line 12:

> 10: #
> 11: # jaxp-strict.properties: this file resembles what will become the Secure-By-Default
> 12: # configuration where a strict restriction is the default. This file allows

strict restriction needs rewording.

Perhaps something that indicates that this property file provides settings that will be equivalent to that will be the default JAXP settings in a future release to make the use of JAXP more secure out of the box

src/java.xml/share/conf/jaxp-compat.properties line 20:

> 18: # JDK has switched to a strict configuration as indicated in jaxp-strict.properties.
> 19: # This configuration contains the same properties as those in jaxp-strict.properties
> 20: # except it sets them back to the current status of the JDK. Note that, although

'....sets them back to the current status of the JDK'

I think you are trying to indicate that this property file specifies the JAXP property values that were in place prior to being More Secure?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1572927195
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1572940722

From davidalayachew at gmail.com  Fri Apr 19 21:02:12 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 19 Apr 2024 17:02:12 -0400
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>

No R?mi, I don't think your idea is the right approach. You are working on
the wrong level of abstraction.

Many users ask requests like this all the time, and what you are suggesting
would be even more error-prone than the equivalent for loop or the IntStream
suggestion that the user above requested. Not to mention that getting it to
parallelize would be a task many users are likely to mess up -- either in
correctness or in performance.

I think you would get far more mileage from adding 2 methods on the list
interface streamWithIndex() and parallelStreamWithIndex() that would return
a Stream<WithIndex<T>>, as opposed to just Stream<T>.

That way, users are not writing a custom Gatherer each time they want to
work with the index. They just have the index be a field in the object.
They can work with it the same way they would any other object field.

Furthermore, doing it this way makes the correct answer obvious. If I need
to do something with an index, stream with the index.

On top of that, it significantly enhances readability by making it clear to
the reader that, whatever this stream is doing will require use of the
index, so watch out for that.



On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr> wrote:

> Hello,
> for me, it seems what you want is  Collector on Stream which is able to
> short-circuit,
> so you can write
>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
> and in reverse
>   list.reversed().stream().collect(Collectors.findFirst(s ->
> s.contains("o")))
>
> Using a Stream here is more general and will work with other collections
> like a LinkedHashSet for example.
> Sadly, there is no way to define a short-circuiting collector :(
>
> You can have a short-circuiting Gatherer like this
>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
>     return Gatherer.ofSequential(
>       () -> new Object() { int index; },
>       Integrtor.ofGreedy((state, element, downstream) -> {
>         var index = state.index++;
>         if (predicate.test(element)) {
>           return downstream.push(index);
>         }
>         return true;
>       }));
>   }
>
> and use it like this:
>   list.stream().gather(findIndex(s ->
> s.contains("o"))).findFirst().orElse(-1);
>
> But it's more verbose.
>
> I wonder if at the same time that the Gatherer API is introduced, the
> Collector API should be enhanced to support short-circuiting collectors ?
>
> regards,
> R?mi
>
>
> ------------------------------
>
> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Friday, April 19, 2024 5:59:39 PM
> *Subject: *Addition of Predicate-based findIndex and findLastIndex
> methods to java.util.List
>
> Subject
> Addition of Predicate-based findIndex and findLastIndex methods to
> java.util.List
>
> Motivation
> The motivation behind this proposal is to enhance the functionality of the
> List interface by providing a more flexible way to find the index of an
> element. Currently, the indexOf and lastIndexOf methods only accept an
> object as a parameter. This limits the flexibility of these methods as they
> can only find the index of exact object matches.
>
> Here I want to propose methods that would accept a Predicate as a
> parameter, allowing users to define a condition that the desired element
> must meet. This would provide a more flexible and powerful way to find the
> index of an element in a list.
>
> The changes I am proposing are implemented in this PR:
> https://github.com/openjdk/jdk/pull/18639. Here is a brief overview of
> the changes made in this pull request:
>
> Added the findIndex  (Predicate<? super E> filter) method to the List
> interface.
> Added the findLastIndex  (Predicate<? super E> filter) method to the List
> interface.
> Implemented these methods in all non-abstract classes that implement the
> List interface, as well as List itself (default impl).
> The changes have been thoroughly tested to ensure they work as expected
> and do not introduce any regressions. The test cases cover a variety of
> scenarios to ensure the robustness of the implementation.
>
> For example, consider the following test case:
>
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
>
> int index1 = list.findIndex(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> Currently, to achieve the same result, we would have to use a more verbose
> approach:
>
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> Or other approaches that require additional instructions and, therefore,
> can`t be used in all scopes (like passing argument to method).
>
> I believe these additions would greatly enhance the functionality and
> flexibility of the List interface, making it more powerful and
> user-friendly. I look forward to your feedback and am open to making any
> necessary changes based on your suggestions.
>
> The main reason I am publishing this proposal in the mailing system is to
> gather feedback from the Java developers community, especially about
> possible caveats related to backward compatibility of your projects. Would
> appreciate every opinion!
>
> Best regards
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/22cc2a5a/attachment-0001.htm>

From jjg at openjdk.org  Fri Apr 19 21:07:02 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 21:07:02 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
 <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>
Message-ID: <7LlnKXolx2fp1kJEq5_UYjcC-q0Y8AF2hidczf7kPl8=.bcfb39c9-9992-44ee-9cec-8bfcda42dd9b@github.com>

On Fri, 19 Apr 2024 20:38:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> OK, fair enough. Approving for the `icu` part

Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067280359

From kvn at openjdk.org  Fri Apr 19 21:11:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 19 Apr 2024 21:11:00 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]
In-Reply-To: <jn4GRdVc97_RFzrGKbDHE7lzgtNdEUAVccZWF9KkHoM=.c92a1950-57ae-4e63-a4c5-ca581a6e4760@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <jn4GRdVc97_RFzrGKbDHE7lzgtNdEUAVccZWF9KkHoM=.c92a1950-57ae-4e63-a4c5-ca581a6e4760@github.com>
Message-ID: <VNDzNOk6Ka18qVLRglBThSjznSDj93rJebbCFMAffUs=.b41da967-2964-4a7e-b7a0-231bd4ef5267@github.com>

On Fri, 19 Apr 2024 20:13:03 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

This looks good. I only have question about long vs short jumps in stub's code.

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2550:

> 2548: 
> 2549:   // If zero, then we're done
> 2550:   __ jccb(Assembler::zero, L_exit);

Code in `generate_unsafe_setmemory()` uses long jumps to `L_exit` but here you use short. Why?

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2638:

> 2636:                                L_exit, _masm);
> 2637:     }
> 2638:     __ jmp(L_exit);

Here is long jump to `L_exit` after `do_setmemory_atomic_loop()` call. Should this be also short jump?

src/hotspot/share/opto/runtime.cpp line 785:

> 783:   fields[argp++] = TypePtr::NOTNULL;        // dest
> 784:   fields[argp++] = TypeX_X;                 // size
> 785:   LP64_ONLY(fields[argp++] = Type::HALF);  // size

Nit: align `/`

src/hotspot/share/utilities/copy.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved.

You forgot to undo year change in this file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-2012400269
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572947954
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572948693
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572955327
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572960023

From kvn at openjdk.org  Fri Apr 19 21:11:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 19 Apr 2024 21:11:00 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]
In-Reply-To: <VNDzNOk6Ka18qVLRglBThSjznSDj93rJebbCFMAffUs=.b41da967-2964-4a7e-b7a0-231bd4ef5267@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <jn4GRdVc97_RFzrGKbDHE7lzgtNdEUAVccZWF9KkHoM=.c92a1950-57ae-4e63-a4c5-ca581a6e4760@github.com>
 <VNDzNOk6Ka18qVLRglBThSjznSDj93rJebbCFMAffUs=.b41da967-2964-4a7e-b7a0-231bd4ef5267@github.com>
Message-ID: <5qkCM1RfvInEvp3ipImOqWXV7Cdg97BUCApATuR2KnI=.30f00efc-d8cd-4abe-9107-bdfa84df9165@github.com>

On Fri, 19 Apr 2024 20:54:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2638:
> 
>> 2636:                                L_exit, _masm);
>> 2637:     }
>> 2638:     __ jmp(L_exit);
> 
> Here is long jump to `L_exit` after `do_setmemory_atomic_loop()` call. Should this be also short jump?

Do we have additional code in debug VM wihch increase distance and requires long jump? I don't see it. Usually it something which call `__ STOP()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1572951726

From davidalayachew at gmail.com  Fri Apr 19 21:11:47 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 19 Apr 2024 17:11:47 -0400
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
Message-ID: <CAA9v-_OJpoiXGzwB-q8y7MdJVhzh7q6qBLYBapX_-krk=JT5SA@mail.gmail.com>

Hello

Thanks for sending this email. Your idea makes a lot of sense, but I feel
that it only serves a very specific use case. That does not make it bad,
but it does make it narrow.

I already suggested my idea in my email to R?mi, where the index is just
another field in the data type being streamed. Doing it this way, we can
not only cover your use case, but the use cases of many others. It has a
far wider reach for the same level of effort.

And finally, make it a point to send an email on the mailing list and
getting consensus BEFORE making a pull request. I am guilty of this too.
But going out of order like this slows down the system and forces reviewers
to take extra steps that they wouldn't have to if you had followed protocol.

On Fri, Apr 19, 2024 at 5:02?PM David Alayachew <davidalayachew at gmail.com>
wrote:

>
> No R?mi, I don't think your idea is the right approach. You are working on
> the wrong level of abstraction.
>
> Many users ask requests like this all the time, and what you are
> suggesting would be even more error-prone than the equivalent for loop or the
> IntStream suggestion that the user above requested. Not to mention that
> getting it to parallelize would be a task many users are likely to mess up
> -- either in correctness or in performance.
>
> I think you would get far more mileage from adding 2 methods on the list
> interface streamWithIndex() and parallelStreamWithIndex() that would return
> a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>
> That way, users are not writing a custom Gatherer each time they want to
> work with the index. They just have the index be a field in the object.
> They can work with it the same way they would any other object field.
>
> Furthermore, doing it this way makes the correct answer obvious. If I need
> to do something with an index, stream with the index.
>
> On top of that, it significantly enhances readability by making it clear
> to the reader that, whatever this stream is doing will require use of the
> index, so watch out for that.
>
>
>
> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hello,
>> for me, it seems what you want is  Collector on Stream which is able to
>> short-circuit,
>> so you can write
>>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
>> and in reverse
>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>> s.contains("o")))
>>
>> Using a Stream here is more general and will work with other collections
>> like a LinkedHashSet for example.
>> Sadly, there is no way to define a short-circuiting collector :(
>>
>> You can have a short-circuiting Gatherer like this
>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
>>     return Gatherer.ofSequential(
>>       () -> new Object() { int index; },
>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>         var index = state.index++;
>>         if (predicate.test(element)) {
>>           return downstream.push(index);
>>         }
>>         return true;
>>       }));
>>   }
>>
>> and use it like this:
>>   list.stream().gather(findIndex(s ->
>> s.contains("o"))).findFirst().orElse(-1);
>>
>> But it's more verbose.
>>
>> I wonder if at the same time that the Gatherer API is introduced, the
>> Collector API should be enhanced to support short-circuiting collectors ?
>>
>> regards,
>> R?mi
>>
>>
>> ------------------------------
>>
>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>> *Subject: *Addition of Predicate-based findIndex and findLastIndex
>> methods to java.util.List
>>
>> Subject
>> Addition of Predicate-based findIndex and findLastIndex methods to
>> java.util.List
>>
>> Motivation
>> The motivation behind this proposal is to enhance the functionality of
>> the List interface by providing a more flexible way to find the index of an
>> element. Currently, the indexOf and lastIndexOf methods only accept an
>> object as a parameter. This limits the flexibility of these methods as they
>> can only find the index of exact object matches.
>>
>> Here I want to propose methods that would accept a Predicate as a
>> parameter, allowing users to define a condition that the desired element
>> must meet. This would provide a more flexible and powerful way to find the
>> index of an element in a list.
>>
>> The changes I am proposing are implemented in this PR:
>> https://github.com/openjdk/jdk/pull/18639. Here is a brief overview of
>> the changes made in this pull request:
>>
>> Added the findIndex  (Predicate<? super E> filter) method to the List
>> interface.
>> Added the findLastIndex  (Predicate<? super E> filter) method to the List
>> interface.
>> Implemented these methods in all non-abstract classes that implement the
>> List interface, as well as List itself (default impl).
>> The changes have been thoroughly tested to ensure they work as expected
>> and do not introduce any regressions. The test cases cover a variety of
>> scenarios to ensure the robustness of the implementation.
>>
>> For example, consider the following test case:
>>
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>>
>> int index1 = list.findIndex(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> Currently, to achieve the same result, we would have to use a more
>> verbose approach:
>>
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> Or other approaches that require additional instructions and, therefore,
>> can`t be used in all scopes (like passing argument to method).
>>
>> I believe these additions would greatly enhance the functionality and
>> flexibility of the List interface, making it more powerful and
>> user-friendly. I look forward to your feedback and am open to making any
>> necessary changes based on your suggestions.
>>
>> The main reason I am publishing this proposal in the mailing system is to
>> gather feedback from the Java developers community, especially about
>> possible caveats related to backward compatibility of your projects. Would
>> appreciate every opinion!
>>
>> Best regards
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/5c6d1dc5/attachment-0001.htm>

From rotan.olexandr at gmail.com  Fri Apr 19 21:16:20 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 00:16:20 +0300
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAA9v-_OJpoiXGzwB-q8y7MdJVhzh7q6qBLYBapX_-krk=JT5SA@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAA9v-_OJpoiXGzwB-q8y7MdJVhzh7q6qBLYBapX_-krk=JT5SA@mail.gmail.com>
Message-ID: <CAP=Y=q8J3mdufCiq=EdQUpirRBo=_cjU486_RhN=T5GLc3OjVw@mail.gmail.com>

Thanks for the advice. Indeed, it was a mistake to implement this before
discussing it in mail. This is my first open-source experience, so i guess
this will be a valuable experience for my future contributions

??, 20 ???. 2024??. ? 00:12, David Alayachew <davidalayachew at gmail.com>:

> Hello
>
> Thanks for sending this email. Your idea makes a lot of sense, but I feel
> that it only serves a very specific use case. That does not make it bad,
> but it does make it narrow.
>
> I already suggested my idea in my email to R?mi, where the index is just
> another field in the data type being streamed. Doing it this way, we can
> not only cover your use case, but the use cases of many others. It has a
> far wider reach for the same level of effort.
>
> And finally, make it a point to send an email on the mailing list and
> getting consensus BEFORE making a pull request. I am guilty of this too.
> But going out of order like this slows down the system and forces reviewers
> to take extra steps that they wouldn't have to if you had followed protocol.
>
> On Fri, Apr 19, 2024 at 5:02?PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>>
>> No R?mi, I don't think your idea is the right approach. You are working
>> on the wrong level of abstraction.
>>
>> Many users ask requests like this all the time, and what you are
>> suggesting would be even more error-prone than the equivalent for loop or the
>> IntStream suggestion that the user above requested. Not to mention that
>> getting it to parallelize would be a task many users are likely to mess up
>> -- either in correctness or in performance.
>>
>> I think you would get far more mileage from adding 2 methods on the list
>> interface streamWithIndex() and parallelStreamWithIndex() that would return
>> a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>
>> That way, users are not writing a custom Gatherer each time they want to
>> work with the index. They just have the index be a field in the object.
>> They can work with it the same way they would any other object field.
>>
>> Furthermore, doing it this way makes the correct answer obvious. If I
>> need to do something with an index, stream with the index.
>>
>> On top of that, it significantly enhances readability by making it clear
>> to the reader that, whatever this stream is doing will require use of the
>> index, so watch out for that.
>>
>>
>>
>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>> Hello,
>>> for me, it seems what you want is  Collector on Stream which is able to
>>> short-circuit,
>>> so you can write
>>>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
>>> and in reverse
>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>> s.contains("o")))
>>>
>>> Using a Stream here is more general and will work with other collections
>>> like a LinkedHashSet for example.
>>> Sadly, there is no way to define a short-circuiting collector :(
>>>
>>> You can have a short-circuiting Gatherer like this
>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
>>>     return Gatherer.ofSequential(
>>>       () -> new Object() { int index; },
>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>         var index = state.index++;
>>>         if (predicate.test(element)) {
>>>           return downstream.push(index);
>>>         }
>>>         return true;
>>>       }));
>>>   }
>>>
>>> and use it like this:
>>>   list.stream().gather(findIndex(s ->
>>> s.contains("o"))).findFirst().orElse(-1);
>>>
>>> But it's more verbose.
>>>
>>> I wonder if at the same time that the Gatherer API is introduced, the
>>> Collector API should be enhanced to support short-circuiting collectors ?
>>>
>>> regards,
>>> R?mi
>>>
>>>
>>> ------------------------------
>>>
>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>> *Subject: *Addition of Predicate-based findIndex and findLastIndex
>>> methods to java.util.List
>>>
>>> Subject
>>> Addition of Predicate-based findIndex and findLastIndex methods to
>>> java.util.List
>>>
>>> Motivation
>>> The motivation behind this proposal is to enhance the functionality of
>>> the List interface by providing a more flexible way to find the index of an
>>> element. Currently, the indexOf and lastIndexOf methods only accept an
>>> object as a parameter. This limits the flexibility of these methods as they
>>> can only find the index of exact object matches.
>>>
>>> Here I want to propose methods that would accept a Predicate as a
>>> parameter, allowing users to define a condition that the desired element
>>> must meet. This would provide a more flexible and powerful way to find the
>>> index of an element in a list.
>>>
>>> The changes I am proposing are implemented in this PR:
>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief overview of
>>> the changes made in this pull request:
>>>
>>> Added the findIndex  (Predicate<? super E> filter) method to the List
>>> interface.
>>> Added the findLastIndex  (Predicate<? super E> filter) method to the
>>> List interface.
>>> Implemented these methods in all non-abstract classes that implement the
>>> List interface, as well as List itself (default impl).
>>> The changes have been thoroughly tested to ensure they work as expected
>>> and do not introduce any regressions. The test cases cover a variety of
>>> scenarios to ensure the robustness of the implementation.
>>>
>>> For example, consider the following test case:
>>>
>>> List<String> list = new ArrayList<>();
>>> list.add("Object one");
>>> list.add("NotObject two");
>>> list.add("NotObject three");
>>>
>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>> System.out.println(index1); // Expected output: 1
>>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>>> System.out.println(index2); // Expected output: 2
>>> Currently, to achieve the same result, we would have to use a more
>>> verbose approach:
>>>
>>> int index1 = IntStream.range(0, list.size())
>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>                      .findFirst()
>>>                      .orElse(-1);
>>> System.out.println(index1); // Output: 1
>>> int index2 = IntStream.range(0, list.size())
>>>                          .filter(i ->
>>> list.get(i).startsWith("NotObject"))
>>>                          .reduce((first, second) -> second)
>>>                          .orElse(-1);
>>> System.out.println(index2); // Output: 2
>>> Or other approaches that require additional instructions and, therefore,
>>> can`t be used in all scopes (like passing argument to method).
>>>
>>> I believe these additions would greatly enhance the functionality and
>>> flexibility of the List interface, making it more powerful and
>>> user-friendly. I look forward to your feedback and am open to making any
>>> necessary changes based on your suggestions.
>>>
>>> The main reason I am publishing this proposal in the mailing system is
>>> to gather feedback from the Java developers community, especially about
>>> possible caveats related to backward compatibility of your projects. Would
>>> appreciate every opinion!
>>>
>>> Best regards
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/f4133e53/attachment.htm>

From davidalayachew at gmail.com  Fri Apr 19 21:31:42 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 19 Apr 2024 17:31:42 -0400
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
Message-ID: <CAA9v-_NptwV4UNo9V1YDB=1os5BViPgYkMkDXJWRgGZis6UdYw@mail.gmail.com>

It is not the goal of Java to be verbose, but it is also not the goal of
Java to be concise either. It is the goal of Java to be clear, correct, and
readable, in order to maximize maintainability, correctness, and
flexibility. When you focus on accomplishing that goal first, you will find
that conciseness takes care of itself.

I understand that my approach is wordier than yours. Please also consider
that my suggestion does exactly one task -- stream an element with its
respective index. And yet, the number of ways that that can be used covers
hundreds of use cases while still being incredibly easy to maintain and
optimize. Far more than what you suggest. My feature easily composes with
others, with anything that can take a Stream<T> in fact.

The bar to adding a feature to Java, even to its libraries, is high. In
fact, there is even a breaking point where a language/library can just be
too dense to work with. Too many methods, too much complexity.

Java makes it a priority to limit adding features or functionality wherever
possible, only relenting when the benefit significantly outweighs the cost.
Adding a method like yours that only serves a tiny slice of use cases just
does not meet the goal of what Java is aiming for -- to get the biggest
bang for buck when adding a feature to language/library.

I think that your pain point is significant and worth addressing. But I
think it should be done in a way that services a much larger group of users
and use cases. I think my idea does that.

On Fri, Apr 19, 2024 at 5:14?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> streamWithIndex() is indeed an interesting approach, however, working with
> pairs of values is not always comfortable as this may make code too wordy,
> which may be fixed using things like properties and tuples (which I am
> currently working on right now btw), but still code like
> list.streamWithIndex().filter(Predicate).findFirst().orElse(-1) is still
> long, thats why i think there is room for both in Java.
>
> Also maybe instead of returning traditional -1 it would be more
> suitable to use OptionalInt instead, but I would like to hear community
> opinion about that.
>
> ??, 20 ???. 2024??. ? 00:02, David Alayachew <davidalayachew at gmail.com>:
>
>>
>> No R?mi, I don't think your idea is the right approach. You are working
>> on the wrong level of abstraction.
>>
>> Many users ask requests like this all the time, and what you are
>> suggesting would be even more error-prone than the equivalent for loop or the
>> IntStream suggestion that the user above requested. Not to mention that
>> getting it to parallelize would be a task many users are likely to mess up
>> -- either in correctness or in performance.
>>
>> I think you would get far more mileage from adding 2 methods on the list
>> interface streamWithIndex() and parallelStreamWithIndex() that would return
>> a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>
>> That way, users are not writing a custom Gatherer each time they want to
>> work with the index. They just have the index be a field in the object.
>> They can work with it the same way they would any other object field.
>>
>> Furthermore, doing it this way makes the correct answer obvious. If I
>> need to do something with an index, stream with the index.
>>
>> On top of that, it significantly enhances readability by making it clear
>> to the reader that, whatever this stream is doing will require use of the
>> index, so watch out for that.
>>
>>
>>
>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>> Hello,
>>> for me, it seems what you want is  Collector on Stream which is able to
>>> short-circuit,
>>> so you can write
>>>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
>>> and in reverse
>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>> s.contains("o")))
>>>
>>> Using a Stream here is more general and will work with other collections
>>> like a LinkedHashSet for example.
>>> Sadly, there is no way to define a short-circuiting collector :(
>>>
>>> You can have a short-circuiting Gatherer like this
>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
>>>     return Gatherer.ofSequential(
>>>       () -> new Object() { int index; },
>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>         var index = state.index++;
>>>         if (predicate.test(element)) {
>>>           return downstream.push(index);
>>>         }
>>>         return true;
>>>       }));
>>>   }
>>>
>>> and use it like this:
>>>   list.stream().gather(findIndex(s ->
>>> s.contains("o"))).findFirst().orElse(-1);
>>>
>>> But it's more verbose.
>>>
>>> I wonder if at the same time that the Gatherer API is introduced, the
>>> Collector API should be enhanced to support short-circuiting collectors ?
>>>
>>> regards,
>>> R?mi
>>>
>>>
>>> ------------------------------
>>>
>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>> *Subject: *Addition of Predicate-based findIndex and findLastIndex
>>> methods to java.util.List
>>>
>>> Subject
>>> Addition of Predicate-based findIndex and findLastIndex methods to
>>> java.util.List
>>>
>>> Motivation
>>> The motivation behind this proposal is to enhance the functionality of
>>> the List interface by providing a more flexible way to find the index of an
>>> element. Currently, the indexOf and lastIndexOf methods only accept an
>>> object as a parameter. This limits the flexibility of these methods as they
>>> can only find the index of exact object matches.
>>>
>>> Here I want to propose methods that would accept a Predicate as a
>>> parameter, allowing users to define a condition that the desired element
>>> must meet. This would provide a more flexible and powerful way to find the
>>> index of an element in a list.
>>>
>>> The changes I am proposing are implemented in this PR:
>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief overview of
>>> the changes made in this pull request:
>>>
>>> Added the findIndex  (Predicate<? super E> filter) method to the List
>>> interface.
>>> Added the findLastIndex  (Predicate<? super E> filter) method to the
>>> List interface.
>>> Implemented these methods in all non-abstract classes that implement the
>>> List interface, as well as List itself (default impl).
>>> The changes have been thoroughly tested to ensure they work as expected
>>> and do not introduce any regressions. The test cases cover a variety of
>>> scenarios to ensure the robustness of the implementation.
>>>
>>> For example, consider the following test case:
>>>
>>> List<String> list = new ArrayList<>();
>>> list.add("Object one");
>>> list.add("NotObject two");
>>> list.add("NotObject three");
>>>
>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>> System.out.println(index1); // Expected output: 1
>>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>>> System.out.println(index2); // Expected output: 2
>>> Currently, to achieve the same result, we would have to use a more
>>> verbose approach:
>>>
>>> int index1 = IntStream.range(0, list.size())
>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>                      .findFirst()
>>>                      .orElse(-1);
>>> System.out.println(index1); // Output: 1
>>> int index2 = IntStream.range(0, list.size())
>>>                          .filter(i ->
>>> list.get(i).startsWith("NotObject"))
>>>                          .reduce((first, second) -> second)
>>>                          .orElse(-1);
>>> System.out.println(index2); // Output: 2
>>> Or other approaches that require additional instructions and, therefore,
>>> can`t be used in all scopes (like passing argument to method).
>>>
>>> I believe these additions would greatly enhance the functionality and
>>> flexibility of the List interface, making it more powerful and
>>> user-friendly. I look forward to your feedback and am open to making any
>>> necessary changes based on your suggestions.
>>>
>>> The main reason I am publishing this proposal in the mailing system is
>>> to gather feedback from the Java developers community, especially about
>>> possible caveats related to backward compatibility of your projects. Would
>>> appreciate every opinion!
>>>
>>> Best regards
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/68b9a368/attachment-0001.htm>

From duke at openjdk.org  Fri Apr 19 21:39:32 2024
From: duke at openjdk.org (xxDark)
Date: Fri, 19 Apr 2024 21:39:32 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
Message-ID: <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>

On Fri, 19 Apr 2024 15:49:11 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted code style changes in Vector

I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067312328

From forax at univ-mlv.fr  Fri Apr 19 21:47:48 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 19 Apr 2024 23:47:48 +0200 (CEST)
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
Message-ID: <258411618.9149442.1713563268524.JavaMail.zimbra@univ-eiffel.fr>

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "??-24 ????????? ??????" <rotan.olexandr at gmail.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Friday, April 19, 2024 11:02:12 PM
> Subject: Re: Addition of Predicate-based findIndex and findLastIndex methods to
> java.util.List

> No R?mi, I don't think your idea is the right approach. You are working on the
> wrong level of abstraction.

Hello David, 

> Many users ask requests like this all the time, and what you are suggesting
> would be even more error-prone than the equivalent for loop or the IntStream
> suggestion that the user above requested.

Could you give an example of why it is more error prone ? 

> Not to mention that getting it to parallelize would be a task many users are
> likely to mess up -- either in correctness or in performance.

Correctness is not an issue athat's why i've used ofSequential() when creating the Gatherer. 
You are right that performance can be an issue, the Gatherer API is more limited compared to what a Spliterator can do. 

> I think you would get far more mileage from adding 2 methods on the list
> interface streamWithIndex() and parallelStreamWithIndex() that would return a
> Stream<WithIndex<T>>, as opposed to just Stream<T>.

Any stream can be "indexed", having an index is not an intrisinc property of a stream of List, so adding an index is more an intermediate operation than a source operation. 
So more like 
list.stream().withIndex() 
than like 
list.streamWithIndex() 

Now, we (the lambda-util expert group) talked 10 years ago to add such design but decide to postpone it because WithIndex<T> should be a value type and the Stream API should be specialized to avoid unecessary allocations. 
So you are right that withIndex() is a more general design but because of the performance issue we can not yet offer such design. 

As a counter argument, you can say that we have the same issue with the Collector API and the Gatherer API which are both not specialized but at least for a Collector, the fact that the accumulator does a side effect which is usualyl a write in memory is slow anyway. And this is also true for a Gatherer, it works well when the Gatherer is itself followed by a Collector. 

> That way, users are not writing a custom Gatherer each time they want to work
> with the index. They just have the index be a field in the object. They can
> work with it the same way they would any other object field.

This custom Gatherer can be declared in Gatherers (with an 's' at the end). 

> Furthermore, doing it this way makes the correct answer obvious. If I need to do
> something with an index, stream with the index.

Technically, here, you want the result to be an index, so you may not want to pay the price of creating an index (your WithIndex objetcs) for every elements but just one when the predicate is true. 
This point is moot if the WithIndex is a value type and Stream is a specialized generics but as I said above, where are not yet at that point. 

> On top of that, it significantly enhances readability by making it clear to the
> reader that, whatever this stream is doing will require use of the index, so
> watch out for that.

With your proposal, you still need to write something like 

list.withIndexStream().filter(withIndex -> predicate(withIndex.element())).mapToInt(WithIndex::index).findFirst().orElse(-1) 

I do not see the enhancement in readability. 

regards, 
R?mi 

> On Fri, Apr 19, 2024, 1:47 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> Hello,
>> for me, it seems what you want is Collector on Stream which is able to
>> short-circuit,
>> so you can write
>> list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
>> and in reverse
>> list.reversed().stream().collect(Collectors.findFirst(s -> s.contains("o")))

>> Using a Stream here is more general and will work with other collections like a
>> LinkedHashSet for example.
>> Sadly, there is no way to define a short-circuiting collector :(

>> You can have a short-circuiting Gatherer like this
>> <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
>> return Gatherer.ofSequential(
>> () -> new Object() { int index; },
>> Integrtor.ofGreedy((state, element, downstream) -> {
>> var index = state.index++;
>> if (predicate.test(element)) {
>> return downstream.push(index);
>> }
>> return true;
>> }));
>> }

>> and use it like this:
>> list.stream().gather(findIndex(s -> s.contains("o"))).findFirst().orElse(-1);

>> But it's more verbose.

>> I wonder if at the same time that the Gatherer API is introduced, the Collector
>> API should be enhanced to support short-circuiting collectors ?

>> regards,
>> R?mi

>>> From: "??-24 ????????? ??????" < [ mailto:rotan.olexandr at gmail.com |
>>> rotan.olexandr at gmail.com ] >
>>> To: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.org |
>>> core-libs-dev at openjdk.org ] >
>>> Sent: Friday, April 19, 2024 5:59:39 PM
>>> Subject: Addition of Predicate-based findIndex and findLastIndex methods to
>>> java.util.List

>>> Subject
>>> Addition of Predicate-based findIndex and findLastIndex methods to
>>> java.util.List

>>> Motivation
>>> The motivation behind this proposal is to enhance the functionality of the List
>>> interface by providing a more flexible way to find the index of an element.
>>> Currently, the indexOf and lastIndexOf methods only accept an object as a
>>> parameter. This limits the flexibility of these methods as they can only find
>>> the index of exact object matches.

>>> Here I want to propose methods that would accept a Predicate as a parameter,
>>> allowing users to define a condition that the desired element must meet. This
>>> would provide a more flexible and powerful way to find the index of an element
>>> in a list.

>>> The changes I am proposing are implemented in this PR: [
>>> https://github.com/openjdk/jdk/pull/18639 |
>>> https://github.com/openjdk/jdk/pull/18639 ] . Here is a brief overview of the
>>> changes made in this pull request:

>>> Added the findIndex (Predicate<? super E> filter) method to the List interface.
>>> Added the findLastIndex (Predicate<? super E> filter) method to the List
>>> interface.
>>> Implemented these methods in all non-abstract classes that implement the List
>>> interface, as well as List itself (default impl).
>>> The changes have been thoroughly tested to ensure they work as expected and do
>>> not introduce any regressions. The test cases cover a variety of scenarios to
>>> ensure the robustness of the implementation.

>>> For example, consider the following test case:

>>> List<String> list = new ArrayList<>();
>>> list.add("Object one");
>>> list.add("NotObject two");
>>> list.add("NotObject three");

>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>> System.out.println(index1); // Expected output: 1
>>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>>> System.out.println(index2); // Expected output: 2
>>> Currently, to achieve the same result, we would have to use a more verbose
>>> approach:

>>> int index1 = IntStream.range(0, list.size())
>>> .filter(i -> list.get(i).contains("ct t"))
>>> .findFirst()
>>> .orElse(-1);
>>> System.out.println(index1); // Output: 1
>>> int index2 = IntStream.range(0, list.size())
>>> .filter(i -> list.get(i).startsWith("NotObject"))
>>> .reduce((first, second) -> second)
>>> .orElse(-1);
>>> System.out.println(index2); // Output: 2
>>> Or other approaches that require additional instructions and, therefore, can`t
>>> be used in all scopes (like passing argument to method).

>>> I believe these additions would greatly enhance the functionality and
>>> flexibility of the List interface, making it more powerful and user-friendly. I
>>> look forward to your feedback and am open to making any necessary changes based
>>> on your suggestions.

>>> The main reason I am publishing this proposal in the mailing system is to gather
>>> feedback from the Java developers community, especially about possible caveats
>>> related to backward compatibility of your projects. Would appreciate every
>>> opinion!

>>> Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/ffec3bfc/attachment-0001.htm>

From joehw at openjdk.org  Fri Apr 19 21:55:09 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 19 Apr 2024 21:55:09 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v4]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  changes description of jaxp-compat and jaxp-strict after discussing with Lance

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/e6386015..019c2aee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=02-03

  Stats: 28 lines in 2 files changed: 2 ins; 4 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From joehw at openjdk.org  Fri Apr 19 21:55:09 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 19 Apr 2024 21:55:09 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v3]
In-Reply-To: <59xH2JBfcqMYYrwSrH9svvrlAPLEHFD3rsB7pjzBIEU=.31c651d5-a68c-4bce-b19c-eb5c13f4a0e0@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <wlYQgLflc_7I-YGEweSqKNXQDUf-bDuCq_SdXXq0XT0=.1ac198be-3e7f-4b7c-a290-d46a8b1ee0fb@github.com>
 <59xH2JBfcqMYYrwSrH9svvrlAPLEHFD3rsB7pjzBIEU=.31c651d5-a68c-4bce-b19c-eb5c13f4a0e0@github.com>
Message-ID: <eVxEXpIOyOcSMJzwOvcyre2rYRd-8R1VPJR4xdYxqck=.fab58f56-7212-4305-9748-ad9bd2c32844@github.com>

On Fri, 19 Apr 2024 20:45:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo
>
> src/java.xml/share/conf/jaxp-compat.properties line 20:
> 
>> 18: # JDK has switched to a strict configuration as indicated in jaxp-strict.properties.
>> 19: # This configuration contains the same properties as those in jaxp-strict.properties
>> 20: # except it sets them back to the current status of the JDK. Note that, although
> 
> '....sets them back to the current status of the JDK'
> 
> I think you are trying to indicate that this property file specifies the JAXP property values that were in place prior to being More Secure?

Thanks Lance for the offline discussion. Updated the description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1573002287

From sgibbons at openjdk.org  Fri Apr 19 22:08:52 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 22:08:52 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Long to short jmp; other cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/dd0094ea..19616244

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=22-23

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Fri Apr 19 22:08:53 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 22:08:53 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]
In-Reply-To: <VNDzNOk6Ka18qVLRglBThSjznSDj93rJebbCFMAffUs=.b41da967-2964-4a7e-b7a0-231bd4ef5267@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <jn4GRdVc97_RFzrGKbDHE7lzgtNdEUAVccZWF9KkHoM=.c92a1950-57ae-4e63-a4c5-ca581a6e4760@github.com>
 <VNDzNOk6Ka18qVLRglBThSjznSDj93rJebbCFMAffUs=.b41da967-2964-4a7e-b7a0-231bd4ef5267@github.com>
Message-ID: <dAt6BWx7XOSHv0F9QWa2IT1a6vzRd_Y8pizOzL-3g3s=.5571cc19-cf0f-4ea9-8859-e8b675b7e1dc@github.com>

On Fri, 19 Apr 2024 20:53:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2550:
> 
>> 2548: 
>> 2549:   // If zero, then we're done
>> 2550:   __ jccb(Assembler::zero, L_exit);
> 
> Code in `generate_unsafe_setmemory()` uses long jumps to `L_exit` but here you use short. Why?

Ah - the original code (3 iterations ago) was about 10 bytes too long for a short jump.  It's short enough now.  Changed.

> src/hotspot/share/opto/runtime.cpp line 785:
> 
>> 783:   fields[argp++] = TypePtr::NOTNULL;        // dest
>> 784:   fields[argp++] = TypeX_X;                 // size
>> 785:   LP64_ONLY(fields[argp++] = Type::HALF);  // size
> 
> Nit: align `/`

Done

> src/hotspot/share/utilities/copy.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> You forgot to undo year change in this file.

Yup. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1573006432
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1573014982
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1573015145

From sgibbons at openjdk.org  Fri Apr 19 22:08:53 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 19 Apr 2024 22:08:53 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]
In-Reply-To: <5qkCM1RfvInEvp3ipImOqWXV7Cdg97BUCApATuR2KnI=.30f00efc-d8cd-4abe-9107-bdfa84df9165@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <jn4GRdVc97_RFzrGKbDHE7lzgtNdEUAVccZWF9KkHoM=.c92a1950-57ae-4e63-a4c5-ca581a6e4760@github.com>
 <VNDzNOk6Ka18qVLRglBThSjznSDj93rJebbCFMAffUs=.b41da967-2964-4a7e-b7a0-231bd4ef5267@github.com>
 <5qkCM1RfvInEvp3ipImOqWXV7Cdg97BUCApATuR2KnI=.30f00efc-d8cd-4abe-9107-bdfa84df9165@github.com>
Message-ID: <LAm8ZguDnpFyEHBEUV1jVa9cIMKq3ntjYBAcgJG_444=.ca5e0767-4fe6-4690-981f-d16228560452@github.com>

On Fri, 19 Apr 2024 20:58:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2638:
>> 
>>> 2636:                                L_exit, _masm);
>>> 2637:     }
>>> 2638:     __ jmp(L_exit);
>> 
>> Here is long jump to `L_exit` after `do_setmemory_atomic_loop()` call. Should this be also short jump?
>
> Do we have additional code in debug VM wihch increase distance and requires long jump? I don't see it. Usually it something which call `__ STOP()`.

The old code required a long jump due to the size of `do_setmemory_atomic_loop` but has since been refactored.  The `jmp(Label)` code will generate a short jump provided the label has been defined and is in range.  Otherwise a long jump is generated.

Changed to `jmpb`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1573012933

From kvn at openjdk.org  Fri Apr 19 22:14:31 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 19 Apr 2024 22:14:31 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]
In-Reply-To: <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
Message-ID: <7KJIFS8Y1SqIbr847g66L6inpqMEyKXA6mIlrmrsG6o=.071b82ef-a248-41f4-a36c-e7e5ae28dacb@github.com>

On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Long to short jmp; other cleanup

Good. I will submit our testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2067343940

From davidalayachew at gmail.com  Fri Apr 19 22:16:45 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 19 Apr 2024 18:16:45 -0400
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <258411618.9149442.1713563268524.JavaMail.zimbra@univ-eiffel.fr>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <258411618.9149442.1713563268524.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAA9v-_OYNXT53KZyztr_zd0xxDmnd-dqKDKtr+s7QifopEELBw@mail.gmail.com>

> Any stream can be "indexed", having an index is not an
> intrisinc property of a stream of List, so adding an
> index is more an intermediate operation than a source
> operation.
>
> So more like
>   list.stream().withIndex()
> than like
>   list.streamWithIndex()

I will start of by conceding this point -- this idea is much better than
mine.

> Could you give an example of why it is more error prone ?

It is error-prone because you are mixing indexing logic with predicate
logic. Those are 2 separate tasks that should be done separately. If
anything, it is for this exact reason why your suggestion of .withIndex()
is better than my .streamWithIndex() -- it separates the streaming from the
indexing. Users grab what they need as the need arises.

> Correctness is not an issue athat's why i've used
> ofSequential() when creating the Gatherer.
> You are right that performance can be an issue, the
> Gatherer API is more limited compared to what a
> Spliterator can do.
>
> This custom Gatherer can be declared in Gatherers (with
> an 's' at the end).

If your intent is to toss this into Gatherers, then I sort of see your
point. But is this a good fit for Gatherers? I thought the entire point of
Gatherers was to provide intermediate logic that is difficult to provide
via normal streaming features?

If anything, I feel like .withIndex() would be the feature to add to
Gatherers. But I think it is too good of a method to put into Gatherers. It
should be on the Stream base class, as you suggested.

> Technically, here, you want the result to be an index, so
> you may not want to pay the price of creating an index
> (your WithIndex objetcs) for every elements but just one
> when the predicate is true.
> This point is moot if the WithIndex is a value type and
> Stream is a specialized generics but as I said above,
> where are not yet at that point.

Ok yes, I also concede that there is missing details in my original
suggestion. Like you said, I am depending on features that aren't here yet,
but this problem is here and now.

Valhalla when?

> With your proposal, you still need to write something like

>   list
>       .withIndexStream()
>       .filter(withIndex -> predicate(withIndex.element()))
>       .mapToInt(WithIndex::index)
>       .findFirst()
>       .orElse(-1)

Come on R?mi, give me some credit here.

If we are making a WithIndex object, you think it is a simple no-body
record? You think nothing else in the ecosystem will change in response to
this inclusion?

Try this instead. I will also include your suggestion to use .withIndex().

list
    .stream()
    .withIndex()
    .filter(WithIndex.filter(predicate))
    .mapToIndex()
    .findFirst()
    .orElse(-1)

On Fri, Apr 19, 2024 at 5:47?PM <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"David Alayachew" <davidalayachew at gmail.com>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>,
> "core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Friday, April 19, 2024 11:02:12 PM
> *Subject: *Re: Addition of Predicate-based findIndex and findLastIndex
> methods to java.util.List
>
>
> No R?mi, I don't think your idea is the right approach. You are working on
> the wrong level of abstraction.
>
>
> Hello David,
>
>
> Many users ask requests like this all the time, and what you are
> suggesting would be even more error-prone than the equivalent for loop or the
> IntStream suggestion that the user above requested.
>
>
> Could you give an example of why it is more error prone ?
>
> Not to mention that getting it to parallelize would be a task many users
> are likely to mess up -- either in correctness or in performance.
>
>
> Correctness is not an issue athat's why i've used ofSequential() when
> creating the Gatherer.
> You are right that performance can be an issue, the Gatherer API is more
> limited compared to what a Spliterator can do.
>
>
> I think you would get far more mileage from adding 2 methods on the list
> interface streamWithIndex() and parallelStreamWithIndex() that would return
> a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>
>
> Any stream can be "indexed", having an index is not an intrisinc property
> of a stream of List, so adding an index is more an intermediate operation
> than a source operation.
> So more like
>   list.stream().withIndex()
> than like
>   list.streamWithIndex()
>
> Now, we (the lambda-util expert group) talked 10 years ago to add such
> design but decide to postpone it because WithIndex<T> should be a value
> type and the Stream API should be specialized to avoid unecessary
> allocations.
> So you are right that withIndex() is a more general design but because of
> the performance issue we can not yet offer such design.
>
> As a counter argument, you can say that we have the same issue with the
> Collector API and the Gatherer API which are both not specialized but at
> least for a Collector, the fact that the accumulator does a side effect
> which is usualyl a write in memory is slow anyway. And this is also true
> for a Gatherer, it works well when the Gatherer is itself followed by a
> Collector.
>
>
> That way, users are not writing a custom Gatherer each time they want to
> work with the index. They just have the index be a field in the object.
> They can work with it the same way they would any other object field.
>
>
> This custom Gatherer can be declared in Gatherers (with an 's' at the end).
>
>
> Furthermore, doing it this way makes the correct answer obvious. If I need
> to do something with an index, stream with the index.
>
>
> Technically, here, you want the result to be an index, so you may not want
> to pay the price of creating an index (your WithIndex objetcs) for every
> elements but just one when the predicate is true.
> This point is moot if the WithIndex is a value type and Stream is a
> specialized generics but as I said above, where are not yet at that point.
>
>
> On top of that, it significantly enhances readability by making it clear
> to the reader that, whatever this stream is doing will require use of the
> index, so watch out for that.
>
>
> With your proposal, you still need to write something like
>
>   list.withIndexStream().filter(withIndex ->
> predicate(withIndex.element())).mapToInt(WithIndex::index).findFirst().orElse(-1)
>
> I do not see the enhancement in readability.
>
> regards,
> R?mi
>
>
>
>
>
> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hello,
>> for me, it seems what you want is  Collector on Stream which is able to
>> short-circuit,
>> so you can write
>>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
>> and in reverse
>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>> s.contains("o")))
>>
>> Using a Stream here is more general and will work with other collections
>> like a LinkedHashSet for example.
>> Sadly, there is no way to define a short-circuiting collector :(
>>
>> You can have a short-circuiting Gatherer like this
>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
>>     return Gatherer.ofSequential(
>>       () -> new Object() { int index; },
>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>         var index = state.index++;
>>         if (predicate.test(element)) {
>>           return downstream.push(index);
>>         }
>>         return true;
>>       }));
>>   }
>>
>> and use it like this:
>>   list.stream().gather(findIndex(s ->
>> s.contains("o"))).findFirst().orElse(-1);
>>
>> But it's more verbose.
>>
>> I wonder if at the same time that the Gatherer API is introduced, the
>> Collector API should be enhanced to support short-circuiting collectors ?
>>
>> regards,
>> R?mi
>>
>>
>> ------------------------------
>>
>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>> *Subject: *Addition of Predicate-based findIndex and findLastIndex
>> methods to java.util.List
>>
>> Subject
>> Addition of Predicate-based findIndex and findLastIndex methods to
>> java.util.List
>>
>> Motivation
>> The motivation behind this proposal is to enhance the functionality of
>> the List interface by providing a more flexible way to find the index of an
>> element. Currently, the indexOf and lastIndexOf methods only accept an
>> object as a parameter. This limits the flexibility of these methods as they
>> can only find the index of exact object matches.
>>
>> Here I want to propose methods that would accept a Predicate as a
>> parameter, allowing users to define a condition that the desired element
>> must meet. This would provide a more flexible and powerful way to find the
>> index of an element in a list.
>>
>> The changes I am proposing are implemented in this PR:
>> https://github.com/openjdk/jdk/pull/18639. Here is a brief overview of
>> the changes made in this pull request:
>>
>> Added the findIndex  (Predicate<? super E> filter) method to the List
>> interface.
>> Added the findLastIndex  (Predicate<? super E> filter) method to the List
>> interface.
>> Implemented these methods in all non-abstract classes that implement the
>> List interface, as well as List itself (default impl).
>> The changes have been thoroughly tested to ensure they work as expected
>> and do not introduce any regressions. The test cases cover a variety of
>> scenarios to ensure the robustness of the implementation.
>>
>> For example, consider the following test case:
>>
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>>
>> int index1 = list.findIndex(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> Currently, to achieve the same result, we would have to use a more
>> verbose approach:
>>
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> Or other approaches that require additional instructions and, therefore,
>> can`t be used in all scopes (like passing argument to method).
>>
>> I believe these additions would greatly enhance the functionality and
>> flexibility of the List interface, making it more powerful and
>> user-friendly. I look forward to your feedback and am open to making any
>> necessary changes based on your suggestions.
>>
>> The main reason I am publishing this proposal in the mailing system is to
>> gather feedback from the Java developers community, especially about
>> possible caveats related to backward compatibility of your projects. Would
>> appreciate every opinion!
>>
>> Best regards
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/f2795580/attachment-0001.htm>

From davidalayachew at gmail.com  Fri Apr 19 22:56:08 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 19 Apr 2024 18:56:08 -0400
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAP=Y=q8aPLwjmg_h3oSbR6ZPPUajocB1P2R1uRBWrYXn3j0LXg@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
 <CAA9v-_NptwV4UNo9V1YDB=1os5BViPgYkMkDXJWRgGZis6UdYw@mail.gmail.com>
 <CAP=Y=q8aPLwjmg_h3oSbR6ZPPUajocB1P2R1uRBWrYXn3j0LXg@mail.gmail.com>
Message-ID: <CAA9v-_PLXYjYzv1xfwKQiVRfZh0XSkxrSkuQOmLD3s5tr9qPFA@mail.gmail.com>

> I think that, while finding the index of a matching
> element is not a very common task, especially among
> commercial developers, when discussing indexed streams,
> this would be the most common use case. To be honest, I
> don't even see any other use cases right now, besides
> maybe some processing based on divisibility of index
> (odd/even as the most common one). I have a pretty strong
> background in competitive programming, more than 5 years,
> and can remember anything more complex than that that
> could not be replaced with Map usage.

Here are 3 off the top of my head.

1. Fetching data from same-sized lists -- This is a trick from
Data-Oriented Design (not to be confused with Data-Oriented Programming)
where you filter down to the indexes that you want, and use the indexes to
fetch related values from the respective lists. So, I would filter down to
Player1, Player4, and Player6, then I would use their indexes to do lookups
in PlayerItemList, PlayerSkinList, etc. This tactic is especially useful
when working with structs (or value classes when Java gets them).

2. Building jumps/skips -- Fetching the indexes at hotspots, and then using
them to create a skip-list-esque structure between the hotspots. Very
useful for realigning search strategies.

3. Calculating distance using index -- This is a sister concept to bullet
2. Let's say I built my skip list above, and have determined that my
desired target is not in the hotspots. I can make a better decision to go
for parallel or sequential by seeing the distance between hotspots. That
distance would be taken by subtracting hotspot index by hotspot index.

And also, there is an entire world of index math. It is not just
divisibility.

> 1. Although indexed streams are flexible, the flexibility
> might come at the cost of readability. Syntax like
> list.FindIndex is pretty straightforward and speaks for
> itself, while indexed-stream-based approach requires
> developer to explicitly evaluate what that chain of
> method does, which would distract them from understanding
> of general program logic flow, while usually being no
> more then utility.

By this logic, many of the methods in the Stream library should instead be
in the Collection library. The are several emails on the lambda mailing
list that address why this wasn't done. I imagine that R?mi himself could
point them out to you.

> The reason for existence of findIndex is the same as for
> indexOf, so saying one is redundant means saying other
> one is redundant too.

Well hold on. I am not at all saying that it is redundant. I am saying that
the functionality that you desire can be easily recreated by using a more
far-reaching feature, the .withIndex() idea that R?mi suggested. I am just
trying to say that your idea probably should not be done on the List
interface.

> 2. Streams are performance-costy, thats the point that is
> hard to argue with. While list implementations could
> provide specified implementations of findIndex based on
> their internal structure, streams work only with generic
> interfaces. Moreover, even default implementation that
> uses ListIterator would be times faster and less resource
> consuming then generic stream-based approach. While I
> understand that performance is not as valuable as
> flexibility and clarity, it is still crucial, at least
> because of it being the main factor server maintenance
> cost after all.

R?mi already addressed a couple of these performance points in his response
to me. Long story short, Valhalla is going to make a lot of what you said
irrelevant.

Regardless, Valhalla is not here yet. So at least for now, I will concede
your point about performance.

On Fri, Apr 19, 2024 at 5:52?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> I think that, while finding the index of a matching element is not a very
> common task, especially among commercial developers, when discussing
> indexed streams, this would be the most common use case. To be honest, I
> don't even see any other use cases right now, besides maybe some processing
> based on divisibility of index (odd/even as the most common one). I have a
> pretty strong background in competitive programming, more than 5 years, and
> can remember anything more complex than that that could not be replaced
> with Map usage.
>
> Regarding clarity, I fully agree with you. I am not a fan of those
> unreadable abbreviations in C/C++ or even in python. However, while it's
> hard to argue that your approach is more flexible, it has two downsides:
>
> 1. Although indexed streams are flexible, the flexibility might come at
> the cost of readability. Syntax like list.FindIndex is pretty
> straightforward and speaks for itself, while indexed-stream-based approach
> requires developer to explicitly evaluate what that chain of method does,
> which would distract them from understanding of general program logic flow,
> while usually being no more then utility. The reason for existence of
> findIndex is the same as for indexOf, so saying one is redundant means
> saying other one is redundant too.
>
> 2. Streams are performance-costy, thats the point that is hard to argue
> with. While list implementations could provide specified implementations of
> findIndex based on their internal structure, streams work only with generic
> interfaces. Moreover, even default implementation that uses ListIterator
> would be times faster and less resource consuming then generic stream-based
> approach. While I understand that performance is not as valuable as
> flexibility and clarity, it is still crucial, at least because of it being
> the main factor server maintenance cost after all.
>
> ??, 20 ???. 2024??. ? 00:32, David Alayachew <davidalayachew at gmail.com>:
>
>> It is not the goal of Java to be verbose, but it is also not the goal of
>> Java to be concise either. It is the goal of Java to be clear, correct, and
>> readable, in order to maximize maintainability, correctness, and
>> flexibility. When you focus on accomplishing that goal first, you will find
>> that conciseness takes care of itself.
>>
>> I understand that my approach is wordier than yours. Please also consider
>> that my suggestion does exactly one task -- stream an element with its
>> respective index. And yet, the number of ways that that can be used covers
>> hundreds of use cases while still being incredibly easy to maintain and
>> optimize. Far more than what you suggest. My feature easily composes with
>> others, with anything that can take a Stream<T> in fact.
>>
>> The bar to adding a feature to Java, even to its libraries, is high. In
>> fact, there is even a breaking point where a language/library can just be
>> too dense to work with. Too many methods, too much complexity.
>>
>> Java makes it a priority to limit adding features or functionality
>> wherever possible, only relenting when the benefit significantly outweighs
>> the cost. Adding a method like yours that only serves a tiny slice of use
>> cases just does not meet the goal of what Java is aiming for -- to get the
>> biggest bang for buck when adding a feature to language/library.
>>
>> I think that your pain point is significant and worth addressing. But I
>> think it should be done in a way that services a much larger group of users
>> and use cases. I think my idea does that.
>>
>> On Fri, Apr 19, 2024 at 5:14?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> streamWithIndex() is indeed an interesting approach, however, working
>>> with pairs of values is not always comfortable as this may make code too
>>> wordy, which may be fixed using things like properties and tuples (which I
>>> am currently working on right now btw), but still code like
>>> list.streamWithIndex().filter(Predicate).findFirst().orElse(-1) is still
>>> long, thats why i think there is room for both in Java.
>>>
>>> Also maybe instead of returning traditional -1 it would be more
>>> suitable to use OptionalInt instead, but I would like to hear community
>>> opinion about that.
>>>
>>> ??, 20 ???. 2024??. ? 00:02, David Alayachew <davidalayachew at gmail.com>:
>>>
>>>>
>>>> No R?mi, I don't think your idea is the right approach. You are working
>>>> on the wrong level of abstraction.
>>>>
>>>> Many users ask requests like this all the time, and what you are
>>>> suggesting would be even more error-prone than the equivalent for loop or the
>>>> IntStream suggestion that the user above requested. Not to mention that
>>>> getting it to parallelize would be a task many users are likely to mess up
>>>> -- either in correctness or in performance.
>>>>
>>>> I think you would get far more mileage from adding 2 methods on the
>>>> list interface streamWithIndex() and parallelStreamWithIndex() that would
>>>> return a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>>>
>>>> That way, users are not writing a custom Gatherer each time they want
>>>> to work with the index. They just have the index be a field in the object.
>>>> They can work with it the same way they would any other object field.
>>>>
>>>> Furthermore, doing it this way makes the correct answer obvious. If I
>>>> need to do something with an index, stream with the index.
>>>>
>>>> On top of that, it significantly enhances readability by making it
>>>> clear to the reader that, whatever this stream is doing will require use of
>>>> the index, so watch out for that.
>>>>
>>>>
>>>>
>>>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>>>
>>>>> Hello,
>>>>> for me, it seems what you want is  Collector on Stream which is able
>>>>> to short-circuit,
>>>>> so you can write
>>>>>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
>>>>> and in reverse
>>>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>>>> s.contains("o")))
>>>>>
>>>>> Using a Stream here is more general and will work with other
>>>>> collections like a LinkedHashSet for example.
>>>>> Sadly, there is no way to define a short-circuiting collector :(
>>>>>
>>>>> You can have a short-circuiting Gatherer like this
>>>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T>
>>>>> predicate) {
>>>>>     return Gatherer.ofSequential(
>>>>>       () -> new Object() { int index; },
>>>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>>>         var index = state.index++;
>>>>>         if (predicate.test(element)) {
>>>>>           return downstream.push(index);
>>>>>         }
>>>>>         return true;
>>>>>       }));
>>>>>   }
>>>>>
>>>>> and use it like this:
>>>>>   list.stream().gather(findIndex(s ->
>>>>> s.contains("o"))).findFirst().orElse(-1);
>>>>>
>>>>> But it's more verbose.
>>>>>
>>>>> I wonder if at the same time that the Gatherer API is introduced, the
>>>>> Collector API should be enhanced to support short-circuiting collectors ?
>>>>>
>>>>> regards,
>>>>> R?mi
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>>>> *Subject: *Addition of Predicate-based findIndex and findLastIndex
>>>>> methods to java.util.List
>>>>>
>>>>> Subject
>>>>> Addition of Predicate-based findIndex and findLastIndex methods to
>>>>> java.util.List
>>>>>
>>>>> Motivation
>>>>> The motivation behind this proposal is to enhance the functionality of
>>>>> the List interface by providing a more flexible way to find the index of an
>>>>> element. Currently, the indexOf and lastIndexOf methods only accept an
>>>>> object as a parameter. This limits the flexibility of these methods as they
>>>>> can only find the index of exact object matches.
>>>>>
>>>>> Here I want to propose methods that would accept a Predicate as a
>>>>> parameter, allowing users to define a condition that the desired element
>>>>> must meet. This would provide a more flexible and powerful way to find the
>>>>> index of an element in a list.
>>>>>
>>>>> The changes I am proposing are implemented in this PR:
>>>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief overview
>>>>> of the changes made in this pull request:
>>>>>
>>>>> Added the findIndex  (Predicate<? super E> filter) method to the List
>>>>> interface.
>>>>> Added the findLastIndex  (Predicate<? super E> filter) method to the
>>>>> List interface.
>>>>> Implemented these methods in all non-abstract classes that implement
>>>>> the List interface, as well as List itself (default impl).
>>>>> The changes have been thoroughly tested to ensure they work as
>>>>> expected and do not introduce any regressions. The test cases cover a
>>>>> variety of scenarios to ensure the robustness of the implementation.
>>>>>
>>>>> For example, consider the following test case:
>>>>>
>>>>> List<String> list = new ArrayList<>();
>>>>> list.add("Object one");
>>>>> list.add("NotObject two");
>>>>> list.add("NotObject three");
>>>>>
>>>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>>>> System.out.println(index1); // Expected output: 1
>>>>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>>>>> System.out.println(index2); // Expected output: 2
>>>>> Currently, to achieve the same result, we would have to use a more
>>>>> verbose approach:
>>>>>
>>>>> int index1 = IntStream.range(0, list.size())
>>>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>>>                      .findFirst()
>>>>>                      .orElse(-1);
>>>>> System.out.println(index1); // Output: 1
>>>>> int index2 = IntStream.range(0, list.size())
>>>>>                          .filter(i ->
>>>>> list.get(i).startsWith("NotObject"))
>>>>>                          .reduce((first, second) -> second)
>>>>>                          .orElse(-1);
>>>>> System.out.println(index2); // Output: 2
>>>>> Or other approaches that require additional instructions and,
>>>>> therefore, can`t be used in all scopes (like passing argument to method).
>>>>>
>>>>> I believe these additions would greatly enhance the functionality and
>>>>> flexibility of the List interface, making it more powerful and
>>>>> user-friendly. I look forward to your feedback and am open to making any
>>>>> necessary changes based on your suggestions.
>>>>>
>>>>> The main reason I am publishing this proposal in the mailing system is
>>>>> to gather feedback from the Java developers community, especially about
>>>>> possible caveats related to backward compatibility of your projects. Would
>>>>> appreciate every opinion!
>>>>>
>>>>> Best regards
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/bd1111bb/attachment-0001.htm>

From mik3hall at gmail.com  Fri Apr 19 23:40:47 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 19 Apr 2024 18:40:47 -0500
Subject: Integrated: 8295111: dpkg appears to have problems resolving
 symbolically linked native libraries
In-Reply-To: <3D9EEBDB-3CBE-4A01-8509-313BE57DC437@gmail.com>
References: <POJyOU_RtOhTZ6hktXZHOaXBi1Msf0t7SbGP8VwYTRk=.06d5e390-acdc-4d9a-9f41-afca4a4ac35a@github.com>
 <x0179lJHCGfQ3XrNpQ-yEgO0jZScVWwrfrHLyeqM9GI=.d5cdf25f-2493-4126-be9a-d46c40add14f@github.com>
 <3D9EEBDB-3CBE-4A01-8509-313BE57DC437@gmail.com>
Message-ID: <C577D9DB-6506-4A44-BC8A-50BDE61A73BA@gmail.com>

I was apparently at least partly misunderstanding this. I thought I verified a missing file on one exception trace. I installed what appeared to be missing packages and that one no longer shows up.

I still get exception traces on some .so files which appear to be reporting errors on dpkg -S commands unable to determine the packages for some files. The files are in fact there. I was seeing these because I was running verbose. Trying some old stuff I still have to see if I could get jpackage to work. Without verbose it runs through indicating no errors. However, running the created deb file doesn?t appear to be creating an app that I can find. Nothing else seems to give me any information on what the actual install is doing. I did notice in the verbose output a lot of libjvm.so <http://libjvm.so/> is missing messages. 

Anyhow, for my current purposes the code doesn?t have to run as a Pi application. I can command line if I have to. Or I was thinking about modifying some of the application code to run standalone.

Thanks anyhow,

Mike

> On Apr 19, 2024, at 1:13?PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> I don?t know what flavors you are looking to support but there seems to be somewhat different issues on a Raspberry Pi. I was just trying to use jpackage there.
> 
> I am getting errors like the command
> 
> dpkg -S /lib/aarch64-linux-gnu/libXau.so <http://libxau.so/>.6 
> The file isn?t found
> 
> These actually appear to have entries in
> 
> /usr/lib/aarch64-linux-gnu
> 
> Which in turn appear to be symbolic links like?
> 
> /usr/lib/aarch64-linux-gnu/libXau.so <http://libxau.so/>.6 -> libXau.so <http://libxau.so/>.6.0.0
> 
> I am thinking I could try making symbolic links as a workaround myself.
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/b1c83ce5/attachment.htm>

From davidalayachew at gmail.com  Fri Apr 19 23:55:47 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 19 Apr 2024 19:55:47 -0400
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAP=Y=q-a4wPT1mxFnVUV=X_8FA8rPc3E1jxLiDsw7ZVj4sGuCA@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
 <CAA9v-_NptwV4UNo9V1YDB=1os5BViPgYkMkDXJWRgGZis6UdYw@mail.gmail.com>
 <CAP=Y=q8aPLwjmg_h3oSbR6ZPPUajocB1P2R1uRBWrYXn3j0LXg@mail.gmail.com>
 <CAP=Y=q88ppGhtuVEr4oe4N4LOPw4Fdhe9Au7dDOmw7JtObYnWw@mail.gmail.com>
 <CAA9v-_OpDb83_sfo9ge=KrH5YmpB+yD36hfS_r1wE6CsX5LTrQ@mail.gmail.com>
 <CAP=Y=q-a4wPT1mxFnVUV=X_8FA8rPc3E1jxLiDsw7ZVj4sGuCA@mail.gmail.com>
Message-ID: <CAA9v-_P9xj4YCPFgS13ben54cq=yNe+3Wdxb5ktshbyOCwrHFA@mail.gmail.com>

> That was what i referred to as "Map-solvable" problems,
> but if this way of doing it is a thing, then I agree with
> the point.

Doing it the Map way would not only be slower, but it would force you to
include more concepts than you need. Your identifier is your index.
Lists/arrays have index. Bringing a map in only complicates things.

As for the rest of your response, I think I understand the trouble here.
You put it best when you said that you are introducing this feature with
the intent of improving the developer experience, specifically through
making code more concise.

I can understand that goal, and it is a good goal to strive for, but
conciseness is one of the last things Java aims to provide as a language or
through its standard library. I won't tell you not to do it, but I will
tell you that there will be significant push back from folks here, and for
good reason -- conciseness is not the priority here at Java. At Java, the
lack of conciseness is not a weakness. Sure, unneeded verbosity can be a
weakness, but the solution I suggested above is basically the tempo that
Java strives for -- compose simple concepts so that you can create what you
need.

All of that is to say, you have made your point clear. You goal is
conciseness and ease of access. Understanding that, it's clear that my
solution is not concise enough to meet that goal, so I won't push it
further.

On Fri, Apr 19, 2024 at 7:26?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> " 1. Fetching data from same-sized lists -- This is a trick from
> Data-Oriented Design (not to be confused with Data-Oriented Programming)
> where you filter down to the indexes that you want, and use the indexes to
> fetch related values from the respective lists. So, I would filter down to
> Player1, Player4, and Player6, then I would use their indexes to do lookups
> in PlayerItemList, PlayerSkinList, etc. This tactic is especially useful
> when working with structs (or value classes when Java gets them)."
>
> That was what i referred to as "Map-solvable" problems, but if this way of
> doing it is a thing, then I agree with the point.
>
> "By this logic, many of the methods in the Stream library should instead
> be in the Collection library. There are several emails on the lambda
> mailing list that address why this wasn't done. I imagine that R?mi himself
> could point them out to you."
>
> It may be just my opinion, but I don't see anything harmful in some
> shortcuts that could be optimized, especially if they still converge to a
> single point under the hood. I would love to read mails about maintainers'
> opinions on why some features of Streams couldnt be also a part of
> Collection library if it would enhance developer experience, so, if it
> wouldn't be hard for you, could you attach some links? Also I guess a good
> compromise would be extension methods, I am currently exploring
> possibilities of their implementation.
>
> "Well hold on. I am not at all saying that it is redundant. I am saying
> that the functionality that you desire can be easily recreated by using a
> more far-reaching feature, the .withIndex() idea that R?mi suggested. I am
> just trying to say that your idea probably should not be done on the List
> interface."
>
> I am not saying that .withIndex() is a bad idea in any way. I can remember
> several times when I was desperately looking for something like python
> enumerate(), but all I found were some IntStream-based approaches. What I
> am saying is, while there is definitely room for both, withIndex does not
> solve the initial problem that motivated me to propose such changes:
> redundant (emphasis on this) verbosity. The main reason I decided to become
> an openjdk contributor is because I love to create tools that make
> development easier and more pleasant, and I feel more sophisticated,
> although a more specific API would deal much better with this task, and as
> this is my personal priority, I would stand my ground here.
>
> "Regardless, Valhalla is not here yet. So at least for now, I will
> concede your point about performance."
>
> Valhalla, at least for now, is nowhere near to a release even as a
> preview, would be great if it will get to Java releases until the next LTS.
> I think that even, even for a 2-4 years, this point is valid, then it at
> least should be taken into consideration.
>
> PS: As you might notice, I am a developer experience guy rather than a
> flexible guy. My opinion is a result of some personal beliefs, but also is
> an aggregation of opinions of numbers of other programmers that I
> introduced to Java, especially switchers. Many of then feel those
> "wordiness" of Java and it repulses potential developers, especially when
> there is C# just by the corner. I think that Java has really strong sides,
> but I would love to cover its "weaknesses" as well, especially if it
> doesn't come with any maintenance burdens.
>
> ??, 20 ???. 2024??. ? 02:00, David Alayachew <davidalayachew at gmail.com>:
>
>> No confusion. You spoke clearly enough to be understood the first time.
>>
>> On Fri, Apr 19, 2024 at 6:28?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Regarding the first point in my last message. "Them" is referring to the
>>> developer, and "evaluate" means to be processed by the developer. Sorry
>>> for the potential confusion
>>>
>>> ??, 20 ???. 2024??. ? 00:52, ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com>:
>>>
>>>> I think that, while finding the index of a matching element is not a
>>>> very common task, especially among commercial developers, when discussing
>>>> indexed streams, this would be the most common use case. To be honest, I
>>>> don't even see any other use cases right now, besides maybe some processing
>>>> based on divisibility of index (odd/even as the most common one). I have a
>>>> pretty strong background in competitive programming, more than 5 years, and
>>>> can remember anything more complex than that that could not be replaced
>>>> with Map usage.
>>>>
>>>> Regarding clarity, I fully agree with you. I am not a fan of those
>>>> unreadable abbreviations in C/C++ or even in python. However, while it's
>>>> hard to argue that your approach is more flexible, it has two downsides:
>>>>
>>>> 1. Although indexed streams are flexible, the flexibility might come at
>>>> the cost of readability. Syntax like list.FindIndex is pretty
>>>> straightforward and speaks for itself, while indexed-stream-based approach
>>>> requires developer to explicitly evaluate what that chain of method does,
>>>> which would distract them from understanding of general program logic flow,
>>>> while usually being no more then utility. The reason for existence of
>>>> findIndex is the same as for indexOf, so saying one is redundant means
>>>> saying other one is redundant too.
>>>>
>>>> 2. Streams are performance-costy, thats the point that is hard to argue
>>>> with. While list implementations could provide specified implementations of
>>>> findIndex based on their internal structure, streams work only with generic
>>>> interfaces. Moreover, even default implementation that uses ListIterator
>>>> would be times faster and less resource consuming then generic stream-based
>>>> approach. While I understand that performance is not as valuable as
>>>> flexibility and clarity, it is still crucial, at least because of it being
>>>> the main factor server maintenance cost after all.
>>>>
>>>> ??, 20 ???. 2024??. ? 00:32, David Alayachew <davidalayachew at gmail.com
>>>> >:
>>>>
>>>>> It is not the goal of Java to be verbose, but it is also not the goal
>>>>> of Java to be concise either. It is the goal of Java to be clear, correct,
>>>>> and readable, in order to maximize maintainability, correctness, and
>>>>> flexibility. When you focus on accomplishing that goal first, you will find
>>>>> that conciseness takes care of itself.
>>>>>
>>>>> I understand that my approach is wordier than yours. Please also
>>>>> consider that my suggestion does exactly one task -- stream an element with
>>>>> its respective index. And yet, the number of ways that that can be used
>>>>> covers hundreds of use cases while still being incredibly easy to maintain
>>>>> and optimize. Far more than what you suggest. My feature easily composes
>>>>> with others, with anything that can take a Stream<T> in fact.
>>>>>
>>>>> The bar to adding a feature to Java, even to its libraries, is high.
>>>>> In fact, there is even a breaking point where a language/library can just
>>>>> be too dense to work with. Too many methods, too much complexity.
>>>>>
>>>>> Java makes it a priority to limit adding features or functionality
>>>>> wherever possible, only relenting when the benefit significantly outweighs
>>>>> the cost. Adding a method like yours that only serves a tiny slice of use
>>>>> cases just does not meet the goal of what Java is aiming for -- to get the
>>>>> biggest bang for buck when adding a feature to language/library.
>>>>>
>>>>> I think that your pain point is significant and worth addressing. But
>>>>> I think it should be done in a way that services a much larger group of
>>>>> users and use cases. I think my idea does that.
>>>>>
>>>>> On Fri, Apr 19, 2024 at 5:14?PM ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> streamWithIndex() is indeed an interesting approach, however, working
>>>>>> with pairs of values is not always comfortable as this may make code too
>>>>>> wordy, which may be fixed using things like properties and tuples (which I
>>>>>> am currently working on right now btw), but still code like
>>>>>> list.streamWithIndex().filter(Predicate).findFirst().orElse(-1) is still
>>>>>> long, thats why i think there is room for both in Java.
>>>>>>
>>>>>> Also maybe instead of returning traditional -1 it would be more
>>>>>> suitable to use OptionalInt instead, but I would like to hear community
>>>>>> opinion about that.
>>>>>>
>>>>>> ??, 20 ???. 2024??. ? 00:02, David Alayachew <
>>>>>> davidalayachew at gmail.com>:
>>>>>>
>>>>>>>
>>>>>>> No R?mi, I don't think your idea is the right approach. You are
>>>>>>> working on the wrong level of abstraction.
>>>>>>>
>>>>>>> Many users ask requests like this all the time, and what you are
>>>>>>> suggesting would be even more error-prone than the equivalent for loop or the
>>>>>>> IntStream suggestion that the user above requested. Not to mention
>>>>>>> that getting it to parallelize would be a task many users are likely to
>>>>>>> mess up -- either in correctness or in performance.
>>>>>>>
>>>>>>> I think you would get far more mileage from adding 2 methods on the
>>>>>>> list interface streamWithIndex() and parallelStreamWithIndex() that would
>>>>>>> return a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>>>>>>
>>>>>>> That way, users are not writing a custom Gatherer each time they
>>>>>>> want to work with the index. They just have the index be a field in the
>>>>>>> object. They can work with it the same way they would any other object
>>>>>>> field.
>>>>>>>
>>>>>>> Furthermore, doing it this way makes the correct answer obvious. If
>>>>>>> I need to do something with an index, stream with the index.
>>>>>>>
>>>>>>> On top of that, it significantly enhances readability by making it
>>>>>>> clear to the reader that, whatever this stream is doing will require use of
>>>>>>> the index, so watch out for that.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>> for me, it seems what you want is  Collector on Stream which is
>>>>>>>> able to short-circuit,
>>>>>>>> so you can write
>>>>>>>>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
>>>>>>>> and in reverse
>>>>>>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>>>>>>> s.contains("o")))
>>>>>>>>
>>>>>>>> Using a Stream here is more general and will work with other
>>>>>>>> collections like a LinkedHashSet for example.
>>>>>>>> Sadly, there is no way to define a short-circuiting collector :(
>>>>>>>>
>>>>>>>> You can have a short-circuiting Gatherer like this
>>>>>>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T>
>>>>>>>> predicate) {
>>>>>>>>     return Gatherer.ofSequential(
>>>>>>>>       () -> new Object() { int index; },
>>>>>>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>>>>>>         var index = state.index++;
>>>>>>>>         if (predicate.test(element)) {
>>>>>>>>           return downstream.push(index);
>>>>>>>>         }
>>>>>>>>         return true;
>>>>>>>>       }));
>>>>>>>>   }
>>>>>>>>
>>>>>>>> and use it like this:
>>>>>>>>   list.stream().gather(findIndex(s ->
>>>>>>>> s.contains("o"))).findFirst().orElse(-1);
>>>>>>>>
>>>>>>>> But it's more verbose.
>>>>>>>>
>>>>>>>> I wonder if at the same time that the Gatherer API is introduced,
>>>>>>>> the Collector API should be enhanced to support short-circuiting collectors
>>>>>>>> ?
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> R?mi
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>>
>>>>>>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>>>>>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>>>>>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>>>>>>> *Subject: *Addition of Predicate-based findIndex and findLastIndex
>>>>>>>> methods to java.util.List
>>>>>>>>
>>>>>>>> Subject
>>>>>>>> Addition of Predicate-based findIndex and findLastIndex methods to
>>>>>>>> java.util.List
>>>>>>>>
>>>>>>>> Motivation
>>>>>>>> The motivation behind this proposal is to enhance the functionality
>>>>>>>> of the List interface by providing a more flexible way to find the index of
>>>>>>>> an element. Currently, the indexOf and lastIndexOf methods only accept an
>>>>>>>> object as a parameter. This limits the flexibility of these methods as they
>>>>>>>> can only find the index of exact object matches.
>>>>>>>>
>>>>>>>> Here I want to propose methods that would accept a Predicate as a
>>>>>>>> parameter, allowing users to define a condition that the desired element
>>>>>>>> must meet. This would provide a more flexible and powerful way to find the
>>>>>>>> index of an element in a list.
>>>>>>>>
>>>>>>>> The changes I am proposing are implemented in this PR:
>>>>>>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief
>>>>>>>> overview of the changes made in this pull request:
>>>>>>>>
>>>>>>>> Added the findIndex  (Predicate<? super E> filter) method to the
>>>>>>>> List interface.
>>>>>>>> Added the findLastIndex  (Predicate<? super E> filter) method to
>>>>>>>> the List interface.
>>>>>>>> Implemented these methods in all non-abstract classes that
>>>>>>>> implement the List interface, as well as List itself (default impl).
>>>>>>>> The changes have been thoroughly tested to ensure they work as
>>>>>>>> expected and do not introduce any regressions. The test cases cover a
>>>>>>>> variety of scenarios to ensure the robustness of the implementation.
>>>>>>>>
>>>>>>>> For example, consider the following test case:
>>>>>>>>
>>>>>>>> List<String> list = new ArrayList<>();
>>>>>>>> list.add("Object one");
>>>>>>>> list.add("NotObject two");
>>>>>>>> list.add("NotObject three");
>>>>>>>>
>>>>>>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>>>>>>> System.out.println(index1); // Expected output: 1
>>>>>>>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>>>>>>>> System.out.println(index2); // Expected output: 2
>>>>>>>> Currently, to achieve the same result, we would have to use a more
>>>>>>>> verbose approach:
>>>>>>>>
>>>>>>>> int index1 = IntStream.range(0, list.size())
>>>>>>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>>>>>>                      .findFirst()
>>>>>>>>                      .orElse(-1);
>>>>>>>> System.out.println(index1); // Output: 1
>>>>>>>> int index2 = IntStream.range(0, list.size())
>>>>>>>>                          .filter(i ->
>>>>>>>> list.get(i).startsWith("NotObject"))
>>>>>>>>                          .reduce((first, second) -> second)
>>>>>>>>                          .orElse(-1);
>>>>>>>> System.out.println(index2); // Output: 2
>>>>>>>> Or other approaches that require additional instructions and,
>>>>>>>> therefore, can`t be used in all scopes (like passing argument to method).
>>>>>>>>
>>>>>>>> I believe these additions would greatly enhance the functionality
>>>>>>>> and flexibility of the List interface, making it more powerful and
>>>>>>>> user-friendly. I look forward to your feedback and am open to making any
>>>>>>>> necessary changes based on your suggestions.
>>>>>>>>
>>>>>>>> The main reason I am publishing this proposal in the mailing system
>>>>>>>> is to gather feedback from the Java developers community, especially about
>>>>>>>> possible caveats related to backward compatibility of your projects. Would
>>>>>>>> appreciate every opinion!
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240419/6e784c99/attachment-0001.htm>

From duke at openjdk.org  Sat Apr 20 00:06:28 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 20 Apr 2024 00:06:28 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs
In-Reply-To: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
Message-ID: <3RSkF8kVcoCwRonUyebeTF3xDDR9CohNpiU6oJdh028=.c596c79d-c2ae-4349-a29e-a14e0587608e@github.com>

On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 685:

> 683:     record TypePairs(Class<?> from, Class<?> to) {
> 684: 
> 685:         private static final Map<TypePairs, String> typePairToName = initialize();

If?`TypePairs.typePairToName` is?never modified after initialisation, then?it?should probably be?made immutable:
Suggestion:

        private static final Map<TypePairs, String> typePairToName = Map.copyOf(initialize());

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 699:

> 697: 
> 698:         public boolean equals(Object other) {
> 699:             if (other instanceof TypePairs otherPair) {

To?match the?behaviour of?the?`equals` method?body generated by?`java?.lang?.runtime?.ObjectMethods?::bootstrap`, this?should?include a?fast?path check for?`this?==?other`:
Suggestion:

            if (this == other) {
                return true;
            }
            if (other instanceof TypePairs otherPair) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18865#discussion_r1573061423
PR Review Comment: https://git.openjdk.org/jdk/pull/18865#discussion_r1573059594

From rotan.olexandr at gmail.com  Sat Apr 20 00:23:49 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 03:23:49 +0300
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAA9v-_P9xj4YCPFgS13ben54cq=yNe+3Wdxb5ktshbyOCwrHFA@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
 <CAA9v-_NptwV4UNo9V1YDB=1os5BViPgYkMkDXJWRgGZis6UdYw@mail.gmail.com>
 <CAP=Y=q8aPLwjmg_h3oSbR6ZPPUajocB1P2R1uRBWrYXn3j0LXg@mail.gmail.com>
 <CAP=Y=q88ppGhtuVEr4oe4N4LOPw4Fdhe9Au7dDOmw7JtObYnWw@mail.gmail.com>
 <CAA9v-_OpDb83_sfo9ge=KrH5YmpB+yD36hfS_r1wE6CsX5LTrQ@mail.gmail.com>
 <CAP=Y=q-a4wPT1mxFnVUV=X_8FA8rPc3E1jxLiDsw7ZVj4sGuCA@mail.gmail.com>
 <CAA9v-_P9xj4YCPFgS13ben54cq=yNe+3Wdxb5ktshbyOCwrHFA@mail.gmail.com>
Message-ID: <CAP=Y=q8iGSx-OnSfu34k4qCh_5cZekOPHJ14=TKB8RKVPBeRig@mail.gmail.com>

Turned out this whole time I was only replying to David. I have to thank
him for his patience explaining me how this whole mailing thing work.

To summarize what has been missed out, besides what have you seen in
quotes. I have pointed out that, while flexibility and simplicity is
important, the main reason why I have decided to propose this feature is to
enhance developer experience.

I know that conciseness is not a main goal of Java, and therefore my
proposal is kind of contradicts the general direction of development of
Java as language, but my desire to make Java more user friendly is based on
personal experience of introducing fresh devs or switchers to java and
their feedback. Therefore, while it is not a priority for community, I
really hope you guys don't mind me working at a backrank of Java making it
a bit prettier.

On Sat, Apr 20, 2024, 02:56 David Alayachew <davidalayachew at gmail.com>
wrote:

> > That was what i referred to as "Map-solvable" problems,
> > but if this way of doing it is a thing, then I agree with
> > the point.
>
> Doing it the Map way would not only be slower, but it would force you to
> include more concepts than you need. Your identifier is your index.
> Lists/arrays have index. Bringing a map in only complicates things.
>
> As for the rest of your response, I think I understand the trouble here.
> You put it best when you said that you are introducing this feature with
> the intent of improving the developer experience, specifically through
> making code more concise.
>
> I can understand that goal, and it is a good goal to strive for, but
> conciseness is one of the last things Java aims to provide as a language or
> through its standard library. I won't tell you not to do it, but I will
> tell you that there will be significant push back from folks here, and for
> good reason -- conciseness is not the priority here at Java. At Java, the
> lack of conciseness is not a weakness. Sure, unneeded verbosity can be a
> weakness, but the solution I suggested above is basically the tempo that
> Java strives for -- compose simple concepts so that you can create what you
> need.
>
> All of that is to say, you have made your point clear. You goal is
> conciseness and ease of access. Understanding that, it's clear that my
> solution is not concise enough to meet that goal, so I won't push it
> further.
>
> On Fri, Apr 19, 2024 at 7:26?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> " 1. Fetching data from same-sized lists -- This is a trick from
>> Data-Oriented Design (not to be confused with Data-Oriented Programming)
>> where you filter down to the indexes that you want, and use the indexes to
>> fetch related values from the respective lists. So, I would filter down to
>> Player1, Player4, and Player6, then I would use their indexes to do lookups
>> in PlayerItemList, PlayerSkinList, etc. This tactic is especially useful
>> when working with structs (or value classes when Java gets them)."
>>
>> That was what i referred to as "Map-solvable" problems, but if this way
>> of doing it is a thing, then I agree with the point.
>>
>> "By this logic, many of the methods in the Stream library should instead
>> be in the Collection library. There are several emails on the lambda
>> mailing list that address why this wasn't done. I imagine that R?mi himself
>> could point them out to you."
>>
>> It may be just my opinion, but I don't see anything harmful in some
>> shortcuts that could be optimized, especially if they still converge to a
>> single point under the hood. I would love to read mails about maintainers'
>> opinions on why some features of Streams couldnt be also a part of
>> Collection library if it would enhance developer experience, so, if it
>> wouldn't be hard for you, could you attach some links? Also I guess a good
>> compromise would be extension methods, I am currently exploring
>> possibilities of their implementation.
>>
>> "Well hold on. I am not at all saying that it is redundant. I am saying
>> that the functionality that you desire can be easily recreated by using a
>> more far-reaching feature, the .withIndex() idea that R?mi suggested. I am
>> just trying to say that your idea probably should not be done on the List
>> interface."
>>
>> I am not saying that .withIndex() is a bad idea in any way. I can
>> remember several times when I was desperately looking for something like
>> python enumerate(), but all I found were some IntStream-based approaches.
>> What I am saying is, while there is definitely room for both, withIndex
>> does not solve the initial problem that motivated me to propose such
>> changes: redundant (emphasis on this) verbosity. The main reason I decided
>> to become an openjdk contributor is because I love to create tools that
>> make development easier and more pleasant, and I feel more sophisticated,
>> although a more specific API would deal much better with this task, and as
>> this is my personal priority, I would stand my ground here.
>>
>> "Regardless, Valhalla is not here yet. So at least for now, I will
>> concede your point about performance."
>>
>> Valhalla, at least for now, is nowhere near to a release even as a
>> preview, would be great if it will get to Java releases until the next LTS.
>> I think that even, even for a 2-4 years, this point is valid, then it at
>> least should be taken into consideration.
>>
>> PS: As you might notice, I am a developer experience guy rather than a
>> flexible guy. My opinion is a result of some personal beliefs, but also is
>> an aggregation of opinions of numbers of other programmers that I
>> introduced to Java, especially switchers. Many of then feel those
>> "wordiness" of Java and it repulses potential developers, especially when
>> there is C# just by the corner. I think that Java has really strong sides,
>> but I would love to cover its "weaknesses" as well, especially if it
>> doesn't come with any maintenance burdens.
>>
>> ??, 20 ???. 2024??. ? 02:00, David Alayachew <davidalayachew at gmail.com>:
>>
>>> No confusion. You spoke clearly enough to be understood the first time.
>>>
>>> On Fri, Apr 19, 2024 at 6:28?PM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Regarding the first point in my last message. "Them" is referring to
>>>> the developer, and "evaluate" means to be processed by the developer. Sorry
>>>> for the potential confusion
>>>>
>>>> ??, 20 ???. 2024??. ? 00:52, ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com>:
>>>>
>>>>> I think that, while finding the index of a matching element is not a
>>>>> very common task, especially among commercial developers, when discussing
>>>>> indexed streams, this would be the most common use case. To be honest, I
>>>>> don't even see any other use cases right now, besides maybe some processing
>>>>> based on divisibility of index (odd/even as the most common one). I have a
>>>>> pretty strong background in competitive programming, more than 5 years, and
>>>>> can remember anything more complex than that that could not be replaced
>>>>> with Map usage.
>>>>>
>>>>> Regarding clarity, I fully agree with you. I am not a fan of those
>>>>> unreadable abbreviations in C/C++ or even in python. However, while it's
>>>>> hard to argue that your approach is more flexible, it has two downsides:
>>>>>
>>>>> 1. Although indexed streams are flexible, the flexibility might come
>>>>> at the cost of readability. Syntax like list.FindIndex is pretty
>>>>> straightforward and speaks for itself, while indexed-stream-based approach
>>>>> requires developer to explicitly evaluate what that chain of method does,
>>>>> which would distract them from understanding of general program logic flow,
>>>>> while usually being no more then utility. The reason for existence of
>>>>> findIndex is the same as for indexOf, so saying one is redundant means
>>>>> saying other one is redundant too.
>>>>>
>>>>> 2. Streams are performance-costy, thats the point that is hard to
>>>>> argue with. While list implementations could provide specified
>>>>> implementations of findIndex based on their internal structure, streams
>>>>> work only with generic interfaces. Moreover, even default implementation
>>>>> that uses ListIterator would be times faster and less resource consuming
>>>>> then generic stream-based approach. While I understand that performance is
>>>>> not as valuable as flexibility and clarity, it is still crucial, at least
>>>>> because of it being the main factor server maintenance cost after all.
>>>>>
>>>>> ??, 20 ???. 2024??. ? 00:32, David Alayachew <davidalayachew at gmail.com
>>>>> >:
>>>>>
>>>>>> It is not the goal of Java to be verbose, but it is also not the goal
>>>>>> of Java to be concise either. It is the goal of Java to be clear, correct,
>>>>>> and readable, in order to maximize maintainability, correctness, and
>>>>>> flexibility. When you focus on accomplishing that goal first, you will find
>>>>>> that conciseness takes care of itself.
>>>>>>
>>>>>> I understand that my approach is wordier than yours. Please also
>>>>>> consider that my suggestion does exactly one task -- stream an element with
>>>>>> its respective index. And yet, the number of ways that that can be used
>>>>>> covers hundreds of use cases while still being incredibly easy to maintain
>>>>>> and optimize. Far more than what you suggest. My feature easily composes
>>>>>> with others, with anything that can take a Stream<T> in fact.
>>>>>>
>>>>>> The bar to adding a feature to Java, even to its libraries, is high.
>>>>>> In fact, there is even a breaking point where a language/library can just
>>>>>> be too dense to work with. Too many methods, too much complexity.
>>>>>>
>>>>>> Java makes it a priority to limit adding features or functionality
>>>>>> wherever possible, only relenting when the benefit significantly outweighs
>>>>>> the cost. Adding a method like yours that only serves a tiny slice of use
>>>>>> cases just does not meet the goal of what Java is aiming for -- to get the
>>>>>> biggest bang for buck when adding a feature to language/library.
>>>>>>
>>>>>> I think that your pain point is significant and worth addressing. But
>>>>>> I think it should be done in a way that services a much larger group of
>>>>>> users and use cases. I think my idea does that.
>>>>>>
>>>>>> On Fri, Apr 19, 2024 at 5:14?PM ??-24 ????????? ?????? <
>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>
>>>>>>> streamWithIndex() is indeed an interesting approach, however,
>>>>>>> working with pairs of values is not always comfortable as this may make
>>>>>>> code too wordy, which may be fixed using things like properties and tuples
>>>>>>> (which I am currently working on right now btw), but still code like
>>>>>>> list.streamWithIndex().filter(Predicate).findFirst().orElse(-1) is still
>>>>>>> long, thats why i think there is room for both in Java.
>>>>>>>
>>>>>>> Also maybe instead of returning traditional -1 it would be more
>>>>>>> suitable to use OptionalInt instead, but I would like to hear community
>>>>>>> opinion about that.
>>>>>>>
>>>>>>> ??, 20 ???. 2024??. ? 00:02, David Alayachew <
>>>>>>> davidalayachew at gmail.com>:
>>>>>>>
>>>>>>>>
>>>>>>>> No R?mi, I don't think your idea is the right approach. You are
>>>>>>>> working on the wrong level of abstraction.
>>>>>>>>
>>>>>>>> Many users ask requests like this all the time, and what you are
>>>>>>>> suggesting would be even more error-prone than the equivalent for loop or the
>>>>>>>> IntStream suggestion that the user above requested. Not to mention
>>>>>>>> that getting it to parallelize would be a task many users are likely to
>>>>>>>> mess up -- either in correctness or in performance.
>>>>>>>>
>>>>>>>> I think you would get far more mileage from adding 2 methods on the
>>>>>>>> list interface streamWithIndex() and parallelStreamWithIndex() that would
>>>>>>>> return a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>>>>>>>
>>>>>>>> That way, users are not writing a custom Gatherer each time they
>>>>>>>> want to work with the index. They just have the index be a field in the
>>>>>>>> object. They can work with it the same way they would any other object
>>>>>>>> field.
>>>>>>>>
>>>>>>>> Furthermore, doing it this way makes the correct answer obvious. If
>>>>>>>> I need to do something with an index, stream with the index.
>>>>>>>>
>>>>>>>> On top of that, it significantly enhances readability by making it
>>>>>>>> clear to the reader that, whatever this stream is doing will require use of
>>>>>>>> the index, so watch out for that.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>> for me, it seems what you want is  Collector on Stream which is
>>>>>>>>> able to short-circuit,
>>>>>>>>> so you can write
>>>>>>>>>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
>>>>>>>>> and in reverse
>>>>>>>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>>>>>>>> s.contains("o")))
>>>>>>>>>
>>>>>>>>> Using a Stream here is more general and will work with other
>>>>>>>>> collections like a LinkedHashSet for example.
>>>>>>>>> Sadly, there is no way to define a short-circuiting collector :(
>>>>>>>>>
>>>>>>>>> You can have a short-circuiting Gatherer like this
>>>>>>>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T>
>>>>>>>>> predicate) {
>>>>>>>>>     return Gatherer.ofSequential(
>>>>>>>>>       () -> new Object() { int index; },
>>>>>>>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>>>>>>>         var index = state.index++;
>>>>>>>>>         if (predicate.test(element)) {
>>>>>>>>>           return downstream.push(index);
>>>>>>>>>         }
>>>>>>>>>         return true;
>>>>>>>>>       }));
>>>>>>>>>   }
>>>>>>>>>
>>>>>>>>> and use it like this:
>>>>>>>>>   list.stream().gather(findIndex(s ->
>>>>>>>>> s.contains("o"))).findFirst().orElse(-1);
>>>>>>>>>
>>>>>>>>> But it's more verbose.
>>>>>>>>>
>>>>>>>>> I wonder if at the same time that the Gatherer API is introduced,
>>>>>>>>> the Collector API should be enhanced to support short-circuiting collectors
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>> R?mi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------
>>>>>>>>>
>>>>>>>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>>>>>>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>>>>>>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>>>>>>>> *Subject: *Addition of Predicate-based findIndex and
>>>>>>>>> findLastIndex methods to java.util.List
>>>>>>>>>
>>>>>>>>> Subject
>>>>>>>>> Addition of Predicate-based findIndex and findLastIndex methods to
>>>>>>>>> java.util.List
>>>>>>>>>
>>>>>>>>> Motivation
>>>>>>>>> The motivation behind this proposal is to enhance the
>>>>>>>>> functionality of the List interface by providing a more flexible way to
>>>>>>>>> find the index of an element. Currently, the indexOf and lastIndexOf
>>>>>>>>> methods only accept an object as a parameter. This limits the flexibility
>>>>>>>>> of these methods as they can only find the index of exact object matches.
>>>>>>>>>
>>>>>>>>> Here I want to propose methods that would accept a Predicate as a
>>>>>>>>> parameter, allowing users to define a condition that the desired element
>>>>>>>>> must meet. This would provide a more flexible and powerful way to find the
>>>>>>>>> index of an element in a list.
>>>>>>>>>
>>>>>>>>> The changes I am proposing are implemented in this PR:
>>>>>>>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief
>>>>>>>>> overview of the changes made in this pull request:
>>>>>>>>>
>>>>>>>>> Added the findIndex  (Predicate<? super E> filter) method to the
>>>>>>>>> List interface.
>>>>>>>>> Added the findLastIndex  (Predicate<? super E> filter) method to
>>>>>>>>> the List interface.
>>>>>>>>> Implemented these methods in all non-abstract classes that
>>>>>>>>> implement the List interface, as well as List itself (default impl).
>>>>>>>>> The changes have been thoroughly tested to ensure they work as
>>>>>>>>> expected and do not introduce any regressions. The test cases cover a
>>>>>>>>> variety of scenarios to ensure the robustness of the implementation.
>>>>>>>>>
>>>>>>>>> For example, consider the following test case:
>>>>>>>>>
>>>>>>>>> List<String> list = new ArrayList<>();
>>>>>>>>> list.add("Object one");
>>>>>>>>> list.add("NotObject two");
>>>>>>>>> list.add("NotObject three");
>>>>>>>>>
>>>>>>>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>>>>>>>> System.out.println(index1); // Expected output: 1
>>>>>>>>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>>>>>>>>> System.out.println(index2); // Expected output: 2
>>>>>>>>> Currently, to achieve the same result, we would have to use a more
>>>>>>>>> verbose approach:
>>>>>>>>>
>>>>>>>>> int index1 = IntStream.range(0, list.size())
>>>>>>>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>>>>>>>                      .findFirst()
>>>>>>>>>                      .orElse(-1);
>>>>>>>>> System.out.println(index1); // Output: 1
>>>>>>>>> int index2 = IntStream.range(0, list.size())
>>>>>>>>>                          .filter(i ->
>>>>>>>>> list.get(i).startsWith("NotObject"))
>>>>>>>>>                          .reduce((first, second) -> second)
>>>>>>>>>                          .orElse(-1);
>>>>>>>>> System.out.println(index2); // Output: 2
>>>>>>>>> Or other approaches that require additional instructions and,
>>>>>>>>> therefore, can`t be used in all scopes (like passing argument to method).
>>>>>>>>>
>>>>>>>>> I believe these additions would greatly enhance the functionality
>>>>>>>>> and flexibility of the List interface, making it more powerful and
>>>>>>>>> user-friendly. I look forward to your feedback and am open to making any
>>>>>>>>> necessary changes based on your suggestions.
>>>>>>>>>
>>>>>>>>> The main reason I am publishing this proposal in the mailing
>>>>>>>>> system is to gather feedback from the Java developers community, especially
>>>>>>>>> about possible caveats related to backward compatibility of your projects.
>>>>>>>>> Would appreciate every opinion!
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/8cb8729b/attachment-0001.htm>

From liach at openjdk.org  Sat Apr 20 04:28:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 20 Apr 2024 04:28:27 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs
In-Reply-To: <3RSkF8kVcoCwRonUyebeTF3xDDR9CohNpiU6oJdh028=.c596c79d-c2ae-4349-a29e-a14e0587608e@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
 <3RSkF8kVcoCwRonUyebeTF3xDDR9CohNpiU6oJdh028=.c596c79d-c2ae-4349-a29e-a14e0587608e@github.com>
Message-ID: <cSz4FEgQiTJB9fB_sO0sMuXaFBCAi86suq7l07dP3E0=.d321d3a0-3a4f-495c-b2e3-34d82ced0f31@github.com>

On Fri, 19 Apr 2024 23:56:00 GMT, ExE Boss <duke at openjdk.org> wrote:

>> We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 699:
> 
>> 697: 
>> 698:         public boolean equals(Object other) {
>> 699:             if (other instanceof TypePairs otherPair) {
> 
> To?match the?behaviour of?the?`equals` method?body generated by?`java?.lang?.runtime?.ObjectMethods?::bootstrap`, this?should?include a?fast?path check for?`this?==?other`:
> Suggestion:
> 
>             if (this == other) {
>                 return true;
>             }
>             if (other instanceof TypePairs otherPair) {

No, see https://www.youtube.com/watch?v=kuzjX_efuDs; this fast path is faster for == matching case but significantly slows down all other branches.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18865#discussion_r1573146432

From kvn at openjdk.org  Sat Apr 20 04:31:34 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 20 Apr 2024 04:31:34 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]
In-Reply-To: <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
Message-ID: <0cg24YXFi4foGH_uKTY6JmABMhzjMH6gmH78iE0CC4w=.a52937a2-d728-4616-b158-a2a338cbb6f4@github.com>

On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Long to short jmp; other cleanup

`runtime/Unsafe/InternalErrorTest.java` test SIGBUS when run with `-Xcomp` (and other flags in test's @run command):

#  SIGBUS (0xa) at pc=0x0000000119514760, pid=63021, tid=28163
#
# JRE version: Java(TM) SE Runtime Environment (23.0) (fastdebug build 23-internal-2024-04-19-2326152.vladimir.kozlov.jdkgit2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-internal-2024-04-19-2326152.vladimir.kozlov.jdkgit2, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Problematic frame:
# v  ~StubRoutines::jbyte_fill 0x0000000119514760

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2067547078

From liangchenblue at gmail.com  Sat Apr 20 07:34:19 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 20 Apr 2024 02:34:19 -0500
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAP=Y=q8iGSx-OnSfu34k4qCh_5cZekOPHJ14=TKB8RKVPBeRig@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
 <CAA9v-_NptwV4UNo9V1YDB=1os5BViPgYkMkDXJWRgGZis6UdYw@mail.gmail.com>
 <CAP=Y=q8aPLwjmg_h3oSbR6ZPPUajocB1P2R1uRBWrYXn3j0LXg@mail.gmail.com>
 <CAP=Y=q88ppGhtuVEr4oe4N4LOPw4Fdhe9Au7dDOmw7JtObYnWw@mail.gmail.com>
 <CAA9v-_OpDb83_sfo9ge=KrH5YmpB+yD36hfS_r1wE6CsX5LTrQ@mail.gmail.com>
 <CAP=Y=q-a4wPT1mxFnVUV=X_8FA8rPc3E1jxLiDsw7ZVj4sGuCA@mail.gmail.com>
 <CAA9v-_P9xj4YCPFgS13ben54cq=yNe+3Wdxb5ktshbyOCwrHFA@mail.gmail.com>
 <CAP=Y=q8iGSx-OnSfu34k4qCh_5cZekOPHJ14=TKB8RKVPBeRig@mail.gmail.com>
Message-ID: <CABe8uE12YP=8e1ngufMavndBdbdPunNpS4m3r1yrQcjh+Pj+sw@mail.gmail.com>

Hi Rotan',
Interface methods are both exposed to callers and to implementations. Is
there any scenario where the implementation can be more efficient than the
stream/gatherer scanning approach?

indexOf or lastIndexOf may be faster if a list has some tricks like a
hashmap to quickly look up the index of an item. In contrast, the predicate
looks too generic and barely optimizable by list implementations; even if
we can stream in parallel, this is already covered by the stream API, so we
can simply declare a Gatherer to perform this findIndex operation on a
stream of elements (also note that a list can be reversed with
List::reversed() since JDK 21, so the same Gatherer can be reused for
findLastIndex)

I think if there is no scenario where implementation can do better with
findIndex, the findIndex should become a Gatherer, which has better
compatibility.

Best,
Chen Liang

On Fri, Apr 19, 2024 at 8:51?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Turned out this whole time I was only replying to David. I have to thank
> him for his patience explaining me how this whole mailing thing work.
>
> To summarize what has been missed out, besides what have you seen in
> quotes. I have pointed out that, while flexibility and simplicity is
> important, the main reason why I have decided to propose this feature is to
> enhance developer experience.
>
> I know that conciseness is not a main goal of Java, and therefore my
> proposal is kind of contradicts the general direction of development of
> Java as language, but my desire to make Java more user friendly is based on
> personal experience of introducing fresh devs or switchers to java and
> their feedback. Therefore, while it is not a priority for community, I
> really hope you guys don't mind me working at a backrank of Java making it
> a bit prettier.
>
> On Sat, Apr 20, 2024, 02:56 David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> > That was what i referred to as "Map-solvable" problems,
>> > but if this way of doing it is a thing, then I agree with
>> > the point.
>>
>> Doing it the Map way would not only be slower, but it would force you to
>> include more concepts than you need. Your identifier is your index.
>> Lists/arrays have index. Bringing a map in only complicates things.
>>
>> As for the rest of your response, I think I understand the trouble here.
>> You put it best when you said that you are introducing this feature with
>> the intent of improving the developer experience, specifically through
>> making code more concise.
>>
>> I can understand that goal, and it is a good goal to strive for, but
>> conciseness is one of the last things Java aims to provide as a language or
>> through its standard library. I won't tell you not to do it, but I will
>> tell you that there will be significant push back from folks here, and for
>> good reason -- conciseness is not the priority here at Java. At Java, the
>> lack of conciseness is not a weakness. Sure, unneeded verbosity can be a
>> weakness, but the solution I suggested above is basically the tempo that
>> Java strives for -- compose simple concepts so that you can create what you
>> need.
>>
>> All of that is to say, you have made your point clear. You goal is
>> conciseness and ease of access. Understanding that, it's clear that my
>> solution is not concise enough to meet that goal, so I won't push it
>> further.
>>
>> On Fri, Apr 19, 2024 at 7:26?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> " 1. Fetching data from same-sized lists -- This is a trick from
>>> Data-Oriented Design (not to be confused with Data-Oriented Programming)
>>> where you filter down to the indexes that you want, and use the indexes to
>>> fetch related values from the respective lists. So, I would filter down to
>>> Player1, Player4, and Player6, then I would use their indexes to do lookups
>>> in PlayerItemList, PlayerSkinList, etc. This tactic is especially useful
>>> when working with structs (or value classes when Java gets them)."
>>>
>>> That was what i referred to as "Map-solvable" problems, but if this way
>>> of doing it is a thing, then I agree with the point.
>>>
>>> "By this logic, many of the methods in the Stream library should
>>> instead be in the Collection library. There are several emails on the
>>> lambda mailing list that address why this wasn't done. I imagine that R?mi
>>> himself could point them out to you."
>>>
>>> It may be just my opinion, but I don't see anything harmful in some
>>> shortcuts that could be optimized, especially if they still converge to a
>>> single point under the hood. I would love to read mails about maintainers'
>>> opinions on why some features of Streams couldnt be also a part of
>>> Collection library if it would enhance developer experience, so, if it
>>> wouldn't be hard for you, could you attach some links? Also I guess a good
>>> compromise would be extension methods, I am currently exploring
>>> possibilities of their implementation.
>>>
>>> "Well hold on. I am not at all saying that it is redundant. I am saying
>>> that the functionality that you desire can be easily recreated by using a
>>> more far-reaching feature, the .withIndex() idea that R?mi suggested. I am
>>> just trying to say that your idea probably should not be done on the List
>>> interface."
>>>
>>> I am not saying that .withIndex() is a bad idea in any way. I can
>>> remember several times when I was desperately looking for something like
>>> python enumerate(), but all I found were some IntStream-based approaches.
>>> What I am saying is, while there is definitely room for both, withIndex
>>> does not solve the initial problem that motivated me to propose such
>>> changes: redundant (emphasis on this) verbosity. The main reason I decided
>>> to become an openjdk contributor is because I love to create tools that
>>> make development easier and more pleasant, and I feel more sophisticated,
>>> although a more specific API would deal much better with this task, and as
>>> this is my personal priority, I would stand my ground here.
>>>
>>> "Regardless, Valhalla is not here yet. So at least for now, I will
>>> concede your point about performance."
>>>
>>> Valhalla, at least for now, is nowhere near to a release even as a
>>> preview, would be great if it will get to Java releases until the next LTS.
>>> I think that even, even for a 2-4 years, this point is valid, then it at
>>> least should be taken into consideration.
>>>
>>> PS: As you might notice, I am a developer experience guy rather than a
>>> flexible guy. My opinion is a result of some personal beliefs, but also is
>>> an aggregation of opinions of numbers of other programmers that I
>>> introduced to Java, especially switchers. Many of then feel those
>>> "wordiness" of Java and it repulses potential developers, especially when
>>> there is C# just by the corner. I think that Java has really strong sides,
>>> but I would love to cover its "weaknesses" as well, especially if it
>>> doesn't come with any maintenance burdens.
>>>
>>> ??, 20 ???. 2024??. ? 02:00, David Alayachew <davidalayachew at gmail.com>:
>>>
>>>> No confusion. You spoke clearly enough to be understood the first time.
>>>>
>>>> On Fri, Apr 19, 2024 at 6:28?PM ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> Regarding the first point in my last message. "Them" is referring to
>>>>> the developer, and "evaluate" means to be processed by the developer. Sorry
>>>>> for the potential confusion
>>>>>
>>>>> ??, 20 ???. 2024??. ? 00:52, ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com>:
>>>>>
>>>>>> I think that, while finding the index of a matching element is not a
>>>>>> very common task, especially among commercial developers, when discussing
>>>>>> indexed streams, this would be the most common use case. To be honest, I
>>>>>> don't even see any other use cases right now, besides maybe some processing
>>>>>> based on divisibility of index (odd/even as the most common one). I have a
>>>>>> pretty strong background in competitive programming, more than 5 years, and
>>>>>> can remember anything more complex than that that could not be replaced
>>>>>> with Map usage.
>>>>>>
>>>>>> Regarding clarity, I fully agree with you. I am not a fan of those
>>>>>> unreadable abbreviations in C/C++ or even in python. However, while it's
>>>>>> hard to argue that your approach is more flexible, it has two downsides:
>>>>>>
>>>>>> 1. Although indexed streams are flexible, the flexibility might come
>>>>>> at the cost of readability. Syntax like list.FindIndex is pretty
>>>>>> straightforward and speaks for itself, while indexed-stream-based approach
>>>>>> requires developer to explicitly evaluate what that chain of method does,
>>>>>> which would distract them from understanding of general program logic flow,
>>>>>> while usually being no more then utility. The reason for existence of
>>>>>> findIndex is the same as for indexOf, so saying one is redundant means
>>>>>> saying other one is redundant too.
>>>>>>
>>>>>> 2. Streams are performance-costy, thats the point that is hard to
>>>>>> argue with. While list implementations could provide specified
>>>>>> implementations of findIndex based on their internal structure, streams
>>>>>> work only with generic interfaces. Moreover, even default implementation
>>>>>> that uses ListIterator would be times faster and less resource consuming
>>>>>> then generic stream-based approach. While I understand that performance is
>>>>>> not as valuable as flexibility and clarity, it is still crucial, at least
>>>>>> because of it being the main factor server maintenance cost after all.
>>>>>>
>>>>>> ??, 20 ???. 2024??. ? 00:32, David Alayachew <
>>>>>> davidalayachew at gmail.com>:
>>>>>>
>>>>>>> It is not the goal of Java to be verbose, but it is also not the
>>>>>>> goal of Java to be concise either. It is the goal of Java to be clear,
>>>>>>> correct, and readable, in order to maximize maintainability, correctness,
>>>>>>> and flexibility. When you focus on accomplishing that goal first, you will
>>>>>>> find that conciseness takes care of itself.
>>>>>>>
>>>>>>> I understand that my approach is wordier than yours. Please also
>>>>>>> consider that my suggestion does exactly one task -- stream an element with
>>>>>>> its respective index. And yet, the number of ways that that can be used
>>>>>>> covers hundreds of use cases while still being incredibly easy to maintain
>>>>>>> and optimize. Far more than what you suggest. My feature easily composes
>>>>>>> with others, with anything that can take a Stream<T> in fact.
>>>>>>>
>>>>>>> The bar to adding a feature to Java, even to its libraries, is high.
>>>>>>> In fact, there is even a breaking point where a language/library can just
>>>>>>> be too dense to work with. Too many methods, too much complexity.
>>>>>>>
>>>>>>> Java makes it a priority to limit adding features or functionality
>>>>>>> wherever possible, only relenting when the benefit significantly outweighs
>>>>>>> the cost. Adding a method like yours that only serves a tiny slice of use
>>>>>>> cases just does not meet the goal of what Java is aiming for -- to get the
>>>>>>> biggest bang for buck when adding a feature to language/library.
>>>>>>>
>>>>>>> I think that your pain point is significant and worth addressing.
>>>>>>> But I think it should be done in a way that services a much larger group of
>>>>>>> users and use cases. I think my idea does that.
>>>>>>>
>>>>>>> On Fri, Apr 19, 2024 at 5:14?PM ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> streamWithIndex() is indeed an interesting approach, however,
>>>>>>>> working with pairs of values is not always comfortable as this may make
>>>>>>>> code too wordy, which may be fixed using things like properties and tuples
>>>>>>>> (which I am currently working on right now btw), but still code like
>>>>>>>> list.streamWithIndex().filter(Predicate).findFirst().orElse(-1) is still
>>>>>>>> long, thats why i think there is room for both in Java.
>>>>>>>>
>>>>>>>> Also maybe instead of returning traditional -1 it would be more
>>>>>>>> suitable to use OptionalInt instead, but I would like to hear community
>>>>>>>> opinion about that.
>>>>>>>>
>>>>>>>> ??, 20 ???. 2024??. ? 00:02, David Alayachew <
>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> No R?mi, I don't think your idea is the right approach. You are
>>>>>>>>> working on the wrong level of abstraction.
>>>>>>>>>
>>>>>>>>> Many users ask requests like this all the time, and what you are
>>>>>>>>> suggesting would be even more error-prone than the equivalent for loop or the
>>>>>>>>> IntStream suggestion that the user above requested. Not to mention
>>>>>>>>> that getting it to parallelize would be a task many users are likely to
>>>>>>>>> mess up -- either in correctness or in performance.
>>>>>>>>>
>>>>>>>>> I think you would get far more mileage from adding 2 methods on
>>>>>>>>> the list interface streamWithIndex() and parallelStreamWithIndex() that
>>>>>>>>> would return a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>>>>>>>>
>>>>>>>>> That way, users are not writing a custom Gatherer each time they
>>>>>>>>> want to work with the index. They just have the index be a field in the
>>>>>>>>> object. They can work with it the same way they would any other object
>>>>>>>>> field.
>>>>>>>>>
>>>>>>>>> Furthermore, doing it this way makes the correct answer obvious.
>>>>>>>>> If I need to do something with an index, stream with the index.
>>>>>>>>>
>>>>>>>>> On top of that, it significantly enhances readability by making it
>>>>>>>>> clear to the reader that, whatever this stream is doing will require use of
>>>>>>>>> the index, so watch out for that.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>> for me, it seems what you want is  Collector on Stream which is
>>>>>>>>>> able to short-circuit,
>>>>>>>>>> so you can write
>>>>>>>>>>   list.stream().collect(Collectors.findFirst(s ->
>>>>>>>>>> s.contains("o")))
>>>>>>>>>> and in reverse
>>>>>>>>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>>>>>>>>> s.contains("o")))
>>>>>>>>>>
>>>>>>>>>> Using a Stream here is more general and will work with other
>>>>>>>>>> collections like a LinkedHashSet for example.
>>>>>>>>>> Sadly, there is no way to define a short-circuiting collector :(
>>>>>>>>>>
>>>>>>>>>> You can have a short-circuiting Gatherer like this
>>>>>>>>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T>
>>>>>>>>>> predicate) {
>>>>>>>>>>     return Gatherer.ofSequential(
>>>>>>>>>>       () -> new Object() { int index; },
>>>>>>>>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>>>>>>>>         var index = state.index++;
>>>>>>>>>>         if (predicate.test(element)) {
>>>>>>>>>>           return downstream.push(index);
>>>>>>>>>>         }
>>>>>>>>>>         return true;
>>>>>>>>>>       }));
>>>>>>>>>>   }
>>>>>>>>>>
>>>>>>>>>> and use it like this:
>>>>>>>>>>   list.stream().gather(findIndex(s ->
>>>>>>>>>> s.contains("o"))).findFirst().orElse(-1);
>>>>>>>>>>
>>>>>>>>>> But it's more verbose.
>>>>>>>>>>
>>>>>>>>>> I wonder if at the same time that the Gatherer API is introduced,
>>>>>>>>>> the Collector API should be enhanced to support short-circuiting collectors
>>>>>>>>>> ?
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> R?mi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------
>>>>>>>>>>
>>>>>>>>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>>>>>>>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>>>>>>>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>>>>>>>>> *Subject: *Addition of Predicate-based findIndex and
>>>>>>>>>> findLastIndex methods to java.util.List
>>>>>>>>>>
>>>>>>>>>> Subject
>>>>>>>>>> Addition of Predicate-based findIndex and findLastIndex methods
>>>>>>>>>> to java.util.List
>>>>>>>>>>
>>>>>>>>>> Motivation
>>>>>>>>>> The motivation behind this proposal is to enhance the
>>>>>>>>>> functionality of the List interface by providing a more flexible way to
>>>>>>>>>> find the index of an element. Currently, the indexOf and lastIndexOf
>>>>>>>>>> methods only accept an object as a parameter. This limits the flexibility
>>>>>>>>>> of these methods as they can only find the index of exact object matches.
>>>>>>>>>>
>>>>>>>>>> Here I want to propose methods that would accept a Predicate as a
>>>>>>>>>> parameter, allowing users to define a condition that the desired element
>>>>>>>>>> must meet. This would provide a more flexible and powerful way to find the
>>>>>>>>>> index of an element in a list.
>>>>>>>>>>
>>>>>>>>>> The changes I am proposing are implemented in this PR:
>>>>>>>>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief
>>>>>>>>>> overview of the changes made in this pull request:
>>>>>>>>>>
>>>>>>>>>> Added the findIndex  (Predicate<? super E> filter) method to the
>>>>>>>>>> List interface.
>>>>>>>>>> Added the findLastIndex  (Predicate<? super E> filter) method to
>>>>>>>>>> the List interface.
>>>>>>>>>> Implemented these methods in all non-abstract classes that
>>>>>>>>>> implement the List interface, as well as List itself (default impl).
>>>>>>>>>> The changes have been thoroughly tested to ensure they work as
>>>>>>>>>> expected and do not introduce any regressions. The test cases cover a
>>>>>>>>>> variety of scenarios to ensure the robustness of the implementation.
>>>>>>>>>>
>>>>>>>>>> For example, consider the following test case:
>>>>>>>>>>
>>>>>>>>>> List<String> list = new ArrayList<>();
>>>>>>>>>> list.add("Object one");
>>>>>>>>>> list.add("NotObject two");
>>>>>>>>>> list.add("NotObject three");
>>>>>>>>>>
>>>>>>>>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>>>>>>>>> System.out.println(index1); // Expected output: 1
>>>>>>>>>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>>>>>>>>>> System.out.println(index2); // Expected output: 2
>>>>>>>>>> Currently, to achieve the same result, we would have to use a
>>>>>>>>>> more verbose approach:
>>>>>>>>>>
>>>>>>>>>> int index1 = IntStream.range(0, list.size())
>>>>>>>>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>>>>>>>>                      .findFirst()
>>>>>>>>>>                      .orElse(-1);
>>>>>>>>>> System.out.println(index1); // Output: 1
>>>>>>>>>> int index2 = IntStream.range(0, list.size())
>>>>>>>>>>                          .filter(i ->
>>>>>>>>>> list.get(i).startsWith("NotObject"))
>>>>>>>>>>                          .reduce((first, second) -> second)
>>>>>>>>>>                          .orElse(-1);
>>>>>>>>>> System.out.println(index2); // Output: 2
>>>>>>>>>> Or other approaches that require additional instructions and,
>>>>>>>>>> therefore, can`t be used in all scopes (like passing argument to method).
>>>>>>>>>>
>>>>>>>>>> I believe these additions would greatly enhance the functionality
>>>>>>>>>> and flexibility of the List interface, making it more powerful and
>>>>>>>>>> user-friendly. I look forward to your feedback and am open to making any
>>>>>>>>>> necessary changes based on your suggestions.
>>>>>>>>>>
>>>>>>>>>> The main reason I am publishing this proposal in the mailing
>>>>>>>>>> system is to gather feedback from the Java developers community, especially
>>>>>>>>>> about possible caveats related to backward compatibility of your projects.
>>>>>>>>>> Would appreciate every opinion!
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>>
>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/e23fb8b6/attachment-0001.htm>

From liach at openjdk.org  Sat Apr 20 07:42:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 20 Apr 2024 07:42:27 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs
In-Reply-To: <3RSkF8kVcoCwRonUyebeTF3xDDR9CohNpiU6oJdh028=.c596c79d-c2ae-4349-a29e-a14e0587608e@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
 <3RSkF8kVcoCwRonUyebeTF3xDDR9CohNpiU6oJdh028=.c596c79d-c2ae-4349-a29e-a14e0587608e@github.com>
Message-ID: <EaFhjARsnijEKxHr-RmRGOuDcjLKpYbomIIsR-CXLls=.5d03abab-e703-460b-89ff-431d80d32123@github.com>

On Sat, 20 Apr 2024 00:00:54 GMT, ExE Boss <duke at openjdk.org> wrote:

>> We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 685:
> 
>> 683:     record TypePairs(Class<?> from, Class<?> to) {
>> 684: 
>> 685:         private static final Map<TypePairs, String> typePairToName = initialize();
> 
> If?`TypePairs.typePairToName` is?never modified after initialisation, then?it?should probably be?made immutable:
> Suggestion:
> 
>         private static final Map<TypePairs, String> typePairToName = Map.copyOf(initialize());

If you really think about it, the `initialize` method itself is somewhat problematic, as it's initializing with byte/short/char on the left, all of which are already converted to int in the of() factory. This should be done in a separate issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18865#discussion_r1573195851

From vklang at openjdk.org  Sat Apr 20 09:09:33 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 20 Apr 2024 09:09:33 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v22]
In-Reply-To: <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>
Message-ID: <dwmTSf23ERx4mDzpo9Ss-HMcMZ7Nqfox9KYOkOv5fi0=.98571b54-46a0-478d-991a-53afa6b2df1e@github.com>

On Fri, 5 Apr 2024 23:13:39 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another update to reachabilityFence() @apiNote

Thanks Brent, I have no objections. Good job!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16644#issuecomment-2067611311

From duke at openjdk.org  Sat Apr 20 09:39:29 2024
From: duke at openjdk.org (Jin Kwon)
Date: Sat, 20 Apr 2024 09:39:29 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc
Message-ID: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>

Fix typos within the `DatabaseMetaData.java`.

-------------

Commit messages:
 - Merge branch 'master' of github.com:onacit/jdk
 - Merge branch 'master' of github.com:onacit/jdk
 - Fix more typos
 - Fix typo
 - Fix wrongly typed constant name
 - Fix more typos
 - Fix typo
 - Fix wrongly typed constant name
 - Fix more typos
 - Fix typo

Changes: https://git.openjdk.org/jdk/pull/18860/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330686
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18860/head:pull/18860

PR: https://git.openjdk.org/jdk/pull/18860

From duke at openjdk.org  Sat Apr 20 09:39:29 2024
From: duke at openjdk.org (Jin Kwon)
Date: Sat, 20 Apr 2024 09:39:29 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc
In-Reply-To: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
Message-ID: <WtqOulto50ud2yGKozJZu5-teIzxsl4hpQhnxP6YRC8=.c966d195-35aa-4359-84f7-616f192fbc87@github.com>

On Fri, 19 Apr 2024 11:33:48 GMT, Jin Kwon <duke at openjdk.org> wrote:

> Fix typos within the `DatabaseMetaData.java`.

@openjdk with issue from where?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18860#issuecomment-2066389888

From jpai at openjdk.org  Sat Apr 20 09:39:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Apr 2024 09:39:29 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc
In-Reply-To: <WtqOulto50ud2yGKozJZu5-teIzxsl4hpQhnxP6YRC8=.c966d195-35aa-4359-84f7-616f192fbc87@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <WtqOulto50ud2yGKozJZu5-teIzxsl4hpQhnxP6YRC8=.c966d195-35aa-4359-84f7-616f192fbc87@github.com>
Message-ID: <77Nuy6hcSJ95ZGo9oYlqQIkdOp_0AbfYH5mraayr8fM=.f2738151-e479-4ae8-aa91-20ca3ec93bb8@github.com>

On Fri, 19 Apr 2024 11:36:48 GMT, Jin Kwon <duke at openjdk.org> wrote:

>> Fix typos within the `DatabaseMetaData.java`.
>
> @openjdk with issue from where?

Hello @onacit, it appears a JBS issue has been filed for this https://bugs.openjdk.org/browse/JDK-8330686. Please change the title of this PR to `8330686: Fix typos in the DatabaseMetaData javadoc` so that it triggers the official review process.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18860#issuecomment-2067548609

From holo3146 at gmail.com  Sat Apr 20 11:09:59 2024
From: holo3146 at gmail.com (Holo The Sage Wolf)
Date: Sat, 20 Apr 2024 14:09:59 +0300
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CABe8uE12YP=8e1ngufMavndBdbdPunNpS4m3r1yrQcjh+Pj+sw@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
 <CAA9v-_NptwV4UNo9V1YDB=1os5BViPgYkMkDXJWRgGZis6UdYw@mail.gmail.com>
 <CAP=Y=q8aPLwjmg_h3oSbR6ZPPUajocB1P2R1uRBWrYXn3j0LXg@mail.gmail.com>
 <CAP=Y=q88ppGhtuVEr4oe4N4LOPw4Fdhe9Au7dDOmw7JtObYnWw@mail.gmail.com>
 <CAA9v-_OpDb83_sfo9ge=KrH5YmpB+yD36hfS_r1wE6CsX5LTrQ@mail.gmail.com>
 <CAP=Y=q-a4wPT1mxFnVUV=X_8FA8rPc3E1jxLiDsw7ZVj4sGuCA@mail.gmail.com>
 <CAA9v-_P9xj4YCPFgS13ben54cq=yNe+3Wdxb5ktshbyOCwrHFA@mail.gmail.com>
 <CAP=Y=q8iGSx-OnSfu34k4qCh_5cZekOPHJ14=TKB8RKVPBeRig@mail.gmail.com>
 <CABe8uE12YP=8e1ngufMavndBdbdPunNpS4m3r1yrQcjh+Pj+sw@mail.gmail.com>
Message-ID: <CAKswmE5gUzXnn=DzKUSM+_Z0qQHQYZ-hy8qWR+TpnY9k0zS2HA@mail.gmail.com>

Hello,

I want to challenge the idea that every stream may be indexed for 3 reasons:

Any sensible type to use for an index (int/long) will be bounded, but
streams need not, e.g.
    new Random().ints().withIndex().forEach(v -> ...);
May result (after a very long time) non sensical values. Using bigInteger
will solve this problem but would be silly as in practice 99.99999% of the
times long is more than enough (and 90% int is probably enough)

The two other problems have to do with the semantics of "index":
Index gives the impression that the "index" is a real position, but the
stream may be truly non deterministic (using e.g. Hardware Random Stream)
Index gives the impression that the "index" respects the canonical order of
the underlying collection (if exists), that is:
var x = myList.stream().parallel()
                .withIndex().findAny().get();
assert x.value() == myList.get(x.index()); // implementation dependent

Which I don't think is possible without enormous performance problems.

---

To be clear about my position: I like and want the idea. The first problem,
in my opinion, shouldn't block it, but we should document it. That being
said, I don't think we should be calling this "index".

On Sat, 20 Apr 2024, 11:54 -, <liangchenblue at gmail.com> wrote:

> Hi Rotan',
> Interface methods are both exposed to callers and to implementations. Is
> there any scenario where the implementation can be more efficient than the
> stream/gatherer scanning approach?
>
> indexOf or lastIndexOf may be faster if a list has some tricks like a
> hashmap to quickly look up the index of an item. In contrast, the predicate
> looks too generic and barely optimizable by list implementations; even if
> we can stream in parallel, this is already covered by the stream API, so we
> can simply declare a Gatherer to perform this findIndex operation on a
> stream of elements (also note that a list can be reversed with
> List::reversed() since JDK 21, so the same Gatherer can be reused for
> findLastIndex)
>
> I think if there is no scenario where implementation can do better with
> findIndex, the findIndex should become a Gatherer, which has better
> compatibility.
>
> Best,
> Chen Liang
>
> On Fri, Apr 19, 2024 at 8:51?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> Turned out this whole time I was only replying to David. I have to thank
>> him for his patience explaining me how this whole mailing thing work.
>>
>> To summarize what has been missed out, besides what have you seen in
>> quotes. I have pointed out that, while flexibility and simplicity is
>> important, the main reason why I have decided to propose this feature is to
>> enhance developer experience.
>>
>> I know that conciseness is not a main goal of Java, and therefore my
>> proposal is kind of contradicts the general direction of development of
>> Java as language, but my desire to make Java more user friendly is based on
>> personal experience of introducing fresh devs or switchers to java and
>> their feedback. Therefore, while it is not a priority for community, I
>> really hope you guys don't mind me working at a backrank of Java making it
>> a bit prettier.
>>
>> On Sat, Apr 20, 2024, 02:56 David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> > That was what i referred to as "Map-solvable" problems,
>>> > but if this way of doing it is a thing, then I agree with
>>> > the point.
>>>
>>> Doing it the Map way would not only be slower, but it would force you to
>>> include more concepts than you need. Your identifier is your index.
>>> Lists/arrays have index. Bringing a map in only complicates things.
>>>
>>> As for the rest of your response, I think I understand the trouble here.
>>> You put it best when you said that you are introducing this feature with
>>> the intent of improving the developer experience, specifically through
>>> making code more concise.
>>>
>>> I can understand that goal, and it is a good goal to strive for, but
>>> conciseness is one of the last things Java aims to provide as a language or
>>> through its standard library. I won't tell you not to do it, but I will
>>> tell you that there will be significant push back from folks here, and for
>>> good reason -- conciseness is not the priority here at Java. At Java, the
>>> lack of conciseness is not a weakness. Sure, unneeded verbosity can be a
>>> weakness, but the solution I suggested above is basically the tempo that
>>> Java strives for -- compose simple concepts so that you can create what you
>>> need.
>>>
>>> All of that is to say, you have made your point clear. You goal is
>>> conciseness and ease of access. Understanding that, it's clear that my
>>> solution is not concise enough to meet that goal, so I won't push it
>>> further.
>>>
>>> On Fri, Apr 19, 2024 at 7:26?PM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> " 1. Fetching data from same-sized lists -- This is a trick from
>>>> Data-Oriented Design (not to be confused with Data-Oriented Programming)
>>>> where you filter down to the indexes that you want, and use the indexes to
>>>> fetch related values from the respective lists. So, I would filter down to
>>>> Player1, Player4, and Player6, then I would use their indexes to do lookups
>>>> in PlayerItemList, PlayerSkinList, etc. This tactic is especially useful
>>>> when working with structs (or value classes when Java gets them)."
>>>>
>>>> That was what i referred to as "Map-solvable" problems, but if this way
>>>> of doing it is a thing, then I agree with the point.
>>>>
>>>> "By this logic, many of the methods in the Stream library should
>>>> instead be in the Collection library. There are several emails on the
>>>> lambda mailing list that address why this wasn't done. I imagine that R?mi
>>>> himself could point them out to you."
>>>>
>>>> It may be just my opinion, but I don't see anything harmful in some
>>>> shortcuts that could be optimized, especially if they still converge to a
>>>> single point under the hood. I would love to read mails about maintainers'
>>>> opinions on why some features of Streams couldnt be also a part of
>>>> Collection library if it would enhance developer experience, so, if it
>>>> wouldn't be hard for you, could you attach some links? Also I guess a good
>>>> compromise would be extension methods, I am currently exploring
>>>> possibilities of their implementation.
>>>>
>>>> "Well hold on. I am not at all saying that it is redundant. I am saying
>>>> that the functionality that you desire can be easily recreated by using a
>>>> more far-reaching feature, the .withIndex() idea that R?mi suggested. I am
>>>> just trying to say that your idea probably should not be done on the List
>>>> interface."
>>>>
>>>> I am not saying that .withIndex() is a bad idea in any way. I can
>>>> remember several times when I was desperately looking for something like
>>>> python enumerate(), but all I found were some IntStream-based approaches.
>>>> What I am saying is, while there is definitely room for both, withIndex
>>>> does not solve the initial problem that motivated me to propose such
>>>> changes: redundant (emphasis on this) verbosity. The main reason I decided
>>>> to become an openjdk contributor is because I love to create tools that
>>>> make development easier and more pleasant, and I feel more sophisticated,
>>>> although a more specific API would deal much better with this task, and as
>>>> this is my personal priority, I would stand my ground here.
>>>>
>>>> "Regardless, Valhalla is not here yet. So at least for now, I will
>>>> concede your point about performance."
>>>>
>>>> Valhalla, at least for now, is nowhere near to a release even as a
>>>> preview, would be great if it will get to Java releases until the next LTS.
>>>> I think that even, even for a 2-4 years, this point is valid, then it at
>>>> least should be taken into consideration.
>>>>
>>>> PS: As you might notice, I am a developer experience guy rather than a
>>>> flexible guy. My opinion is a result of some personal beliefs, but also is
>>>> an aggregation of opinions of numbers of other programmers that I
>>>> introduced to Java, especially switchers. Many of then feel those
>>>> "wordiness" of Java and it repulses potential developers, especially when
>>>> there is C# just by the corner. I think that Java has really strong sides,
>>>> but I would love to cover its "weaknesses" as well, especially if it
>>>> doesn't come with any maintenance burdens.
>>>>
>>>> ??, 20 ???. 2024??. ? 02:00, David Alayachew <davidalayachew at gmail.com
>>>> >:
>>>>
>>>>> No confusion. You spoke clearly enough to be understood the first time.
>>>>>
>>>>> On Fri, Apr 19, 2024 at 6:28?PM ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> Regarding the first point in my last message. "Them" is referring to
>>>>>> the developer, and "evaluate" means to be processed by the developer. Sorry
>>>>>> for the potential confusion
>>>>>>
>>>>>> ??, 20 ???. 2024??. ? 00:52, ??-24 ????????? ?????? <
>>>>>> rotan.olexandr at gmail.com>:
>>>>>>
>>>>>>> I think that, while finding the index of a matching element is not a
>>>>>>> very common task, especially among commercial developers, when discussing
>>>>>>> indexed streams, this would be the most common use case. To be honest, I
>>>>>>> don't even see any other use cases right now, besides maybe some processing
>>>>>>> based on divisibility of index (odd/even as the most common one). I have a
>>>>>>> pretty strong background in competitive programming, more than 5 years, and
>>>>>>> can remember anything more complex than that that could not be replaced
>>>>>>> with Map usage.
>>>>>>>
>>>>>>> Regarding clarity, I fully agree with you. I am not a fan of those
>>>>>>> unreadable abbreviations in C/C++ or even in python. However, while it's
>>>>>>> hard to argue that your approach is more flexible, it has two downsides:
>>>>>>>
>>>>>>> 1. Although indexed streams are flexible, the flexibility might come
>>>>>>> at the cost of readability. Syntax like list.FindIndex is pretty
>>>>>>> straightforward and speaks for itself, while indexed-stream-based approach
>>>>>>> requires developer to explicitly evaluate what that chain of method does,
>>>>>>> which would distract them from understanding of general program logic flow,
>>>>>>> while usually being no more then utility. The reason for existence of
>>>>>>> findIndex is the same as for indexOf, so saying one is redundant means
>>>>>>> saying other one is redundant too.
>>>>>>>
>>>>>>> 2. Streams are performance-costy, thats the point that is hard to
>>>>>>> argue with. While list implementations could provide specified
>>>>>>> implementations of findIndex based on their internal structure, streams
>>>>>>> work only with generic interfaces. Moreover, even default implementation
>>>>>>> that uses ListIterator would be times faster and less resource consuming
>>>>>>> then generic stream-based approach. While I understand that performance is
>>>>>>> not as valuable as flexibility and clarity, it is still crucial, at least
>>>>>>> because of it being the main factor server maintenance cost after all.
>>>>>>>
>>>>>>> ??, 20 ???. 2024??. ? 00:32, David Alayachew <
>>>>>>> davidalayachew at gmail.com>:
>>>>>>>
>>>>>>>> It is not the goal of Java to be verbose, but it is also not the
>>>>>>>> goal of Java to be concise either. It is the goal of Java to be clear,
>>>>>>>> correct, and readable, in order to maximize maintainability, correctness,
>>>>>>>> and flexibility. When you focus on accomplishing that goal first, you will
>>>>>>>> find that conciseness takes care of itself.
>>>>>>>>
>>>>>>>> I understand that my approach is wordier than yours. Please also
>>>>>>>> consider that my suggestion does exactly one task -- stream an element with
>>>>>>>> its respective index. And yet, the number of ways that that can be used
>>>>>>>> covers hundreds of use cases while still being incredibly easy to maintain
>>>>>>>> and optimize. Far more than what you suggest. My feature easily composes
>>>>>>>> with others, with anything that can take a Stream<T> in fact.
>>>>>>>>
>>>>>>>> The bar to adding a feature to Java, even to its libraries, is
>>>>>>>> high. In fact, there is even a breaking point where a language/library can
>>>>>>>> just be too dense to work with. Too many methods, too much complexity.
>>>>>>>>
>>>>>>>> Java makes it a priority to limit adding features or functionality
>>>>>>>> wherever possible, only relenting when the benefit significantly outweighs
>>>>>>>> the cost. Adding a method like yours that only serves a tiny slice of use
>>>>>>>> cases just does not meet the goal of what Java is aiming for -- to get the
>>>>>>>> biggest bang for buck when adding a feature to language/library.
>>>>>>>>
>>>>>>>> I think that your pain point is significant and worth addressing.
>>>>>>>> But I think it should be done in a way that services a much larger group of
>>>>>>>> users and use cases. I think my idea does that.
>>>>>>>>
>>>>>>>> On Fri, Apr 19, 2024 at 5:14?PM ??-24 ????????? ?????? <
>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> streamWithIndex() is indeed an interesting approach, however,
>>>>>>>>> working with pairs of values is not always comfortable as this may make
>>>>>>>>> code too wordy, which may be fixed using things like properties and tuples
>>>>>>>>> (which I am currently working on right now btw), but still code like
>>>>>>>>> list.streamWithIndex().filter(Predicate).findFirst().orElse(-1) is still
>>>>>>>>> long, thats why i think there is room for both in Java.
>>>>>>>>>
>>>>>>>>> Also maybe instead of returning traditional -1 it would be more
>>>>>>>>> suitable to use OptionalInt instead, but I would like to hear community
>>>>>>>>> opinion about that.
>>>>>>>>>
>>>>>>>>> ??, 20 ???. 2024??. ? 00:02, David Alayachew <
>>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No R?mi, I don't think your idea is the right approach. You are
>>>>>>>>>> working on the wrong level of abstraction.
>>>>>>>>>>
>>>>>>>>>> Many users ask requests like this all the time, and what you are
>>>>>>>>>> suggesting would be even more error-prone than the equivalent for loop or the
>>>>>>>>>> IntStream suggestion that the user above requested. Not to
>>>>>>>>>> mention that getting it to parallelize would be a task many users are
>>>>>>>>>> likely to mess up -- either in correctness or in performance.
>>>>>>>>>>
>>>>>>>>>> I think you would get far more mileage from adding 2 methods on
>>>>>>>>>> the list interface streamWithIndex() and parallelStreamWithIndex() that
>>>>>>>>>> would return a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>>>>>>>>>
>>>>>>>>>> That way, users are not writing a custom Gatherer each time they
>>>>>>>>>> want to work with the index. They just have the index be a field in the
>>>>>>>>>> object. They can work with it the same way they would any other object
>>>>>>>>>> field.
>>>>>>>>>>
>>>>>>>>>> Furthermore, doing it this way makes the correct answer obvious.
>>>>>>>>>> If I need to do something with an index, stream with the index.
>>>>>>>>>>
>>>>>>>>>> On top of that, it significantly enhances readability by making
>>>>>>>>>> it clear to the reader that, whatever this stream is doing will require use
>>>>>>>>>> of the index, so watch out for that.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>> for me, it seems what you want is  Collector on Stream which is
>>>>>>>>>>> able to short-circuit,
>>>>>>>>>>> so you can write
>>>>>>>>>>>   list.stream().collect(Collectors.findFirst(s ->
>>>>>>>>>>> s.contains("o")))
>>>>>>>>>>> and in reverse
>>>>>>>>>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>>>>>>>>>> s.contains("o")))
>>>>>>>>>>>
>>>>>>>>>>> Using a Stream here is more general and will work with other
>>>>>>>>>>> collections like a LinkedHashSet for example.
>>>>>>>>>>> Sadly, there is no way to define a short-circuiting collector :(
>>>>>>>>>>>
>>>>>>>>>>> You can have a short-circuiting Gatherer like this
>>>>>>>>>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T>
>>>>>>>>>>> predicate) {
>>>>>>>>>>>     return Gatherer.ofSequential(
>>>>>>>>>>>       () -> new Object() { int index; },
>>>>>>>>>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>>>>>>>>>         var index = state.index++;
>>>>>>>>>>>         if (predicate.test(element)) {
>>>>>>>>>>>           return downstream.push(index);
>>>>>>>>>>>         }
>>>>>>>>>>>         return true;
>>>>>>>>>>>       }));
>>>>>>>>>>>   }
>>>>>>>>>>>
>>>>>>>>>>> and use it like this:
>>>>>>>>>>>   list.stream().gather(findIndex(s ->
>>>>>>>>>>> s.contains("o"))).findFirst().orElse(-1);
>>>>>>>>>>>
>>>>>>>>>>> But it's more verbose.
>>>>>>>>>>>
>>>>>>>>>>> I wonder if at the same time that the Gatherer API is
>>>>>>>>>>> introduced, the Collector API should be enhanced to support
>>>>>>>>>>> short-circuiting collectors ?
>>>>>>>>>>>
>>>>>>>>>>> regards,
>>>>>>>>>>> R?mi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------
>>>>>>>>>>>
>>>>>>>>>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>>>>>>>>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>>>>>>>>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>>>>>>>>>> *Subject: *Addition of Predicate-based findIndex and
>>>>>>>>>>> findLastIndex methods to java.util.List
>>>>>>>>>>>
>>>>>>>>>>> Subject
>>>>>>>>>>> Addition of Predicate-based findIndex and findLastIndex methods
>>>>>>>>>>> to java.util.List
>>>>>>>>>>>
>>>>>>>>>>> Motivation
>>>>>>>>>>> The motivation behind this proposal is to enhance the
>>>>>>>>>>> functionality of the List interface by providing a more flexible way to
>>>>>>>>>>> find the index of an element. Currently, the indexOf and lastIndexOf
>>>>>>>>>>> methods only accept an object as a parameter. This limits the flexibility
>>>>>>>>>>> of these methods as they can only find the index of exact object matches.
>>>>>>>>>>>
>>>>>>>>>>> Here I want to propose methods that would accept a Predicate as
>>>>>>>>>>> a parameter, allowing users to define a condition that the desired element
>>>>>>>>>>> must meet. This would provide a more flexible and powerful way to find the
>>>>>>>>>>> index of an element in a list.
>>>>>>>>>>>
>>>>>>>>>>> The changes I am proposing are implemented in this PR:
>>>>>>>>>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief
>>>>>>>>>>> overview of the changes made in this pull request:
>>>>>>>>>>>
>>>>>>>>>>> Added the findIndex  (Predicate<? super E> filter) method to the
>>>>>>>>>>> List interface.
>>>>>>>>>>> Added the findLastIndex  (Predicate<? super E> filter) method to
>>>>>>>>>>> the List interface.
>>>>>>>>>>> Implemented these methods in all non-abstract classes that
>>>>>>>>>>> implement the List interface, as well as List itself (default impl).
>>>>>>>>>>> The changes have been thoroughly tested to ensure they work as
>>>>>>>>>>> expected and do not introduce any regressions. The test cases cover a
>>>>>>>>>>> variety of scenarios to ensure the robustness of the implementation.
>>>>>>>>>>>
>>>>>>>>>>> For example, consider the following test case:
>>>>>>>>>>>
>>>>>>>>>>> List<String> list = new ArrayList<>();
>>>>>>>>>>> list.add("Object one");
>>>>>>>>>>> list.add("NotObject two");
>>>>>>>>>>> list.add("NotObject three");
>>>>>>>>>>>
>>>>>>>>>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>>>>>>>>>> System.out.println(index1); // Expected output: 1
>>>>>>>>>>> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
>>>>>>>>>>> System.out.println(index2); // Expected output: 2
>>>>>>>>>>> Currently, to achieve the same result, we would have to use a
>>>>>>>>>>> more verbose approach:
>>>>>>>>>>>
>>>>>>>>>>> int index1 = IntStream.range(0, list.size())
>>>>>>>>>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>>>>>>>>>                      .findFirst()
>>>>>>>>>>>                      .orElse(-1);
>>>>>>>>>>> System.out.println(index1); // Output: 1
>>>>>>>>>>> int index2 = IntStream.range(0, list.size())
>>>>>>>>>>>                          .filter(i ->
>>>>>>>>>>> list.get(i).startsWith("NotObject"))
>>>>>>>>>>>                          .reduce((first, second) -> second)
>>>>>>>>>>>                          .orElse(-1);
>>>>>>>>>>> System.out.println(index2); // Output: 2
>>>>>>>>>>> Or other approaches that require additional instructions and,
>>>>>>>>>>> therefore, can`t be used in all scopes (like passing argument to method).
>>>>>>>>>>>
>>>>>>>>>>> I believe these additions would greatly enhance the
>>>>>>>>>>> functionality and flexibility of the List interface, making it more
>>>>>>>>>>> powerful and user-friendly. I look forward to your feedback and am open to
>>>>>>>>>>> making any necessary changes based on your suggestions.
>>>>>>>>>>>
>>>>>>>>>>> The main reason I am publishing this proposal in the mailing
>>>>>>>>>>> system is to gather feedback from the Java developers community, especially
>>>>>>>>>>> about possible caveats related to backward compatibility of your projects.
>>>>>>>>>>> Would appreciate every opinion!
>>>>>>>>>>>
>>>>>>>>>>> Best regards
>>>>>>>>>>>
>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/37d7d8ca/attachment-0001.htm>

From duke at openjdk.org  Sat Apr 20 11:53:36 2024
From: duke at openjdk.org (Korov)
Date: Sat, 20 Apr 2024 11:53:36 GMT
Subject: RFR: 8330624: Inconsistent use of semicolon in the code snippet of
 java.io.Serializable javadoc
Message-ID: <I2DZ3fh2RKeDrHs8Uyr4ky6YDHwCdo6t-UvOYAtkiK8=.1f90a822-8aed-4556-bc9a-ad70acbf12c0@github.com>

Fix the description of java.io.Serializable.

-------------

Commit messages:
 - Inconsistent use of semicolon in the code snippet of java.io.Serializable javadoc

Changes: https://git.openjdk.org/jdk/pull/18874/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330624
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18874.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18874/head:pull/18874

PR: https://git.openjdk.org/jdk/pull/18874

From rotan.olexandr at gmail.com  Sat Apr 20 12:02:04 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 15:02:04 +0300
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAKswmE5gUzXnn=DzKUSM+_Z0qQHQYZ-hy8qWR+TpnY9k0zS2HA@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
 <CAA9v-_NptwV4UNo9V1YDB=1os5BViPgYkMkDXJWRgGZis6UdYw@mail.gmail.com>
 <CAP=Y=q8aPLwjmg_h3oSbR6ZPPUajocB1P2R1uRBWrYXn3j0LXg@mail.gmail.com>
 <CAP=Y=q88ppGhtuVEr4oe4N4LOPw4Fdhe9Au7dDOmw7JtObYnWw@mail.gmail.com>
 <CAA9v-_OpDb83_sfo9ge=KrH5YmpB+yD36hfS_r1wE6CsX5LTrQ@mail.gmail.com>
 <CAP=Y=q-a4wPT1mxFnVUV=X_8FA8rPc3E1jxLiDsw7ZVj4sGuCA@mail.gmail.com>
 <CAA9v-_P9xj4YCPFgS13ben54cq=yNe+3Wdxb5ktshbyOCwrHFA@mail.gmail.com>
 <CAP=Y=q8iGSx-OnSfu34k4qCh_5cZekOPHJ14=TKB8RKVPBeRig@mail.gmail.com>
 <CABe8uE12YP=8e1ngufMavndBdbdPunNpS4m3r1yrQcjh+Pj+sw@mail.gmail.com>
 <CAKswmE5gUzXnn=DzKUSM+_Z0qQHQYZ-hy8qWR+TpnY9k0zS2HA@mail.gmail.com>
Message-ID: <CAP=Y=q99n_+-JRu-b2U0+RvvF4UL9fRHNgQn6rE7UOi-Kv+g1g@mail.gmail.com>

Regarding what Holo said, I think enumerated() would be a more suitable
name.

I have few ideas about implementation of such things, like separate
EnumeratedStream interface, which extends stream and provides methods like
forEach(BiConsumer<Integer, P_IN>), etc. This would eliminate unnecessary
object instantiation and also make stream interface more comfortable as
enumeration of steam won't require to consume index in every operation.\

Although it is an interesting and important topic, I have to ask you guys
to move it to another thread if possible. This thread already shifted
significantly from the original topic, which was potential compatibility
and API issues that I need to fix before applying for CSR.

??, 20 ???. 2024??. ? 14:10, Holo The Sage Wolf <holo3146 at gmail.com>:

> Hello,
>
> I want to challenge the idea that every stream may be indexed for 3
> reasons:
>
> Any sensible type to use for an index (int/long) will be bounded, but
> streams need not, e.g.
>     new Random().ints().withIndex().forEach(v -> ...);
> May result (after a very long time) non sensical values. Using bigInteger
> will solve this problem but would be silly as in practice 99.99999% of the
> times long is more than enough (and 90% int is probably enough)
>
> The two other problems have to do with the semantics of "index":
> Index gives the impression that the "index" is a real position, but the
> stream may be truly non deterministic (using e.g. Hardware Random Stream)
> Index gives the impression that the "index" respects the canonical order
> of the underlying collection (if exists), that is:
> var x = myList.stream().parallel()
>                 .withIndex().findAny().get();
> assert x.value() == myList.get(x.index()); // implementation dependent
>
> Which I don't think is possible without enormous performance problems.
>
> ---
>
> To be clear about my position: I like and want the idea. The first
> problem, in my opinion, shouldn't block it, but we should document it. That
> being said, I don't think we should be calling this "index".
>
> On Sat, 20 Apr 2024, 11:54 -, <liangchenblue at gmail.com> wrote:
>
>> Hi Rotan',
>> Interface methods are both exposed to callers and to implementations. Is
>> there any scenario where the implementation can be more efficient than the
>> stream/gatherer scanning approach?
>>
>> indexOf or lastIndexOf may be faster if a list has some tricks like a
>> hashmap to quickly look up the index of an item. In contrast, the predicate
>> looks too generic and barely optimizable by list implementations; even if
>> we can stream in parallel, this is already covered by the stream API, so we
>> can simply declare a Gatherer to perform this findIndex operation on a
>> stream of elements (also note that a list can be reversed with
>> List::reversed() since JDK 21, so the same Gatherer can be reused for
>> findLastIndex)
>>
>> I think if there is no scenario where implementation can do better with
>> findIndex, the findIndex should become a Gatherer, which has better
>> compatibility.
>>
>> Best,
>> Chen Liang
>>
>> On Fri, Apr 19, 2024 at 8:51?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Turned out this whole time I was only replying to David. I have to thank
>>> him for his patience explaining me how this whole mailing thing work.
>>>
>>> To summarize what has been missed out, besides what have you seen in
>>> quotes. I have pointed out that, while flexibility and simplicity is
>>> important, the main reason why I have decided to propose this feature is to
>>> enhance developer experience.
>>>
>>> I know that conciseness is not a main goal of Java, and therefore my
>>> proposal is kind of contradicts the general direction of development of
>>> Java as language, but my desire to make Java more user friendly is based on
>>> personal experience of introducing fresh devs or switchers to java and
>>> their feedback. Therefore, while it is not a priority for community, I
>>> really hope you guys don't mind me working at a backrank of Java making it
>>> a bit prettier.
>>>
>>> On Sat, Apr 20, 2024, 02:56 David Alayachew <davidalayachew at gmail.com>
>>> wrote:
>>>
>>>> > That was what i referred to as "Map-solvable" problems,
>>>> > but if this way of doing it is a thing, then I agree with
>>>> > the point.
>>>>
>>>> Doing it the Map way would not only be slower, but it would force you
>>>> to include more concepts than you need. Your identifier is your index.
>>>> Lists/arrays have index. Bringing a map in only complicates things.
>>>>
>>>> As for the rest of your response, I think I understand the trouble
>>>> here. You put it best when you said that you are introducing this feature
>>>> with the intent of improving the developer experience, specifically through
>>>> making code more concise.
>>>>
>>>> I can understand that goal, and it is a good goal to strive for, but
>>>> conciseness is one of the last things Java aims to provide as a language or
>>>> through its standard library. I won't tell you not to do it, but I will
>>>> tell you that there will be significant push back from folks here, and for
>>>> good reason -- conciseness is not the priority here at Java. At Java, the
>>>> lack of conciseness is not a weakness. Sure, unneeded verbosity can be a
>>>> weakness, but the solution I suggested above is basically the tempo that
>>>> Java strives for -- compose simple concepts so that you can create what you
>>>> need.
>>>>
>>>> All of that is to say, you have made your point clear. You goal is
>>>> conciseness and ease of access. Understanding that, it's clear that my
>>>> solution is not concise enough to meet that goal, so I won't push it
>>>> further.
>>>>
>>>> On Fri, Apr 19, 2024 at 7:26?PM ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> " 1. Fetching data from same-sized lists -- This is a trick from
>>>>> Data-Oriented Design (not to be confused with Data-Oriented Programming)
>>>>> where you filter down to the indexes that you want, and use the indexes to
>>>>> fetch related values from the respective lists. So, I would filter down to
>>>>> Player1, Player4, and Player6, then I would use their indexes to do lookups
>>>>> in PlayerItemList, PlayerSkinList, etc. This tactic is especially useful
>>>>> when working with structs (or value classes when Java gets them)."
>>>>>
>>>>> That was what i referred to as "Map-solvable" problems, but if this
>>>>> way of doing it is a thing, then I agree with the point.
>>>>>
>>>>> "By this logic, many of the methods in the Stream library should
>>>>> instead be in the Collection library. There are several emails on the
>>>>> lambda mailing list that address why this wasn't done. I imagine that R?mi
>>>>> himself could point them out to you."
>>>>>
>>>>> It may be just my opinion, but I don't see anything harmful in some
>>>>> shortcuts that could be optimized, especially if they still converge to a
>>>>> single point under the hood. I would love to read mails about maintainers'
>>>>> opinions on why some features of Streams couldnt be also a part of
>>>>> Collection library if it would enhance developer experience, so, if it
>>>>> wouldn't be hard for you, could you attach some links? Also I guess a good
>>>>> compromise would be extension methods, I am currently exploring
>>>>> possibilities of their implementation.
>>>>>
>>>>> "Well hold on. I am not at all saying that it is redundant. I am
>>>>> saying that the functionality that you desire can be easily recreated by
>>>>> using a more far-reaching feature, the .withIndex() idea that R?mi
>>>>> suggested. I am just trying to say that your idea probably should not be
>>>>> done on the List interface."
>>>>>
>>>>> I am not saying that .withIndex() is a bad idea in any way. I can
>>>>> remember several times when I was desperately looking for something like
>>>>> python enumerate(), but all I found were some IntStream-based approaches.
>>>>> What I am saying is, while there is definitely room for both, withIndex
>>>>> does not solve the initial problem that motivated me to propose such
>>>>> changes: redundant (emphasis on this) verbosity. The main reason I decided
>>>>> to become an openjdk contributor is because I love to create tools that
>>>>> make development easier and more pleasant, and I feel more sophisticated,
>>>>> although a more specific API would deal much better with this task, and as
>>>>> this is my personal priority, I would stand my ground here.
>>>>>
>>>>> "Regardless, Valhalla is not here yet. So at least for now, I will
>>>>> concede your point about performance."
>>>>>
>>>>> Valhalla, at least for now, is nowhere near to a release even as a
>>>>> preview, would be great if it will get to Java releases until the next LTS.
>>>>> I think that even, even for a 2-4 years, this point is valid, then it at
>>>>> least should be taken into consideration.
>>>>>
>>>>> PS: As you might notice, I am a developer experience guy rather than a
>>>>> flexible guy. My opinion is a result of some personal beliefs, but also is
>>>>> an aggregation of opinions of numbers of other programmers that I
>>>>> introduced to Java, especially switchers. Many of then feel those
>>>>> "wordiness" of Java and it repulses potential developers, especially when
>>>>> there is C# just by the corner. I think that Java has really strong sides,
>>>>> but I would love to cover its "weaknesses" as well, especially if it
>>>>> doesn't come with any maintenance burdens.
>>>>>
>>>>> ??, 20 ???. 2024??. ? 02:00, David Alayachew <davidalayachew at gmail.com
>>>>> >:
>>>>>
>>>>>> No confusion. You spoke clearly enough to be understood the first
>>>>>> time.
>>>>>>
>>>>>> On Fri, Apr 19, 2024 at 6:28?PM ??-24 ????????? ?????? <
>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>
>>>>>>> Regarding the first point in my last message. "Them" is referring to
>>>>>>> the developer, and "evaluate" means to be processed by the developer. Sorry
>>>>>>> for the potential confusion
>>>>>>>
>>>>>>> ??, 20 ???. 2024??. ? 00:52, ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com>:
>>>>>>>
>>>>>>>> I think that, while finding the index of a matching element is not
>>>>>>>> a very common task, especially among commercial developers, when discussing
>>>>>>>> indexed streams, this would be the most common use case. To be honest, I
>>>>>>>> don't even see any other use cases right now, besides maybe some processing
>>>>>>>> based on divisibility of index (odd/even as the most common one). I have a
>>>>>>>> pretty strong background in competitive programming, more than 5 years, and
>>>>>>>> can remember anything more complex than that that could not be replaced
>>>>>>>> with Map usage.
>>>>>>>>
>>>>>>>> Regarding clarity, I fully agree with you. I am not a fan of those
>>>>>>>> unreadable abbreviations in C/C++ or even in python. However, while it's
>>>>>>>> hard to argue that your approach is more flexible, it has two downsides:
>>>>>>>>
>>>>>>>> 1. Although indexed streams are flexible, the flexibility might
>>>>>>>> come at the cost of readability. Syntax like list.FindIndex is pretty
>>>>>>>> straightforward and speaks for itself, while indexed-stream-based approach
>>>>>>>> requires developer to explicitly evaluate what that chain of method does,
>>>>>>>> which would distract them from understanding of general program logic flow,
>>>>>>>> while usually being no more then utility. The reason for existence of
>>>>>>>> findIndex is the same as for indexOf, so saying one is redundant means
>>>>>>>> saying other one is redundant too.
>>>>>>>>
>>>>>>>> 2. Streams are performance-costy, thats the point that is hard to
>>>>>>>> argue with. While list implementations could provide specified
>>>>>>>> implementations of findIndex based on their internal structure, streams
>>>>>>>> work only with generic interfaces. Moreover, even default implementation
>>>>>>>> that uses ListIterator would be times faster and less resource consuming
>>>>>>>> then generic stream-based approach. While I understand that performance is
>>>>>>>> not as valuable as flexibility and clarity, it is still crucial, at least
>>>>>>>> because of it being the main factor server maintenance cost after all.
>>>>>>>>
>>>>>>>> ??, 20 ???. 2024??. ? 00:32, David Alayachew <
>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>
>>>>>>>>> It is not the goal of Java to be verbose, but it is also not the
>>>>>>>>> goal of Java to be concise either. It is the goal of Java to be clear,
>>>>>>>>> correct, and readable, in order to maximize maintainability, correctness,
>>>>>>>>> and flexibility. When you focus on accomplishing that goal first, you will
>>>>>>>>> find that conciseness takes care of itself.
>>>>>>>>>
>>>>>>>>> I understand that my approach is wordier than yours. Please also
>>>>>>>>> consider that my suggestion does exactly one task -- stream an element with
>>>>>>>>> its respective index. And yet, the number of ways that that can be used
>>>>>>>>> covers hundreds of use cases while still being incredibly easy to maintain
>>>>>>>>> and optimize. Far more than what you suggest. My feature easily composes
>>>>>>>>> with others, with anything that can take a Stream<T> in fact.
>>>>>>>>>
>>>>>>>>> The bar to adding a feature to Java, even to its libraries, is
>>>>>>>>> high. In fact, there is even a breaking point where a language/library can
>>>>>>>>> just be too dense to work with. Too many methods, too much complexity.
>>>>>>>>>
>>>>>>>>> Java makes it a priority to limit adding features or functionality
>>>>>>>>> wherever possible, only relenting when the benefit significantly outweighs
>>>>>>>>> the cost. Adding a method like yours that only serves a tiny slice of use
>>>>>>>>> cases just does not meet the goal of what Java is aiming for -- to get the
>>>>>>>>> biggest bang for buck when adding a feature to language/library.
>>>>>>>>>
>>>>>>>>> I think that your pain point is significant and worth addressing.
>>>>>>>>> But I think it should be done in a way that services a much larger group of
>>>>>>>>> users and use cases. I think my idea does that.
>>>>>>>>>
>>>>>>>>> On Fri, Apr 19, 2024 at 5:14?PM ??-24 ????????? ?????? <
>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> streamWithIndex() is indeed an interesting approach, however,
>>>>>>>>>> working with pairs of values is not always comfortable as this may make
>>>>>>>>>> code too wordy, which may be fixed using things like properties and tuples
>>>>>>>>>> (which I am currently working on right now btw), but still code like
>>>>>>>>>> list.streamWithIndex().filter(Predicate).findFirst().orElse(-1) is still
>>>>>>>>>> long, thats why i think there is room for both in Java.
>>>>>>>>>>
>>>>>>>>>> Also maybe instead of returning traditional -1 it would be more
>>>>>>>>>> suitable to use OptionalInt instead, but I would like to hear community
>>>>>>>>>> opinion about that.
>>>>>>>>>>
>>>>>>>>>> ??, 20 ???. 2024??. ? 00:02, David Alayachew <
>>>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No R?mi, I don't think your idea is the right approach. You are
>>>>>>>>>>> working on the wrong level of abstraction.
>>>>>>>>>>>
>>>>>>>>>>> Many users ask requests like this all the time, and what you are
>>>>>>>>>>> suggesting would be even more error-prone than the equivalent for loop or the
>>>>>>>>>>> IntStream suggestion that the user above requested. Not to
>>>>>>>>>>> mention that getting it to parallelize would be a task many users are
>>>>>>>>>>> likely to mess up -- either in correctness or in performance.
>>>>>>>>>>>
>>>>>>>>>>> I think you would get far more mileage from adding 2 methods on
>>>>>>>>>>> the list interface streamWithIndex() and parallelStreamWithIndex() that
>>>>>>>>>>> would return a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>>>>>>>>>>
>>>>>>>>>>> That way, users are not writing a custom Gatherer each time they
>>>>>>>>>>> want to work with the index. They just have the index be a field in the
>>>>>>>>>>> object. They can work with it the same way they would any other object
>>>>>>>>>>> field.
>>>>>>>>>>>
>>>>>>>>>>> Furthermore, doing it this way makes the correct answer obvious.
>>>>>>>>>>> If I need to do something with an index, stream with the index.
>>>>>>>>>>>
>>>>>>>>>>> On top of that, it significantly enhances readability by making
>>>>>>>>>>> it clear to the reader that, whatever this stream is doing will require use
>>>>>>>>>>> of the index, so watch out for that.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> for me, it seems what you want is  Collector on Stream which is
>>>>>>>>>>>> able to short-circuit,
>>>>>>>>>>>> so you can write
>>>>>>>>>>>>   list.stream().collect(Collectors.findFirst(s ->
>>>>>>>>>>>> s.contains("o")))
>>>>>>>>>>>> and in reverse
>>>>>>>>>>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>>>>>>>>>>> s.contains("o")))
>>>>>>>>>>>>
>>>>>>>>>>>> Using a Stream here is more general and will work with other
>>>>>>>>>>>> collections like a LinkedHashSet for example.
>>>>>>>>>>>> Sadly, there is no way to define a short-circuiting collector :(
>>>>>>>>>>>>
>>>>>>>>>>>> You can have a short-circuiting Gatherer like this
>>>>>>>>>>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T>
>>>>>>>>>>>> predicate) {
>>>>>>>>>>>>     return Gatherer.ofSequential(
>>>>>>>>>>>>       () -> new Object() { int index; },
>>>>>>>>>>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>>>>>>>>>>         var index = state.index++;
>>>>>>>>>>>>         if (predicate.test(element)) {
>>>>>>>>>>>>           return downstream.push(index);
>>>>>>>>>>>>         }
>>>>>>>>>>>>         return true;
>>>>>>>>>>>>       }));
>>>>>>>>>>>>   }
>>>>>>>>>>>>
>>>>>>>>>>>> and use it like this:
>>>>>>>>>>>>   list.stream().gather(findIndex(s ->
>>>>>>>>>>>> s.contains("o"))).findFirst().orElse(-1);
>>>>>>>>>>>>
>>>>>>>>>>>> But it's more verbose.
>>>>>>>>>>>>
>>>>>>>>>>>> I wonder if at the same time that the Gatherer API is
>>>>>>>>>>>> introduced, the Collector API should be enhanced to support
>>>>>>>>>>>> short-circuiting collectors ?
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>> R?mi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>>>>>>>>>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>>>>>>>>>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>>>>>>>>>>> *Subject: *Addition of Predicate-based findIndex and
>>>>>>>>>>>> findLastIndex methods to java.util.List
>>>>>>>>>>>>
>>>>>>>>>>>> Subject
>>>>>>>>>>>> Addition of Predicate-based findIndex and findLastIndex methods
>>>>>>>>>>>> to java.util.List
>>>>>>>>>>>>
>>>>>>>>>>>> Motivation
>>>>>>>>>>>> The motivation behind this proposal is to enhance the
>>>>>>>>>>>> functionality of the List interface by providing a more flexible way to
>>>>>>>>>>>> find the index of an element. Currently, the indexOf and lastIndexOf
>>>>>>>>>>>> methods only accept an object as a parameter. This limits the flexibility
>>>>>>>>>>>> of these methods as they can only find the index of exact object matches.
>>>>>>>>>>>>
>>>>>>>>>>>> Here I want to propose methods that would accept a Predicate as
>>>>>>>>>>>> a parameter, allowing users to define a condition that the desired element
>>>>>>>>>>>> must meet. This would provide a more flexible and powerful way to find the
>>>>>>>>>>>> index of an element in a list.
>>>>>>>>>>>>
>>>>>>>>>>>> The changes I am proposing are implemented in this PR:
>>>>>>>>>>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief
>>>>>>>>>>>> overview of the changes made in this pull request:
>>>>>>>>>>>>
>>>>>>>>>>>> Added the findIndex  (Predicate<? super E> filter) method to
>>>>>>>>>>>> the List interface.
>>>>>>>>>>>> Added the findLastIndex  (Predicate<? super E> filter) method
>>>>>>>>>>>> to the List interface.
>>>>>>>>>>>> Implemented these methods in all non-abstract classes that
>>>>>>>>>>>> implement the List interface, as well as List itself (default impl).
>>>>>>>>>>>> The changes have been thoroughly tested to ensure they work as
>>>>>>>>>>>> expected and do not introduce any regressions. The test cases cover a
>>>>>>>>>>>> variety of scenarios to ensure the robustness of the implementation.
>>>>>>>>>>>>
>>>>>>>>>>>> For example, consider the following test case:
>>>>>>>>>>>>
>>>>>>>>>>>> List<String> list = new ArrayList<>();
>>>>>>>>>>>> list.add("Object one");
>>>>>>>>>>>> list.add("NotObject two");
>>>>>>>>>>>> list.add("NotObject three");
>>>>>>>>>>>>
>>>>>>>>>>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>>>>>>>>>>> System.out.println(index1); // Expected output: 1
>>>>>>>>>>>> int index2 = list. findLastIndex(s ->
>>>>>>>>>>>> s.startsWith("NotObject"));
>>>>>>>>>>>> System.out.println(index2); // Expected output: 2
>>>>>>>>>>>> Currently, to achieve the same result, we would have to use a
>>>>>>>>>>>> more verbose approach:
>>>>>>>>>>>>
>>>>>>>>>>>> int index1 = IntStream.range(0, list.size())
>>>>>>>>>>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>>>>>>>>>>                      .findFirst()
>>>>>>>>>>>>                      .orElse(-1);
>>>>>>>>>>>> System.out.println(index1); // Output: 1
>>>>>>>>>>>> int index2 = IntStream.range(0, list.size())
>>>>>>>>>>>>                          .filter(i ->
>>>>>>>>>>>> list.get(i).startsWith("NotObject"))
>>>>>>>>>>>>                          .reduce((first, second) -> second)
>>>>>>>>>>>>                          .orElse(-1);
>>>>>>>>>>>> System.out.println(index2); // Output: 2
>>>>>>>>>>>> Or other approaches that require additional instructions and,
>>>>>>>>>>>> therefore, can`t be used in all scopes (like passing argument to method).
>>>>>>>>>>>>
>>>>>>>>>>>> I believe these additions would greatly enhance the
>>>>>>>>>>>> functionality and flexibility of the List interface, making it more
>>>>>>>>>>>> powerful and user-friendly. I look forward to your feedback and am open to
>>>>>>>>>>>> making any necessary changes based on your suggestions.
>>>>>>>>>>>>
>>>>>>>>>>>> The main reason I am publishing this proposal in the mailing
>>>>>>>>>>>> system is to gather feedback from the Java developers community, especially
>>>>>>>>>>>> about possible caveats related to backward compatibility of your projects.
>>>>>>>>>>>> Would appreciate every opinion!
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards
>>>>>>>>>>>>
>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/702ba1bd/attachment-0001.htm>

From jbhateja at openjdk.org  Sat Apr 20 14:25:33 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 20 Apr 2024 14:25:33 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]
In-Reply-To: <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
Message-ID: <EE7ep_2JQtjDodw2i9TFTSjib963s51OLZZW8pJ62Ow=.dc24887d-a5e2-4009-9510-b7b02f73abc7@github.com>

On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Long to short jmp; other cleanup

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2530:

> 2528:     switch (type) {
> 2529:       case USM_SHORT:
> 2530:         __ movw(Address(dest, (2 * i)), wide_value);

MOVW emits an extra Operand Size Override prefix byte compared to 32 and 64 bit stores, any specific reason for keeping same unroll factor for all the stores.

src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2539:

> 2537:         break;
> 2538:     }
> 2539:   }

I understand we want to be as accurate as possible in filling the tail in an event of SIGBUS, but we are anyways creating a wide value for 8 packed bytes if destination segment was quadword aligned, aligned quadword stores are implicitly atomic on x86 targets, what's your thoughts on using a vector instruction based loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1573297441
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1573299069

From sgibbons at openjdk.org  Sat Apr 20 19:09:43 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 20 Apr 2024 19:09:43 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v25]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <3Z1vY5KHl-D5I1VoQYb6w0B1QToR0cVOnOov_vfrAe0=.d7e4944e-b781-477a-862b-dc067fab9d13@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix UnsafeCopyMemoryMark scope issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18555/files
  - new: https://git.openjdk.org/jdk/pull/18555/files/19616244..c1290169

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=23-24

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Sat Apr 20 19:09:44 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 20 Apr 2024 19:09:44 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]
In-Reply-To: <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
Message-ID: <nMJLqyTqHEmhuzH5eYo9m-NVm-mZ_Z-diwIQPG6yT_s=.ce04e5f8-4c3a-4ca8-9713-e31a57f3d5cc@github.com>

On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Long to short jmp; other cleanup

The SIGBUS was due to improper scoping of the UnsafeCopyMemoryMark.  The change is:

`   {`
`     // Add set memory mark to protect against unsafe accesses faulting`
`-    UnsafeCopyMemoryMark(this, ((t == T_BYTE) && !aligned), true);`
`+    UnsafeCopyMemoryMark usmm(this, ((t == T_BYTE) && !aligned), true);`
`     __ generate_fill(t, aligned, to, value, r11, rax, xmm0);`
`   }`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2067758164

From sgibbons at openjdk.org  Sat Apr 20 19:09:44 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 20 Apr 2024 19:09:44 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]
In-Reply-To: <EE7ep_2JQtjDodw2i9TFTSjib963s51OLZZW8pJ62Ow=.dc24887d-a5e2-4009-9510-b7b02f73abc7@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
 <EE7ep_2JQtjDodw2i9TFTSjib963s51OLZZW8pJ62Ow=.dc24887d-a5e2-4009-9510-b7b02f73abc7@github.com>
Message-ID: <oE1zI4PI-SVJVtwXXv4rrQV8X860yLT-fGH6NvZpS1A=.c23e5ef1-9360-45ca-abf1-7fbd30dbc63c@github.com>

On Sat, 20 Apr 2024 14:14:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Long to short jmp; other cleanup
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2530:
> 
>> 2528:     switch (type) {
>> 2529:       case USM_SHORT:
>> 2530:         __ movw(Address(dest, (2 * i)), wide_value);
> 
> MOVW emits an extra Operand Size Override prefix byte compared to 32 and 64 bit stores, any specific reason for keeping same unroll factor for all the stores.

My understanding is the spec requires the appropriate-sized write based on alignment and size.  This is why there's no 128-bit or 256-bit store loops.

> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2539:
> 
>> 2537:         break;
>> 2538:     }
>> 2539:   }
> 
> I understand we want to be as accurate as possible in filling the tail in an event of SIGBUS, but we are anyways creating a wide value for 8 packed bytes if destination segment was quadword aligned, aligned quadword stores are implicitly atomic on x86 targets, what's your thoughts on using a vector instruction based loop.

I believe the spec is specific on the size of the store required given alignment and size.  I want to honor that spec even though wider stores could be done in many cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1573373720
PR Review Comment: https://git.openjdk.org/jdk/pull/18555#discussion_r1573374108

From rotan.olexandr at gmail.com  Sat Apr 20 19:11:19 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 22:11:19 +0300
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <CAP=Y=q99n_+-JRu-b2U0+RvvF4UL9fRHNgQn6rE7UOi-Kv+g1g@mail.gmail.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PEa-EcO41h=+wS50gCoVn=WWxVPgZ-oh56OFOYY=YnFQ@mail.gmail.com>
 <CAP=Y=q9iCSgvwQSYdmV_ZueEsXeDCMi-L4xYRwKzFGioRZC6RQ@mail.gmail.com>
 <CAA9v-_NptwV4UNo9V1YDB=1os5BViPgYkMkDXJWRgGZis6UdYw@mail.gmail.com>
 <CAP=Y=q8aPLwjmg_h3oSbR6ZPPUajocB1P2R1uRBWrYXn3j0LXg@mail.gmail.com>
 <CAP=Y=q88ppGhtuVEr4oe4N4LOPw4Fdhe9Au7dDOmw7JtObYnWw@mail.gmail.com>
 <CAA9v-_OpDb83_sfo9ge=KrH5YmpB+yD36hfS_r1wE6CsX5LTrQ@mail.gmail.com>
 <CAP=Y=q-a4wPT1mxFnVUV=X_8FA8rPc3E1jxLiDsw7ZVj4sGuCA@mail.gmail.com>
 <CAA9v-_P9xj4YCPFgS13ben54cq=yNe+3Wdxb5ktshbyOCwrHFA@mail.gmail.com>
 <CAP=Y=q8iGSx-OnSfu34k4qCh_5cZekOPHJ14=TKB8RKVPBeRig@mail.gmail.com>
 <CABe8uE12YP=8e1ngufMavndBdbdPunNpS4m3r1yrQcjh+Pj+sw@mail.gmail.com>
 <CAKswmE5gUzXnn=DzKUSM+_Z0qQHQYZ-hy8qWR+TpnY9k0zS2HA@mail.gmail.com>
 <CAP=Y=q99n_+-JRu-b2U0+RvvF4UL9fRHNgQn6rE7UOi-Kv+g1g@mail.gmail.com>
Message-ID: <CAP=Y=q-=tJJF_VEGLC-Q5vK3AMvEpO+aQf6A1GYRK4dmcZ3L9g@mail.gmail.com>

Regarding performance concerns, I did some benchmarking, results are
attached to this mail, and also available in repo
https://github.com/Evemose/bench , along with code used in benchmarks. This
is not the most robust benchmark you will see, but common sense and results
indicate that complexity is O(n), so this should be at least worth
considering.

Summarizing, there are significant differences in performance of
stream-based approach and list-based, second outperform first in 10-20
times on average. I didn't measure memory usage, but it's obvious streams
would lose there too.

??, 20 ???. 2024??. ? 15:02, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> Regarding what Holo said, I think enumerated() would be a more suitable
> name.
>
> I have few ideas about implementation of such things, like separate
> EnumeratedStream interface, which extends stream and provides methods like
> forEach(BiConsumer<Integer, P_IN>), etc. This would eliminate unnecessary
> object instantiation and also make stream interface more comfortable as
> enumeration of steam won't require to consume index in every operation.\
>
> Although it is an interesting and important topic, I have to ask you guys
> to move it to another thread if possible. This thread already shifted
> significantly from the original topic, which was potential compatibility
> and API issues that I need to fix before applying for CSR.
>
> ??, 20 ???. 2024??. ? 14:10, Holo The Sage Wolf <holo3146 at gmail.com>:
>
>> Hello,
>>
>> I want to challenge the idea that every stream may be indexed for 3
>> reasons:
>>
>> Any sensible type to use for an index (int/long) will be bounded, but
>> streams need not, e.g.
>>     new Random().ints().withIndex().forEach(v -> ...);
>> May result (after a very long time) non sensical values. Using bigInteger
>> will solve this problem but would be silly as in practice 99.99999% of the
>> times long is more than enough (and 90% int is probably enough)
>>
>> The two other problems have to do with the semantics of "index":
>> Index gives the impression that the "index" is a real position, but the
>> stream may be truly non deterministic (using e.g. Hardware Random Stream)
>> Index gives the impression that the "index" respects the canonical order
>> of the underlying collection (if exists), that is:
>> var x = myList.stream().parallel()
>>                 .withIndex().findAny().get();
>> assert x.value() == myList.get(x.index()); // implementation dependent
>>
>> Which I don't think is possible without enormous performance problems.
>>
>> ---
>>
>> To be clear about my position: I like and want the idea. The first
>> problem, in my opinion, shouldn't block it, but we should document it. That
>> being said, I don't think we should be calling this "index".
>>
>> On Sat, 20 Apr 2024, 11:54 -, <liangchenblue at gmail.com> wrote:
>>
>>> Hi Rotan',
>>> Interface methods are both exposed to callers and to implementations. Is
>>> there any scenario where the implementation can be more efficient than the
>>> stream/gatherer scanning approach?
>>>
>>> indexOf or lastIndexOf may be faster if a list has some tricks like a
>>> hashmap to quickly look up the index of an item. In contrast, the predicate
>>> looks too generic and barely optimizable by list implementations; even if
>>> we can stream in parallel, this is already covered by the stream API, so we
>>> can simply declare a Gatherer to perform this findIndex operation on a
>>> stream of elements (also note that a list can be reversed with
>>> List::reversed() since JDK 21, so the same Gatherer can be reused for
>>> findLastIndex)
>>>
>>> I think if there is no scenario where implementation can do better with
>>> findIndex, the findIndex should become a Gatherer, which has better
>>> compatibility.
>>>
>>> Best,
>>> Chen Liang
>>>
>>> On Fri, Apr 19, 2024 at 8:51?PM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Turned out this whole time I was only replying to David. I have to
>>>> thank him for his patience explaining me how this whole mailing thing work.
>>>>
>>>> To summarize what has been missed out, besides what have you seen in
>>>> quotes. I have pointed out that, while flexibility and simplicity is
>>>> important, the main reason why I have decided to propose this feature is to
>>>> enhance developer experience.
>>>>
>>>> I know that conciseness is not a main goal of Java, and therefore my
>>>> proposal is kind of contradicts the general direction of development of
>>>> Java as language, but my desire to make Java more user friendly is based on
>>>> personal experience of introducing fresh devs or switchers to java and
>>>> their feedback. Therefore, while it is not a priority for community, I
>>>> really hope you guys don't mind me working at a backrank of Java making it
>>>> a bit prettier.
>>>>
>>>> On Sat, Apr 20, 2024, 02:56 David Alayachew <davidalayachew at gmail.com>
>>>> wrote:
>>>>
>>>>> > That was what i referred to as "Map-solvable" problems,
>>>>> > but if this way of doing it is a thing, then I agree with
>>>>> > the point.
>>>>>
>>>>> Doing it the Map way would not only be slower, but it would force you
>>>>> to include more concepts than you need. Your identifier is your index.
>>>>> Lists/arrays have index. Bringing a map in only complicates things.
>>>>>
>>>>> As for the rest of your response, I think I understand the trouble
>>>>> here. You put it best when you said that you are introducing this feature
>>>>> with the intent of improving the developer experience, specifically through
>>>>> making code more concise.
>>>>>
>>>>> I can understand that goal, and it is a good goal to strive for, but
>>>>> conciseness is one of the last things Java aims to provide as a language or
>>>>> through its standard library. I won't tell you not to do it, but I will
>>>>> tell you that there will be significant push back from folks here, and for
>>>>> good reason -- conciseness is not the priority here at Java. At Java, the
>>>>> lack of conciseness is not a weakness. Sure, unneeded verbosity can be a
>>>>> weakness, but the solution I suggested above is basically the tempo that
>>>>> Java strives for -- compose simple concepts so that you can create what you
>>>>> need.
>>>>>
>>>>> All of that is to say, you have made your point clear. You goal is
>>>>> conciseness and ease of access. Understanding that, it's clear that my
>>>>> solution is not concise enough to meet that goal, so I won't push it
>>>>> further.
>>>>>
>>>>> On Fri, Apr 19, 2024 at 7:26?PM ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> " 1. Fetching data from same-sized lists -- This is a trick from
>>>>>> Data-Oriented Design (not to be confused with Data-Oriented Programming)
>>>>>> where you filter down to the indexes that you want, and use the indexes to
>>>>>> fetch related values from the respective lists. So, I would filter down to
>>>>>> Player1, Player4, and Player6, then I would use their indexes to do lookups
>>>>>> in PlayerItemList, PlayerSkinList, etc. This tactic is especially useful
>>>>>> when working with structs (or value classes when Java gets them)."
>>>>>>
>>>>>> That was what i referred to as "Map-solvable" problems, but if this
>>>>>> way of doing it is a thing, then I agree with the point.
>>>>>>
>>>>>> "By this logic, many of the methods in the Stream library should
>>>>>> instead be in the Collection library. There are several emails on the
>>>>>> lambda mailing list that address why this wasn't done. I imagine that R?mi
>>>>>> himself could point them out to you."
>>>>>>
>>>>>> It may be just my opinion, but I don't see anything harmful in some
>>>>>> shortcuts that could be optimized, especially if they still converge to a
>>>>>> single point under the hood. I would love to read mails about maintainers'
>>>>>> opinions on why some features of Streams couldnt be also a part of
>>>>>> Collection library if it would enhance developer experience, so, if it
>>>>>> wouldn't be hard for you, could you attach some links? Also I guess a good
>>>>>> compromise would be extension methods, I am currently exploring
>>>>>> possibilities of their implementation.
>>>>>>
>>>>>> "Well hold on. I am not at all saying that it is redundant. I am
>>>>>> saying that the functionality that you desire can be easily recreated by
>>>>>> using a more far-reaching feature, the .withIndex() idea that R?mi
>>>>>> suggested. I am just trying to say that your idea probably should not be
>>>>>> done on the List interface."
>>>>>>
>>>>>> I am not saying that .withIndex() is a bad idea in any way. I can
>>>>>> remember several times when I was desperately looking for something like
>>>>>> python enumerate(), but all I found were some IntStream-based approaches.
>>>>>> What I am saying is, while there is definitely room for both, withIndex
>>>>>> does not solve the initial problem that motivated me to propose such
>>>>>> changes: redundant (emphasis on this) verbosity. The main reason I decided
>>>>>> to become an openjdk contributor is because I love to create tools that
>>>>>> make development easier and more pleasant, and I feel more sophisticated,
>>>>>> although a more specific API would deal much better with this task, and as
>>>>>> this is my personal priority, I would stand my ground here.
>>>>>>
>>>>>> "Regardless, Valhalla is not here yet. So at least for now, I will
>>>>>> concede your point about performance."
>>>>>>
>>>>>> Valhalla, at least for now, is nowhere near to a release even as a
>>>>>> preview, would be great if it will get to Java releases until the next LTS.
>>>>>> I think that even, even for a 2-4 years, this point is valid, then it at
>>>>>> least should be taken into consideration.
>>>>>>
>>>>>> PS: As you might notice, I am a developer experience guy rather than
>>>>>> a flexible guy. My opinion is a result of some personal beliefs, but also
>>>>>> is an aggregation of opinions of numbers of other programmers that I
>>>>>> introduced to Java, especially switchers. Many of then feel those
>>>>>> "wordiness" of Java and it repulses potential developers, especially when
>>>>>> there is C# just by the corner. I think that Java has really strong sides,
>>>>>> but I would love to cover its "weaknesses" as well, especially if it
>>>>>> doesn't come with any maintenance burdens.
>>>>>>
>>>>>> ??, 20 ???. 2024??. ? 02:00, David Alayachew <
>>>>>> davidalayachew at gmail.com>:
>>>>>>
>>>>>>> No confusion. You spoke clearly enough to be understood the first
>>>>>>> time.
>>>>>>>
>>>>>>> On Fri, Apr 19, 2024 at 6:28?PM ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> Regarding the first point in my last message. "Them" is
>>>>>>>> referring to the developer, and "evaluate" means to be processed by the
>>>>>>>> developer. Sorry for the potential confusion
>>>>>>>>
>>>>>>>> ??, 20 ???. 2024??. ? 00:52, ??-24 ????????? ?????? <
>>>>>>>> rotan.olexandr at gmail.com>:
>>>>>>>>
>>>>>>>>> I think that, while finding the index of a matching element is not
>>>>>>>>> a very common task, especially among commercial developers, when discussing
>>>>>>>>> indexed streams, this would be the most common use case. To be honest, I
>>>>>>>>> don't even see any other use cases right now, besides maybe some processing
>>>>>>>>> based on divisibility of index (odd/even as the most common one). I have a
>>>>>>>>> pretty strong background in competitive programming, more than 5 years, and
>>>>>>>>> can remember anything more complex than that that could not be replaced
>>>>>>>>> with Map usage.
>>>>>>>>>
>>>>>>>>> Regarding clarity, I fully agree with you. I am not a fan of those
>>>>>>>>> unreadable abbreviations in C/C++ or even in python. However, while it's
>>>>>>>>> hard to argue that your approach is more flexible, it has two downsides:
>>>>>>>>>
>>>>>>>>> 1. Although indexed streams are flexible, the flexibility might
>>>>>>>>> come at the cost of readability. Syntax like list.FindIndex is pretty
>>>>>>>>> straightforward and speaks for itself, while indexed-stream-based approach
>>>>>>>>> requires developer to explicitly evaluate what that chain of method does,
>>>>>>>>> which would distract them from understanding of general program logic flow,
>>>>>>>>> while usually being no more then utility. The reason for existence of
>>>>>>>>> findIndex is the same as for indexOf, so saying one is redundant means
>>>>>>>>> saying other one is redundant too.
>>>>>>>>>
>>>>>>>>> 2. Streams are performance-costy, thats the point that is hard to
>>>>>>>>> argue with. While list implementations could provide specified
>>>>>>>>> implementations of findIndex based on their internal structure, streams
>>>>>>>>> work only with generic interfaces. Moreover, even default implementation
>>>>>>>>> that uses ListIterator would be times faster and less resource consuming
>>>>>>>>> then generic stream-based approach. While I understand that performance is
>>>>>>>>> not as valuable as flexibility and clarity, it is still crucial, at least
>>>>>>>>> because of it being the main factor server maintenance cost after all.
>>>>>>>>>
>>>>>>>>> ??, 20 ???. 2024??. ? 00:32, David Alayachew <
>>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>>
>>>>>>>>>> It is not the goal of Java to be verbose, but it is also not the
>>>>>>>>>> goal of Java to be concise either. It is the goal of Java to be clear,
>>>>>>>>>> correct, and readable, in order to maximize maintainability, correctness,
>>>>>>>>>> and flexibility. When you focus on accomplishing that goal first, you will
>>>>>>>>>> find that conciseness takes care of itself.
>>>>>>>>>>
>>>>>>>>>> I understand that my approach is wordier than yours. Please also
>>>>>>>>>> consider that my suggestion does exactly one task -- stream an element with
>>>>>>>>>> its respective index. And yet, the number of ways that that can be used
>>>>>>>>>> covers hundreds of use cases while still being incredibly easy to maintain
>>>>>>>>>> and optimize. Far more than what you suggest. My feature easily composes
>>>>>>>>>> with others, with anything that can take a Stream<T> in fact.
>>>>>>>>>>
>>>>>>>>>> The bar to adding a feature to Java, even to its libraries, is
>>>>>>>>>> high. In fact, there is even a breaking point where a language/library can
>>>>>>>>>> just be too dense to work with. Too many methods, too much complexity.
>>>>>>>>>>
>>>>>>>>>> Java makes it a priority to limit adding features or
>>>>>>>>>> functionality wherever possible, only relenting when the benefit
>>>>>>>>>> significantly outweighs the cost. Adding a method like yours that only
>>>>>>>>>> serves a tiny slice of use cases just does not meet the goal of what Java
>>>>>>>>>> is aiming for -- to get the biggest bang for buck when adding a feature to
>>>>>>>>>> language/library.
>>>>>>>>>>
>>>>>>>>>> I think that your pain point is significant and worth addressing.
>>>>>>>>>> But I think it should be done in a way that services a much larger group of
>>>>>>>>>> users and use cases. I think my idea does that.
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 19, 2024 at 5:14?PM ??-24 ????????? ?????? <
>>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> streamWithIndex() is indeed an interesting approach, however,
>>>>>>>>>>> working with pairs of values is not always comfortable as this may make
>>>>>>>>>>> code too wordy, which may be fixed using things like properties and tuples
>>>>>>>>>>> (which I am currently working on right now btw), but still code like
>>>>>>>>>>> list.streamWithIndex().filter(Predicate).findFirst().orElse(-1) is still
>>>>>>>>>>> long, thats why i think there is room for both in Java.
>>>>>>>>>>>
>>>>>>>>>>> Also maybe instead of returning traditional -1 it would be more
>>>>>>>>>>> suitable to use OptionalInt instead, but I would like to hear community
>>>>>>>>>>> opinion about that.
>>>>>>>>>>>
>>>>>>>>>>> ??, 20 ???. 2024??. ? 00:02, David Alayachew <
>>>>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No R?mi, I don't think your idea is the right approach. You are
>>>>>>>>>>>> working on the wrong level of abstraction.
>>>>>>>>>>>>
>>>>>>>>>>>> Many users ask requests like this all the time, and what you
>>>>>>>>>>>> are suggesting would be even more error-prone than the equivalent for loop
>>>>>>>>>>>> or the IntStream suggestion that the user above requested. Not
>>>>>>>>>>>> to mention that getting it to parallelize would be a task many users are
>>>>>>>>>>>> likely to mess up -- either in correctness or in performance.
>>>>>>>>>>>>
>>>>>>>>>>>> I think you would get far more mileage from adding 2 methods on
>>>>>>>>>>>> the list interface streamWithIndex() and parallelStreamWithIndex() that
>>>>>>>>>>>> would return a Stream<WithIndex<T>>, as opposed to just Stream<T>.
>>>>>>>>>>>>
>>>>>>>>>>>> That way, users are not writing a custom Gatherer each time
>>>>>>>>>>>> they want to work with the index. They just have the index be a field in
>>>>>>>>>>>> the object. They can work with it the same way they would any other object
>>>>>>>>>>>> field.
>>>>>>>>>>>>
>>>>>>>>>>>> Furthermore, doing it this way makes the correct answer
>>>>>>>>>>>> obvious. If I need to do something with an index, stream with the index.
>>>>>>>>>>>>
>>>>>>>>>>>> On top of that, it significantly enhances readability by making
>>>>>>>>>>>> it clear to the reader that, whatever this stream is doing will require use
>>>>>>>>>>>> of the index, so watch out for that.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Apr 19, 2024, 1:47?PM Remi Forax <forax at univ-mlv.fr>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> for me, it seems what you want is  Collector on Stream which
>>>>>>>>>>>>> is able to short-circuit,
>>>>>>>>>>>>> so you can write
>>>>>>>>>>>>>   list.stream().collect(Collectors.findFirst(s ->
>>>>>>>>>>>>> s.contains("o")))
>>>>>>>>>>>>> and in reverse
>>>>>>>>>>>>>   list.reversed().stream().collect(Collectors.findFirst(s ->
>>>>>>>>>>>>> s.contains("o")))
>>>>>>>>>>>>>
>>>>>>>>>>>>> Using a Stream here is more general and will work with other
>>>>>>>>>>>>> collections like a LinkedHashSet for example.
>>>>>>>>>>>>> Sadly, there is no way to define a short-circuiting collector
>>>>>>>>>>>>> :(
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can have a short-circuiting Gatherer like this
>>>>>>>>>>>>>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T>
>>>>>>>>>>>>> predicate) {
>>>>>>>>>>>>>     return Gatherer.ofSequential(
>>>>>>>>>>>>>       () -> new Object() { int index; },
>>>>>>>>>>>>>       Integrtor.ofGreedy((state, element, downstream) -> {
>>>>>>>>>>>>>         var index = state.index++;
>>>>>>>>>>>>>         if (predicate.test(element)) {
>>>>>>>>>>>>>           return downstream.push(index);
>>>>>>>>>>>>>         }
>>>>>>>>>>>>>         return true;
>>>>>>>>>>>>>       }));
>>>>>>>>>>>>>   }
>>>>>>>>>>>>>
>>>>>>>>>>>>> and use it like this:
>>>>>>>>>>>>>   list.stream().gather(findIndex(s ->
>>>>>>>>>>>>> s.contains("o"))).findFirst().orElse(-1);
>>>>>>>>>>>>>
>>>>>>>>>>>>> But it's more verbose.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wonder if at the same time that the Gatherer API is
>>>>>>>>>>>>> introduced, the Collector API should be enhanced to support
>>>>>>>>>>>>> short-circuiting collectors ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> regards,
>>>>>>>>>>>>> R?mi
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
>>>>>>>>>>>>> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>>>>>>>>>>>>> *Sent: *Friday, April 19, 2024 5:59:39 PM
>>>>>>>>>>>>> *Subject: *Addition of Predicate-based findIndex and
>>>>>>>>>>>>> findLastIndex methods to java.util.List
>>>>>>>>>>>>>
>>>>>>>>>>>>> Subject
>>>>>>>>>>>>> Addition of Predicate-based findIndex and findLastIndex
>>>>>>>>>>>>> methods to java.util.List
>>>>>>>>>>>>>
>>>>>>>>>>>>> Motivation
>>>>>>>>>>>>> The motivation behind this proposal is to enhance the
>>>>>>>>>>>>> functionality of the List interface by providing a more flexible way to
>>>>>>>>>>>>> find the index of an element. Currently, the indexOf and lastIndexOf
>>>>>>>>>>>>> methods only accept an object as a parameter. This limits the flexibility
>>>>>>>>>>>>> of these methods as they can only find the index of exact object matches.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here I want to propose methods that would accept a Predicate
>>>>>>>>>>>>> as a parameter, allowing users to define a condition that the desired
>>>>>>>>>>>>> element must meet. This would provide a more flexible and powerful way to
>>>>>>>>>>>>> find the index of an element in a list.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The changes I am proposing are implemented in this PR:
>>>>>>>>>>>>> https://github.com/openjdk/jdk/pull/18639. Here is a brief
>>>>>>>>>>>>> overview of the changes made in this pull request:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Added the findIndex  (Predicate<? super E> filter) method to
>>>>>>>>>>>>> the List interface.
>>>>>>>>>>>>> Added the findLastIndex  (Predicate<? super E> filter) method
>>>>>>>>>>>>> to the List interface.
>>>>>>>>>>>>> Implemented these methods in all non-abstract classes that
>>>>>>>>>>>>> implement the List interface, as well as List itself (default impl).
>>>>>>>>>>>>> The changes have been thoroughly tested to ensure they work as
>>>>>>>>>>>>> expected and do not introduce any regressions. The test cases cover a
>>>>>>>>>>>>> variety of scenarios to ensure the robustness of the implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example, consider the following test case:
>>>>>>>>>>>>>
>>>>>>>>>>>>> List<String> list = new ArrayList<>();
>>>>>>>>>>>>> list.add("Object one");
>>>>>>>>>>>>> list.add("NotObject two");
>>>>>>>>>>>>> list.add("NotObject three");
>>>>>>>>>>>>>
>>>>>>>>>>>>> int index1 = list.findIndex(s -> s.contains("ct t"));
>>>>>>>>>>>>> System.out.println(index1); // Expected output: 1
>>>>>>>>>>>>> int index2 = list. findLastIndex(s ->
>>>>>>>>>>>>> s.startsWith("NotObject"));
>>>>>>>>>>>>> System.out.println(index2); // Expected output: 2
>>>>>>>>>>>>> Currently, to achieve the same result, we would have to use a
>>>>>>>>>>>>> more verbose approach:
>>>>>>>>>>>>>
>>>>>>>>>>>>> int index1 = IntStream.range(0, list.size())
>>>>>>>>>>>>>                      .filter(i -> list.get(i).contains("ct t"))
>>>>>>>>>>>>>                      .findFirst()
>>>>>>>>>>>>>                      .orElse(-1);
>>>>>>>>>>>>> System.out.println(index1); // Output: 1
>>>>>>>>>>>>> int index2 = IntStream.range(0, list.size())
>>>>>>>>>>>>>                          .filter(i ->
>>>>>>>>>>>>> list.get(i).startsWith("NotObject"))
>>>>>>>>>>>>>                          .reduce((first, second) -> second)
>>>>>>>>>>>>>                          .orElse(-1);
>>>>>>>>>>>>> System.out.println(index2); // Output: 2
>>>>>>>>>>>>> Or other approaches that require additional instructions and,
>>>>>>>>>>>>> therefore, can`t be used in all scopes (like passing argument to method).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I believe these additions would greatly enhance the
>>>>>>>>>>>>> functionality and flexibility of the List interface, making it more
>>>>>>>>>>>>> powerful and user-friendly. I look forward to your feedback and am open to
>>>>>>>>>>>>> making any necessary changes based on your suggestions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The main reason I am publishing this proposal in the mailing
>>>>>>>>>>>>> system is to gather feedback from the Java developers community, especially
>>>>>>>>>>>>> about possible caveats related to backward compatibility of your projects.
>>>>>>>>>>>>> Would appreciate every opinion!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>
>>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/fe8c0ffa/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plots.zip
Type: application/x-zip-compressed
Size: 263730 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/fe8c0ffa/plots-0001.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.csv
Type: text/csv
Size: 4841 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/fe8c0ffa/data-0001.csv>

From sgibbons at openjdk.org  Sat Apr 20 19:14:32 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 20 Apr 2024 19:14:32 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]
In-Reply-To: <0cg24YXFi4foGH_uKTY6JmABMhzjMH6gmH78iE0CC4w=.a52937a2-d728-4616-b158-a2a338cbb6f4@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <S-YlBiVRv1VoEiuIhYUsV8WPOwKhxd1uynTOQznTOg8=.06d92778-6c8d-4b0a-a41f-1ac9de26e987@github.com>
 <0cg24YXFi4foGH_uKTY6JmABMhzjMH6gmH78iE0CC4w=.a52937a2-d728-4616-b158-a2a338cbb6f4@github.com>
Message-ID: <bCw6LVZIplVjB2GACl58IQM9FP2PXmW_m6aCcC9mZmo=.9467b600-2ce6-4469-9be6-39290904e593@github.com>

On Sat, 20 Apr 2024 04:28:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Long to short jmp; other cleanup
>
> `runtime/Unsafe/InternalErrorTest.java` test SIGBUS when run with `-Xcomp` (and other flags in test's @run command):
> 
> #  SIGBUS (0xa) at pc=0x0000000119514760, pid=63021, tid=28163
> #
> # JRE version: Java(TM) SE Runtime Environment (23.0) (fastdebug build 23-internal-2024-04-19-2326152.vladimir.kozlov.jdkgit2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-internal-2024-04-19-2326152.vladimir.kozlov.jdkgit2, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # Problematic frame:
> # v  ~StubRoutines::jbyte_fill 0x0000000119514760

@vnkozlov Thanks for the feedback.  Can you please start the testing again?  I'd appreciate it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2067759300

From rotan.olexandr at gmail.com  Sat Apr 20 20:25:15 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 23:25:15 +0300
Subject: Bag (Multiset) Collection
Message-ID: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>

In this letter I would like to express some of my thoughts regarding the
potential Multiset interface.

I, personally, have encountered a few situations where such an interface
could come in handy, mostly when I needed an ordered collection that
permits duplicates. That time I used guava`s TreeMultiset, but I think Java
itself should have such a collection in its std library. While it is not a
very common problem, there are still a bunch of use cases where such things
could come in handy.

I am willing to take on development of such thing, but there are a few
concerns about Multiset:

1. Is there any other use for this besides ordered collection that permits
duplicates? I can't remember anything else from the top of my head.

2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet class
hierarchy, while not being directly connected. I think introducing any
other ordered collection will require some refactoring of existing
collection interfaces (for example extract SortedCollection from SortedSet,
Navigable Collection from NavigableSet etc.). From the perspective of clean
code, this would be the right decision, but I feel like this will be a very
complex task to accomplish.

3. Maybe there should be few versions of Tree collection (for example, for
regular tasks red-black tree and B-Tree for large amounts of data). I have
some expirience implementing both, but is it really needed in standard
library?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/71033a5d/attachment.htm>

From davidalayachew at gmail.com  Sat Apr 20 20:30:51 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 20 Apr 2024 16:30:51 -0400
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
Message-ID: <CAA9v-_MJvipucEQnPHrMzm3r971Zb4NbdxrZMCTAO8ouK9dN2Q@mail.gmail.com>

Your Bag suggestion has been asked so frequently that there is an FAQ entry
in the official Java Docs.

https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3

On Sat, Apr 20, 2024 at 4:25?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> In this letter I would like to express some of my thoughts regarding the
> potential Multiset interface.
>
> I, personally, have encountered a few situations where such an interface
> could come in handy, mostly when I needed an ordered collection that
> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
> itself should have such a collection in its std library. While it is not a
> very common problem, there are still a bunch of use cases where such things
> could come in handy.
>
> I am willing to take on development of such thing, but there are a few
> concerns about Multiset:
>
> 1. Is there any other use for this besides ordered collection that permits
> duplicates? I can't remember anything else from the top of my head.
>
> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet class
> hierarchy, while not being directly connected. I think introducing any
> other ordered collection will require some refactoring of existing
> collection interfaces (for example extract SortedCollection from SortedSet,
> Navigable Collection from NavigableSet etc.). From the perspective of clean
> code, this would be the right decision, but I feel like this will be a very
> complex task to accomplish.
>
> 3. Maybe there should be few versions of Tree collection (for example, for
> regular tasks red-black tree and B-Tree for large amounts of data). I have
> some expirience implementing both, but is it really needed in standard
> library?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/9e2d77a4/attachment.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 20:44:31 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 23:44:31 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q_F3xf3mCY2Q_VY0oghye54juixe7hXrJ-sipGFLCVZ_g@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAA9v-_MJvipucEQnPHrMzm3r971Zb4NbdxrZMCTAO8ouK9dN2Q@mail.gmail.com>
 <CAP=Y=q_F3xf3mCY2Q_VY0oghye54juixe7hXrJ-sipGFLCVZ_g@mail.gmail.com>
Message-ID: <CAP=Y=q9_uBTOJuhMUFQi5rSSdRQtuHQahXit3j1L9eYJd9EZ0g@mail.gmail.com>

I agree with the point made in the FAQ about the popularity of such
problems. That said, I don't think that it is that unpopular to be ignored.

Regarding Map.values(), this is the case, but, In my experience, one of the
main advantages of using TreeMultiset was O(long n) modification
complexity. Collection views returned by map, for obvious reasons, forbid
modification. Also, correct me if I`m wrong, but while TreeMultiset is an
unpopular requirement, it is at least as popular as TreeSet.

Also, I may not have a full view of how such Bag collections can be
implemented and used, however, I feel like there could be more to it.

I am not insisting on anything, I just feel that if there is someone (like
me lol) who is willing to take on full development and integration cycle,
there aren't much reason to reject such enhancements.

??, 20 ???. 2024??. ? 23:43, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> I agree with the point made in the FAQ about the popularity of such
> problems. That said, I don't think that it is that unpopular to be ignored.
>
> Regarding Map.values(), this is the case, but, In my experience, one of
> the main advantages of using TreeMultiset was O(long n) modification
> complexity. Collection views returned by map, for obvious reasons, forbid
> modification. Also, correct me if I`m wrong, but while TreeMultiset is an
> unpopular requirement, it is at least as popular as TreeSet.
>
> Also, I may not have a full view of how such Bag collections can be
> implemented and used, however, I feel like there could be more to it.
>
> I am not insisting on anything, I just feel that if there is someone (like
> me lol) who is willing to take on full development and integration cycle,
> there aren't much reason to reject such enhancements.
>
> ??, 20 ???. 2024??. ? 23:31, David Alayachew <davidalayachew at gmail.com>:
>
>> Your Bag suggestion has been asked so frequently that there is an FAQ
>> entry in the official Java Docs.
>>
>>
>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3
>>
>> On Sat, Apr 20, 2024 at 4:25?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> In this letter I would like to express some of my thoughts regarding the
>>> potential Multiset interface.
>>>
>>> I, personally, have encountered a few situations where such an interface
>>> could come in handy, mostly when I needed an ordered collection that
>>> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
>>> itself should have such a collection in its std library. While it is not a
>>> very common problem, there are still a bunch of use cases where such things
>>> could come in handy.
>>>
>>> I am willing to take on development of such thing, but there are a few
>>> concerns about Multiset:
>>>
>>> 1. Is there any other use for this besides ordered collection that
>>> permits duplicates? I can't remember anything else from the top of my head.
>>>
>>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>>> class hierarchy, while not being directly connected. I think introducing
>>> any other ordered collection will require some refactoring of existing
>>> collection interfaces (for example extract SortedCollection from SortedSet,
>>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>>> code, this would be the right decision, but I feel like this will be a very
>>> complex task to accomplish.
>>>
>>> 3. Maybe there should be few versions of Tree collection (for example,
>>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>>> have some expirience implementing both, but is it really needed in standard
>>> library?
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/a31c04c8/attachment-0001.htm>

From kvn at openjdk.org  Sat Apr 20 20:48:31 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 20 Apr 2024 20:48:31 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v25]
In-Reply-To: <3Z1vY5KHl-D5I1VoQYb6w0B1QToR0cVOnOov_vfrAe0=.d7e4944e-b781-477a-862b-dc067fab9d13@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <3Z1vY5KHl-D5I1VoQYb6w0B1QToR0cVOnOov_vfrAe0=.d7e4944e-b781-477a-862b-dc067fab9d13@github.com>
Message-ID: <uD4qmeApf6zdRQl5tIWox_A1PIAGmlWVBx_UYrXQStw=.8ae2ebc3-0fad-4230-8d3e-eba476c60102@github.com>

On Sat, 20 Apr 2024 19:09:43 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix UnsafeCopyMemoryMark scope issue

Before I do testing, please sync with mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2067777569

From holo3146 at gmail.com  Sat Apr 20 20:51:51 2024
From: holo3146 at gmail.com (Holo The Sage Wolf)
Date: Sat, 20 Apr 2024 23:51:51 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
Message-ID: <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>

By "ordered collection" you mean "unordered collection"?

How common is it to actually use a multiset in general? Of course there are
use cases, and there are areas in which it is used a lot, but I don't
believe it is common enough to be part of the std with the one exception of
concurrent bag.

On Sat, 20 Apr 2024, 23:25 ??-24 ????????? ??????, <rotan.olexandr at gmail.com>
wrote:

> In this letter I would like to express some of my thoughts regarding the
> potential Multiset interface.
>
> I, personally, have encountered a few situations where such an interface
> could come in handy, mostly when I needed an ordered collection that
> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
> itself should have such a collection in its std library. While it is not a
> very common problem, there are still a bunch of use cases where such things
> could come in handy.
>
> I am willing to take on development of such thing, but there are a few
> concerns about Multiset:
>
> 1. Is there any other use for this besides ordered collection that permits
> duplicates? I can't remember anything else from the top of my head.
>
> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet class
> hierarchy, while not being directly connected. I think introducing any
> other ordered collection will require some refactoring of existing
> collection interfaces (for example extract SortedCollection from SortedSet,
> Navigable Collection from NavigableSet etc.). From the perspective of clean
> code, this would be the right decision, but I feel like this will be a very
> complex task to accomplish.
>
> 3. Maybe there should be few versions of Tree collection (for example, for
> regular tasks red-black tree and B-Tree for large amounts of data). I have
> some expirience implementing both, but is it really needed in standard
> library?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/001d5826/attachment.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 21:00:49 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 00:00:49 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>
Message-ID: <CAP=Y=q-1KSND_zPyotBCskJ2onBJS6Y0Le5Acn5OkLiXWvaXKA@mail.gmail.com>

Concurrent Bag is something like CopyOnWriteArrayList or Vector, don't we
have it already? (I know vectors aren't optimized). THe whole point of the
bag is to store duplicate elements without preserving order, which allows
things like ordered collections. There could be mutable collections for
concurrency optimized with read-write locks though, if that is what you are
referring to as "concurrent bag", and I am missing the point why this
can't be a part of list interface, then that just adds one more use case to
potential Bag interface.

PS: Ordered means it preserves order based on comparator, what you are
referring to as ordered essentially means sequential, or am I missing a
point?

??, 20 ???. 2024??. ? 23:52, Holo The Sage Wolf <holo3146 at gmail.com>:

> By "ordered collection" you mean "unordered collection"?
>
> How common is it to actually use a multiset in general? Of course there
> are use cases, and there are areas in which it is used a lot, but I don't
> believe it is common enough to be part of the std with the one exception of
> concurrent bag.
>
> On Sat, 20 Apr 2024, 23:25 ??-24 ????????? ??????, <
> rotan.olexandr at gmail.com> wrote:
>
>> In this letter I would like to express some of my thoughts regarding the
>> potential Multiset interface.
>>
>> I, personally, have encountered a few situations where such an interface
>> could come in handy, mostly when I needed an ordered collection that
>> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
>> itself should have such a collection in its std library. While it is not a
>> very common problem, there are still a bunch of use cases where such things
>> could come in handy.
>>
>> I am willing to take on development of such thing, but there are a few
>> concerns about Multiset:
>>
>> 1. Is there any other use for this besides ordered collection that
>> permits duplicates? I can't remember anything else from the top of my head.
>>
>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>> class hierarchy, while not being directly connected. I think introducing
>> any other ordered collection will require some refactoring of existing
>> collection interfaces (for example extract SortedCollection from SortedSet,
>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>> code, this would be the right decision, but I feel like this will be a very
>> complex task to accomplish.
>>
>> 3. Maybe there should be few versions of Tree collection (for example,
>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>> have some expirience implementing both, but is it really needed in standard
>> library?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/bc9ec02a/attachment-0001.htm>

From davidalayachew at gmail.com  Sat Apr 20 21:05:59 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 20 Apr 2024 17:05:59 -0400
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q9_uBTOJuhMUFQi5rSSdRQtuHQahXit3j1L9eYJd9EZ0g@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAA9v-_MJvipucEQnPHrMzm3r971Zb4NbdxrZMCTAO8ouK9dN2Q@mail.gmail.com>
 <CAP=Y=q_F3xf3mCY2Q_VY0oghye54juixe7hXrJ-sipGFLCVZ_g@mail.gmail.com>
 <CAP=Y=q9_uBTOJuhMUFQi5rSSdRQtuHQahXit3j1L9eYJd9EZ0g@mail.gmail.com>
Message-ID: <CAA9v-_OozOiMeLd6k7cY+YENv0ZB0vN6-PYNT4MPqzvhVUiZnQ@mail.gmail.com>

I won't stop you, but remember, you are not the one maintaining the large
number of collection implementations in the JDK. The ones who are may feel
differently. This FAQ gives a good hint of their opinion, even to your
retorts.

On Sat, Apr 20, 2024, 4:44?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> I agree with the point made in the FAQ about the popularity of such
> problems. That said, I don't think that it is that unpopular to be ignored.
>
> Regarding Map.values(), this is the case, but, In my experience, one of
> the main advantages of using TreeMultiset was O(long n) modification
> complexity. Collection views returned by map, for obvious reasons, forbid
> modification. Also, correct me if I`m wrong, but while TreeMultiset is an
> unpopular requirement, it is at least as popular as TreeSet.
>
> Also, I may not have a full view of how such Bag collections can be
> implemented and used, however, I feel like there could be more to it.
>
> I am not insisting on anything, I just feel that if there is someone (like
> me lol) who is willing to take on full development and integration cycle,
> there aren't much reason to reject such enhancements.
>
> ??, 20 ???. 2024??. ? 23:43, ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com>:
>
>> I agree with the point made in the FAQ about the popularity of such
>> problems. That said, I don't think that it is that unpopular to be ignored.
>>
>> Regarding Map.values(), this is the case, but, In my experience, one of
>> the main advantages of using TreeMultiset was O(long n) modification
>> complexity. Collection views returned by map, for obvious reasons, forbid
>> modification. Also, correct me if I`m wrong, but while TreeMultiset is an
>> unpopular requirement, it is at least as popular as TreeSet.
>>
>> Also, I may not have a full view of how such Bag collections can be
>> implemented and used, however, I feel like there could be more to it.
>>
>> I am not insisting on anything, I just feel that if there is someone
>> (like me lol) who is willing to take on full development and integration
>> cycle, there aren't much reason to reject such enhancements.
>>
>> ??, 20 ???. 2024??. ? 23:31, David Alayachew <davidalayachew at gmail.com>:
>>
>>> Your Bag suggestion has been asked so frequently that there is an FAQ
>>> entry in the official Java Docs.
>>>
>>>
>>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3
>>>
>>> On Sat, Apr 20, 2024 at 4:25?PM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> In this letter I would like to express some of my thoughts regarding
>>>> the potential Multiset interface.
>>>>
>>>> I, personally, have encountered a few situations where such an
>>>> interface could come in handy, mostly when I needed an ordered collection
>>>> that permits duplicates. That time I used guava`s TreeMultiset, but I think
>>>> Java itself should have such a collection in its std library. While it is
>>>> not a very common problem, there are still a bunch of use cases where such
>>>> things could come in handy.
>>>>
>>>> I am willing to take on development of such thing, but there are a few
>>>> concerns about Multiset:
>>>>
>>>> 1. Is there any other use for this besides ordered collection that
>>>> permits duplicates? I can't remember anything else from the top of my head.
>>>>
>>>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>>>> class hierarchy, while not being directly connected. I think introducing
>>>> any other ordered collection will require some refactoring of existing
>>>> collection interfaces (for example extract SortedCollection from SortedSet,
>>>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>>>> code, this would be the right decision, but I feel like this will be a very
>>>> complex task to accomplish.
>>>>
>>>> 3. Maybe there should be few versions of Tree collection (for example,
>>>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>>>> have some expirience implementing both, but is it really needed in standard
>>>> library?
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/8f4b4ac1/attachment.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 21:07:35 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 00:07:35 +0300
Subject: EnumeratedStream
Message-ID: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>

My proposal regarding findIndex brought up a topic that, as I see, has been
brought up here multiple times.

My idea is to extend the existing stream interface in the new
EnumeratedStream interface. Such an approach has a number of advantages.

1. Some methods will be able to explicitly specify that they require an
enumerated stream.

2. This would allow us to use an enumerated stream just as the default
value stream, if the index is redundant at a certain processing step.

3. This could help introduce a more user-friendly interface: instead of
passing pairs of index and value, they could be passed as separate
variables, which will make code more concise.

Consider following example:
List.of(1, 2, 3).stream()
                .enumerated()
                .map(idx, value -> idx % 2 == 0 ? value : -value);

looks much better than
List.of(1, 2, 3).stream()
                .enumerated()
                .map(pair -> pair.idx % 2 == 0 ? pair.value : -pair.value);

However, I see some caveats with this approach, which relate to parallel
streams:
when a stream is backed by a collection, you might expect assigned indexes
to represent order of iteration through collection, especially when talking
about sequential collections. Assigning indexes in such streams could be a
difficult task in a parallel environment. It should either assign index to
a stream elements at the moment when stream becomes parallelized, which is
also impossible if already parallelized stream is being enumerated, and
also wont work for infinite streams, or make enumerated stream at least
partially sequential by passing elements to processing in order they were
passed to stream at the first place, which is also hard or maybe even
impossible to achieve.

Also, side note: methods that already accept 2 parameters might become
kinda verbose, like reduce that will have to accept for params (idx1, val1,
idx2, val2), but i think that is not a big deal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/29f6d386/attachment.htm>

From holo3146 at gmail.com  Sat Apr 20 21:33:42 2024
From: holo3146 at gmail.com (Holo The Sage Wolf)
Date: Sun, 21 Apr 2024 00:33:42 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q-1KSND_zPyotBCskJ2onBJS6Y0Le5Acn5OkLiXWvaXKA@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>
 <CAP=Y=q-1KSND_zPyotBCskJ2onBJS6Y0Le5Acn5OkLiXWvaXKA@mail.gmail.com>
Message-ID: <CAKswmE6smn1JVHH-iN6OrrvmHVZVLufNoW5tKgUC3i-_tfjA=w@mail.gmail.com>

Let me prefix this by saying that I'm a mathematician, so maybe the lingo I
use is a bit different. A multi set has no structure apart from "counting
duplication", just like a set has no structure at all, ordered set **is not
a set** and ordered multi set **is not a multi set**.

With the clarification you gave I understand what you mean and retract my
first question (although I believe that "sortedX" or "priorityX" are the
naming Java has for what you called "orderedX").

> THe whole point of the bag is to store duplicate elements without
preserving order, which allows things like ordered collections.

No, the whole point of the bag is to store elements. The difference between
a bag and a list is that a bag has less, anything you can do with a bag you
can do with a list.

The benefit of having a bag is to have a more restrictive interface for the
times you don't need the extra structure, as well as the possible
performant implementation that doesn't need to respect a stricted contract.

CopyOnWriteArratList is more than just a bag.


> then that just adds one more use case to potential Bag interface

Indeed, I gave concurrent bag as an example of a possible implementation of
a bag interface, but you didn't answer my main question, just how common is
a use if a bag to change the std for it?

To me it sounds like you are interested only on the sorted/navigable
variations, so an alternative solution will be to improve PriorityQueue to
have a "subQueue" methods (and friends) as well as extending it to a
Navigable variation.




On Sun, 21 Apr 2024, 00:01 ??-24 ????????? ??????, <rotan.olexandr at gmail.com>
wrote:

> Concurrent Bag is something like CopyOnWriteArrayList or Vector, don't we
> have it already? (I know vectors aren't optimized). THe whole point of the
> bag is to store duplicate elements without preserving order, which allows
> things like ordered collections. There could be mutable collections for
> concurrency optimized with read-write locks though, if that is what you are
> referring to as "concurrent bag", and I am missing the point why this
> can't be a part of list interface, then that just adds one more use case to
> potential Bag interface.
>
> PS: Ordered means it preserves order based on comparator, what you are
> referring to as ordered essentially means sequential, or am I missing a
> point?
>
> ??, 20 ???. 2024??. ? 23:52, Holo The Sage Wolf <holo3146 at gmail.com>:
>
>> By "ordered collection" you mean "unordered collection"?
>>
>> How common is it to actually use a multiset in general? Of course there
>> are use cases, and there are areas in which it is used a lot, but I don't
>> believe it is common enough to be part of the std with the one exception of
>> concurrent bag.
>>
>> On Sat, 20 Apr 2024, 23:25 ??-24 ????????? ??????, <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> In this letter I would like to express some of my thoughts regarding the
>>> potential Multiset interface.
>>>
>>> I, personally, have encountered a few situations where such an interface
>>> could come in handy, mostly when I needed an ordered collection that
>>> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
>>> itself should have such a collection in its std library. While it is not a
>>> very common problem, there are still a bunch of use cases where such things
>>> could come in handy.
>>>
>>> I am willing to take on development of such thing, but there are a few
>>> concerns about Multiset:
>>>
>>> 1. Is there any other use for this besides ordered collection that
>>> permits duplicates? I can't remember anything else from the top of my head.
>>>
>>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>>> class hierarchy, while not being directly connected. I think introducing
>>> any other ordered collection will require some refactoring of existing
>>> collection interfaces (for example extract SortedCollection from SortedSet,
>>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>>> code, this would be the right decision, but I feel like this will be a very
>>> complex task to accomplish.
>>>
>>> 3. Maybe there should be few versions of Tree collection (for example,
>>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>>> have some expirience implementing both, but is it really needed in standard
>>> library?
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/5d872439/attachment-0001.htm>

From davidalayachew at gmail.com  Sat Apr 20 21:55:16 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 20 Apr 2024 17:55:16 -0400
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
Message-ID: <CAA9v-_PHKGoZUneyyT63W-A12=Dm8H4YBQ4SXmxAaoDVOoW8BA@mail.gmail.com>

I am in full support of this idea. I do also appreciate the functionality
of using a BiFunction<INDEX, T, R> on the map method instead of a normal
Function<WithIndex<T>, R>.

As for the actual enumeration logic, my vote is that it should simply
enumerate as it arrives, with no context or care given to what came before
it. Consider the following examples.

final List<Integer> list = List.of(0, 1, 2, 3, 4, 5, 6, 7, 8, 9);

System.out.println(list.stream().enumerated().filter((idx, val) -> val % 2
== 0).toList());
//0:0, 2:2, 4:4, 6:6, 8:8

System.out.println(list.stream().filter(val -> val % 2 ==
0).enumerated().toList());
//0:0, 1:2, 2:4, 3:6, 4:8

Enumeration is applied as it arrives, and no sooner. That, I feel, will
keep the implementation simplest, and allow the streaming logic to make the
most sense. And I added helpful reinterpretations of filter() method (like
you did with map()), but I don't think either is necessary.

Of course, the big question looming over all of this is -- does this
feature carry its weight? You and I vote yes, but let's see what the
community says.

What do you all think? Is this feature worth it -- with or without some
changes?

On Sat, Apr 20, 2024 at 5:07?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> My proposal regarding findIndex brought up a topic that, as I see, has
> been brought up here multiple times.
>
> My idea is to extend the existing stream interface in the new
> EnumeratedStream interface. Such an approach has a number of advantages.
>
> 1. Some methods will be able to explicitly specify that they require an
> enumerated stream.
>
> 2. This would allow us to use an enumerated stream just as the default
> value stream, if the index is redundant at a certain processing step.
>
> 3. This could help introduce a more user-friendly interface: instead of
> passing pairs of index and value, they could be passed as separate
> variables, which will make code more concise.
>
> Consider following example:
> List.of(1, 2, 3).stream()
>                 .enumerated()
>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>
> looks much better than
> List.of(1, 2, 3).stream()
>                 .enumerated()
>                 .map(pair -> pair.idx % 2 == 0 ? pair.value : -pair.value);
>
> However, I see some caveats with this approach, which relate to parallel
> streams:
> when a stream is backed by a collection, you might expect assigned indexes
> to represent order of iteration through collection, especially when talking
> about sequential collections. Assigning indexes in such streams could be a
> difficult task in a parallel environment. It should either assign index to
> a stream elements at the moment when stream becomes parallelized, which is
> also impossible if already parallelized stream is being enumerated, and
> also wont work for infinite streams, or make enumerated stream at least
> partially sequential by passing elements to processing in order they were
> passed to stream at the first place, which is also hard or maybe even
> impossible to achieve.
>
> Also, side note: methods that already accept 2 parameters might become
> kinda verbose, like reduce that will have to accept for params (idx1, val1,
> idx2, val2), but i think that is not a big deal
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/6a658889/attachment.htm>

From davidalayachew at gmail.com  Sat Apr 20 22:04:18 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 20 Apr 2024 18:04:18 -0400
Subject: Bag (Multiset) Collection
In-Reply-To: <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>
Message-ID: <CAA9v-_O62cpNCNccyNKeJ7DWCJCrZHihc3E1T6CgUhtcH_DPfQ@mail.gmail.com>

Biggest use case is definitely when creating different histograms from the
same dataset. Our friends in sci-py land spend A LOT of time doing this.
Our R friends also use this frequently.

I can imagine this bag implementation would not just be good for
Collections, but would play well with the Collectors framework, as well as
Gatherers.

On Sat, Apr 20, 2024 at 5:57?PM Holo The Sage Wolf <holo3146 at gmail.com>
wrote:

> By "ordered collection" you mean "unordered collection"?
>
> How common is it to actually use a multiset in general? Of course there
> are use cases, and there are areas in which it is used a lot, but I don't
> believe it is common enough to be part of the std with the one exception of
> concurrent bag.
>
> On Sat, 20 Apr 2024, 23:25 ??-24 ????????? ??????, <
> rotan.olexandr at gmail.com> wrote:
>
>> In this letter I would like to express some of my thoughts regarding the
>> potential Multiset interface.
>>
>> I, personally, have encountered a few situations where such an interface
>> could come in handy, mostly when I needed an ordered collection that
>> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
>> itself should have such a collection in its std library. While it is not a
>> very common problem, there are still a bunch of use cases where such things
>> could come in handy.
>>
>> I am willing to take on development of such thing, but there are a few
>> concerns about Multiset:
>>
>> 1. Is there any other use for this besides ordered collection that
>> permits duplicates? I can't remember anything else from the top of my head.
>>
>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>> class hierarchy, while not being directly connected. I think introducing
>> any other ordered collection will require some refactoring of existing
>> collection interfaces (for example extract SortedCollection from SortedSet,
>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>> code, this would be the right decision, but I feel like this will be a very
>> complex task to accomplish.
>>
>> 3. Maybe there should be few versions of Tree collection (for example,
>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>> have some expirience implementing both, but is it really needed in standard
>> library?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/a96f378b/attachment.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 22:17:37 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 01:17:37 +0300
Subject: EnumeratedStream
In-Reply-To: <CAA9v-_PHKGoZUneyyT63W-A12=Dm8H4YBQ4SXmxAaoDVOoW8BA@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CAA9v-_PHKGoZUneyyT63W-A12=Dm8H4YBQ4SXmxAaoDVOoW8BA@mail.gmail.com>
Message-ID: <CAP=Y=q9YQ69oLnNvmscTn-Ljs6MSO+jbowFxcKhchT3cpmotvA@mail.gmail.com>

Yes, your point about enumeration is the best way to do it, i guess, I am
also voting for this. This makes the most sense considering the way that
method invocation chains should be handled

??, 21 ???. 2024??. ? 00:55, David Alayachew <davidalayachew at gmail.com>:

> I am in full support of this idea. I do also appreciate the functionality
> of using a BiFunction<INDEX, T, R> on the map method instead of a normal
> Function<WithIndex<T>, R>.
>
> As for the actual enumeration logic, my vote is that it should simply
> enumerate as it arrives, with no context or care given to what came before
> it. Consider the following examples.
>
> final List<Integer> list = List.of(0, 1, 2, 3, 4, 5, 6, 7, 8, 9);
>
> System.out.println(list.stream().enumerated().filter((idx, val) -> val % 2
> == 0).toList());
> //0:0, 2:2, 4:4, 6:6, 8:8
>
> System.out.println(list.stream().filter(val -> val % 2 ==
> 0).enumerated().toList());
> //0:0, 1:2, 2:4, 3:6, 4:8
>
> Enumeration is applied as it arrives, and no sooner. That, I feel, will
> keep the implementation simplest, and allow the streaming logic to make the
> most sense. And I added helpful reinterpretations of filter() method (like
> you did with map()), but I don't think either is necessary.
>
> Of course, the big question looming over all of this is -- does this
> feature carry its weight? You and I vote yes, but let's see what the
> community says.
>
> What do you all think? Is this feature worth it -- with or without some
> changes?
>
> On Sat, Apr 20, 2024 at 5:07?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> My proposal regarding findIndex brought up a topic that, as I see, has
>> been brought up here multiple times.
>>
>> My idea is to extend the existing stream interface in the new
>> EnumeratedStream interface. Such an approach has a number of advantages.
>>
>> 1. Some methods will be able to explicitly specify that they require an
>> enumerated stream.
>>
>> 2. This would allow us to use an enumerated stream just as the default
>> value stream, if the index is redundant at a certain processing step.
>>
>> 3. This could help introduce a more user-friendly interface: instead of
>> passing pairs of index and value, they could be passed as separate
>> variables, which will make code more concise.
>>
>> Consider following example:
>> List.of(1, 2, 3).stream()
>>                 .enumerated()
>>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>>
>> looks much better than
>> List.of(1, 2, 3).stream()
>>                 .enumerated()
>>                 .map(pair -> pair.idx % 2 == 0 ? pair.value :
>> -pair.value);
>>
>> However, I see some caveats with this approach, which relate to parallel
>> streams:
>> when a stream is backed by a collection, you might expect assigned
>> indexes to represent order of iteration through collection, especially when
>> talking about sequential collections. Assigning indexes in such streams
>> could be a difficult task in a parallel environment. It should either
>> assign index to a stream elements at the moment when stream becomes
>> parallelized, which is also impossible if already parallelized stream is
>> being enumerated, and also wont work for infinite streams, or make
>> enumerated stream at least partially sequential by passing elements to
>> processing in order they were passed to stream at the first place, which is
>> also hard or maybe even impossible to achieve.
>>
>> Also, side note: methods that already accept 2 parameters might become
>> kinda verbose, like reduce that will have to accept for params (idx1, val1,
>> idx2, val2), but i think that is not a big deal
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/1acc57e7/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 22:19:03 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 01:19:03 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q-F--qngiOTcEGuMzFcrPA3bsu05Add1Xw=ZHn3Su=C7w@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>
 <CAP=Y=q-1KSND_zPyotBCskJ2onBJS6Y0Le5Acn5OkLiXWvaXKA@mail.gmail.com>
 <CAKswmE6smn1JVHH-iN6OrrvmHVZVLufNoW5tKgUC3i-_tfjA=w@mail.gmail.com>
 <CAP=Y=q-F--qngiOTcEGuMzFcrPA3bsu05Add1Xw=ZHn3Su=C7w@mail.gmail.com>
Message-ID: <CAP=Y=q_7cYu_St0_q3k6D-uHVVE-YQMtM4cazMCMsKM3YBfKGw@mail.gmail.com>

Firstly, about queues. As far as I know, priority queue is implemented as
heap, not tree, so things like subQueue doesn't make much sense in this
context.

About popularity: this is indeed not very popular, might even be negligible
outside of sorted multiset (lets adopt java naming conventions for those
from now on). Although, I could provide at least few examples:

1. Batch tasks processing, especially in concurrent environments, when
tasks could have different priorities. Sometimes tasks that are stored in a
queue are processed in batches. Using today's stdlib of Java,
acquiring such a batch of tasks from collection would be a O(n * log n)
complexity, because each heapification is log n and called after each task
is popped. Using TreeMultiset, this could be achieved in log (n). This also
applies to messaging.

2. Implementing custom data structures. Not a task most of commercial
developers encounter, although for specific types of tasks, like big data
processing, custom datastructs could be a thing. Some collections,
expeciall ordered, like B-tree, could require sorted multiset as part of
internal implementation.

3. Again, for sorted multisets, counting frequency is a common task for
commercial developers. Counting element frequencies using multisets is the
thing that simply couldn't be achieved by set and is inefficient in list.
This could have various use cases, from data displaying in histograms in
generated reports to data validation is stateful systems (checking if user
has not exceeded permitted amount of attempts, for example).

4. Storage for the result of db queries. Another common task is to fetch
some ordered data from the database, and then modify it to preserve order.
This category of tasks could be optimized using ordered multisets.

5. Concurent bag, as you just mentioned. This could be used in concurrent
environment as I mentioned above, or just as less restricting
concurrent collection as preserving sequence of elements could be a complex
and resource consuming task in mutable concurrent collections

As you might see, almost all of those indeed converge to a sorted
collection of duplicating elements. I am not sure If there is much more to
it, but what i would like to say is that feature like this would definitely
not be redundant for "enterprise" language like Java, where optimizing some
operations from O(n) or even O(n * log n) to O (log n) could introduce
significant performance improvement, as well as reducing amount of possible
bugs by taking on some of responsibilities related to preserving order of
elements sorted.

??, 21 ???. 2024??. ? 00:33, Holo The Sage Wolf <holo3146 at gmail.com>:

??, 21 ???. 2024??. ? 01:06, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> Firstly, about queues. As far as I know, priority queue is implemented as
> heap, not tree, so things like subQueue doesn't make much sense in this
> context.
>
> About popularity: this is indeed not very popular, might even be
> negligible outside of sorted multiset (lets adopt java naming conventions
> for those from now on). Although, I could provide at least few examples:
>
> 1. Batch tasks processing, especially in concurrent environments, when
> tasks could have different priorities. Sometimes tasks that are stored in a
> queue are processed in batches. Using today's stdlib of Java,
> acquiring such a batch of tasks from collection would be a O(n * log n)
> complexity, because each heapification is log n and called after each task
> is popped. Using TreeMultiset, this could be achieved in log (n). This also
> applies to messaging.
>
> 2. Implementing custom data structures. Not a task most of commercial
> developers encounter, although for specific types of tasks, like big data
> processing, custom datastructs could be a thing. Some collections,
> expeciall ordered, like B-tree, could require sorted multiset as part of
> internal implementation.
>
> 3. Again, for sorted multisets, counting frequency is a common task for
> commercial developers. Counting element frequencies using multisets is the
> thing that simply couldn't be achieved by set and is inefficient in list.
> This could have various use cases, from data displaying in histograms in
> generated reports to data validation is stateful systems (checking if user
> has not exceeded permitted amount of attempts, for example).
>
> 4. Storage for the result of db queries. Another common task is to fetch
> some ordered data from the database, and then modify it to preserve order.
> This category of tasks could be optimized using ordered multisets.
>
> 5. Concurent bag, as you just mentioned. This could be used in concurrent
> environment as I mentioned above, or just as less restricting
> concurrent collection as preserving sequence of elements could be a complex
> and resource consuming task in mutable concurrent collections
>
> As you might see, almost all of those indeed converge to a sorted
> collection of duplicating elements. I am not sure If there is much more to
> it, but what i would like to say is that feature like this would definitely
> not be redundant for "enterprise" language like Java, where optimizing some
> operations from O(n) or even O(n * log n) to O (log n) could introduce
> significant performance improvement, as well as reducing amount of possible
> bugs by taking on some of responsibilities related to preserving order of
> elements sorted.
>
> ??, 21 ???. 2024??. ? 00:33, Holo The Sage Wolf <holo3146 at gmail.com>:
>
>> Let me prefix this by saying that I'm a mathematician, so maybe the lingo
>> I use is a bit different. A multi set has no structure apart from "counting
>> duplication", just like a set has no structure at all, ordered set **is not
>> a set** and ordered multi set **is not a multi set**.
>>
>> With the clarification you gave I understand what you mean and retract my
>> first question (although I believe that "sortedX" or "priorityX" are the
>> naming Java has for what you called "orderedX").
>>
>> > THe whole point of the bag is to store duplicate elements without
>> preserving order, which allows things like ordered collections.
>>
>> No, the whole point of the bag is to store elements. The difference
>> between a bag and a list is that a bag has less, anything you can do with a
>> bag you can do with a list.
>>
>> The benefit of having a bag is to have a more restrictive interface for
>> the times you don't need the extra structure, as well as the possible
>> performant implementation that doesn't need to respect a stricted contract.
>>
>> CopyOnWriteArratList is more than just a bag.
>>
>>
>> > then that just adds one more use case to potential Bag interface
>>
>> Indeed, I gave concurrent bag as an example of a possible implementation
>> of a bag interface, but you didn't answer my main question, just how common
>> is a use if a bag to change the std for it?
>>
>> To me it sounds like you are interested only on the sorted/navigable
>> variations, so an alternative solution will be to improve PriorityQueue to
>> have a "subQueue" methods (and friends) as well as extending it to a
>> Navigable variation.
>>
>>
>>
>>
>> On Sun, 21 Apr 2024, 00:01 ??-24 ????????? ??????, <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Concurrent Bag is something like CopyOnWriteArrayList or Vector, don't
>>> we have it already? (I know vectors aren't optimized). THe whole point of
>>> the bag is to store duplicate elements without preserving order, which
>>> allows things like ordered collections. There could be mutable collections
>>> for concurrency optimized with read-write locks though, if that is what you
>>> are referring to as "concurrent bag", and I am missing the point why this
>>> can't be a part of list interface, then that just adds one more use case to
>>> potential Bag interface.
>>>
>>> PS: Ordered means it preserves order based on comparator, what you are
>>> referring to as ordered essentially means sequential, or am I missing a
>>> point?
>>>
>>> ??, 20 ???. 2024??. ? 23:52, Holo The Sage Wolf <holo3146 at gmail.com>:
>>>
>>>> By "ordered collection" you mean "unordered collection"?
>>>>
>>>> How common is it to actually use a multiset in general? Of course there
>>>> are use cases, and there are areas in which it is used a lot, but I don't
>>>> believe it is common enough to be part of the std with the one exception of
>>>> concurrent bag.
>>>>
>>>> On Sat, 20 Apr 2024, 23:25 ??-24 ????????? ??????, <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> In this letter I would like to express some of my thoughts regarding
>>>>> the potential Multiset interface.
>>>>>
>>>>> I, personally, have encountered a few situations where such an
>>>>> interface could come in handy, mostly when I needed an ordered collection
>>>>> that permits duplicates. That time I used guava`s TreeMultiset, but I think
>>>>> Java itself should have such a collection in its std library. While it is
>>>>> not a very common problem, there are still a bunch of use cases where such
>>>>> things could come in handy.
>>>>>
>>>>> I am willing to take on development of such thing, but there are a few
>>>>> concerns about Multiset:
>>>>>
>>>>> 1. Is there any other use for this besides ordered collection that
>>>>> permits duplicates? I can't remember anything else from the top of my head.
>>>>>
>>>>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>>>>> class hierarchy, while not being directly connected. I think introducing
>>>>> any other ordered collection will require some refactoring of existing
>>>>> collection interfaces (for example extract SortedCollection from SortedSet,
>>>>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>>>>> code, this would be the right decision, but I feel like this will be a very
>>>>> complex task to accomplish.
>>>>>
>>>>> 3. Maybe there should be few versions of Tree collection (for example,
>>>>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>>>>> have some expirience implementing both, but is it really needed in standard
>>>>> library?
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/adbf9b64/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 22:21:24 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 01:21:24 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q_BTd3ONnOtFo=4PaW1CncRLAkXv-W=Ew7HxBRCxJ1gQg@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>
 <CAP=Y=q-1KSND_zPyotBCskJ2onBJS6Y0Le5Acn5OkLiXWvaXKA@mail.gmail.com>
 <CAKswmE6smn1JVHH-iN6OrrvmHVZVLufNoW5tKgUC3i-_tfjA=w@mail.gmail.com>
 <CAP=Y=q-F--qngiOTcEGuMzFcrPA3bsu05Add1Xw=ZHn3Su=C7w@mail.gmail.com>
 <CAP=Y=q_7cYu_St0_q3k6D-uHVVE-YQMtM4cazMCMsKM3YBfKGw@mail.gmail.com>
 <CAP=Y=q_BTd3ONnOtFo=4PaW1CncRLAkXv-W=Ew7HxBRCxJ1gQg@mail.gmail.com>
Message-ID: <CAP=Y=q_K=JfwtJ1ch++5b5eY0h-6K2aaLdY8dbmpVm8=Y-UBwQ@mail.gmail.com>

Also, after some research, I found that HashMultisets also have some area
of application in image detection and event simulations

??, 21 ???. 2024??. ? 01:19, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> Sorry for duplicate, I accidentally sent last message only to you
>
> ??, 21 ???. 2024??. ? 01:19, ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com>:
>
>> Firstly, about queues. As far as I know, priority queue is implemented as
>> heap, not tree, so things like subQueue doesn't make much sense in this
>> context.
>>
>> About popularity: this is indeed not very popular, might even be
>> negligible outside of sorted multiset (lets adopt java naming conventions
>> for those from now on). Although, I could provide at least few examples:
>>
>> 1. Batch tasks processing, especially in concurrent environments, when
>> tasks could have different priorities. Sometimes tasks that are stored in a
>> queue are processed in batches. Using today's stdlib of Java,
>> acquiring such a batch of tasks from collection would be a O(n * log n)
>> complexity, because each heapification is log n and called after each task
>> is popped. Using TreeMultiset, this could be achieved in log (n). This also
>> applies to messaging.
>>
>> 2. Implementing custom data structures. Not a task most of commercial
>> developers encounter, although for specific types of tasks, like big data
>> processing, custom datastructs could be a thing. Some collections,
>> expeciall ordered, like B-tree, could require sorted multiset as part of
>> internal implementation.
>>
>> 3. Again, for sorted multisets, counting frequency is a common task for
>> commercial developers. Counting element frequencies using multisets is the
>> thing that simply couldn't be achieved by set and is inefficient in list.
>> This could have various use cases, from data displaying in histograms in
>> generated reports to data validation is stateful systems (checking if user
>> has not exceeded permitted amount of attempts, for example).
>>
>> 4. Storage for the result of db queries. Another common task is to fetch
>> some ordered data from the database, and then modify it to preserve order.
>> This category of tasks could be optimized using ordered multisets.
>>
>> 5. Concurent bag, as you just mentioned. This could be used in concurrent
>> environment as I mentioned above, or just as less restricting
>> concurrent collection as preserving sequence of elements could be a complex
>> and resource consuming task in mutable concurrent collections
>>
>> As you might see, almost all of those indeed converge to a sorted
>> collection of duplicating elements. I am not sure If there is much more to
>> it, but what i would like to say is that feature like this would definitely
>> not be redundant for "enterprise" language like Java, where optimizing some
>> operations from O(n) or even O(n * log n) to O (log n) could introduce
>> significant performance improvement, as well as reducing amount of possible
>> bugs by taking on some of responsibilities related to preserving order of
>> elements sorted.
>>
>> ??, 21 ???. 2024??. ? 00:33, Holo The Sage Wolf <holo3146 at gmail.com>:
>>
>> ??, 21 ???. 2024??. ? 01:06, ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com>:
>>
>>> Firstly, about queues. As far as I know, priority queue is implemented
>>> as heap, not tree, so things like subQueue doesn't make much sense in this
>>> context.
>>>
>>> About popularity: this is indeed not very popular, might even be
>>> negligible outside of sorted multiset (lets adopt java naming conventions
>>> for those from now on). Although, I could provide at least few examples:
>>>
>>> 1. Batch tasks processing, especially in concurrent environments, when
>>> tasks could have different priorities. Sometimes tasks that are stored in a
>>> queue are processed in batches. Using today's stdlib of Java,
>>> acquiring such a batch of tasks from collection would be a O(n * log n)
>>> complexity, because each heapification is log n and called after each task
>>> is popped. Using TreeMultiset, this could be achieved in log (n). This also
>>> applies to messaging.
>>>
>>> 2. Implementing custom data structures. Not a task most of commercial
>>> developers encounter, although for specific types of tasks, like big data
>>> processing, custom datastructs could be a thing. Some collections,
>>> expeciall ordered, like B-tree, could require sorted multiset as part of
>>> internal implementation.
>>>
>>> 3. Again, for sorted multisets, counting frequency is a common task for
>>> commercial developers. Counting element frequencies using multisets is the
>>> thing that simply couldn't be achieved by set and is inefficient in list.
>>> This could have various use cases, from data displaying in histograms in
>>> generated reports to data validation is stateful systems (checking if user
>>> has not exceeded permitted amount of attempts, for example).
>>>
>>> 4. Storage for the result of db queries. Another common task is to fetch
>>> some ordered data from the database, and then modify it to preserve order.
>>> This category of tasks could be optimized using ordered multisets.
>>>
>>> 5. Concurent bag, as you just mentioned. This could be used in
>>> concurrent environment as I mentioned above, or just as less restricting
>>> concurrent collection as preserving sequence of elements could be a complex
>>> and resource consuming task in mutable concurrent collections
>>>
>>> As you might see, almost all of those indeed converge to a sorted
>>> collection of duplicating elements. I am not sure If there is much more to
>>> it, but what i would like to say is that feature like this would definitely
>>> not be redundant for "enterprise" language like Java, where optimizing some
>>> operations from O(n) or even O(n * log n) to O (log n) could introduce
>>> significant performance improvement, as well as reducing amount of possible
>>> bugs by taking on some of responsibilities related to preserving order of
>>> elements sorted.
>>>
>>> ??, 21 ???. 2024??. ? 00:33, Holo The Sage Wolf <holo3146 at gmail.com>:
>>>
>>>> Let me prefix this by saying that I'm a mathematician, so maybe the
>>>> lingo I use is a bit different. A multi set has no structure apart from
>>>> "counting duplication", just like a set has no structure at all, ordered
>>>> set **is not a set** and ordered multi set **is not a multi set**.
>>>>
>>>> With the clarification you gave I understand what you mean and retract
>>>> my first question (although I believe that "sortedX" or "priorityX" are the
>>>> naming Java has for what you called "orderedX").
>>>>
>>>> > THe whole point of the bag is to store duplicate elements without
>>>> preserving order, which allows things like ordered collections.
>>>>
>>>> No, the whole point of the bag is to store elements. The difference
>>>> between a bag and a list is that a bag has less, anything you can do with a
>>>> bag you can do with a list.
>>>>
>>>> The benefit of having a bag is to have a more restrictive interface for
>>>> the times you don't need the extra structure, as well as the possible
>>>> performant implementation that doesn't need to respect a stricted contract.
>>>>
>>>> CopyOnWriteArratList is more than just a bag.
>>>>
>>>>
>>>> > then that just adds one more use case to potential Bag interface
>>>>
>>>> Indeed, I gave concurrent bag as an example of a possible
>>>> implementation of a bag interface, but you didn't answer my main question,
>>>> just how common is a use if a bag to change the std for it?
>>>>
>>>> To me it sounds like you are interested only on the sorted/navigable
>>>> variations, so an alternative solution will be to improve PriorityQueue to
>>>> have a "subQueue" methods (and friends) as well as extending it to a
>>>> Navigable variation.
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, 21 Apr 2024, 00:01 ??-24 ????????? ??????, <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> Concurrent Bag is something like CopyOnWriteArrayList or Vector, don't
>>>>> we have it already? (I know vectors aren't optimized). THe whole point of
>>>>> the bag is to store duplicate elements without preserving order, which
>>>>> allows things like ordered collections. There could be mutable collections
>>>>> for concurrency optimized with read-write locks though, if that is what you
>>>>> are referring to as "concurrent bag", and I am missing the point why this
>>>>> can't be a part of list interface, then that just adds one more use case to
>>>>> potential Bag interface.
>>>>>
>>>>> PS: Ordered means it preserves order based on comparator, what you are
>>>>> referring to as ordered essentially means sequential, or am I missing a
>>>>> point?
>>>>>
>>>>> ??, 20 ???. 2024??. ? 23:52, Holo The Sage Wolf <holo3146 at gmail.com>:
>>>>>
>>>>>> By "ordered collection" you mean "unordered collection"?
>>>>>>
>>>>>> How common is it to actually use a multiset in general? Of course
>>>>>> there are use cases, and there are areas in which it is used a lot, but I
>>>>>> don't believe it is common enough to be part of the std with the one
>>>>>> exception of concurrent bag.
>>>>>>
>>>>>> On Sat, 20 Apr 2024, 23:25 ??-24 ????????? ??????, <
>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>
>>>>>>> In this letter I would like to express some of my thoughts regarding
>>>>>>> the potential Multiset interface.
>>>>>>>
>>>>>>> I, personally, have encountered a few situations where such an
>>>>>>> interface could come in handy, mostly when I needed an ordered collection
>>>>>>> that permits duplicates. That time I used guava`s TreeMultiset, but I think
>>>>>>> Java itself should have such a collection in its std library. While it is
>>>>>>> not a very common problem, there are still a bunch of use cases where such
>>>>>>> things could come in handy.
>>>>>>>
>>>>>>> I am willing to take on development of such thing, but there are a
>>>>>>> few concerns about Multiset:
>>>>>>>
>>>>>>> 1. Is there any other use for this besides ordered collection that
>>>>>>> permits duplicates? I can't remember anything else from the top of my head.
>>>>>>>
>>>>>>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>>>>>>> class hierarchy, while not being directly connected. I think introducing
>>>>>>> any other ordered collection will require some refactoring of existing
>>>>>>> collection interfaces (for example extract SortedCollection from SortedSet,
>>>>>>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>>>>>>> code, this would be the right decision, but I feel like this will be a very
>>>>>>> complex task to accomplish.
>>>>>>>
>>>>>>> 3. Maybe there should be few versions of Tree collection (for
>>>>>>> example, for regular tasks red-black tree and B-Tree for large amounts of
>>>>>>> data). I have some expirience implementing both, but is it really needed in
>>>>>>> standard library?
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/e006929e/attachment-0001.htm>

From sgibbons at openjdk.org  Sat Apr 20 22:31:48 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 20 Apr 2024 22:31:48 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v26]
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'openjdk:master' into setMemory
 - Fix UnsafeCopyMemoryMark scope issue
 - Long to short jmp; other cleanup
 - Review comments
 - Address review comments; update copyright years
 - Add enter() and leave(); remove Windows-specific register stuff
 - Fix memory mark after sync to upstream
 - Merge branch 'openjdk:master' into setMemory
 - Set memory test (#23)
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill
   
   * Remove MUSL_LIBC ifdef
   
   * Remove MUSL_LIBC ifdef
 - Set memory test (#22)
   
   * Even more review comments
   
   * Re-write of atomic copy loops
   
   * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
   
   * Only add a memory mark for byte unaligned fill
 - ... and 27 more: https://git.openjdk.org/jdk/compare/6d569961...1122b500

-------------

Changes: https://git.openjdk.org/jdk/pull/18555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=25
  Stats: 507 lines in 36 files changed: 420 ins; 5 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/18555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18555/head:pull/18555

PR: https://git.openjdk.org/jdk/pull/18555

From sgibbons at openjdk.org  Sat Apr 20 22:31:48 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 20 Apr 2024 22:31:48 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v25]
In-Reply-To: <3Z1vY5KHl-D5I1VoQYb6w0B1QToR0cVOnOov_vfrAe0=.d7e4944e-b781-477a-862b-dc067fab9d13@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <3Z1vY5KHl-D5I1VoQYb6w0B1QToR0cVOnOov_vfrAe0=.d7e4944e-b781-477a-862b-dc067fab9d13@github.com>
Message-ID: <RNjARjLeXpnWX7y2EK1a8qMH_3Jaktx8K5fBbL0m1rQ=.1bd90f47-ce76-425d-b3ac-37a176f504d3@github.com>

On Sat, 20 Apr 2024 19:09:43 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix UnsafeCopyMemoryMark scope issue

Merge done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2067803696

From liangchenblue at gmail.com  Sat Apr 20 22:57:14 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 20 Apr 2024 17:57:14 -0500
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
Message-ID: <CABe8uE1weBaaEdPa3tnaS8ZMYC9t9Jnpyaatv5m0=AWLcr3yXA@mail.gmail.com>

Hi IP-24 Oleksandr Rotan',
You can use a Map<T, Collection<T>>. This map stores T as the object
equivalence key, and each Collection<T> in this map stores the values known
to be equal to the key. Since map compares keys by equals, any key in the
collection can be used to find the collection in the Map<T, Collection<T>>.

If you want a Tree/Navigable multiset, you can just make it a
NavigableMap<T, Collection<T>>. If you use this concurrently, you can
replace the value Collection<T> with something like CopyOnWriteArrayList<T>.

Is there any Multiset functionality not covered by such a Map<T,
Collection<T>> setup?

P.S. For the other versions of tree collections, I think JDK uses Red Black
tree due to its superior performance when there's frequent removal. AVL is
known for faster additions but involves a lot more balance operations
during removal. If we are looking at immutable navigable/sorted
collections, we can use an array and perform binary search, which works
just like a tree.

Regards,
Chen Liang


On Sat, Apr 20, 2024 at 3:25?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> In this letter I would like to express some of my thoughts regarding the
> potential Multiset interface.
>
> I, personally, have encountered a few situations where such an interface
> could come in handy, mostly when I needed an ordered collection that
> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
> itself should have such a collection in its std library. While it is not a
> very common problem, there are still a bunch of use cases where such things
> could come in handy.
>
> I am willing to take on development of such thing, but there are a few
> concerns about Multiset:
>
> 1. Is there any other use for this besides ordered collection that permits
> duplicates? I can't remember anything else from the top of my head.
>
> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet class
> hierarchy, while not being directly connected. I think introducing any
> other ordered collection will require some refactoring of existing
> collection interfaces (for example extract SortedCollection from SortedSet,
> Navigable Collection from NavigableSet etc.). From the perspective of clean
> code, this would be the right decision, but I feel like this will be a very
> complex task to accomplish.
>
> 3. Maybe there should be few versions of Tree collection (for example, for
> regular tasks red-black tree and B-Tree for large amounts of data). I have
> some expirience implementing both, but is it really needed in standard
> library?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/e959ab8f/attachment.htm>

From liangchenblue at gmail.com  Sat Apr 20 23:05:59 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 20 Apr 2024 18:05:59 -0500
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
Message-ID: <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>

Hi Oleksandr,
I fear that enumeration might not be applicable to all streams, especially
parallel ones. If we have a parallel stream, we might not always process
all elements in order, and even index generation can be unreliable. In
addition, stream merging will become a headache. I think Gatherers.scan(()
-> new Indexed<>(0, dummy), (indexed, value) -> new
Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
which should serve your purpose.

And for expanded operations for enumerated streams, there are similar
features for primitive streams already, where they have extra methods like
summaryStatistics() compared to object streams. We most likely will have
Gatherers that explicitly work on Stream<Indexed<V>> to support
type-specific operations, partly due to Java's type limits and that Stream
hierarchy is effectively closed.

Best,
Chen Liang

On Sat, Apr 20, 2024 at 4:07?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> My proposal regarding findIndex brought up a topic that, as I see, has
> been brought up here multiple times.
>
> My idea is to extend the existing stream interface in the new
> EnumeratedStream interface. Such an approach has a number of advantages.
>
> 1. Some methods will be able to explicitly specify that they require an
> enumerated stream.
>
> 2. This would allow us to use an enumerated stream just as the default
> value stream, if the index is redundant at a certain processing step.
>
> 3. This could help introduce a more user-friendly interface: instead of
> passing pairs of index and value, they could be passed as separate
> variables, which will make code more concise.
>
> Consider following example:
> List.of(1, 2, 3).stream()
>                 .enumerated()
>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>
> looks much better than
> List.of(1, 2, 3).stream()
>                 .enumerated()
>                 .map(pair -> pair.idx % 2 == 0 ? pair.value : -pair.value);
>
> However, I see some caveats with this approach, which relate to parallel
> streams:
> when a stream is backed by a collection, you might expect assigned indexes
> to represent order of iteration through collection, especially when talking
> about sequential collections. Assigning indexes in such streams could be a
> difficult task in a parallel environment. It should either assign index to
> a stream elements at the moment when stream becomes parallelized, which is
> also impossible if already parallelized stream is being enumerated, and
> also wont work for infinite streams, or make enumerated stream at least
> partially sequential by passing elements to processing in order they were
> passed to stream at the first place, which is also hard or maybe even
> impossible to achieve.
>
> Also, side note: methods that already accept 2 parameters might become
> kinda verbose, like reduce that will have to accept for params (idx1, val1,
> idx2, val2), but i think that is not a big deal
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/13162438/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 23:20:06 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 02:20:06 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CABe8uE1weBaaEdPa3tnaS8ZMYC9t9Jnpyaatv5m0=AWLcr3yXA@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CABe8uE1weBaaEdPa3tnaS8ZMYC9t9Jnpyaatv5m0=AWLcr3yXA@mail.gmail.com>
Message-ID: <CAP=Y=q9qnzH_sFXGY6Kvjy1+1aCnF1s3zY2hrEkgh0_1udrsBg@mail.gmail.com>

Hello!

The example you have provided is indeed a workaround. Such a setup indeed
covers most of the problems, nothing I could get from the top of my head
that can't be accomplished using this.

However, there are a few downsides:

1. Obvious performance and memory overhead. I think no elaboration here is
needed, maybe jsut point out that, from my experience, we are talking about
multiples of 10 when explaining gap in performance.

2. Extremely uncomfortable API. Most of the operations with multisets, at
the end of the day, converge to iteration over elements. Every data
processing pipeline requires additional flattening before processing in
most of the cases, or using nested loops. If, for example, you have a web
API that works with data processing and visualization, every IO operation
would require mapping from list or array to map back and forth. This could
(and will) introduce some errors and make code less maintainable.

Also, which is important for me, this approach is very frustrating. My goal
will always be developer experience improvement in the first place. I know
that is not a top-level priority for Java maintainers, but I will always
try my best to make the life of Java users more comfortable.

??, 21 ???. 2024??. ? 01:57, - <liangchenblue at gmail.com>:

> Hi IP-24 Oleksandr Rotan',
> You can use a Map<T, Collection<T>>. This map stores T as the object
> equivalence key, and each Collection<T> in this map stores the values known
> to be equal to the key. Since map compares keys by equals, any key in the
> collection can be used to find the collection in the Map<T, Collection<T>>.
>
> If you want a Tree/Navigable multiset, you can just make it a
> NavigableMap<T, Collection<T>>. If you use this concurrently, you can
> replace the value Collection<T> with something like CopyOnWriteArrayList<T>.
>
> Is there any Multiset functionality not covered by such a Map<T,
> Collection<T>> setup?
>
> P.S. For the other versions of tree collections, I think JDK uses Red
> Black tree due to its superior performance when there's frequent removal.
> AVL is known for faster additions but involves a lot more balance
> operations during removal. If we are looking at immutable navigable/sorted
> collections, we can use an array and perform binary search, which works
> just like a tree.
>
> Regards,
> Chen Liang
>
>
> On Sat, Apr 20, 2024 at 3:25?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> In this letter I would like to express some of my thoughts regarding the
>> potential Multiset interface.
>>
>> I, personally, have encountered a few situations where such an interface
>> could come in handy, mostly when I needed an ordered collection that
>> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
>> itself should have such a collection in its std library. While it is not a
>> very common problem, there are still a bunch of use cases where such things
>> could come in handy.
>>
>> I am willing to take on development of such thing, but there are a few
>> concerns about Multiset:
>>
>> 1. Is there any other use for this besides ordered collection that
>> permits duplicates? I can't remember anything else from the top of my head.
>>
>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>> class hierarchy, while not being directly connected. I think introducing
>> any other ordered collection will require some refactoring of existing
>> collection interfaces (for example extract SortedCollection from SortedSet,
>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>> code, this would be the right decision, but I feel like this will be a very
>> complex task to accomplish.
>>
>> 3. Maybe there should be few versions of Tree collection (for example,
>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>> have some expirience implementing both, but is it really needed in standard
>> library?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/3e807b52/attachment.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 23:33:26 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 02:33:26 +0300
Subject: EnumeratedStream
In-Reply-To: <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
Message-ID: <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>

Hello again.

I have imagined implementation of enumerated streams in a slightly
different way. I think enumerated streams should be a separate kind of
stream like parallel, sequential or some primitive stream. This way
enumeration could be deferred to the time that index is being consumed,
This would eliminate issue with stream merging and also kind of smoothen
the issue with parallel streams, as the indexed will follow the order
elements have been passed to processing.

This could potentially lead to another issue with consistency of indexes
through stream pipeline, but there could be a workaround like
IdentityHashMaps that is received from previous enumerated streams.

This way we could make streams more efficient and also introduce a more
user-friendly API, which is essentially a win-win situation.

Regarding concatenation specifically, we could either introduce separate
methods for merging enumerated streams, where we define how conflicts are
resolved, or just treat them as usual streams, so the result of
concatenation of enumerated streams will result in a normal stream that
should be enumerated once again. Also i don't really see how gathering
elements into index-value pairs solves issue with conflicting indexes

??, 21 ???. 2024??. ? 02:06, - <liangchenblue at gmail.com>:

> Hi Oleksandr,
> I fear that enumeration might not be applicable to all streams, especially
> parallel ones. If we have a parallel stream, we might not always process
> all elements in order, and even index generation can be unreliable. In
> addition, stream merging will become a headache. I think Gatherers.scan(()
> -> new Indexed<>(0, dummy), (indexed, value) -> new
> Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
> which should serve your purpose.
>
> And for expanded operations for enumerated streams, there are similar
> features for primitive streams already, where they have extra methods like
> summaryStatistics() compared to object streams. We most likely will have
> Gatherers that explicitly work on Stream<Indexed<V>> to support
> type-specific operations, partly due to Java's type limits and that Stream
> hierarchy is effectively closed.
>
> Best,
> Chen Liang
>
> On Sat, Apr 20, 2024 at 4:07?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> My proposal regarding findIndex brought up a topic that, as I see, has
>> been brought up here multiple times.
>>
>> My idea is to extend the existing stream interface in the new
>> EnumeratedStream interface. Such an approach has a number of advantages.
>>
>> 1. Some methods will be able to explicitly specify that they require an
>> enumerated stream.
>>
>> 2. This would allow us to use an enumerated stream just as the default
>> value stream, if the index is redundant at a certain processing step.
>>
>> 3. This could help introduce a more user-friendly interface: instead of
>> passing pairs of index and value, they could be passed as separate
>> variables, which will make code more concise.
>>
>> Consider following example:
>> List.of(1, 2, 3).stream()
>>                 .enumerated()
>>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>>
>> looks much better than
>> List.of(1, 2, 3).stream()
>>                 .enumerated()
>>                 .map(pair -> pair.idx % 2 == 0 ? pair.value :
>> -pair.value);
>>
>> However, I see some caveats with this approach, which relate to parallel
>> streams:
>> when a stream is backed by a collection, you might expect assigned
>> indexes to represent order of iteration through collection, especially when
>> talking about sequential collections. Assigning indexes in such streams
>> could be a difficult task in a parallel environment. It should either
>> assign index to a stream elements at the moment when stream becomes
>> parallelized, which is also impossible if already parallelized stream is
>> being enumerated, and also wont work for infinite streams, or make
>> enumerated stream at least partially sequential by passing elements to
>> processing in order they were passed to stream at the first place, which is
>> also hard or maybe even impossible to achieve.
>>
>> Also, side note: methods that already accept 2 parameters might become
>> kinda verbose, like reduce that will have to accept for params (idx1, val1,
>> idx2, val2), but i think that is not a big deal
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/7ca44e77/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 23:47:28 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 02:47:28 +0300
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
Message-ID: <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>

I would like to correct myself a bit: indexes should be assigned at the
moment an element is received from upstream, not when it is passed to
processing. Not sure if it will effectively change order of execution in
actual implementation, but to put it this way would be more precise

??, 21 ???. 2024??. ? 02:33, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> Hello again.
>
> I have imagined implementation of enumerated streams in a slightly
> different way. I think enumerated streams should be a separate kind of
> stream like parallel, sequential or some primitive stream. This way
> enumeration could be deferred to the time that index is being consumed,
> This would eliminate issue with stream merging and also kind of smoothen
> the issue with parallel streams, as the indexed will follow the order
> elements have been passed to processing.
>
> This could potentially lead to another issue with consistency of indexes
> through stream pipeline, but there could be a workaround like
> IdentityHashMaps that is received from previous enumerated streams.
>
> This way we could make streams more efficient and also introduce a more
> user-friendly API, which is essentially a win-win situation.
>
> Regarding concatenation specifically, we could either introduce separate
> methods for merging enumerated streams, where we define how conflicts are
> resolved, or just treat them as usual streams, so the result of
> concatenation of enumerated streams will result in a normal stream that
> should be enumerated once again. Also i don't really see how gathering
> elements into index-value pairs solves issue with conflicting indexes
>
> ??, 21 ???. 2024??. ? 02:06, - <liangchenblue at gmail.com>:
>
>> Hi Oleksandr,
>> I fear that enumeration might not be applicable to all streams,
>> especially parallel ones. If we have a parallel stream, we might not always
>> process all elements in order, and even index generation can be unreliable.
>> In addition, stream merging will become a headache. I think
>> Gatherers.scan(() -> new Indexed<>(0, dummy), (indexed, value) -> new
>> Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
>> which should serve your purpose.
>>
>> And for expanded operations for enumerated streams, there are similar
>> features for primitive streams already, where they have extra methods like
>> summaryStatistics() compared to object streams. We most likely will have
>> Gatherers that explicitly work on Stream<Indexed<V>> to support
>> type-specific operations, partly due to Java's type limits and that Stream
>> hierarchy is effectively closed.
>>
>> Best,
>> Chen Liang
>>
>> On Sat, Apr 20, 2024 at 4:07?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> My proposal regarding findIndex brought up a topic that, as I see, has
>>> been brought up here multiple times.
>>>
>>> My idea is to extend the existing stream interface in the new
>>> EnumeratedStream interface. Such an approach has a number of advantages.
>>>
>>> 1. Some methods will be able to explicitly specify that they require an
>>> enumerated stream.
>>>
>>> 2. This would allow us to use an enumerated stream just as the default
>>> value stream, if the index is redundant at a certain processing step.
>>>
>>> 3. This could help introduce a more user-friendly interface: instead of
>>> passing pairs of index and value, they could be passed as separate
>>> variables, which will make code more concise.
>>>
>>> Consider following example:
>>> List.of(1, 2, 3).stream()
>>>                 .enumerated()
>>>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>>>
>>> looks much better than
>>> List.of(1, 2, 3).stream()
>>>                 .enumerated()
>>>                 .map(pair -> pair.idx % 2 == 0 ? pair.value :
>>> -pair.value);
>>>
>>> However, I see some caveats with this approach, which relate to parallel
>>> streams:
>>> when a stream is backed by a collection, you might expect assigned
>>> indexes to represent order of iteration through collection, especially when
>>> talking about sequential collections. Assigning indexes in such streams
>>> could be a difficult task in a parallel environment. It should either
>>> assign index to a stream elements at the moment when stream becomes
>>> parallelized, which is also impossible if already parallelized stream is
>>> being enumerated, and also wont work for infinite streams, or make
>>> enumerated stream at least partially sequential by passing elements to
>>> processing in order they were passed to stream at the first place, which is
>>> also hard or maybe even impossible to achieve.
>>>
>>> Also, side note: methods that already accept 2 parameters might become
>>> kinda verbose, like reduce that will have to accept for params (idx1, val1,
>>> idx2, val2), but i think that is not a big deal
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/e547bf26/attachment.htm>

From liangchenblue at gmail.com  Sun Apr 21 00:08:00 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 20 Apr 2024 19:08:00 -0500
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
Message-ID: <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>

We must convert index-processing operations to a `gather(Gatherers.scan(/*
index gathering */))` immediate before the operation that uses the index,
and immediately unwrap the indices afterwards.

Syntactically writing such 3 lines for every index-aware operation would be
weird; I actually wonder if we can find a way to convert a
Gatherer<Indexed<T>, ?, R> into a Gatherer<T, ?, R>; the nested gatherer
itself will receive the enumerated values. I don't know if such a way to
compose Gatherer has been studied, but this would allow us to define all
indexed operations as gatherers instead of having to make new
BiConsumers for indices. This would be interesting to look into. So the
ideal form would be:

BiPredicate<Integer, T> filter = ...
Gatherer<Indexed<T>, ?, R> filterGatherer = Gatherer.of((_, indexed, sink)
-> return (!filter.test(indexed.index(), indexed.value())) ||
sink.push(indexed.value()));
Gatherer<T, ?, R> wrapped = IndexedGatherer.wrap(filterGatherer); // a
factory method performing wrapping
return stream.gather(wrapped) // and more

On Sat, Apr 20, 2024 at 6:47?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> I would like to correct myself a bit: indexes should be assigned at the
> moment an element is received from upstream, not when it is passed to
> processing. Not sure if it will effectively change order of execution in
> actual implementation, but to put it this way would be more precise
>
> ??, 21 ???. 2024??. ? 02:33, ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com>:
>
>> Hello again.
>>
>> I have imagined implementation of enumerated streams in a slightly
>> different way. I think enumerated streams should be a separate kind of
>> stream like parallel, sequential or some primitive stream. This way
>> enumeration could be deferred to the time that index is being consumed,
>> This would eliminate issue with stream merging and also kind of smoothen
>> the issue with parallel streams, as the indexed will follow the order
>> elements have been passed to processing.
>>
>> This could potentially lead to another issue with consistency of indexes
>> through stream pipeline, but there could be a workaround like
>> IdentityHashMaps that is received from previous enumerated streams.
>>
>> This way we could make streams more efficient and also introduce a more
>> user-friendly API, which is essentially a win-win situation.
>>
>> Regarding concatenation specifically, we could either introduce separate
>> methods for merging enumerated streams, where we define how conflicts are
>> resolved, or just treat them as usual streams, so the result of
>> concatenation of enumerated streams will result in a normal stream that
>> should be enumerated once again. Also i don't really see how gathering
>> elements into index-value pairs solves issue with conflicting indexes
>>
>> ??, 21 ???. 2024??. ? 02:06, - <liangchenblue at gmail.com>:
>>
>>> Hi Oleksandr,
>>> I fear that enumeration might not be applicable to all streams,
>>> especially parallel ones. If we have a parallel stream, we might not always
>>> process all elements in order, and even index generation can be unreliable.
>>> In addition, stream merging will become a headache. I think
>>> Gatherers.scan(() -> new Indexed<>(0, dummy), (indexed, value) -> new
>>> Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
>>> which should serve your purpose.
>>>
>>> And for expanded operations for enumerated streams, there are similar
>>> features for primitive streams already, where they have extra methods like
>>> summaryStatistics() compared to object streams. We most likely will have
>>> Gatherers that explicitly work on Stream<Indexed<V>> to support
>>> type-specific operations, partly due to Java's type limits and that Stream
>>> hierarchy is effectively closed.
>>>
>>> Best,
>>> Chen Liang
>>>
>>> On Sat, Apr 20, 2024 at 4:07?PM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> My proposal regarding findIndex brought up a topic that, as I see, has
>>>> been brought up here multiple times.
>>>>
>>>> My idea is to extend the existing stream interface in the new
>>>> EnumeratedStream interface. Such an approach has a number of advantages.
>>>>
>>>> 1. Some methods will be able to explicitly specify that they require an
>>>> enumerated stream.
>>>>
>>>> 2. This would allow us to use an enumerated stream just as the default
>>>> value stream, if the index is redundant at a certain processing step.
>>>>
>>>> 3. This could help introduce a more user-friendly interface: instead of
>>>> passing pairs of index and value, they could be passed as separate
>>>> variables, which will make code more concise.
>>>>
>>>> Consider following example:
>>>> List.of(1, 2, 3).stream()
>>>>                 .enumerated()
>>>>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>>>>
>>>> looks much better than
>>>> List.of(1, 2, 3).stream()
>>>>                 .enumerated()
>>>>                 .map(pair -> pair.idx % 2 == 0 ? pair.value :
>>>> -pair.value);
>>>>
>>>> However, I see some caveats with this approach, which relate to
>>>> parallel streams:
>>>> when a stream is backed by a collection, you might expect assigned
>>>> indexes to represent order of iteration through collection, especially when
>>>> talking about sequential collections. Assigning indexes in such streams
>>>> could be a difficult task in a parallel environment. It should either
>>>> assign index to a stream elements at the moment when stream becomes
>>>> parallelized, which is also impossible if already parallelized stream is
>>>> being enumerated, and also wont work for infinite streams, or make
>>>> enumerated stream at least partially sequential by passing elements to
>>>> processing in order they were passed to stream at the first place, which is
>>>> also hard or maybe even impossible to achieve.
>>>>
>>>> Also, side note: methods that already accept 2 parameters might become
>>>> kinda verbose, like reduce that will have to accept for params (idx1, val1,
>>>> idx2, val2), but i think that is not a big deal
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/5c7aa787/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sun Apr 21 00:12:58 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 03:12:58 +0300
Subject: EnumeratedStream
In-Reply-To: <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
Message-ID: <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>

I am sorry, but I feel like I am missing the point of your response and how
is it related to what I have said.

Regarding wrapping and unwrapping indexed pairs, one of advantages of the
approach I have suggested is that EnumeratedStream is still a stream and
all index-unaware ops could still be applied to it

On Sun, Apr 21, 2024, 03:08 - <liangchenblue at gmail.com> wrote:

> We must convert index-processing operations to a `gather(Gatherers.scan(/*
> index gathering */))` immediate before the operation that uses the index,
> and immediately unwrap the indices afterwards.
>
> Syntactically writing such 3 lines for every index-aware operation would
> be weird; I actually wonder if we can find a way to convert a
> Gatherer<Indexed<T>, ?, R> into a Gatherer<T, ?, R>; the nested gatherer
> itself will receive the enumerated values. I don't know if such a way to
> compose Gatherer has been studied, but this would allow us to define all
> indexed operations as gatherers instead of having to make new
> BiConsumers for indices. This would be interesting to look into. So the
> ideal form would be:
>
> BiPredicate<Integer, T> filter = ...
> Gatherer<Indexed<T>, ?, R> filterGatherer = Gatherer.of((_, indexed, sink)
> -> return (!filter.test(indexed.index(), indexed.value())) ||
> sink.push(indexed.value()));
> Gatherer<T, ?, R> wrapped = IndexedGatherer.wrap(filterGatherer); // a
> factory method performing wrapping
> return stream.gather(wrapped) // and more
>
> On Sat, Apr 20, 2024 at 6:47?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> I would like to correct myself a bit: indexes should be assigned at the
>> moment an element is received from upstream, not when it is passed to
>> processing. Not sure if it will effectively change order of execution in
>> actual implementation, but to put it this way would be more precise
>>
>> ??, 21 ???. 2024??. ? 02:33, ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com>:
>>
>>> Hello again.
>>>
>>> I have imagined implementation of enumerated streams in a slightly
>>> different way. I think enumerated streams should be a separate kind of
>>> stream like parallel, sequential or some primitive stream. This way
>>> enumeration could be deferred to the time that index is being consumed,
>>> This would eliminate issue with stream merging and also kind of smoothen
>>> the issue with parallel streams, as the indexed will follow the order
>>> elements have been passed to processing.
>>>
>>> This could potentially lead to another issue with consistency of indexes
>>> through stream pipeline, but there could be a workaround like
>>> IdentityHashMaps that is received from previous enumerated streams.
>>>
>>> This way we could make streams more efficient and also introduce a more
>>> user-friendly API, which is essentially a win-win situation.
>>>
>>> Regarding concatenation specifically, we could either introduce separate
>>> methods for merging enumerated streams, where we define how conflicts are
>>> resolved, or just treat them as usual streams, so the result of
>>> concatenation of enumerated streams will result in a normal stream that
>>> should be enumerated once again. Also i don't really see how gathering
>>> elements into index-value pairs solves issue with conflicting indexes
>>>
>>> ??, 21 ???. 2024??. ? 02:06, - <liangchenblue at gmail.com>:
>>>
>>>> Hi Oleksandr,
>>>> I fear that enumeration might not be applicable to all streams,
>>>> especially parallel ones. If we have a parallel stream, we might not always
>>>> process all elements in order, and even index generation can be unreliable.
>>>> In addition, stream merging will become a headache. I think
>>>> Gatherers.scan(() -> new Indexed<>(0, dummy), (indexed, value) -> new
>>>> Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
>>>> which should serve your purpose.
>>>>
>>>> And for expanded operations for enumerated streams, there are similar
>>>> features for primitive streams already, where they have extra methods like
>>>> summaryStatistics() compared to object streams. We most likely will have
>>>> Gatherers that explicitly work on Stream<Indexed<V>> to support
>>>> type-specific operations, partly due to Java's type limits and that Stream
>>>> hierarchy is effectively closed.
>>>>
>>>> Best,
>>>> Chen Liang
>>>>
>>>> On Sat, Apr 20, 2024 at 4:07?PM ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> My proposal regarding findIndex brought up a topic that, as I see, has
>>>>> been brought up here multiple times.
>>>>>
>>>>> My idea is to extend the existing stream interface in the new
>>>>> EnumeratedStream interface. Such an approach has a number of advantages.
>>>>>
>>>>> 1. Some methods will be able to explicitly specify that they require
>>>>> an enumerated stream.
>>>>>
>>>>> 2. This would allow us to use an enumerated stream just as the default
>>>>> value stream, if the index is redundant at a certain processing step.
>>>>>
>>>>> 3. This could help introduce a more user-friendly interface: instead
>>>>> of passing pairs of index and value, they could be passed as separate
>>>>> variables, which will make code more concise.
>>>>>
>>>>> Consider following example:
>>>>> List.of(1, 2, 3).stream()
>>>>>                 .enumerated()
>>>>>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>>>>>
>>>>> looks much better than
>>>>> List.of(1, 2, 3).stream()
>>>>>                 .enumerated()
>>>>>                 .map(pair -> pair.idx % 2 == 0 ? pair.value :
>>>>> -pair.value);
>>>>>
>>>>> However, I see some caveats with this approach, which relate to
>>>>> parallel streams:
>>>>> when a stream is backed by a collection, you might expect assigned
>>>>> indexes to represent order of iteration through collection, especially when
>>>>> talking about sequential collections. Assigning indexes in such streams
>>>>> could be a difficult task in a parallel environment. It should either
>>>>> assign index to a stream elements at the moment when stream becomes
>>>>> parallelized, which is also impossible if already parallelized stream is
>>>>> being enumerated, and also wont work for infinite streams, or make
>>>>> enumerated stream at least partially sequential by passing elements to
>>>>> processing in order they were passed to stream at the first place, which is
>>>>> also hard or maybe even impossible to achieve.
>>>>>
>>>>> Also, side note: methods that already accept 2 parameters might become
>>>>> kinda verbose, like reduce that will have to accept for params (idx1, val1,
>>>>> idx2, val2), but i think that is not a big deal
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/345115f8/attachment.htm>

From liangchenblue at gmail.com  Sun Apr 21 00:25:36 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 20 Apr 2024 19:25:36 -0500
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
Message-ID: <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>

My point is that we can create Gatherers that gather indexed elements
(indexed gatherer), and another factory wraps the Gatherer so the index
boxing and automatically performed before sending to the indexed gatherer.
All other stream operations, like indexed filter, indexed collect, etc. can
all be done through the indexed gatherer.

On Sat, Apr 20, 2024 at 7:13?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> I am sorry, but I feel like I am missing the point of your response and
> how is it related to what I have said.
>
> Regarding wrapping and unwrapping indexed pairs, one of advantages of the
> approach I have suggested is that EnumeratedStream is still a stream and
> all index-unaware ops could still be applied to it
>
> On Sun, Apr 21, 2024, 03:08 - <liangchenblue at gmail.com> wrote:
>
>> We must convert index-processing operations to a
>> `gather(Gatherers.scan(/* index gathering */))` immediate before the
>> operation that uses the index, and immediately unwrap the indices
>> afterwards.
>>
>> Syntactically writing such 3 lines for every index-aware operation would
>> be weird; I actually wonder if we can find a way to convert a
>> Gatherer<Indexed<T>, ?, R> into a Gatherer<T, ?, R>; the nested gatherer
>> itself will receive the enumerated values. I don't know if such a way to
>> compose Gatherer has been studied, but this would allow us to define all
>> indexed operations as gatherers instead of having to make new
>> BiConsumers for indices. This would be interesting to look into. So the
>> ideal form would be:
>>
>> BiPredicate<Integer, T> filter = ...
>> Gatherer<Indexed<T>, ?, R> filterGatherer = Gatherer.of((_, indexed,
>> sink) -> return (!filter.test(indexed.index(), indexed.value())) ||
>> sink.push(indexed.value()));
>> Gatherer<T, ?, R> wrapped = IndexedGatherer.wrap(filterGatherer); // a
>> factory method performing wrapping
>> return stream.gather(wrapped) // and more
>>
>> On Sat, Apr 20, 2024 at 6:47?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> I would like to correct myself a bit: indexes should be assigned at the
>>> moment an element is received from upstream, not when it is passed to
>>> processing. Not sure if it will effectively change order of execution in
>>> actual implementation, but to put it this way would be more precise
>>>
>>> ??, 21 ???. 2024??. ? 02:33, ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com>:
>>>
>>>> Hello again.
>>>>
>>>> I have imagined implementation of enumerated streams in a slightly
>>>> different way. I think enumerated streams should be a separate kind of
>>>> stream like parallel, sequential or some primitive stream. This way
>>>> enumeration could be deferred to the time that index is being consumed,
>>>> This would eliminate issue with stream merging and also kind of smoothen
>>>> the issue with parallel streams, as the indexed will follow the order
>>>> elements have been passed to processing.
>>>>
>>>> This could potentially lead to another issue with consistency of
>>>> indexes through stream pipeline, but there could be a workaround like
>>>> IdentityHashMaps that is received from previous enumerated streams.
>>>>
>>>> This way we could make streams more efficient and also introduce a more
>>>> user-friendly API, which is essentially a win-win situation.
>>>>
>>>> Regarding concatenation specifically, we could either introduce
>>>> separate methods for merging enumerated streams, where we define how
>>>> conflicts are resolved, or just treat them as usual streams, so the result
>>>> of concatenation of enumerated streams will result in a normal stream that
>>>> should be enumerated once again. Also i don't really see how gathering
>>>> elements into index-value pairs solves issue with conflicting indexes
>>>>
>>>> ??, 21 ???. 2024??. ? 02:06, - <liangchenblue at gmail.com>:
>>>>
>>>>> Hi Oleksandr,
>>>>> I fear that enumeration might not be applicable to all streams,
>>>>> especially parallel ones. If we have a parallel stream, we might not always
>>>>> process all elements in order, and even index generation can be unreliable.
>>>>> In addition, stream merging will become a headache. I think
>>>>> Gatherers.scan(() -> new Indexed<>(0, dummy), (indexed, value) -> new
>>>>> Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
>>>>> which should serve your purpose.
>>>>>
>>>>> And for expanded operations for enumerated streams, there are similar
>>>>> features for primitive streams already, where they have extra methods like
>>>>> summaryStatistics() compared to object streams. We most likely will have
>>>>> Gatherers that explicitly work on Stream<Indexed<V>> to support
>>>>> type-specific operations, partly due to Java's type limits and that Stream
>>>>> hierarchy is effectively closed.
>>>>>
>>>>> Best,
>>>>> Chen Liang
>>>>>
>>>>> On Sat, Apr 20, 2024 at 4:07?PM ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> My proposal regarding findIndex brought up a topic that, as I see,
>>>>>> has been brought up here multiple times.
>>>>>>
>>>>>> My idea is to extend the existing stream interface in the new
>>>>>> EnumeratedStream interface. Such an approach has a number of advantages.
>>>>>>
>>>>>> 1. Some methods will be able to explicitly specify that they require
>>>>>> an enumerated stream.
>>>>>>
>>>>>> 2. This would allow us to use an enumerated stream just as the
>>>>>> default value stream, if the index is redundant at a certain processing
>>>>>> step.
>>>>>>
>>>>>> 3. This could help introduce a more user-friendly interface: instead
>>>>>> of passing pairs of index and value, they could be passed as separate
>>>>>> variables, which will make code more concise.
>>>>>>
>>>>>> Consider following example:
>>>>>> List.of(1, 2, 3).stream()
>>>>>>                 .enumerated()
>>>>>>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>>>>>>
>>>>>> looks much better than
>>>>>> List.of(1, 2, 3).stream()
>>>>>>                 .enumerated()
>>>>>>                 .map(pair -> pair.idx % 2 == 0 ? pair.value :
>>>>>> -pair.value);
>>>>>>
>>>>>> However, I see some caveats with this approach, which relate to
>>>>>> parallel streams:
>>>>>> when a stream is backed by a collection, you might expect assigned
>>>>>> indexes to represent order of iteration through collection, especially when
>>>>>> talking about sequential collections. Assigning indexes in such streams
>>>>>> could be a difficult task in a parallel environment. It should either
>>>>>> assign index to a stream elements at the moment when stream becomes
>>>>>> parallelized, which is also impossible if already parallelized stream is
>>>>>> being enumerated, and also wont work for infinite streams, or make
>>>>>> enumerated stream at least partially sequential by passing elements to
>>>>>> processing in order they were passed to stream at the first place, which is
>>>>>> also hard or maybe even impossible to achieve.
>>>>>>
>>>>>> Also, side note: methods that already accept 2 parameters might
>>>>>> become kinda verbose, like reduce that will have to accept for params
>>>>>> (idx1, val1, idx2, val2), but i think that is not a big deal
>>>>>>
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/b8e1e0cb/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sun Apr 21 00:36:03 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 03:36:03 +0300
Subject: EnumeratedStream
In-Reply-To: <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
Message-ID: <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>

Yes, I think every possible intermediate operation could be made index
aware using gatherers. The point is: should it be turned?

As a developers of jdk itself, we are not limited in a ways we could
provide tools for Java users, especially when it comes to adding completely
new features and not modifying existing apis.

Gatherer-based approach looks like we are developers of third party library
that has to look for workarounds instead of directly adding features we
need. It's syntax is more wordy without any payoff in flexibility, and
obviously would be slower and memory-costy.

For me seems that implementing this using gatherer would only introduce
unnecessary intermediate steps in operation internal pipeline without any
visible payoff.

Also, indexes created this way will be inconsistent between operations, and
I am not sure if that is what we are looking for.

On Sun, Apr 21, 2024, 03:25 - <liangchenblue at gmail.com> wrote:

> My point is that we can create Gatherers that gather indexed elements
> (indexed gatherer), and another factory wraps the Gatherer so the index
> boxing and automatically performed before sending to the indexed gatherer.
> All other stream operations, like indexed filter, indexed collect, etc. can
> all be done through the indexed gatherer.
>
> On Sat, Apr 20, 2024 at 7:13?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> I am sorry, but I feel like I am missing the point of your response and
>> how is it related to what I have said.
>>
>> Regarding wrapping and unwrapping indexed pairs, one of advantages of the
>> approach I have suggested is that EnumeratedStream is still a stream and
>> all index-unaware ops could still be applied to it
>>
>> On Sun, Apr 21, 2024, 03:08 - <liangchenblue at gmail.com> wrote:
>>
>>> We must convert index-processing operations to a
>>> `gather(Gatherers.scan(/* index gathering */))` immediate before the
>>> operation that uses the index, and immediately unwrap the indices
>>> afterwards.
>>>
>>> Syntactically writing such 3 lines for every index-aware operation would
>>> be weird; I actually wonder if we can find a way to convert a
>>> Gatherer<Indexed<T>, ?, R> into a Gatherer<T, ?, R>; the nested gatherer
>>> itself will receive the enumerated values. I don't know if such a way to
>>> compose Gatherer has been studied, but this would allow us to define all
>>> indexed operations as gatherers instead of having to make new
>>> BiConsumers for indices. This would be interesting to look into. So the
>>> ideal form would be:
>>>
>>> BiPredicate<Integer, T> filter = ...
>>> Gatherer<Indexed<T>, ?, R> filterGatherer = Gatherer.of((_, indexed,
>>> sink) -> return (!filter.test(indexed.index(), indexed.value())) ||
>>> sink.push(indexed.value()));
>>> Gatherer<T, ?, R> wrapped = IndexedGatherer.wrap(filterGatherer); // a
>>> factory method performing wrapping
>>> return stream.gather(wrapped) // and more
>>>
>>> On Sat, Apr 20, 2024 at 6:47?PM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> I would like to correct myself a bit: indexes should be assigned at the
>>>> moment an element is received from upstream, not when it is passed to
>>>> processing. Not sure if it will effectively change order of execution in
>>>> actual implementation, but to put it this way would be more precise
>>>>
>>>> ??, 21 ???. 2024??. ? 02:33, ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com>:
>>>>
>>>>> Hello again.
>>>>>
>>>>> I have imagined implementation of enumerated streams in a slightly
>>>>> different way. I think enumerated streams should be a separate kind of
>>>>> stream like parallel, sequential or some primitive stream. This way
>>>>> enumeration could be deferred to the time that index is being consumed,
>>>>> This would eliminate issue with stream merging and also kind of smoothen
>>>>> the issue with parallel streams, as the indexed will follow the order
>>>>> elements have been passed to processing.
>>>>>
>>>>> This could potentially lead to another issue with consistency of
>>>>> indexes through stream pipeline, but there could be a workaround like
>>>>> IdentityHashMaps that is received from previous enumerated streams.
>>>>>
>>>>> This way we could make streams more efficient and also introduce a
>>>>> more user-friendly API, which is essentially a win-win situation.
>>>>>
>>>>> Regarding concatenation specifically, we could either introduce
>>>>> separate methods for merging enumerated streams, where we define how
>>>>> conflicts are resolved, or just treat them as usual streams, so the result
>>>>> of concatenation of enumerated streams will result in a normal stream that
>>>>> should be enumerated once again. Also i don't really see how gathering
>>>>> elements into index-value pairs solves issue with conflicting indexes
>>>>>
>>>>> ??, 21 ???. 2024??. ? 02:06, - <liangchenblue at gmail.com>:
>>>>>
>>>>>> Hi Oleksandr,
>>>>>> I fear that enumeration might not be applicable to all streams,
>>>>>> especially parallel ones. If we have a parallel stream, we might not always
>>>>>> process all elements in order, and even index generation can be unreliable.
>>>>>> In addition, stream merging will become a headache. I think
>>>>>> Gatherers.scan(() -> new Indexed<>(0, dummy), (indexed, value) -> new
>>>>>> Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
>>>>>> which should serve your purpose.
>>>>>>
>>>>>> And for expanded operations for enumerated streams, there are similar
>>>>>> features for primitive streams already, where they have extra methods like
>>>>>> summaryStatistics() compared to object streams. We most likely will have
>>>>>> Gatherers that explicitly work on Stream<Indexed<V>> to support
>>>>>> type-specific operations, partly due to Java's type limits and that Stream
>>>>>> hierarchy is effectively closed.
>>>>>>
>>>>>> Best,
>>>>>> Chen Liang
>>>>>>
>>>>>> On Sat, Apr 20, 2024 at 4:07?PM ??-24 ????????? ?????? <
>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>
>>>>>>> My proposal regarding findIndex brought up a topic that, as I see,
>>>>>>> has been brought up here multiple times.
>>>>>>>
>>>>>>> My idea is to extend the existing stream interface in the new
>>>>>>> EnumeratedStream interface. Such an approach has a number of advantages.
>>>>>>>
>>>>>>> 1. Some methods will be able to explicitly specify that they require
>>>>>>> an enumerated stream.
>>>>>>>
>>>>>>> 2. This would allow us to use an enumerated stream just as the
>>>>>>> default value stream, if the index is redundant at a certain processing
>>>>>>> step.
>>>>>>>
>>>>>>> 3. This could help introduce a more user-friendly interface: instead
>>>>>>> of passing pairs of index and value, they could be passed as separate
>>>>>>> variables, which will make code more concise.
>>>>>>>
>>>>>>> Consider following example:
>>>>>>> List.of(1, 2, 3).stream()
>>>>>>>                 .enumerated()
>>>>>>>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>>>>>>>
>>>>>>> looks much better than
>>>>>>> List.of(1, 2, 3).stream()
>>>>>>>                 .enumerated()
>>>>>>>                 .map(pair -> pair.idx % 2 == 0 ? pair.value :
>>>>>>> -pair.value);
>>>>>>>
>>>>>>> However, I see some caveats with this approach, which relate to
>>>>>>> parallel streams:
>>>>>>> when a stream is backed by a collection, you might expect assigned
>>>>>>> indexes to represent order of iteration through collection, especially when
>>>>>>> talking about sequential collections. Assigning indexes in such streams
>>>>>>> could be a difficult task in a parallel environment. It should either
>>>>>>> assign index to a stream elements at the moment when stream becomes
>>>>>>> parallelized, which is also impossible if already parallelized stream is
>>>>>>> being enumerated, and also wont work for infinite streams, or make
>>>>>>> enumerated stream at least partially sequential by passing elements to
>>>>>>> processing in order they were passed to stream at the first place, which is
>>>>>>> also hard or maybe even impossible to achieve.
>>>>>>>
>>>>>>> Also, side note: methods that already accept 2 parameters might
>>>>>>> become kinda verbose, like reduce that will have to accept for params
>>>>>>> (idx1, val1, idx2, val2), but i think that is not a big deal
>>>>>>>
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/c03311b2/attachment.htm>

From liangchenblue at gmail.com  Sun Apr 21 00:39:44 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 20 Apr 2024 19:39:44 -0500
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q_7cYu_St0_q3k6D-uHVVE-YQMtM4cazMCMsKM3YBfKGw@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAKswmE7EhwjVx40j5bkUEmTWeY0vyCyuRGFPUDK5eKX_C3Y-sA@mail.gmail.com>
 <CAP=Y=q-1KSND_zPyotBCskJ2onBJS6Y0Le5Acn5OkLiXWvaXKA@mail.gmail.com>
 <CAKswmE6smn1JVHH-iN6OrrvmHVZVLufNoW5tKgUC3i-_tfjA=w@mail.gmail.com>
 <CAP=Y=q-F--qngiOTcEGuMzFcrPA3bsu05Add1Xw=ZHn3Su=C7w@mail.gmail.com>
 <CAP=Y=q_7cYu_St0_q3k6D-uHVVE-YQMtM4cazMCMsKM3YBfKGw@mail.gmail.com>
Message-ID: <CABe8uE1LUFACOuKZL2Pag7bsZmoBKygBh7hrULZnsjw3CDnBEw@mail.gmail.com>

>
> 1. Batch tasks processing, especially in concurrent environments, when
> tasks could have different priorities. Sometimes tasks that are stored in a
> queue are processed in batches. Using today's stdlib of Java,
> acquiring such a batch of tasks from collection would be a O(n * log n)
> complexity, because each heapification is log n and called after each task
> is popped. Using TreeMultiset, this could be achieved in log (n). This also
> applies to messaging.
>
This is a good point. There's no way for users to attach tree node metadata
that are maintained when a BST is rebalanced, so having a rank operation
for a Tree Multiset is quite helpful. Unfortunately, not even google guava
supports this operation, but this is technically easy to implement.

I think this is the main advantage of a Multiset over regular Map<T,
Collection<T>> implementations. However, given Java's TreeMap doesn't even
support getting element by rank (its RBTree nodes don't record size), we
might have to start with adding size to RBTree nodes first.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/8a617205/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sun Apr 21 00:44:36 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 03:44:36 +0300
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
 <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
Message-ID: <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>

Also enumerated stream should also support index-aware terminal operations,
which getherers are incapable of, so it will also require to create
index-aware collectors. I am not aware if this is even possible, but this
looks like another separate functionality in different place, and some
developers might just don't be aware of its existence. I think that we as
language devs should think not only about what is possible in language, but
also about is it comfortable and is it obvious for user

On Sun, Apr 21, 2024, 03:36 ??-24 ????????? ?????? <rotan.olexandr at gmail.com>
wrote:

> Yes, I think every possible intermediate operation could be made index
> aware using gatherers. The point is: should it be turned?
>
> As a developers of jdk itself, we are not limited in a ways we could
> provide tools for Java users, especially when it comes to adding completely
> new features and not modifying existing apis.
>
> Gatherer-based approach looks like we are developers of third party
> library that has to look for workarounds instead of directly adding
> features we need. It's syntax is more wordy without any payoff in
> flexibility, and obviously would be slower and memory-costy.
>
> For me seems that implementing this using gatherer would only introduce
> unnecessary intermediate steps in operation internal pipeline without any
> visible payoff.
>
> Also, indexes created this way will be inconsistent between operations,
> and I am not sure if that is what we are looking for.
>
> On Sun, Apr 21, 2024, 03:25 - <liangchenblue at gmail.com> wrote:
>
>> My point is that we can create Gatherers that gather indexed elements
>> (indexed gatherer), and another factory wraps the Gatherer so the index
>> boxing and automatically performed before sending to the indexed gatherer.
>> All other stream operations, like indexed filter, indexed collect, etc. can
>> all be done through the indexed gatherer.
>>
>> On Sat, Apr 20, 2024 at 7:13?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> I am sorry, but I feel like I am missing the point of your response and
>>> how is it related to what I have said.
>>>
>>> Regarding wrapping and unwrapping indexed pairs, one of advantages of
>>> the approach I have suggested is that EnumeratedStream is still a stream
>>> and all index-unaware ops could still be applied to it
>>>
>>> On Sun, Apr 21, 2024, 03:08 - <liangchenblue at gmail.com> wrote:
>>>
>>>> We must convert index-processing operations to a
>>>> `gather(Gatherers.scan(/* index gathering */))` immediate before the
>>>> operation that uses the index, and immediately unwrap the indices
>>>> afterwards.
>>>>
>>>> Syntactically writing such 3 lines for every index-aware operation
>>>> would be weird; I actually wonder if we can find a way to convert a
>>>> Gatherer<Indexed<T>, ?, R> into a Gatherer<T, ?, R>; the nested gatherer
>>>> itself will receive the enumerated values. I don't know if such a way to
>>>> compose Gatherer has been studied, but this would allow us to define all
>>>> indexed operations as gatherers instead of having to make new
>>>> BiConsumers for indices. This would be interesting to look into. So the
>>>> ideal form would be:
>>>>
>>>> BiPredicate<Integer, T> filter = ...
>>>> Gatherer<Indexed<T>, ?, R> filterGatherer = Gatherer.of((_, indexed,
>>>> sink) -> return (!filter.test(indexed.index(), indexed.value())) ||
>>>> sink.push(indexed.value()));
>>>> Gatherer<T, ?, R> wrapped = IndexedGatherer.wrap(filterGatherer); // a
>>>> factory method performing wrapping
>>>> return stream.gather(wrapped) // and more
>>>>
>>>> On Sat, Apr 20, 2024 at 6:47?PM ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> I would like to correct myself a bit: indexes should be assigned at
>>>>> the moment an element is received from upstream, not when it is passed to
>>>>> processing. Not sure if it will effectively change order of execution in
>>>>> actual implementation, but to put it this way would be more precise
>>>>>
>>>>> ??, 21 ???. 2024??. ? 02:33, ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com>:
>>>>>
>>>>>> Hello again.
>>>>>>
>>>>>> I have imagined implementation of enumerated streams in a slightly
>>>>>> different way. I think enumerated streams should be a separate kind of
>>>>>> stream like parallel, sequential or some primitive stream. This way
>>>>>> enumeration could be deferred to the time that index is being consumed,
>>>>>> This would eliminate issue with stream merging and also kind of smoothen
>>>>>> the issue with parallel streams, as the indexed will follow the order
>>>>>> elements have been passed to processing.
>>>>>>
>>>>>> This could potentially lead to another issue with consistency of
>>>>>> indexes through stream pipeline, but there could be a workaround like
>>>>>> IdentityHashMaps that is received from previous enumerated streams.
>>>>>>
>>>>>> This way we could make streams more efficient and also introduce a
>>>>>> more user-friendly API, which is essentially a win-win situation.
>>>>>>
>>>>>> Regarding concatenation specifically, we could either introduce
>>>>>> separate methods for merging enumerated streams, where we define how
>>>>>> conflicts are resolved, or just treat them as usual streams, so the result
>>>>>> of concatenation of enumerated streams will result in a normal stream that
>>>>>> should be enumerated once again. Also i don't really see how gathering
>>>>>> elements into index-value pairs solves issue with conflicting indexes
>>>>>>
>>>>>> ??, 21 ???. 2024??. ? 02:06, - <liangchenblue at gmail.com>:
>>>>>>
>>>>>>> Hi Oleksandr,
>>>>>>> I fear that enumeration might not be applicable to all streams,
>>>>>>> especially parallel ones. If we have a parallel stream, we might not always
>>>>>>> process all elements in order, and even index generation can be unreliable.
>>>>>>> In addition, stream merging will become a headache. I think
>>>>>>> Gatherers.scan(() -> new Indexed<>(0, dummy), (indexed, value) -> new
>>>>>>> Indexed<>(indexed.index() + 1, value)) can create a Stream<Indexed<V>>
>>>>>>> which should serve your purpose.
>>>>>>>
>>>>>>> And for expanded operations for enumerated streams, there are
>>>>>>> similar features for primitive streams already, where they have extra
>>>>>>> methods like summaryStatistics() compared to object streams. We most likely
>>>>>>> will have Gatherers that explicitly work on Stream<Indexed<V>> to support
>>>>>>> type-specific operations, partly due to Java's type limits and that Stream
>>>>>>> hierarchy is effectively closed.
>>>>>>>
>>>>>>> Best,
>>>>>>> Chen Liang
>>>>>>>
>>>>>>> On Sat, Apr 20, 2024 at 4:07?PM ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> My proposal regarding findIndex brought up a topic that, as I see,
>>>>>>>> has been brought up here multiple times.
>>>>>>>>
>>>>>>>> My idea is to extend the existing stream interface in the new
>>>>>>>> EnumeratedStream interface. Such an approach has a number of advantages.
>>>>>>>>
>>>>>>>> 1. Some methods will be able to explicitly specify that they
>>>>>>>> require an enumerated stream.
>>>>>>>>
>>>>>>>> 2. This would allow us to use an enumerated stream just as the
>>>>>>>> default value stream, if the index is redundant at a certain processing
>>>>>>>> step.
>>>>>>>>
>>>>>>>> 3. This could help introduce a more user-friendly interface:
>>>>>>>> instead of passing pairs of index and value, they could be passed as
>>>>>>>> separate variables, which will make code more concise.
>>>>>>>>
>>>>>>>> Consider following example:
>>>>>>>> List.of(1, 2, 3).stream()
>>>>>>>>                 .enumerated()
>>>>>>>>                 .map(idx, value -> idx % 2 == 0 ? value : -value);
>>>>>>>>
>>>>>>>> looks much better than
>>>>>>>> List.of(1, 2, 3).stream()
>>>>>>>>                 .enumerated()
>>>>>>>>                 .map(pair -> pair.idx % 2 == 0 ? pair.value :
>>>>>>>> -pair.value);
>>>>>>>>
>>>>>>>> However, I see some caveats with this approach, which relate to
>>>>>>>> parallel streams:
>>>>>>>> when a stream is backed by a collection, you might expect assigned
>>>>>>>> indexes to represent order of iteration through collection, especially when
>>>>>>>> talking about sequential collections. Assigning indexes in such streams
>>>>>>>> could be a difficult task in a parallel environment. It should either
>>>>>>>> assign index to a stream elements at the moment when stream becomes
>>>>>>>> parallelized, which is also impossible if already parallelized stream is
>>>>>>>> being enumerated, and also wont work for infinite streams, or make
>>>>>>>> enumerated stream at least partially sequential by passing elements to
>>>>>>>> processing in order they were passed to stream at the first place, which is
>>>>>>>> also hard or maybe even impossible to achieve.
>>>>>>>>
>>>>>>>> Also, side note: methods that already accept 2 parameters might
>>>>>>>> become kinda verbose, like reduce that will have to accept for params
>>>>>>>> (idx1, val1, idx2, val2), but i think that is not a big deal
>>>>>>>>
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/e870df28/attachment.htm>

From liangchenblue at gmail.com  Sun Apr 21 01:03:32 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 20 Apr 2024 20:03:32 -0500
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
 <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
 <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>
Message-ID: <CABe8uE28p2tQfByN8VhChgpAHsSYf3c+wYu+WQL2fgwMyB5Mkg@mail.gmail.com>

On Sat, Apr 20, 2024 at 7:44?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Also enumerated stream should also support index-aware terminal
> operations, which getherers are incapable of, so it will also require to
> create index-aware collectors. I am not aware if this is even possible, but
> this looks like another separate functionality in different place, and some
> developers might just don't be aware of its existence. I think that we as
> language devs should think not only about what is possible in language, but
> also about is it comfortable and is it obvious for user
>
Gatherers can become many-to-one; notice it has a state A, it can totally
choose to only emit a single element R in its finisher (i.e. its integrator
only touches state and element and ignores the downstream), then you can
use findAny().orElseThrow() to access that single collector result. That
said, the factory I proposed can try to wrap Collectors the same way it
wraps Gatherers. See conclusion below.

> On Sun, Apr 21, 2024, 03:36 ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> Yes, I think every possible intermediate operation could be made index
>> aware using gatherers. The point is: should it be turned?
>>
>> As a developers of jdk itself, we are not limited in a ways we could
>> provide tools for Java users, especially when it comes to adding completely
>> new features and not modifying existing apis.
>>
> Creating a new type of pipeline is only going to blow up the complexity of
Streams; having IntStream, LongStream, DoubleStream and Stream, together
with the 4-way spliterators (Spliterator.OfInt etc.) and iterators
(PrimitiveIterator.OfInt etc.), is already an API nightmare. And the
indexing will multiply all the intermediate and terminal operations by 2,
further blowing up the API, which I don't believe is the right direction to
go.

>
>>
> Gatherer-based approach looks like we are developers of third party
>> library that has to look for workarounds instead of directly adding
>> features we need. It's syntax is more wordy without any payoff in
>> flexibility, and obviously would be slower and memory-costy.
>>
> Gatherer is not a "third party hook", but an essential API that represents
all possible stream operations, including Collector. Gatherer would not be
slow; it already supports short-circuiting and should not add extra
overheads, as Gatherer is like an API for all possible stream operations.

>
>> For me seems that implementing this using gatherer would only introduce
>> unnecessary intermediate steps in operation internal pipeline without any
>> visible payoff.
>>
> Implementing with Gatherer would reduce useless API exposure, as indexed
operations are't that frequently used and are useless in parallel
scenarios. Especially that these indexed operations aren't optimizable by
stream subclasses, much like how findIndex is not helpful in Lists as
Predicates can't be easily decoded like Object equivalence/hashCode, which
some Lists can use to speed up indexOf.

>
>> Also, indexes created this way will be inconsistent between operations,
>> and I am not sure if that is what we are looking for.
>>
> We declare an index-aware gatherer and my said factory converts it to an
index-unaware, sequential gatherer; the factory gatherer prepares indices
before calling our index-aware gatherer.

For my factory, if you think my 4-line syntax above is too verbose, we can
encapsulate those to become
public static <T> Gatherer<T, ?, T> filter(Predicate<Indexed<T>> predicate)
etc.

And the primary methods will be:
public static <T, A, R> Gatherer<T, ?, R> indexed(Gatherer<Indexed<T>, A,
R> gatherer)
public static <T, A, R> Collector<T, ?, R> indexed(Collector<Indexed<T>, A,
R> collector)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/80407420/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sun Apr 21 01:29:47 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 04:29:47 +0300
Subject: EnumeratedStream
In-Reply-To: <CABe8uE28p2tQfByN8VhChgpAHsSYf3c+wYu+WQL2fgwMyB5Mkg@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
 <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
 <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>
 <CABe8uE28p2tQfByN8VhChgpAHsSYf3c+wYu+WQL2fgwMyB5Mkg@mail.gmail.com>
Message-ID: <CAP=Y=q-fw-sBT0fij-Y6KRxaRZXHQjBDfFpE6wpXwwtzNDxavg@mail.gmail.com>

Gatherers could be effectively terminal, but I don't think Gatherer API
designers intended it to be. In related JEP, gatherers are described as a
way to declare custom intermediate operations, and introducing "terminal"
gatherers would be misleading.

Talking about performance, not even considering gather() method itself,
creating an instance of Indexed object for each value in stream is costy
and might turn into a nightmare for infinite streams.

As for internals of Stream API right now, I am not aware about its current
state, so not much to say here except that adding a new type of streams
that just slightly extends existing functionality might not be that
harmful, I guess.

Regarding API exposure, I don't think that moving it from stream directly
to Gatherers factory would be much of a deal since to see index-aware
methods user must explicitly convert stream to enumerated.

I also think the I didn't express my point about index consistency clear
enough. Consider following:

List.of(1,2,3).stream().enumerated().filter((idx, i) -> i*idx <
2).map((idx, val) -> idx * val)

Result : (4, 9)

With your approach

List.of(1,2,3).stream().gather(Gatherers.filterIndexed((idx, val) ->
idx*val < 2)).gather(Gatherers.mapIndexed((idx, val) -> idx * val))

Result : (2, 6)

Not only second option is much more verbose, but also indexes of stream are
inconsistent between operations.

PS: regarding findIndex, I did some benchmarking today, you might like to
take a look. On average list-based version outperform collector and
gatherer-based in more then 10 times. And also lists in stdlib doesn't have
any hashcode-based implementations. I wrote 19 implementations in list
subclasses and none of them had anything but simple traversing logic inside
indexOf. But that's topic of another thread

On Sun, Apr 21, 2024, 04:03 - <liangchenblue at gmail.com> wrote:

> On Sat, Apr 20, 2024 at 7:44?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> Also enumerated stream should also support index-aware terminal
>> operations, which getherers are incapable of, so it will also require to
>> create index-aware collectors. I am not aware if this is even possible, but
>> this looks like another separate functionality in different place, and some
>> developers might just don't be aware of its existence. I think that we as
>> language devs should think not only about what is possible in language, but
>> also about is it comfortable and is it obvious for user
>>
> Gatherers can become many-to-one; notice it has a state A, it can totally
> choose to only emit a single element R in its finisher (i.e. its integrator
> only touches state and element and ignores the downstream), then you can
> use findAny().orElseThrow() to access that single collector result. That
> said, the factory I proposed can try to wrap Collectors the same way it
> wraps Gatherers. See conclusion below.
>
>> On Sun, Apr 21, 2024, 03:36 ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Yes, I think every possible intermediate operation could be made index
>>> aware using gatherers. The point is: should it be turned?
>>>
>>> As a developers of jdk itself, we are not limited in a ways we could
>>> provide tools for Java users, especially when it comes to adding completely
>>> new features and not modifying existing apis.
>>>
>> Creating a new type of pipeline is only going to blow up the complexity
> of Streams; having IntStream, LongStream, DoubleStream and Stream, together
> with the 4-way spliterators (Spliterator.OfInt etc.) and iterators
> (PrimitiveIterator.OfInt etc.), is already an API nightmare. And the
> indexing will multiply all the intermediate and terminal operations by 2,
> further blowing up the API, which I don't believe is the right direction to
> go.
>
>>
>>>
>> Gatherer-based approach looks like we are developers of third party
>>> library that has to look for workarounds instead of directly adding
>>> features we need. It's syntax is more wordy without any payoff in
>>> flexibility, and obviously would be slower and memory-costy.
>>>
>> Gatherer is not a "third party hook", but an essential API that
> represents all possible stream operations, including Collector. Gatherer
> would not be slow; it already supports short-circuiting and should not add
> extra overheads, as Gatherer is like an API for all possible stream
> operations.
>
>>
>>> For me seems that implementing this using gatherer would only introduce
>>> unnecessary intermediate steps in operation internal pipeline without any
>>> visible payoff.
>>>
>> Implementing with Gatherer would reduce useless API exposure, as indexed
> operations are't that frequently used and are useless in parallel
> scenarios. Especially that these indexed operations aren't optimizable by
> stream subclasses, much like how findIndex is not helpful in Lists as
> Predicates can't be easily decoded like Object equivalence/hashCode, which
> some Lists can use to speed up indexOf.
>
>>
>>> Also, indexes created this way will be inconsistent between operations,
>>> and I am not sure if that is what we are looking for.
>>>
>> We declare an index-aware gatherer and my said factory converts it to an
> index-unaware, sequential gatherer; the factory gatherer prepares indices
> before calling our index-aware gatherer.
>
> For my factory, if you think my 4-line syntax above is too verbose, we can
> encapsulate those to become
> public static <T> Gatherer<T, ?, T> filter(Predicate<Indexed<T>> predicate)
> etc.
>
> And the primary methods will be:
> public static <T, A, R> Gatherer<T, ?, R> indexed(Gatherer<Indexed<T>, A,
> R> gatherer)
> public static <T, A, R> Collector<T, ?, R> indexed(Collector<Indexed<T>,
> A, R> collector)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/db895e8a/attachment.htm>

From liangchenblue at gmail.com  Sun Apr 21 03:35:02 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 20 Apr 2024 22:35:02 -0500
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q-fw-sBT0fij-Y6KRxaRZXHQjBDfFpE6wpXwwtzNDxavg@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
 <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
 <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>
 <CABe8uE28p2tQfByN8VhChgpAHsSYf3c+wYu+WQL2fgwMyB5Mkg@mail.gmail.com>
 <CAP=Y=q-fw-sBT0fij-Y6KRxaRZXHQjBDfFpE6wpXwwtzNDxavg@mail.gmail.com>
Message-ID: <CABe8uE0tw=sDLKhfjz=994um3WoOaXP87P94NRxFv0Lo0z0Z6w@mail.gmail.com>

On Sat, Apr 20, 2024 at 8:29?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Gatherers could be effectively terminal, but I don't think Gatherer API
> designers intended it to be. In related JEP, gatherers are described as a
> way to declare custom intermediate operations, and introducing "terminal"
> gatherers would be misleading.
>
I will show you an API that expands on collectors too.

>
> Talking about performance, not even considering gather() method itself,
> creating an instance of Indexed object for each value in stream is costy
> and might turn into a nightmare for infinite streams.
>
We will have value objects soon (Project Valhalla), by then the object
creation will be much more lightweight as it's effectively a tuple. This is
not really a thing of concern.

>
> As for internals of Stream API right now, I am not aware about its current
> state, so not much to say here except that adding a new type of streams
> that just slightly extends existing functionality might not be that
> harmful, I guess.
>
> Regarding API exposure, I don't think that moving it from stream directly
> to Gatherers factory would be much of a deal since to see index-aware
> methods user must explicitly convert stream to enumerated.
>
Having another set of EnumeratedStream APIs and implementations is going to
be a nightmare to maintain. Also it has bad interpolatability to convert
itself back into regular streams for other usages, while Stream<Indexed<T>>
are much better in that aspect.

>
> I also think the I didn't express my point about index consistency clear
> enough. Consider following:
>
Notice that Stream.filter retains instead of drops the matching elements!
Since otherwise your results don't make sense. I will assume you mean
"filter" like "dropIf"

>
> List.of(1,2,3).stream().enumerated().filter((idx, i) -> i*idx <
> 2).map((idx, val) -> idx * val)
>
> Result : (4, 9)
>
Does idx start from 0 or 1? All Java indices start from 0, having it start
from 1 in enumerated is really weird. I will assume you mean [2, 6]=[1*2,
2*3]
Your use case is even simpler, this case can be covered in a simple
gatherer like this:
Gatherer.ofSequential(() -> new int[] {0},
            Gatherer.Integrator.ofGreedy((counter, v, sink) ->
                    sink.push(new Indexed<>(counter[0]++, v))))
Better than writing thousands lines of new code. The functionalities are
already implemented in my sample project in
https://github.com/liachmodded/IndexedStream/tree/main/src/main/java/com/github/liachmodded/indexedstream

>
> With your approach
>
> List.of(1,2,3).stream().gather(Gatherers.filterIndexed((idx, val) ->
> idx*val < 2)).gather(Gatherers.mapIndexed((idx, val) -> idx * val))
>
> Result : (2, 6)
>
I will assume you mean [0, 3]=[0*2, 1*3]

>
> Not only second option is much more verbose, but also indexes of stream
> are inconsistent between operations.
>
Then what does EnumeratedStream serve? We would assume the enumeration
means the enumeration at the current stage so we want the number
immediately. If you want the enumeration at a particular stage, it's better
to zip your stream items with an index like my gatherer above at an
explicit step.

Also I have already made a showcase git repository with your two test cases
at
https://github.com/liachmodded/IndexedStream/blob/main/src/test/java/com/github/liachmodded/indexedstream/IndexedGatherersTest.java
Feel free to rant and tell what you really want that aren't served by these
few simple classes.

>
> PS: regarding findIndex, I did some benchmarking today, you might like to
> take a look. On average list-based version outperform collector and
> gatherer-based in more then 10 times. And also lists in stdlib doesn't have
> any hashcode-based implementations. I wrote 19 implementations in list
> subclasses and none of them had anything but simple traversing logic inside
> indexOf. But that's topic of another thread
>
Thanks for the prompt, I will look at it and reply in the other thread.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240420/6cece526/attachment-0001.htm>

From duke at openjdk.org  Sun Apr 21 04:40:49 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Sun, 21 Apr 2024 04:40:49 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 <NC3E6wpsavqRXUqdgNHh3y26lFSIPXoA0yi
 KcV_2CyI=.391c9553-458a-417f-b86d-2c88dacf7df1@github.com>
 <Kc8tP6_hlFmF_NqcwSHEX6NF9atmoeglRsRFTrLaA5A=.bacb4a7d-26cb-4fdc-8f7b-f883587cd58c@github.com>
 <xrA2rqmjQ-gHGaZ23SQIYZCgda6sHslW2oHIqQxyM2Y=.f4ae4438-78b0-4eb1-b4aa-ed461c31ef1f@github.com>
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
 <hSP68W3vGCfGCOlUCf84DDw0qzt9Z7d-56LKLALocYo=.6c507f84-037d-449f-b4f6-f8c9771e6409@github.com>
 <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@github.com>
 <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>
 <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
 <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>
Message-ID: <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>

On Tue, 9 Apr 2024 21:36:46 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>>> Hi Vamsi (@vamsi-parasa), few questions on your test environment:
>>> 
>>> * what are the hardware specs of your server ?
>>> * bare-metal or virtual ?
>>> * are other services or big processes running ?
>>> * os tuning ? CPU HT: off? Fixed CPU governor or frequency ?
>>> * isolation using taskset ?
>>> 
>>> Maybe C2 JIT (+ CDS archive) are given more performance on stock jdk sort than same code running outside jdk...
>>> 
>>> Thanks, Laurent
>> 
>> Hi Laurent,
>> 
>> The benchmarks are run on Intel TigerLake Core i7 machine. It's bare-metal without any virtualization. HT is ON and there is no other specific OS tuning or isolation using taskset.
>> 
>> Thanks,
>> Vamsi
>
> Hello Vamsi (@vamsi-parasa),
> 
> Could you please run the new benchmarking?
> To save time and don't patch JDK several times, I've created JavaBenchmarkHarness
> class which is under package java.util and compares several versions of DPQS.
> Also I prepared several versions of current sorting source from JDK to detect what is going wrong.
> 
> What you need is to compile and run JavaBenchmarkHarness once:
> 
> javac --patch-module java.base=. -d classes *.java
> java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness
> 
> Find the sources there:
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java  
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_ins.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_mrg.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_piv.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_prt.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r29p.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r29p5.java
> 
> Thank you,
> Vladimir

Hi Vladimir (@iaroslavski),

Please see the data below:

Thanks,
Vamsi



name | builder | size | mode | count | score
-- | -- | -- | -- | -- | --
b01 | RANDOM | 600 | avg | 325677 | 6.862
b01 | RANDOM | 3000 | avg | 52041 | 82.233
b01 | RANDOM | 90000 | avg | 1217 | 4456.51
b01 | RANDOM | 400000 | avg | 242 | 22923.28
b01 | RANDOM | 1000000 | avg | 90 | 60598.84
b01 | REPEATED | 600 | avg | 651354 | 1.933
b01 | REPEATED | 3000 | avg | 104083 | 13.753
b01 | REPEATED | 90000 | avg | 2435 | 723.039
b01 | REPEATED | 400000 | avg | 484 | 3084.416
b01 | REPEATED | 1000000 | avg | 180 | 8234.428
b01 | STAGGER | 600 | avg | 1954062 | 1.005
b01 | STAGGER | 3000 | avg | 312251 | 4.945
b01 | STAGGER | 90000 | avg | 7305 | 133.126
b01 | STAGGER | 400000 | avg | 1453 | 592.144
b01 | STAGGER | 1000000 | avg | 542 | 1493.876
b01 | SHUFFLE | 600 | avg | 325677 | 5.12
b01 | SHUFFLE | 3000 | avg | 52041 | 29.252
b01 | SHUFFLE | 90000 | avg | 1217 | 1396.664
b01 | SHUFFLE | 400000 | avg | 242 | 5743.489
b01 | SHUFFLE | 1000000 | avg | 90 | 15490.81
b01_ins | RANDOM | 600 | avg | 325677 | 7.594
b01_ins | RANDOM | 3000 | avg | 52041 | 78.631
b01_ins | RANDOM | 90000 | avg | 1217 | 4312.511
b01_ins | RANDOM | 400000 | avg | 242 | 22108.18
b01_ins | RANDOM | 1000000 | avg | 90 | 58467.16
b01_ins | REPEATED | 600 | avg | 651354 | 1.569
b01_ins | REPEATED | 3000 | avg | 104083 | 11.313
b01_ins | REPEATED | 90000 | avg | 2435 | 720.838
b01_ins | REPEATED | 400000 | avg | 484 | 3003.673
b01_ins | REPEATED | 1000000 | avg | 180 | 8144.944
b01_ins | STAGGER | 600 | avg | 1954062 | 0.98
b01_ins | STAGGER | 3000 | avg | 312251 | 4.948
b01_ins | STAGGER | 90000 | avg | 7305 | 132.909
b01_ins | STAGGER | 400000 | avg | 1453 | 592.572
b01_ins | STAGGER | 1000000 | avg | 542 | 1492.627
b01_ins | SHUFFLE | 600 | avg | 325677 | 4.092
b01_ins | SHUFFLE | 3000 | avg | 52041 | 27.138
b01_ins | SHUFFLE | 90000 | avg | 1217 | 1304.326
b01_ins | SHUFFLE | 400000 | avg | 242 | 5465.745
b01_ins | SHUFFLE | 1000000 | avg | 90 | 14585.08
b01_mrg | RANDOM | 600 | avg | 325677 | 7.139
b01_mrg | RANDOM | 3000 | avg | 52041 | 81.01
b01_mrg | RANDOM | 90000 | avg | 1217 | 4266.084
b01_mrg | RANDOM | 400000 | avg | 242 | 21937.77
b01_mrg | RANDOM | 1000000 | avg | 90 | 58177.72
b01_mrg | REPEATED | 600 | avg | 651354 | 1.36
b01_mrg | REPEATED | 3000 | avg | 104083 | 9.013
b01_mrg | REPEATED | 90000 | avg | 2435 | 737.684
b01_mrg | REPEATED | 400000 | avg | 484 | 3152.447
b01_mrg | REPEATED | 1000000 | avg | 180 | 8366.866
b01_mrg | STAGGER | 600 | avg | 1954062 | 0.73
b01_mrg | STAGGER | 3000 | avg | 312251 | 3.733
b01_mrg | STAGGER | 90000 | avg | 7305 | 114.35
b01_mrg | STAGGER | 400000 | avg | 1453 | 524.821
b01_mrg | STAGGER | 1000000 | avg | 542 | 1351.504
b01_mrg | SHUFFLE | 600 | avg | 325677 | 4.986
b01_mrg | SHUFFLE | 3000 | avg | 52041 | 28.456
b01_mrg | SHUFFLE | 90000 | avg | 1217 | 1291.609
b01_mrg | SHUFFLE | 400000 | avg | 242 | 5743.312
b01_mrg | SHUFFLE | 1000000 | avg | 90 | 15173.89
b01_piv | RANDOM | 600 | avg | 325677 | 6.108
b01_piv | RANDOM | 3000 | avg | 52041 | 77.286
b01_piv | RANDOM | 90000 | avg | 1217 | 4275.036
b01_piv | RANDOM | 400000 | avg | 242 | 21485.54
b01_piv | RANDOM | 1000000 | avg | 90 | 57532.96
b01_piv | REPEATED | 600 | avg | 651354 | 1.035
b01_piv | REPEATED | 3000 | avg | 104083 | 5.13
b01_piv | REPEATED | 90000 | avg | 2435 | 545.294
b01_piv | REPEATED | 400000 | avg | 484 | 2357.776
b01_piv | REPEATED | 1000000 | avg | 180 | 5897.241
b01_piv | STAGGER | 600 | avg | 1954062 | 0.98
b01_piv | STAGGER | 3000 | avg | 312251 | 4.924
b01_piv | STAGGER | 90000 | avg | 7305 | 132.861
b01_piv | STAGGER | 400000 | avg | 1453 | 590.477
b01_piv | STAGGER | 1000000 | avg | 542 | 1490.788
b01_piv | SHUFFLE | 600 | avg | 325677 | 4.647
b01_piv | SHUFFLE | 3000 | avg | 52041 | 28.797
b01_piv | SHUFFLE | 90000 | avg | 1217 | 1199.174
b01_piv | SHUFFLE | 400000 | avg | 242 | 5333.113
b01_piv | SHUFFLE | 1000000 | avg | 90 | 13569.69
b01_prt | RANDOM | 600 | avg | 325677 | 6.198
b01_prt | RANDOM | 3000 | avg | 52041 | 76.981
b01_prt | RANDOM | 90000 | avg | 1217 | 4084.038
b01_prt | RANDOM | 400000 | avg | 242 | 20829.11
b01_prt | RANDOM | 1000000 | avg | 90 | 54992.42
b01_prt | REPEATED | 600 | avg | 651354 | 1.695
b01_prt | REPEATED | 3000 | avg | 104083 | 10.026
b01_prt | REPEATED | 90000 | avg | 2435 | 713.94
b01_prt | REPEATED | 400000 | avg | 484 | 3046.4
b01_prt | REPEATED | 1000000 | avg | 180 | 8107.396
b01_prt | STAGGER | 600 | avg | 1954062 | 0.996
b01_prt | STAGGER | 3000 | avg | 312251 | 4.945
b01_prt | STAGGER | 90000 | avg | 7305 | 133.185
b01_prt | STAGGER | 400000 | avg | 1453 | 592.432
b01_prt | STAGGER | 1000000 | avg | 542 | 1491.101
b01_prt | SHUFFLE | 600 | avg | 325677 | 4.438
b01_prt | SHUFFLE | 3000 | avg | 52041 | 23.821
b01_prt | SHUFFLE | 90000 | avg | 1217 | 1172.62
b01_prt | SHUFFLE | 400000 | avg | 242 | 4874.561
b01_prt | SHUFFLE | 1000000 | avg | 90 | 12895.43
r29p | RANDOM | 600 | avg | 325677 | 4.352
r29p | RANDOM | 3000 | avg | 52041 | 65.579
r29p | RANDOM | 90000 | avg | 1217 | 3829.863
r29p | RANDOM | 400000 | avg | 242 | 19222.97
r29p | RANDOM | 1000000 | avg | 90 | 51848.6
r29p | REPEATED | 600 | avg | 651354 | 1.1
r29p | REPEATED | 3000 | avg | 104083 | 5.357
r29p | REPEATED | 90000 | avg | 2435 | 581.597
r29p | REPEATED | 400000 | avg | 484 | 2538.564
r29p | REPEATED | 1000000 | avg | 180 | 6406.969
r29p | STAGGER | 600 | avg | 1954062 | 0.486
r29p | STAGGER | 3000 | avg | 312251 | 2.396
r29p | STAGGER | 90000 | avg | 7305 | 71.766
r29p | STAGGER | 400000 | avg | 1453 | 341.391
r29p | STAGGER | 1000000 | avg | 542 | 948.696
r29p | SHUFFLE | 600 | avg | 325677 | 2.733
r29p | SHUFFLE | 3000 | avg | 52041 | 16.883
r29p | SHUFFLE | 90000 | avg | 1217 | 987.346
r29p | SHUFFLE | 400000 | avg | 242 | 4541.698
r29p | SHUFFLE | 1000000 | avg | 90 | 11179.08
r29p5 | RANDOM | 600 | avg | 325677 | 4.153
r29p5 | RANDOM | 3000 | avg | 52041 | 62.496
r29p5 | RANDOM | 90000 | avg | 1217 | 3833.639
r29p5 | RANDOM | 400000 | avg | 242 | 19222.55
r29p5 | RANDOM | 1000000 | avg | 90 | 51200.3
r29p5 | REPEATED | 600 | avg | 651354 | 1.044
r29p5 | REPEATED | 3000 | avg | 104083 | 4.994
r29p5 | REPEATED | 90000 | avg | 2435 | 583.856
r29p5 | REPEATED | 400000 | avg | 484 | 2482.716
r29p5 | REPEATED | 1000000 | avg | 180 | 6270.456
r29p5 | STAGGER | 600 | avg | 1954062 | 0.501
r29p5 | STAGGER | 3000 | avg | 312251 | 2.488
r29p5 | STAGGER | 90000 | avg | 7305 | 74.435
r29p5 | STAGGER | 400000 | avg | 1453 | 353.166
r29p5 | STAGGER | 1000000 | avg | 542 | 978.56
r29p5 | SHUFFLE | 600 | avg | 325677 | 3.006
r29p5 | SHUFFLE | 3000 | avg | 52041 | 18.062
r29p5 | SHUFFLE | 90000 | avg | 1217 | 1009.819
r29p5 | SHUFFLE | 400000 | avg | 242 | 4638.24
r29p5 | SHUFFLE | 1000000 | avg | 90 | 11350.48
p_b01 | RANDOM | 600 | avg | 325677 | 7.273
p_b01 | RANDOM | 3000 | avg | 52041 | 82.233
p_b01 | RANDOM | 90000 | avg | 1217 | 650.813
p_b01 | RANDOM | 400000 | avg | 242 | 2676.309
p_b01 | RANDOM | 1000000 | avg | 90 | 6862.199
p_b01 | REPEATED | 600 | avg | 651354 | 1.3
p_b01 | REPEATED | 3000 | avg | 104083 | 9.647
p_b01 | REPEATED | 90000 | avg | 2435 | 245.071
p_b01 | REPEATED | 400000 | avg | 484 | 972.151
p_b01 | REPEATED | 1000000 | avg | 180 | 2481.689
p_b01 | STAGGER | 600 | avg | 1954062 | 0.977
p_b01 | STAGGER | 3000 | avg | 312251 | 4.771
p_b01 | STAGGER | 90000 | avg | 7305 | 64.934
p_b01 | STAGGER | 400000 | avg | 1453 | 185.96
p_b01 | STAGGER | 1000000 | avg | 542 | 498.298
p_b01 | SHUFFLE | 600 | avg | 325677 | 5.131
p_b01 | SHUFFLE | 3000 | avg | 52041 | 29.535
p_b01 | SHUFFLE | 90000 | avg | 1217 | 271.691
p_b01 | SHUFFLE | 400000 | avg | 242 | 893.958
p_b01 | SHUFFLE | 1000000 | avg | 90 | 2016.456
p_b01_ins | RANDOM | 600 | avg | 325677 | 7.697
p_b01_ins | RANDOM | 3000 | avg | 52041 | 73.044
p_b01_ins | RANDOM | 90000 | avg | 1217 | 639.5
p_b01_ins | RANDOM | 400000 | avg | 242 | 2627.147
p_b01_ins | RANDOM | 1000000 | avg | 90 | 6965.733
p_b01_ins | REPEATED | 600 | avg | 651354 | 1.085
p_b01_ins | REPEATED | 3000 | avg | 104083 | 8.177
p_b01_ins | REPEATED | 90000 | avg | 2435 | 252.955
p_b01_ins | REPEATED | 400000 | avg | 484 | 1012.75
p_b01_ins | REPEATED | 1000000 | avg | 180 | 2448.868
p_b01_ins | STAGGER | 600 | avg | 1954062 | 1.132
p_b01_ins | STAGGER | 3000 | avg | 312251 | 5.343
p_b01_ins | STAGGER | 90000 | avg | 7305 | 65.105
p_b01_ins | STAGGER | 400000 | avg | 1453 | 192.285
p_b01_ins | STAGGER | 1000000 | avg | 542 | 506.095
p_b01_ins | SHUFFLE | 600 | avg | 325677 | 4.151
p_b01_ins | SHUFFLE | 3000 | avg | 52041 | 27.158
p_b01_ins | SHUFFLE | 90000 | avg | 1217 | 270.81
p_b01_ins | SHUFFLE | 400000 | avg | 242 | 867.613
p_b01_ins | SHUFFLE | 1000000 | avg | 90 | 1963.741
p_b01_mrg | RANDOM | 600 | avg | 325677 | 7.139
p_b01_mrg | RANDOM | 3000 | avg | 52041 | 73.579
p_b01_mrg | RANDOM | 90000 | avg | 1217 | 619.217
p_b01_mrg | RANDOM | 400000 | avg | 242 | 2542.126
p_b01_mrg | RANDOM | 1000000 | avg | 90 | 6573.197
p_b01_mrg | REPEATED | 600 | avg | 651354 | 1.18
p_b01_mrg | REPEATED | 3000 | avg | 104083 | 8.585
p_b01_mrg | REPEATED | 90000 | avg | 2435 | 304.565
p_b01_mrg | REPEATED | 400000 | avg | 484 | 993.142
p_b01_mrg | REPEATED | 1000000 | avg | 180 | 2440.591
p_b01_mrg | STAGGER | 600 | avg | 1954062 | 0.765
p_b01_mrg | STAGGER | 3000 | avg | 312251 | 3.779
p_b01_mrg | STAGGER | 90000 | avg | 7305 | 66.429
p_b01_mrg | STAGGER | 400000 | avg | 1453 | 207.316
p_b01_mrg | STAGGER | 1000000 | avg | 542 | 535.042
p_b01_mrg | SHUFFLE | 600 | avg | 325677 | 4.996
p_b01_mrg | SHUFFLE | 3000 | avg | 52041 | 28.052
p_b01_mrg | SHUFFLE | 90000 | avg | 1217 | 270.357
p_b01_mrg | SHUFFLE | 400000 | avg | 242 | 899.677
p_b01_mrg | SHUFFLE | 1000000 | avg | 90 | 2000.463
p_b01_piv | RANDOM | 600 | avg | 325677 | 6.991
p_b01_piv | RANDOM | 3000 | avg | 52041 | 76.157
p_b01_piv | RANDOM | 90000 | avg | 1217 | 56.604
p_b01_piv | RANDOM | 400000 | avg | 242 | 134.653
p_b01_piv | RANDOM | 1000000 | avg | 90 | 374.473
p_b01_piv | REPEATED | 600 | avg | 651354 | 1.009
p_b01_piv | REPEATED | 3000 | avg | 104083 | 4.718
p_b01_piv | REPEATED | 90000 | avg | 2435 | 56.453
p_b01_piv | REPEATED | 400000 | avg | 484 | 852.866
p_b01_piv | REPEATED | 1000000 | avg | 180 | 2183.644
p_b01_piv | STAGGER | 600 | avg | 1954062 | 0.97
p_b01_piv | STAGGER | 3000 | avg | 312251 | 4.791
p_b01_piv | STAGGER | 90000 | avg | 7305 | 66.761
p_b01_piv | STAGGER | 400000 | avg | 1453 | 191.334
p_b01_piv | STAGGER | 1000000 | avg | 542 | 516.535
p_b01_piv | SHUFFLE | 600 | avg | 325677 | 4.681
p_b01_piv | SHUFFLE | 3000 | avg | 52041 | 28.77
p_b01_piv | SHUFFLE | 90000 | avg | 1217 | 126.367
p_b01_piv | SHUFFLE | 400000 | avg | 242 | 288.9
p_b01_piv | SHUFFLE | 1000000 | avg | 90 | 972.511
p_b01_prt | RANDOM | 600 | avg | 325677 | 6.339
p_b01_prt | RANDOM | 3000 | avg | 52041 | 73.78
p_b01_prt | RANDOM | 90000 | avg | 1217 | 577.255
p_b01_prt | RANDOM | 400000 | avg | 242 | 2342.825
p_b01_prt | RANDOM | 1000000 | avg | 90 | 6087.572
p_b01_prt | REPEATED | 600 | avg | 651354 | 1.137
p_b01_prt | REPEATED | 3000 | avg | 104083 | 6.946
p_b01_prt | REPEATED | 90000 | avg | 2435 | 204.205
p_b01_prt | REPEATED | 400000 | avg | 484 | 995.421
p_b01_prt | REPEATED | 1000000 | avg | 180 | 2411.23
p_b01_prt | STAGGER | 600 | avg | 1954062 | 1.128
p_b01_prt | STAGGER | 3000 | avg | 312251 | 5.341
p_b01_prt | STAGGER | 90000 | avg | 7305 | 64.844
p_b01_prt | STAGGER | 400000 | avg | 1453 | 189.274
p_b01_prt | STAGGER | 1000000 | avg | 542 | 506.245
p_b01_prt | SHUFFLE | 600 | avg | 325677 | 4.393
p_b01_prt | SHUFFLE | 3000 | avg | 52041 | 25.166
p_b01_prt | SHUFFLE | 90000 | avg | 1217 | 235.482
p_b01_prt | SHUFFLE | 400000 | avg | 242 | 758.64
p_b01_prt | SHUFFLE | 1000000 | avg | 90 | 1710.273
p_r29p | RANDOM | 600 | avg | 325677 | 4.005
p_r29p | RANDOM | 3000 | avg | 52041 | 67.873
p_r29p | RANDOM | 90000 | avg | 1217 | 325.19
p_r29p | RANDOM | 400000 | avg | 242 | 1221.24
p_r29p | RANDOM | 1000000 | avg | 90 | 3047.764
p_r29p | REPEATED | 600 | avg | 651354 | 1.054
p_r29p | REPEATED | 3000 | avg | 104083 | 4.982
p_r29p | REPEATED | 90000 | avg | 2435 | 250.923
p_r29p | REPEATED | 400000 | avg | 484 | 1031.028
p_r29p | REPEATED | 1000000 | avg | 180 | 2516.481
p_r29p | STAGGER | 600 | avg | 1954062 | 0.496
p_r29p | STAGGER | 3000 | avg | 312251 | 2.476
p_r29p | STAGGER | 90000 | avg | 7305 | 54.193
p_r29p | STAGGER | 400000 | avg | 1453 | 207.309
p_r29p | STAGGER | 1000000 | avg | 542 | 486.682
p_r29p | SHUFFLE | 600 | avg | 325677 | 2.801
p_r29p | SHUFFLE | 3000 | avg | 52041 | 17.811
p_r29p | SHUFFLE | 90000 | avg | 1217 | 142.732
p_r29p | SHUFFLE | 400000 | avg | 242 | 750.188
p_r29p | SHUFFLE | 1000000 | avg | 90 | 1625.551
p_r29p5 | RANDOM | 600 | avg | 325677 | 4.447
p_r29p5 | RANDOM | 3000 | avg | 52041 | 62.797
p_r29p5 | RANDOM | 90000 | avg | 1217 | 326.74
p_r29p5 | RANDOM | 400000 | avg | 242 | 1212.317
p_r29p5 | RANDOM | 1000000 | avg | 90 | 2994.011
p_r29p5 | REPEATED | 600 | avg | 651354 | 1.132
p_r29p5 | REPEATED | 3000 | avg | 104083 | 5.474
p_r29p5 | REPEATED | 90000 | avg | 2435 | 244.921
p_r29p5 | REPEATED | 400000 | avg | 484 | 1056.798
p_r29p5 | REPEATED | 1000000 | avg | 180 | 2558.885
p_r29p5 | STAGGER | 600 | avg | 1954062 | 0.553
p_r29p5 | STAGGER | 3000 | avg | 312251 | 2.687
p_r29p5 | STAGGER | 90000 | avg | 7305 | 57.763
p_r29p5 | STAGGER | 400000 | avg | 1453 | 207.106
p_r29p5 | STAGGER | 1000000 | avg | 542 | 480.437
p_r29p5 | SHUFFLE | 600 | avg | 325677 | 3.018
p_r29p5 | SHUFFLE | 3000 | avg | 52041 | 18.435
p_r29p5 | SHUFFLE | 90000 | avg | 1217 | 144.3
p_r29p5 | SHUFFLE | 400000 | avg | 242 | 750.63
p_r29p5 | SHUFFLE | 1000000 | avg | 90 | 1638.547

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2067901458

From rotan.olexandr at gmail.com  Sun Apr 21 10:49:16 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 13:49:16 +0300
Subject: EnumeratedStream
In-Reply-To: <CABe8uE0tw=sDLKhfjz=994um3WoOaXP87P94NRxFv0Lo0z0Z6w@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
 <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
 <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>
 <CABe8uE28p2tQfByN8VhChgpAHsSYf3c+wYu+WQL2fgwMyB5Mkg@mail.gmail.com>
 <CAP=Y=q-fw-sBT0fij-Y6KRxaRZXHQjBDfFpE6wpXwwtzNDxavg@mail.gmail.com>
 <CABe8uE0tw=sDLKhfjz=994um3WoOaXP87P94NRxFv0Lo0z0Z6w@mail.gmail.com>
Message-ID: <CAP=Y=q8UCrZh+7z_=5+3xx3QsW=Yru+3pSYmrOui0VPJz4g7ew@mail.gmail.com>

I have heard your proposal. Your approach indeed for sure has its
advantages.

One thing I don't like referring to is Valhalla. It's not even a
preview and no one really knows when it will be, relying on it when
designing API now would be strange to say the least.

One possible thing that could dramatically simplify implementation of my
approach is introduction of generic reification, which would allow
primitives as type params. I am currently studying the working of javac and
possible implementation of this is one of the topics in my research.
However, let's stick to what we have in jdk right now from now on.

I would like to hear opinions of other people regarding the design of such
API, especially David and Remi, since, as I understand, that's not the
first time they witness a discussion like this, so maybe they have
something to tell here.

??, 21 ???. 2024??. ? 06:35, - <liangchenblue at gmail.com>:

> On Sat, Apr 20, 2024 at 8:29?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> Gatherers could be effectively terminal, but I don't think Gatherer API
>> designers intended it to be. In related JEP, gatherers are described as a
>> way to declare custom intermediate operations, and introducing "terminal"
>> gatherers would be misleading.
>>
> I will show you an API that expands on collectors too.
>
>>
>> Talking about performance, not even considering gather() method itself,
>> creating an instance of Indexed object for each value in stream is costy
>> and might turn into a nightmare for infinite streams.
>>
> We will have value objects soon (Project Valhalla), by then the object
> creation will be much more lightweight as it's effectively a tuple. This is
> not really a thing of concern.
>
>>
>> As for internals of Stream API right now, I am not aware about its
>> current state, so not much to say here except that adding a new type of
>> streams that just slightly extends existing functionality might not be that
>> harmful, I guess.
>>
>> Regarding API exposure, I don't think that moving it from stream directly
>> to Gatherers factory would be much of a deal since to see index-aware
>> methods user must explicitly convert stream to enumerated.
>>
> Having another set of EnumeratedStream APIs and implementations is going
> to be a nightmare to maintain. Also it has bad interpolatability to convert
> itself back into regular streams for other usages, while Stream<Indexed<T>>
> are much better in that aspect.
>
>>
>> I also think the I didn't express my point about index consistency clear
>> enough. Consider following:
>>
> Notice that Stream.filter retains instead of drops the matching elements!
> Since otherwise your results don't make sense. I will assume you mean
> "filter" like "dropIf"
>
>>
>> List.of(1,2,3).stream().enumerated().filter((idx, i) -> i*idx <
>> 2).map((idx, val) -> idx * val)
>>
>> Result : (4, 9)
>>
> Does idx start from 0 or 1? All Java indices start from 0, having it start
> from 1 in enumerated is really weird. I will assume you mean [2, 6]=[1*2,
> 2*3]
> Your use case is even simpler, this case can be covered in a simple
> gatherer like this:
> Gatherer.ofSequential(() -> new int[] {0},
>             Gatherer.Integrator.ofGreedy((counter, v, sink) ->
>                     sink.push(new Indexed<>(counter[0]++, v))))
> Better than writing thousands lines of new code. The functionalities are
> already implemented in my sample project in
>
> https://github.com/liachmodded/IndexedStream/tree/main/src/main/java/com/github/liachmodded/indexedstream
>
>>
>> With your approach
>>
>> List.of(1,2,3).stream().gather(Gatherers.filterIndexed((idx, val) ->
>> idx*val < 2)).gather(Gatherers.mapIndexed((idx, val) -> idx * val))
>>
>> Result : (2, 6)
>>
> I will assume you mean [0, 3]=[0*2, 1*3]
>
>>
>> Not only second option is much more verbose, but also indexes of stream
>> are inconsistent between operations.
>>
> Then what does EnumeratedStream serve? We would assume the enumeration
> means the enumeration at the current stage so we want the number
> immediately. If you want the enumeration at a particular stage, it's better
> to zip your stream items with an index like my gatherer above at an
> explicit step.
>
> Also I have already made a showcase git repository with your two test
> cases at
>
> https://github.com/liachmodded/IndexedStream/blob/main/src/test/java/com/github/liachmodded/indexedstream/IndexedGatherersTest.java
> Feel free to rant and tell what you really want that aren't served by
> these few simple classes.
>
>>
>> PS: regarding findIndex, I did some benchmarking today, you might like to
>> take a look. On average list-based version outperform collector and
>> gatherer-based in more then 10 times. And also lists in stdlib doesn't have
>> any hashcode-based implementations. I wrote 19 implementations in list
>> subclasses and none of them had anything but simple traversing logic inside
>> indexOf. But that's topic of another thread
>>
> Thanks for the prompt, I will look at it and reply in the other thread.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/16c66919/attachment-0001.htm>

From liangchenblue at gmail.com  Sun Apr 21 13:31:29 2024
From: liangchenblue at gmail.com (-)
Date: Sun, 21 Apr 2024 08:31:29 -0500
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q8UCrZh+7z_=5+3xx3QsW=Yru+3pSYmrOui0VPJz4g7ew@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
 <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
 <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>
 <CABe8uE28p2tQfByN8VhChgpAHsSYf3c+wYu+WQL2fgwMyB5Mkg@mail.gmail.com>
 <CAP=Y=q-fw-sBT0fij-Y6KRxaRZXHQjBDfFpE6wpXwwtzNDxavg@mail.gmail.com>
 <CABe8uE0tw=sDLKhfjz=994um3WoOaXP87P94NRxFv0Lo0z0Z6w@mail.gmail.com>
 <CAP=Y=q8UCrZh+7z_=5+3xx3QsW=Yru+3pSYmrOui0VPJz4g7ew@mail.gmail.com>
Message-ID: <CABe8uE1h+6zwqMrdauu2oVQTVW+1hYrS5GLNs_xJ5Tf797NyEQ@mail.gmail.com>

On Sun, Apr 21, 2024 at 5:49?AM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> I have heard your proposal. Your approach indeed for sure has its
> advantages.
>
> One thing I don't like referring to is Valhalla. It's not even a
> preview and no one really knows when it will be, relying on it when
> designing API now would be strange to say the least.
>
Valhalla's value classes are actually quite ready; the compatibility and
the type system are quite fleshed out in the recent iterations, and the
prototypes are already functional.

>
> One possible thing that could dramatically simplify implementation of my
> approach is introduction of generic reification, which would allow
> primitives as type params. I am currently studying the working of javac and
> possible implementation of this is one of the topics in my research.
> However, let's stick to what we have in jdk right now from now on.
>
Generic reification is part of project Valhalla too, in that it allows
wrapper classes in generics to have the same performance as the primitives
with generic specialization. Compiling many classes to achieve generic
reification is an alternative, but I don't think it's feasible.

>
> I would like to hear opinions of other people regarding the design of such
> API, especially David and Remi, since, as I understand, that's not the
> first time they witness a discussion like this, so maybe they have
> something to tell here.
>
Unfortunately you will have to wait. Most JDK engineers are employees who
work on weekdays; only a few are enthusiasts. I think we may get more
discussion traffic on Monday.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/84bb397b/attachment.htm>

From jbhateja at openjdk.org  Sun Apr 21 13:40:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 21 Apr 2024 13:40:00 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v18]
In-Reply-To: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
Message-ID: <1nYoblnuDaQmp__ljc9W0EjmTtPGXI7zxS0QwaRlpUM=.50798174-eb25-4c5e-879b-029f15e135e4@github.com>

> Hi All,
> 
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
> 
> Following is the summary of changes:-
> 
> 1) Intrinsify sub-word gather using hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.5-10x gains with included micro.
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
> 
> 
> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
> 
> 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-8318650
 - Review resolutions.
 - Review comment resolutions.
 - Review comments resolutions
 - Review comments resolutions.
 - Review comments resolutions.
 - Generalizing masked sub-gather support.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650
 - Fix incorrect comment
 - ... and 6 more: https://git.openjdk.org/jdk/compare/6d569961...b24cc5cd

-------------

Changes: https://git.openjdk.org/jdk/pull/16354/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=17
  Stats: 1178 lines in 32 files changed: 1129 ins; 21 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/16354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16354/head:pull/16354

PR: https://git.openjdk.org/jdk/pull/16354

From rotan.olexandr at gmail.com  Sun Apr 21 13:48:31 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 16:48:31 +0300
Subject: EnumeratedStream
In-Reply-To: <CABe8uE1h+6zwqMrdauu2oVQTVW+1hYrS5GLNs_xJ5Tf797NyEQ@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
 <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
 <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>
 <CABe8uE28p2tQfByN8VhChgpAHsSYf3c+wYu+WQL2fgwMyB5Mkg@mail.gmail.com>
 <CAP=Y=q-fw-sBT0fij-Y6KRxaRZXHQjBDfFpE6wpXwwtzNDxavg@mail.gmail.com>
 <CABe8uE0tw=sDLKhfjz=994um3WoOaXP87P94NRxFv0Lo0z0Z6w@mail.gmail.com>
 <CAP=Y=q8UCrZh+7z_=5+3xx3QsW=Yru+3pSYmrOui0VPJz4g7ew@mail.gmail.com>
 <CABe8uE1h+6zwqMrdauu2oVQTVW+1hYrS5GLNs_xJ5Tf797NyEQ@mail.gmail.com>
Message-ID: <CAP=Y=q8P9e+bTymyu0tj=_iZjHfxpqOVF=+aFQEThuO5gDb1wQ@mail.gmail.com>

I am not really familiar with goals and milestones of Valhalla project, but
what I meant by simplification is that there would not be any more need to
convert to promotove streams explicitly as Stream<primitive> would be a
thing. If that's what Valhalla is working on, then this would be just
great. Performance concerns regarding wrappers  are also valid  , but here
I am talking about implementation complexity.

If going little off topic, compiling many classes to achieve generic
reification in fact looks odd, but it in fact provides best developer
experience, Converting primitive arrays to collections is one of the
examples of major problems issues with it, along with some methods of
Arrays class (like sort, if I am not mistaken), just don't work with
primitives.Approach that is used in C#, while has its downsides, provides
much better user experience. However, what I am looking into right now is
some hybrid form of generic handling, where generic maybe be reified on
demand of developer (or implicitly if primitive is used). I am working on
some prototypes at the moment

??, 21 ???. 2024??. ? 16:31, - <liangchenblue at gmail.com>:

> On Sun, Apr 21, 2024 at 5:49?AM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> I have heard your proposal. Your approach indeed for sure has its
>> advantages.
>>
>> One thing I don't like referring to is Valhalla. It's not even a
>> preview and no one really knows when it will be, relying on it when
>> designing API now would be strange to say the least.
>>
> Valhalla's value classes are actually quite ready; the compatibility and
> the type system are quite fleshed out in the recent iterations, and the
> prototypes are already functional.
>
>>
>> One possible thing that could dramatically simplify implementation of my
>> approach is introduction of generic reification, which would allow
>> primitives as type params. I am currently studying the working of javac and
>> possible implementation of this is one of the topics in my research.
>> However, let's stick to what we have in jdk right now from now on.
>>
> Generic reification is part of project Valhalla too, in that it allows
> wrapper classes in generics to have the same performance as the primitives
> with generic specialization. Compiling many classes to achieve generic
> reification is an alternative, but I don't think it's feasible.
>
>>
>> I would like to hear opinions of other people regarding the design of
>> such API, especially David and Remi, since, as I understand, that's not the
>> first time they witness a discussion like this, so maybe they have
>> something to tell here.
>>
> Unfortunately you will have to wait. Most JDK engineers are employees who
> work on weekdays; only a few are enthusiasts. I think we may get more
> discussion traffic on Monday.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/9082eee0/attachment-0001.htm>

From duke at openjdk.org  Sun Apr 21 15:02:35 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Sun, 21 Apr 2024 15:02:35 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 <NC3E6wpsavqRXUqdgNHh3y26lFSIPXoA0yi
 KcV_2CyI=.391c9553-458a-417f-b86d-2c88dacf7df1@github.com>
 <Kc8tP6_hlFmF_NqcwSHEX6NF9atmoeglRsRFTrLaA5A=.bacb4a7d-26cb-4fdc-8f7b-f883587cd58c@github.com>
 <xrA2rqmjQ-gHGaZ23SQIYZCgda6sHslW2oHIqQxyM2Y=.f4ae4438-78b0-4eb1-b4aa-ed461c31ef1f@github.com>
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
 <hSP68W3vGCfGCOlUCf84DDw0qzt9Z7d-56LKLALocYo=.6c507f84-037d-449f-b4f6-f8c9771e6409@github.com>
 <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@github.com>
 <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>
 <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
 <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>
 <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>
Message-ID: <xPhYXEAdOzrsIfQoeDYec7aIIF_WWNgB0olsMRBxN8A=.2ba436da-4a3c-437a-9484-9fb676d474de@github.com>

On Sun, 21 Apr 2024 04:37:45 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Could you please run the new benchmarking?
>> To save time and don't patch JDK several times, I've created JavaBenchmarkHarness
>> class which is under package java.util and compares several versions of DPQS.
>> Also I prepared several versions of current sorting source from JDK to detect what is going wrong.
>> 
>> What you need is to compile and run JavaBenchmarkHarness once:
>> 
>> javac --patch-module java.base=. -d classes *.java
>> java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness
>> 
>> Find the sources there:
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java  
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_ins.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_mrg.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_piv.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_prt.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r29p.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r29p5.java
>> 
>> Thank you,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> Please see the data below:
> 
> Thanks,
> Vamsi
> 
> 
> 
> name | builder | size | mode | count | score
> -- | -- | -- | -- | -- | --
> b01 | RANDOM | 600 | avg | 325677 | 6.862
> b01 | RANDOM | 3000 | avg | 52041 | 82.233
> b01 | RANDOM | 90000 | avg | 1217 | 4456.51
> b01 | RANDOM | 400000 | avg | 242 | 22923.28
> b01 | RANDOM | 1000000 | avg | 90 | 60598.84
> b01 | REPEATED | 600 | avg | 651354 | 1.933
> b01 | REPEATED | 3000 | avg | 104083 | 13.753
> b01 | REPEATED | 90000 | avg | 2435 | 723.039
> b01 | REPEATED | 400000 | avg | 484 | 3084.416
> b01 | REPEATED | 1000000 | avg | 180 | 8234.428
> b01 | STAGGER | 600 | avg | 1954062 | 1.005
> b01 | STAGGER | 3000 | avg | 312251 | 4.945
> b01 | STAGGER | 90000 | avg | 7305 | 133.126
> b01 | STAGGER | 400000 | avg | 1453 | 592.144
> b01 | STAGGER | 1000000 | avg | 542 | 1493.876
> b01 | SHUFFLE | 600 | avg | 325677 | 5.12
> b01 | SHUFFLE | 3000 | avg | 52041 | 29.252
> b01 | SHUFFLE | 90000 | avg | 1217 | 1396.664
> b01 | SHUFFLE | 400000 | avg | 242 | 5743.489
> b01 | SHUFFLE | 1000000 | avg | 90 | 15490.81
> b01_ins | RANDOM | 600 | avg | 325677 | 7.594
> b01_ins | RANDOM | 3000 | avg | 52041 | 78.631
> b01_ins | RANDOM | 90000 | avg | 1217 | 4312.511
> b01_ins | RANDOM | 400000 | avg | 242 | 22108.18
> b01_ins | RANDOM | 1000000 | avg | 90 | 58467.16
> b01_ins | REPEATED | 600 | avg | 651354 | 1.569
> b01_ins | REPEATED | 3000 | avg | 104083 | 11.313
> b01_ins | REPEATED | 90000 | avg | 2435 | 720.838
> b01_ins | REPEATED | 400000 | avg | 484 | 3003.673
> b01_ins | REPEATED | 1000000 | avg | 180 | 8144.944
> b01_ins | STAGGER | 600 | avg | 1954062 | 0.98
> b01_ins | STAGGER | 3000 | avg | 312251 | 4.948
> b01_ins | STAGGER | 90000 | avg | 7305 | 132.909
> b01_ins | STAGGER | 400000 | avg | 1453 | 592.572
> b01_ins | STAGGER | 1000000 | avg | 542 | 1492.627
> b01_ins | SHUFFLE | 600 | avg | 325677 | 4.092
> b01_ins | SHUFFLE | 3000 | avg | 52041 | 27.138
> b01_ins | SHUFFLE | 90000 | avg | 1217 | 1304.326
> b01_ins | SHUFFLE | 400000 | avg | 242 | 5465.745
> b01_ins | SHUFFLE | 1000000 | avg | 90 | 14585.08
> b01_mrg | RANDOM | 600 | avg | 325677 | 7.139
> b01_mrg | RANDOM | 3000 | avg | 52041 | 81.01
> b01_mrg | RANDOM | 90000 | avg | 1217 | 4266.084
> b01_mrg | RANDOM | 400000 | avg | 242 | 21937.77
> b01_mrg | RANDOM | 1000000 | avg | 90 | 58177.72
> b01_mrg | REPEATED | 600 | avg | 651354 | 1.36
> b01_mrg | REPEATED | 3000 | avg | 104083 | 9.013
> b01_mrg | REPEATED | 90000 | avg | 2435 | 737.684
> b01_mrg | REPEATED | 400000 | avg | 484 | 3152.447
> b01_mrg | REPEATED | 1000000 | avg |...

Thank you, @vamsi-parasa !
I will investigate the result

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2068075025

From rotan.olexandr at gmail.com  Sun Apr 21 15:45:56 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 18:45:56 +0300
Subject: EnumeratedStream
In-Reply-To: <CAP=Y=q8b9++4073FddWdVJuYN47FLRiVW63NkNmuRqUV5XhPTQ@mail.gmail.com>
References: <CAP=Y=q9YjK9OJBYvSU-zqw=7GdKpXTZB-fkvnLPXD6KAMXW5vw@mail.gmail.com>
 <CABe8uE2FUzCjsMRO+bh8+CRz_mRWLiVfMq+QnFw+gi_MoiOAbQ@mail.gmail.com>
 <CAP=Y=q-g=q1XWWW-6EB9cUSuswd8Pi52YeFWazbhG=apL9MJ3w@mail.gmail.com>
 <CAP=Y=q-=QgUPivZY-dmoznOMAH=PMF7Aga0jv=i4fHOr8hMQGg@mail.gmail.com>
 <CABe8uE2x-8Q_qpdE4YYi=TOHvWmfTLBuKySQgBcFOEdBZNNoPw@mail.gmail.com>
 <CAP=Y=q8ABGY5c6XWJiPmtb50NUg9ccSYOvG5tSSGA5b8PUuF6A@mail.gmail.com>
 <CABe8uE0CnaS2WCCDw+gCyK8beSGX4OpHdT4BbEF-N_4NuTnHZg@mail.gmail.com>
 <CAP=Y=q9_SOntc3WiU3bhURVst1-GSAf0wJUNbrK4szCP_XRd9A@mail.gmail.com>
 <CAP=Y=q8JJBJDN8YrOKjdyWyeO_=gSXiL0EZuR_NAH4iKqgqDgg@mail.gmail.com>
 <CABe8uE28p2tQfByN8VhChgpAHsSYf3c+wYu+WQL2fgwMyB5Mkg@mail.gmail.com>
 <CAP=Y=q-fw-sBT0fij-Y6KRxaRZXHQjBDfFpE6wpXwwtzNDxavg@mail.gmail.com>
 <CABe8uE0tw=sDLKhfjz=994um3WoOaXP87P94NRxFv0Lo0z0Z6w@mail.gmail.com>
 <CAP=Y=q8UCrZh+7z_=5+3xx3QsW=Yru+3pSYmrOui0VPJz4g7ew@mail.gmail.com>
 <CABe8uE1h+6zwqMrdauu2oVQTVW+1hYrS5GLNs_xJ5Tf797NyEQ@mail.gmail.com>
 <CAP=Y=q8P9e+bTymyu0tj=_iZjHfxpqOVF=+aFQEThuO5gDb1wQ@mail.gmail.com>
 <CAP=Y=q8b9++4073FddWdVJuYN47FLRiVW63NkNmuRqUV5XhPTQ@mail.gmail.com>
Message-ID: <CAP=Y=q_dVUWOki-zirameyDt2G5ed1gXGbxap4STaNtDBfaHLQ@mail.gmail.com>

To clear things up, Issues are related to handling using type erasure, not
class generating approach.

??, 21 ???. 2024??. ? 18:45, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> To clear thing up, Issues are related to handling using type erasure, not
> class generating approach.
>
> ??, 21 ???. 2024??. ? 16:48, ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com>:
>
>> I am not really familiar with goals and milestones of Valhalla project,
>> but what I meant by simplification is that there would not be any more need
>> to convert to promotove streams explicitly as Stream<primitive> would be a
>> thing. If that's what Valhalla is working on, then this would be just
>> great. Performance concerns regarding wrappers  are also valid  , but here
>> I am talking about implementation complexity.
>>
>> If going little off topic, compiling many classes to achieve generic
>> reification in fact looks odd, but it in fact provides best developer
>> experience, Converting primitive arrays to collections is one of the
>> examples of major problems issues with it, along with some methods of
>> Arrays class (like sort, if I am not mistaken), just don't work with
>> primitives.Approach that is used in C#, while has its downsides, provides
>> much better user experience. However, what I am looking into right now is
>> some hybrid form of generic handling, where generic maybe be reified on
>> demand of developer (or implicitly if primitive is used). I am working on
>> some prototypes at the moment
>>
>> ??, 21 ???. 2024??. ? 16:31, - <liangchenblue at gmail.com>:
>>
>>> On Sun, Apr 21, 2024 at 5:49?AM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> I have heard your proposal. Your approach indeed for sure has its
>>>> advantages.
>>>>
>>>> One thing I don't like referring to is Valhalla. It's not even a
>>>> preview and no one really knows when it will be, relying on it when
>>>> designing API now would be strange to say the least.
>>>>
>>> Valhalla's value classes are actually quite ready; the compatibility and
>>> the type system are quite fleshed out in the recent iterations, and the
>>> prototypes are already functional.
>>>
>>>>
>>>> One possible thing that could dramatically simplify implementation of
>>>> my approach is introduction of generic reification, which would allow
>>>> primitives as type params. I am currently studying the working of javac and
>>>> possible implementation of this is one of the topics in my research.
>>>> However, let's stick to what we have in jdk right now from now on.
>>>>
>>> Generic reification is part of project Valhalla too, in that it allows
>>> wrapper classes in generics to have the same performance as the primitives
>>> with generic specialization. Compiling many classes to achieve generic
>>> reification is an alternative, but I don't think it's feasible.
>>>
>>>>
>>>> I would like to hear opinions of other people regarding the design of
>>>> such API, especially David and Remi, since, as I understand, that's not the
>>>> first time they witness a discussion like this, so maybe they have
>>>> something to tell here.
>>>>
>>> Unfortunately you will have to wait. Most JDK engineers are employees
>>> who work on weekdays; only a few are enthusiasts. I think we may get more
>>> discussion traffic on Monday.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240421/ae542602/attachment.htm>

From kvn at openjdk.org  Sun Apr 21 16:45:39 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 21 Apr 2024 16:45:39 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v26]
In-Reply-To: <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>
Message-ID: <WKtYgyUtcqNTu4hPdPpdt7ic2Hrq6fr8ktJGlwiEOnU=.282c8b73-30ea-42bd-aeb1-0aa5908e9950@github.com>

On Sat, 20 Apr 2024 22:31:48 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'openjdk:master' into setMemory
>  - Fix UnsafeCopyMemoryMark scope issue
>  - Long to short jmp; other cleanup
>  - Review comments
>  - Address review comments; update copyright years
>  - Add enter() and leave(); remove Windows-specific register stuff
>  - Fix memory mark after sync to upstream
>  - Merge branch 'openjdk:master' into setMemory
>  - Set memory test (#23)
>    
>    * Even more review comments
>    
>    * Re-write of atomic copy loops
>    
>    * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
>    
>    * Only add a memory mark for byte unaligned fill
>    
>    * Remove MUSL_LIBC ifdef
>    
>    * Remove MUSL_LIBC ifdef
>  - Set memory test (#22)
>    
>    * Even more review comments
>    
>    * Re-write of atomic copy loops
>    
>    * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
>    
>    * Only add a memory mark for byte unaligned fill
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/6d569961...1122b500

My testing passed. Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-2013478795

From sgibbons at openjdk.org  Sun Apr 21 21:01:38 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sun, 21 Apr 2024 21:01:38 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v26]
In-Reply-To: <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>
Message-ID: <tq8ROzlcICZ40FQqp4fMtZ1a-Yb9ZT9ZqoE2FrV2WH8=.7ea4e5ea-fbf6-42b1-882c-8b7dc08eae33@github.com>

On Sat, 20 Apr 2024 22:31:48 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'openjdk:master' into setMemory
>  - Fix UnsafeCopyMemoryMark scope issue
>  - Long to short jmp; other cleanup
>  - Review comments
>  - Address review comments; update copyright years
>  - Add enter() and leave(); remove Windows-specific register stuff
>  - Fix memory mark after sync to upstream
>  - Merge branch 'openjdk:master' into setMemory
>  - Set memory test (#23)
>    
>    * Even more review comments
>    
>    * Re-write of atomic copy loops
>    
>    * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
>    
>    * Only add a memory mark for byte unaligned fill
>    
>    * Remove MUSL_LIBC ifdef
>    
>    * Remove MUSL_LIBC ifdef
>  - Set memory test (#22)
>    
>    * Even more review comments
>    
>    * Re-write of atomic copy loops
>    
>    * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
>    
>    * Only add a memory mark for byte unaligned fill
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/6d569961...1122b500

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2068196116

From jbhateja at openjdk.org  Sun Apr 21 23:24:41 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 21 Apr 2024 23:24:41 GMT
Subject: Integrated: 8318650: Optimized subword gather for x86 targets.
In-Reply-To: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
Message-ID: <6zpY5qLpjjfNh62GcpLMHjB_big53dvZmPhwCLMRvCU=.409cf55f-08d6-4135-b7bc-9a544cc18eaa@github.com>

On Wed, 25 Oct 2023 04:34:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
> 
> Following is the summary of changes:-
> 
> 1) Intrinsify sub-word gather using hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.5-10x gains with included micro.
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
> 
> 
> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 185e711b
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/185e711bfe4c4d013b56e867f85cfb4177b3a2cf
Stats:     1178 lines in 32 files changed: 1129 ins; 21 del; 28 mod

8318650: Optimized subword gather for x86 targets.

Reviewed-by: sviswanathan, epeter, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/16354

From jbhateja at openjdk.org  Sun Apr 21 23:27:44 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 21 Apr 2024 23:27:44 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v26]
In-Reply-To: <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>
Message-ID: <V7Kj_zwOF1b25FqJao52k44H0f6aITGlKimVkSip2oM=.52db0eb0-bdd1-4656-b063-7adb3a7ea2b1@github.com>

On Sat, 20 Apr 2024 22:31:48 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'openjdk:master' into setMemory
>  - Fix UnsafeCopyMemoryMark scope issue
>  - Long to short jmp; other cleanup
>  - Review comments
>  - Address review comments; update copyright years
>  - Add enter() and leave(); remove Windows-specific register stuff
>  - Fix memory mark after sync to upstream
>  - Merge branch 'openjdk:master' into setMemory
>  - Set memory test (#23)
>    
>    * Even more review comments
>    
>    * Re-write of atomic copy loops
>    
>    * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
>    
>    * Only add a memory mark for byte unaligned fill
>    
>    * Remove MUSL_LIBC ifdef
>    
>    * Remove MUSL_LIBC ifdef
>  - Set memory test (#22)
>    
>    * Even more review comments
>    
>    * Re-write of atomic copy loops
>    
>    * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
>    
>    * Only add a memory mark for byte unaligned fill
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/6d569961...1122b500

Marked as reviewed by jbhateja (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-2013564907

From sgibbons at openjdk.org  Sun Apr 21 23:27:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sun, 21 Apr 2024 23:27:45 GMT
Subject: Integrated: 8329331: Intrinsify Unsafe::setMemory
In-Reply-To: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
Message-ID: <ZO9C_FSJoeY4ap5j58z2b0CI1nXMIUNmQxyU2UHrn34=.458ace65-0967-40d9-9898-019357f7f6e3@github.com>

On Fri, 29 Mar 2024 22:32:06 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
> 
> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
> 
> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
> 
> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)

This pull request has now been integrated.

Changeset: bd67ac69
Author:    Scott Gibbons <sgibbons at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd67ac69a234cd1096e534c7d4a45d88715884b4
Stats:     507 lines in 36 files changed: 420 ins; 5 del; 82 mod

8329331: Intrinsify Unsafe::setMemory

Reviewed-by: sviswanathan, jbhateja, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/18555

From pminborg at openjdk.org  Mon Apr 22 08:46:53 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 Apr 2024 08:46:53 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v7]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <lj7O4Bv1QYMArWAyHkuzZ8zbXQ7mj2WF7b_fDEt8hpk=.e22d8bb2-5dc3-4f8a-b4e1-261aab5c8b00@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

Per Minborg 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:

 - Simplify tests
 - Add a test for null arg
 - Add a test for findOrThrow()
 - Merge branch 'master' into symbol-lookup-findorthrow
 - Change exception type
 - Update src/java.base/share/classes/java/lang/foreign/package-info.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Fix typo
 - Update after PR comments
 - ... and 2 more: https://git.openjdk.org/jdk/compare/76cd531f...0e06e0d6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/e2f6c4c9..0e06e0d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=05-06

  Stats: 91042 lines in 1455 files changed: 42444 ins; 38886 del; 9712 mod
  Patch: https://git.openjdk.org/jdk/pull/18474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18474/head:pull/18474

PR: https://git.openjdk.org/jdk/pull/18474

From redestad at openjdk.org  Mon Apr 22 08:51:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 08:51:41 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs [v2]
In-Reply-To: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
Message-ID: <3p7K82iR_VB49VMHQvdiD5FtT4r5ckggRFnZ1_L6aeM=.dad3aaba-d81b-449c-9468-92f9f36f84f9@github.com>

> We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant mappings; store an immutable copy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18865/files
  - new: https://git.openjdk.org/jdk/pull/18865/files/57d50841..b6d29f2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18865&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18865&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18865.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18865/head:pull/18865

PR: https://git.openjdk.org/jdk/pull/18865

From redestad at openjdk.org  Mon Apr 22 08:57:45 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 08:57:45 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs [v3]
In-Reply-To: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
Message-ID: <NbdEt36jkLdlB9K6kMMWsaRdqBadZ_-u1btVjWTUusk=.93ce78f6-fb0d-4e75-8b42-92663c38e077@github.com>

> We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes, splitting these out to a separate PR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18865/files
  - new: https://git.openjdk.org/jdk/pull/18865/files/b6d29f2a..6226f1b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18865&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18865&range=01-02

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18865.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18865/head:pull/18865

PR: https://git.openjdk.org/jdk/pull/18865

From redestad at openjdk.org  Mon Apr 22 08:57:45 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 08:57:45 GMT
Subject: RFR: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs [v3]
In-Reply-To: <EaFhjARsnijEKxHr-RmRGOuDcjLKpYbomIIsR-CXLls=.5d03abab-e703-460b-89ff-431d80d32123@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
 <3RSkF8kVcoCwRonUyebeTF3xDDR9CohNpiU6oJdh028=.c596c79d-c2ae-4349-a29e-a14e0587608e@github.com>
 <EaFhjARsnijEKxHr-RmRGOuDcjLKpYbomIIsR-CXLls=.5d03abab-e703-460b-89ff-431d80d32123@github.com>
Message-ID: <tXpLW13ymENdhN3T0xSS5ydY2pWcwS0fFEgZGHv6Atk=.12e26c0c-ad13-467d-84c8-fb5db4f7ec50@github.com>

On Sat, 20 Apr 2024 07:39:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 685:
>> 
>>> 683:     record TypePairs(Class<?> from, Class<?> to) {
>>> 684: 
>>> 685:         private static final Map<TypePairs, String> typePairToName = initialize();
>> 
>> If?`TypePairs.typePairToName` is?never modified after initialisation, then?it?should probably be?made immutable:
>> Suggestion:
>> 
>>         private static final Map<TypePairs, String> typePairToName = Map.copyOf(initialize());
>
> If you really think about it, the `initialize` method itself is somewhat problematic, as it's initializing with byte/short/char on the left, all of which are already converted to int in the of() factory. This should be done in a separate issue.

Yes, the "redirected" mappings can simply be removed in the current implementation. 

Using `Map.copyOf` should be ok to nail down the read-only intent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18865#discussion_r1574385797

From redestad at openjdk.org  Mon Apr 22 08:57:45 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 08:57:45 GMT
Subject: Integrated: 8330681: Explicit hashCode and equals for
 java.lang.runtime.SwitchBootstraps$TypePairs
In-Reply-To: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
References: <WO_WJOVSD-pF7WwcSEjTOWs0rPDehNc-6UpoJds5DEg=.be59779b-8d36-4d3b-b60e-b4c03cbb286e@github.com>
Message-ID: <dLh_uBwl9wNNyLqvq7L6CzkL2lFXQQSrOlCBfShJnPk=.ca015974-965f-4740-90f6-a7d9f1d9125a@github.com>

On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from happening on first use.

This pull request has now been integrated.

Changeset: 3d62bbf4
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d62bbf4f2ea1b37d59c8307225239a88d9e66c0
Stats:     18 lines in 1 file changed: 14 ins; 3 del; 1 mod

8330681: Explicit hashCode and equals for java.lang.runtime.SwitchBootstraps$TypePairs

Reviewed-by: jlahoda, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/18865

From redestad at openjdk.org  Mon Apr 22 08:58:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 08:58:36 GMT
Subject: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v3]
In-Reply-To: <RwSGiqh9MPNYmOtbI-pGXjyOFOajBh2xcQq5X9mdSh4=.cc7c1fbe-ad04-414a-8cf2-02e79c935d2a@github.com>
References: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
 <RwSGiqh9MPNYmOtbI-pGXjyOFOajBh2xcQq5X9mdSh4=.cc7c1fbe-ad04-414a-8cf2-02e79c935d2a@github.com>
Message-ID: <PKSIsm4n9-i-hrJaU9A3KoUW7GAKOA0Fky7xYSp8hco=.d7b71528-3475-48f8-9087-be7afcebc376@github.com>

On Fri, 19 Apr 2024 07:42:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Investigating a recent regression in mainline I realized we have an opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by using `invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This avoids generating type checking adapters and equates to a one-off startup win of around 5ms in any app that ever has the need to spin up a toString, equals or hashCode method on a record.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Copyright
>  - Formatting

Thanks for the reviews, Mandy!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18845#issuecomment-2068853277

From redestad at openjdk.org  Mon Apr 22 08:58:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 08:58:37 GMT
Subject: Integrated: 8330595: Invoke ObjectMethods::bootstrap method exactly
In-Reply-To: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
References: <aVum7q2abq6ZxCz2En1MBmF9aGpgW2uTWT3RbGRwpek=.60161f83-3d70-4b58-b8aa-7595cfc313a8@github.com>
Message-ID: <B--5qR42rFznXAmidz_XMrlxSLc0BNsN8w263FNuuAM=.8ecd6931-8d3b-4a88-bece-126b72f85f46@github.com>

On Thu, 18 Apr 2024 20:11:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Investigating a recent regression in mainline I realized we have an opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by using `invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This avoids generating type checking adapters and equates to a one-off startup win of around 5ms in any app that ever has the need to spin up a toString, equals or hashCode method on a record.

This pull request has now been integrated.

Changeset: 35b30c81
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/35b30c81e0153a12881e622b861ee38c8166ef72
Stats:     17 lines in 1 file changed: 15 ins; 1 del; 1 mod

8330595: Invoke ObjectMethods::bootstrap method exactly

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/18845

From redestad at openjdk.org  Mon Apr 22 09:02:31 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 09:02:31 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v6]
In-Reply-To: <3m2NeLy-0IjoU414JSSzSSUaLfauwUAXbIQ8ueofgsE=.d2e3d01e-e580-4368-9bdb-8d7b4b54af01@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <3m2NeLy-0IjoU414JSSzSSUaLfauwUAXbIQ8ueofgsE=.d2e3d01e-e580-4368-9bdb-8d7b4b54af01@github.com>
Message-ID: <vPR0NJdw8vtr8S2wolfVqEZEbzTWJikDJn7l2QVv1Yk=.6f614488-f841-48ec-85ce-44f0820929af@github.com>

On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor SimpleStringBuilderStrategy::<clinit> overhead reduction

This one is still waiting for a review. 

@mlchung @asotona: Alan asked me to use the ClassFile API here. As it's only used in what's effectively a slow path it shouldn't be blocked by the startup investigations we're doing there, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2068862978

From redestad at openjdk.org  Mon Apr 22 10:39:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 10:39:19 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale
Message-ID: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>

This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.

These numbers are against a baseline which include #18865 and #18845, which already improved the situation:


Name             Cnt          Base         Error           Test         Error         Unit  Change
Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
  :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
  :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
  :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
  * = significant


Comparing to a baseline without those recent improvements the overhead was almost the double: 

Name             Cnt          Base         Error           Test         Error         Unit  Change
Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
  :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
  :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
  :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
  * = significant

-------------

Commit messages:
 - Merge branch 'master' into deswitch
 - Desugar switch in Locale::createLocale

Changes: https://git.openjdk.org/jdk/pull/18882/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18882&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330802
  Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18882.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18882/head:pull/18882

PR: https://git.openjdk.org/jdk/pull/18882

From mbaesken at openjdk.org  Mon Apr 22 11:33:30 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 22 Apr 2024 11:33:30 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
Message-ID: <Pn-kFTRaSQ6zZEAFW72rzootAM3sSs-PnD21HBCn4Zg=.00979e95-518f-4c2e-afb6-f03f3b7071a4@github.com>

On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove launcher executable path trace output

Hi, any additional comments / reviews ?
Thanks Matthias

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2069158463

From alanb at openjdk.org  Mon Apr 22 11:59:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Apr 2024 11:59:29 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <Pn-kFTRaSQ6zZEAFW72rzootAM3sSs-PnD21HBCn4Zg=.00979e95-518f-4c2e-afb6-f03f3b7071a4@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
 <Pn-kFTRaSQ6zZEAFW72rzootAM3sSs-PnD21HBCn4Zg=.00979e95-518f-4c2e-afb6-f03f3b7071a4@github.com>
Message-ID: <T0TSnYbpR41LP2E33eSFApN5fX2Ok6Oo-bvvxLy9DEI=.ebd3cced-30a7-4f51-8a1c-45ad36c3862e@github.com>

On Mon, 22 Apr 2024 11:30:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi, any additional comments / reviews ? Thanks Matthias

It still looks like left over trace messages from a debugging session, need to think about about what tracing make sense here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2069209127

From alanb at openjdk.org  Mon Apr 22 12:06:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Apr 2024 12:06:27 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale
In-Reply-To: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
Message-ID: <marIrqWystdEnpOKw29SOifFCz2f7EK950wZEu1k8F4=.5d90d214-08c8-476e-9122-18afe0a6217d@github.com>

On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
> 
> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
> 
> 
> Name             Cnt          Base         Error           Test         Error         Unit  Change
> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>   * = significant
> 
> 
> Comparing to a baseline without those recent improvements the overhead was almost the double: 
> 
> Name             Cnt          Base         Error           Test         Error         Unit  Change
> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>   * = significant

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18882#pullrequestreview-2014569606

From alanb at openjdk.org  Mon Apr 22 12:45:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Apr 2024 12:45:53 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in loom repo for some time.

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 five additional commits since the last revision:

 - Merge
 - Sync up from loom repo, update copyright headers
 - Merge
 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18598/files
  - new: https://git.openjdk.org/jdk/pull/18598/files/a21a8d6b..0d99fe0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18598&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18598&range=00-01

  Stats: 35845 lines in 976 files changed: 19000 ins; 10527 del; 6318 mod
  Patch: https://git.openjdk.org/jdk/pull/18598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18598/head:pull/18598

PR: https://git.openjdk.org/jdk/pull/18598

From alanb at openjdk.org  Mon Apr 22 12:45:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Apr 2024 12:45:53 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <1A4v-0RIqCwLMUTCZ4XUEC0uV4Qwegh5JGZZOvVeauo=.c15ac785-d844-461f-97cf-da4ea890f220@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in loom repo for some time.

The changes are updated to pin when attempting to increase parallelism. That removes the possibility of preemption in begingBlocking for now so hopefully this is easier to understand. Also removed the transferTo overloads for now, that would make it easier too but we may want to come back to them in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18598#issuecomment-2069298348

From liach at openjdk.org  Mon Apr 22 13:08:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Apr 2024 13:08:30 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale
In-Reply-To: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
Message-ID: <WxlYzyX1RQ5lE0gAx_CtmRO6oZZVO27V863HklwZ6eg=.1416b315-cdb2-4df9-9379-3865be259321@github.com>

On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
> 
> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
> 
> 
> Name             Cnt          Base         Error           Test         Error         Unit  Change
> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>   * = significant
> 
> 
> Comparing to a baseline without those recent improvements the overhead was almost the double: 
> 
> Name             Cnt          Base         Error           Test         Error         Unit  Change
> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>   * = significant

src/java.base/share/classes/java/util/Locale.java line 1003:

> 1001:             return new Locale(lk.base, lk.exts);
> 1002:         } else {
> 1003:             throw new InternalError("should not happen");

The default branch was required in the switch. Can we simply drop this branch and have a ClassCastException to LocalKey instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18882#discussion_r1574727393

From redestad at openjdk.org  Mon Apr 22 13:41:31 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 13:41:31 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale
In-Reply-To: <WxlYzyX1RQ5lE0gAx_CtmRO6oZZVO27V863HklwZ6eg=.1416b315-cdb2-4df9-9379-3865be259321@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
 <WxlYzyX1RQ5lE0gAx_CtmRO6oZZVO27V863HklwZ6eg=.1416b315-cdb2-4df9-9379-3865be259321@github.com>
Message-ID: <MOeEMMwck3dasPtUa-nNDb7M3O26m7bVmmIto57PkT0=.d440d00a-b010-4c38-ba67-93245028278a@github.com>

On Mon, 22 Apr 2024 13:05:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
>> 
>> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
>> 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>>   * = significant
>> 
>> 
>> Comparing to a baseline without those recent improvements the overhead was almost the double: 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>>   * = significant
>
> src/java.base/share/classes/java/util/Locale.java line 1003:
> 
>> 1001:             return new Locale(lk.base, lk.exts);
>> 1002:         } else {
>> 1003:             throw new InternalError("should not happen");
> 
> The default branch was required in the switch. Can we simply drop this branch and have a ClassCastException to LocalKey instead?

You mean like so:


    private static Locale createLocale(Object key) {
        if (key instanceof BaseLocale base) {
            return new Locale(base, null);
        }
        LocaleKey lk = (LocaleKey)key;
        return new Locale(lk.base, lk.exts);
    }
 ```
 ?
 
 I think this should be alright. The type of the "impossibly" thrown exception would differ.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18882#discussion_r1574776021

From mcimadamore at openjdk.org  Mon Apr 22 13:49:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 Apr 2024 13:49:37 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v7]
In-Reply-To: <lj7O4Bv1QYMArWAyHkuzZ8zbXQ7mj2WF7b_fDEt8hpk=.e22d8bb2-5dc3-4f8a-b4e1-261aab5c8b00@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <lj7O4Bv1QYMArWAyHkuzZ8zbXQ7mj2WF7b_fDEt8hpk=.e22d8bb2-5dc3-4f8a-b4e1-261aab5c8b00@github.com>
Message-ID: <YqMHwwkz2Lezr2Mvaav4QLyOAaO1OrjMCq8R3nhBpdA=.6ad77975-989f-42eb-9644-f3b576b68f00@github.com>

On Mon, 22 Apr 2024 08:46:53 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg 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:
> 
>  - Simplify tests
>  - Add a test for null arg
>  - Add a test for findOrThrow()
>  - Merge branch 'master' into symbol-lookup-findorthrow
>  - Change exception type
>  - Update src/java.base/share/classes/java/lang/foreign/package-info.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Fix typo
>  - Update after PR comments
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9a68d47d...0e06e0d6

test/jdk/java/foreign/loaderLookup/TestSymbolLookupFindOrThrow.java line 41:

> 39: 
> 40:     static {
> 41:         System.loadLibrary("Foo");

Where is this lib defined?

test/jdk/java/foreign/loaderLookup/TestSymbolLookupFindOrThrow.java line 58:

> 56:     @Test
> 57:     void findOrThrowNullArg() {
> 58:         assertThrows(NullPointerException.class, () ->

I believe this should already be checked by the TestNulls test - which is a test that automatically checks that _all_ API methods handle nulls accordingly. Please check that, and maybe remove this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1574788219
PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1574786946

From liach at openjdk.org  Mon Apr 22 13:51:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Apr 2024 13:51:29 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale
In-Reply-To: <MOeEMMwck3dasPtUa-nNDb7M3O26m7bVmmIto57PkT0=.d440d00a-b010-4c38-ba67-93245028278a@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
 <WxlYzyX1RQ5lE0gAx_CtmRO6oZZVO27V863HklwZ6eg=.1416b315-cdb2-4df9-9379-3865be259321@github.com>
 <MOeEMMwck3dasPtUa-nNDb7M3O26m7bVmmIto57PkT0=.d440d00a-b010-4c38-ba67-93245028278a@github.com>
Message-ID: <C1yqE8U2ib5H5eLxsyDEtkZwXcKdtV0gEDHZA1Syg2w=.c87c70d3-f55f-4366-878b-2d4d1d68f55d@github.com>

On Mon, 22 Apr 2024 13:38:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 1003:
>> 
>>> 1001:             return new Locale(lk.base, lk.exts);
>>> 1002:         } else {
>>> 1003:             throw new InternalError("should not happen");
>> 
>> The default branch was required in the switch. Can we simply drop this branch and have a ClassCastException to LocalKey instead?
>
> You mean like so:
> 
> 
>     private static Locale createLocale(Object key) {
>         if (key instanceof BaseLocale base) {
>             return new Locale(base, null);
>         }
>         LocaleKey lk = (LocaleKey)key;
>         return new Locale(lk.base, lk.exts);
>     }
>  ```
>  ?
>  
>  I think this should be alright. The type of the "impossibly" thrown exception would differ.

Yes, just like how jli handles the Class/MethodType union type arguments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18882#discussion_r1574791014

From jkratochvil at openjdk.org  Mon Apr 22 13:59:30 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 22 Apr 2024 13:59:30 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
In-Reply-To: <c294bf3f-6df7-4d47-b68d-13b2c2222b5a@oracle.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <c294bf3f-6df7-4d47-b68d-13b2c2222b5a@oracle.com>
Message-ID: <bocf_l6kKagKeqgEhID2Y4UN-yxMC3tL_lXcrFfgyWA=.24552163-bf2e-4e13-8c47-40a65a36f882@github.com>

On Fri, 19 Apr 2024 05:18:51 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> I think (I am agreeing with you Severin) that the goal of the heuristic is to inform the JVM (and any associated serviceability tools) that the JVM is in a resource constrained/managed execution context...

"resource constrained" (my patch) vs. "managed" (this patch) is the difference of the two patches being discussed.

Anyway in this patch one could unify naming across variables/parameters, the same value is called `_is_ro`, `is_read_only`, `ro_opt`, `read_only`, `ro`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2069537759

From redestad at openjdk.org  Mon Apr 22 14:11:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 22 Apr 2024 14:11:41 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale [v2]
In-Reply-To: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
Message-ID: <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>

> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
> 
> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
> 
> 
> Name             Cnt          Base         Error           Test         Error         Unit  Change
> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>   * = significant
> 
> 
> Comparing to a baseline without those recent improvements the overhead was almost the double: 
> 
> Name             Cnt          Base         Error           Test         Error         Unit  Change
> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>   * = significant

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove InternalError in favor of CCE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18882/files
  - new: https://git.openjdk.org/jdk/pull/18882/files/c4f5ee7c..0afa47ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18882&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18882&range=00-01

  Stats: 6 lines in 1 file changed: 2 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18882.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18882/head:pull/18882

PR: https://git.openjdk.org/jdk/pull/18882

From sgibbons at openjdk.org  Mon Apr 22 14:16:06 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 22 Apr 2024 14:16:06 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v16]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <6UnFG26aCrqCe5egk5hKsogxeOBNNdUuHfGveP82n_4=.7be96c8b-a2b9-4bdd-90f1-65ff60b5ae7f@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:

 - Merge branch 'openjdk:master' into indexof
 - Remove infinite loop (used for debugging)
 - Merge branch 'openjdk:master' into indexof
 - Cleaned up, ready for review
 - Pre-cleanup code
 - Add JMH. Add 16-byte compares to arrays_equals
 - Better method for mask creation
 - Merge branch 'openjdk:master' into indexof
 - Most cleanup done.
 - Remove header dependency
 - ... and 38 more: https://git.openjdk.org/jdk/compare/3e65d90b...8e0ce70a

-------------

Changes: https://git.openjdk.org/jdk/pull/16753/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=15
  Stats: 4903 lines in 19 files changed: 4549 ins; 241 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From liach at openjdk.org  Mon Apr 22 14:16:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Apr 2024 14:16:31 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale [v2]
In-Reply-To: <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
 <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
Message-ID: <nJHuLWnc3hwaYBQoOgcnOrUEXmauSbNJWJ4yOahjdw0=.def21b94-ebb1-4c19-a596-b87ecc4f179c@github.com>

On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
>> 
>> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
>> 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>>   * = significant
>> 
>> 
>> Comparing to a baseline without those recent improvements the overhead was almost the double: 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove InternalError in favor of CCE

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18882#pullrequestreview-2014893801

From rriggs at openjdk.org  Mon Apr 22 14:59:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Apr 2024 14:59:27 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale [v2]
In-Reply-To: <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
 <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
Message-ID: <xyXju-lbS7JUrcQdvcAzao5viYYZF4CY0OCUzrPoYHU=.ee95ed56-476a-4c79-ba81-62cd97f38e8b@github.com>

On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
>> 
>> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
>> 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>>   * = significant
>> 
>> 
>> Comparing to a baseline without those recent improvements the overhead was almost the double: 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove InternalError in favor of CCE

LGTM, the CCE is the equivalent of should-not-reach-here.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18882#pullrequestreview-2015014213

From naoto at openjdk.org  Mon Apr 22 16:13:28 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 Apr 2024 16:13:28 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale [v2]
In-Reply-To: <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
 <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
Message-ID: <FMMiXZw0_1ITnqNP0pOkAc8G_WM_IVcPvJRukltxNBc=.bb154609-7eaf-4d10-804b-3813550632b9@github.com>

On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
>> 
>> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
>> 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>>   * = significant
>> 
>> 
>> Comparing to a baseline without those recent improvements the overhead was almost the double: 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove InternalError in favor of CCE

Thanks for the fix, Claes!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18882#pullrequestreview-2015234211

From ihse at openjdk.org  Mon Apr 22 17:21:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Apr 2024 17:21:30 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
Message-ID: <Mf1C2VKl5EMrdmjB7zOsD0xSZCkODHEdbtMgc_ynG7A=.e9424dd8-1e3b-4466-a0e6-8e6947ca7895@github.com>

On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove launcher executable path trace output

What is the use case for this tracing functionality? I recently was quite helped by it when debugging static java launching. And in that case, the more logging the better. But that sounds like a very special case. Is this something that end users are supposed to use to help solve problems?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2070309758

From mchung at openjdk.org  Mon Apr 22 17:23:30 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 22 Apr 2024 17:23:30 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale [v2]
In-Reply-To: <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
 <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
Message-ID: <VWHQi4muzCaWmbpR2j8gJkIrcTKkw17GaZsUuUv2GoY=.16662f4c-aa29-4a37-b8f8-e9095378f18f@github.com>

On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
>> 
>> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
>> 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>>   * = significant
>> 
>> 
>> Comparing to a baseline without those recent improvements the overhead was almost the double: 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove InternalError in favor of CCE

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18882#pullrequestreview-2015399334

From clanger at openjdk.org  Mon Apr 22 17:38:31 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 22 Apr 2024 17:38:31 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
Message-ID: <q4_23r2iJxwp6vUXvX_O58e4KYgM9PQXN0MRxIISTKE=.86866310-594b-4524-a052-12cd253b93b9@github.com>

On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove launcher executable path trace output

It helped to understand the issue behind https://bugs.openjdk.org/browse/JDK-8329653

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2070365643

From jjg at openjdk.org  Mon Apr 22 17:41:28 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 22 Apr 2024 17:41:28 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
 <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
Message-ID: <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>

On Fri, 19 Apr 2024 19:29:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > We do not have an overall style guide. The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.
> 
> That's what I do.
> 
> I saw either style used in JDK. Yet I didn't check which style is more common? to decide which style I should use when creating new files with javadoc comments. [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) doesn't have a blank line between the javadoc comment and class declaration; nor do javadoc comments for fields and methods.

The document [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) is depressingly obsolete, as indicated by this text towards the end:

>Footnotes
>
> [1] At Java Software, we use @version for the SCCS version. See "man sccs-get" for details. The consensus seems to be the following:

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2070379608

From aivanov at openjdk.org  Mon Apr 22 17:56:28 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Apr 2024 17:56:28 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
 <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
 <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>
Message-ID: <00Gbr5mrPAEDVFsF8tkDSasn1qIk1OftDX9nvExC9mg=.c3313acd-0939-4af8-9c36-e9c8b7e6e518@github.com>

On Mon, 22 Apr 2024 17:38:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The document [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) is depressingly obsolete, as indicated by this text towards the end:

I know. Yet there's nothing newer, is there?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2070433346

From bpb at openjdk.org  Mon Apr 22 18:39:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Apr 2024 18:39:31 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
Message-ID: <GeLsrCnZslRDkk9mEXYNa2KXVLARMEFAGJqaymusVuY=.7799ca07-5479-4ae1-b93a-5545c93a54e4@github.com>

On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in loom repo for some time.
>
> 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 five additional commits since the last revision:
> 
>  - Merge
>  - Sync up from loom repo, update copyright headers
>  - Merge
>  - Merge
>  - Initial commit

Looks fine. I think dropping the `transferTo` overloads for now is good.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18598#pullrequestreview-2015549163

From naoto at openjdk.org  Mon Apr 22 18:50:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 Apr 2024 18:50:58 GMT
Subject: RFR: 8319990: Update CLDR to Version 45.0
Message-ID: <Wyp4kxo3jyIf17I182D5xPZt_4g1dVgv9yxMTSP18gg=.80be586b-01d2-4cca-a12d-4b63ed7eedb0@github.com>

Upgrading the CLDR to version 45.0. We now have versions specified in the javadoc (`LocaleServiceProvider`), a corresponding CSR has also been drafted.

-------------

Commit messages:
 - .md files
 - release-45
 - Fix tests for CLDR-17482 Fix million compact number issue in Italian
 - release-45-beta4
 - release-v45-beta3
 - Added CLDR 45 release info
 - release-45-beta1
 - release-45-alpha3
 - release-45-alpha2
 - release-45-alpha0
 - ... and 1 more: https://git.openjdk.org/jdk/compare/140f5671...90a1edcb

Changes: https://git.openjdk.org/jdk/pull/18900/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18900&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319990
  Stats: 7401 lines in 1075 files changed: 307 ins; 4640 del; 2454 mod
  Patch: https://git.openjdk.org/jdk/pull/18900.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18900/head:pull/18900

PR: https://git.openjdk.org/jdk/pull/18900

From mchung at openjdk.org  Mon Apr 22 19:07:34 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 22 Apr 2024 19:07:34 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v3]
In-Reply-To: <PlXx7PbugqeUyTpSkSJRLmSLRSDUeXdrMSMjjB90JxI=.3be92706-6b4b-41bd-a859-8c5579212bed@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <PlXx7PbugqeUyTpSkSJRLmSLRSDUeXdrMSMjjB90JxI=.3be92706-6b4b-41bd-a859-8c5579212bed@github.com>
Message-ID: <-xrN1jI0RCCUnCM1iEPLCkD9OyTWcy80JsxeXFgaiAA=.7fb90626-9e80-48f7-b177-c7b262325047@github.com>

On Fri, 19 Apr 2024 19:39:09 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing space formatting

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 908:

> 906: 
> 907:     private static boolean isStatic = false;
> 908:     private static boolean noArgs = false;

Suggestion:

    private static boolean isStaticMain = false;
    private static boolean noArgMain = false;

src/java.base/share/native/libjli/java.c line 396:

> 394: int
> 395: invokeStaticMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs,
> 396:         JavaVM *vm, int ret) {

As `CHECK_EXCEPTION_xxx_LEAVE` assumes to be used within JavaMain and it changes the value of the local `ret` variable, it should call `CHECK_EXCEPTION_RETURN_VALUE` and `NULL_CHECK_RETURN_VALUE` instead.  

JavaMain should call `CHECK_EXCEPTION_LEAVE(1);` after this method returns to print any exception and exit.

src/java.base/share/native/libjli/java.c line 399:

> 397:     jmethodID mainID = (*env)->GetStaticMethodID(env, mainClass, "main",
> 398:                                   "([Ljava/lang/String;)V");
> 399:     CHECK_EXCEPTION_LEAVE(1);

Is this needed?  `invokeStaticMainWithArgs` should only be called if the main method is validated as a static main with args.

A sanity check `NULL_CHECK0(mainID)` may be adequate (to use existing macro and so  keeping the return value 0 to indicate error).

src/java.base/share/native/libjli/java.c line 409:

> 407:  */
> 408: int
> 409: invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs,

int
invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs) {
    jmethodID mainID = (*env)->GetMethodID(env, mainClass, "main",
                                 "([Ljava/lang/String;)V");
    NULL_CHECK0(mainID);                             
    jmethodID constructor = (*env)->GetMethodID(env, mainClass, "<init>", "()V");
    NULL_CHECK0(constructor);
    jobject mainObject = (*env)->NewObject(env, mainClass, constructor);
    CHECK_EXCEPTION_RETURN_VALUE(0);
    NULL_CHECK0(mainObject);
    (*env)->CallVoidMethod(env, mainObject, mainID, mainArgs);
    return 1;
}

src/java.base/share/native/libjli/java.c line 431:

> 429:     jmethodID mainID = (*env)->GetStaticMethodID(env, mainClass, "main",
> 430:                                        "()V");
> 431:     CHECK_EXCEPTION_LEAVE(1);

Same comment as `invokeStaticMainWithArgs`.

Suggestion:

    NULL_CHECK0(mainID);

src/java.base/share/native/libjli/java.c line 441:

> 439:  */
> 440: int
> 441: invokeInstanceMainWithoutArgs(JNIEnv *env, jclass mainClass,

See the suggestion for `invokeInstanceMainWithArgs`

src/java.base/share/native/libjli/java.c line 610:

> 608: 
> 609: 
> 610:     jclass helperClass = GetLauncherHelperClass(env);

Follow this file convention, declare all local variables at the beginning of this function.

src/java.base/share/native/libjli/java.c line 614:

> 612:         (*env)->GetStaticFieldID(env, helperClass, "isStatic", "Z");
> 613:     jboolean isStatic =
> 614:         (*env)->GetStaticBooleanField(env, helperClass, isStaticField);

Check exception.   Local variable declared at the beginning of the function.

Suggestion:

    isStaticMainField = (*env)->GetStaticFieldID(env, helperClass, "isStaticMain", "Z");
    CHECK_EXCEPTION_NULL_LEAVE(isStaticMain);
    isStaticMain = (*env)->GetStaticBooleanField(env, helperClass, isStaticMainField);

src/java.base/share/native/libjli/java.c line 619:

> 617:         (*env)->GetStaticFieldID(env, helperClass, "noArgs", "Z");
> 618:     jboolean noArgs =
> 619:         (*env)->GetStaticBooleanField(env, helperClass, noArgsField);

Suggestion:

    noArgMainField = (*env)->GetStaticFieldID(env, helperClass, "noArgMain", "Z");
    CHECK_EXCEPTION_NULL_LEAVE(noArgMain);
    noArgMain = (*env)->GetStaticBooleanField(env, helperClass, noArgMainField);

src/java.base/share/native/libjli/java.c line 634:

> 632:        }
> 633:     }
> 634: 

Add `CHECK_EXCEPTION_LEAVE(1);` to check any exception thrown when the main method is invoked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575165463
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575203911
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575201446
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575237945
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575234012
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575238650
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575222579
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575225615
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575226535
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1575227620

From bpb at openjdk.org  Mon Apr 22 19:11:40 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Apr 2024 19:11:40 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier
Message-ID: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>

Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.

-------------

Commit messages:
 - 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier

Changes: https://git.openjdk.org/jdk/pull/18901/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18901&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330748
  Stats: 137 lines in 2 files changed: 134 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18901/head:pull/18901

PR: https://git.openjdk.org/jdk/pull/18901

From bpb at openjdk.org  Mon Apr 22 19:49:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Apr 2024 19:49:44 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
Message-ID: <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>

> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  Correct ID in test @bug tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18901/files
  - new: https://git.openjdk.org/jdk/pull/18901/files/08bb9cb6..57e4917b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18901&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18901&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18901/head:pull/18901

PR: https://git.openjdk.org/jdk/pull/18901

From joehw at openjdk.org  Mon Apr 22 20:44:28 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 22 Apr 2024 20:44:28 GMT
Subject: RFR: 8319990: Update CLDR to Version 45.0
In-Reply-To: <Wyp4kxo3jyIf17I182D5xPZt_4g1dVgv9yxMTSP18gg=.80be586b-01d2-4cca-a12d-4b63ed7eedb0@github.com>
References: <Wyp4kxo3jyIf17I182D5xPZt_4g1dVgv9yxMTSP18gg=.80be586b-01d2-4cca-a12d-4b63ed7eedb0@github.com>
Message-ID: <qYIor2Tjj5tq8BaOGLQyNO9e72qfAVRN7ZjVBtqGjn0=.d8e84bdc-0708-43d6-8f25-baa674b0e5f3@github.com>

On Mon, 22 Apr 2024 18:44:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to version 45.0. We now have versions specified in the javadoc (`LocaleServiceProvider`), a corresponding CSR has also been drafted.

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18900#pullrequestreview-2015768841

From jlu at openjdk.org  Mon Apr 22 20:49:27 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 22 Apr 2024 20:49:27 GMT
Subject: RFR: 8319990: Update CLDR to Version 45.0
In-Reply-To: <Wyp4kxo3jyIf17I182D5xPZt_4g1dVgv9yxMTSP18gg=.80be586b-01d2-4cca-a12d-4b63ed7eedb0@github.com>
References: <Wyp4kxo3jyIf17I182D5xPZt_4g1dVgv9yxMTSP18gg=.80be586b-01d2-4cca-a12d-4b63ed7eedb0@github.com>
Message-ID: <pl5n32Qrg2R7j3KFOBmd4g0sL8zDw72khALrXiXF7-s=.99f147be-30e5-456e-8180-59bd643697eb@github.com>

On Mon, 22 Apr 2024 18:44:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to version 45.0. We now have versions specified in the javadoc (`LocaleServiceProvider`), a corresponding CSR has also been drafted.

LGTM; `LocaleServiceProvider` displays correct CLDR version (45), and Italian compact millions is fixed in regression tests

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18900#pullrequestreview-2015776529

From sgibbons at openjdk.org  Mon Apr 22 21:00:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 22 Apr 2024 21:00:45 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v17]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <05mD2dSduIgyzdnDqUHlh6CEqjWDkJ3wa_XK58tJy4Y=.a1d85af3-17e1-471f-a665-66d0693fda25@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Move arrays_equals back to c2_MacroAssembler

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/8e0ce70a..1d141fde

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=15-16

  Stats: 576 lines in 5 files changed: 288 ins; 282 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From bchristi at openjdk.org  Tue Apr 23 00:00:00 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 23 Apr 2024 00:00:00 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v23]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <mVJfAKB2QFxXaMBLnhNfPAXM6XmoyROGZK2-bVY9iVQ=.d9db74f4-efd7-4656-bdc8-a4533e1a0cee@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  add details on use of reference queues; swap reachability/memviz sections

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/91d4db48..27d0c249

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=21-22

  Stats: 81 lines in 1 file changed: 41 ins; 33 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From bpb at openjdk.org  Tue Apr 23 01:21:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Apr 2024 01:21:32 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
Message-ID: <DE-UUw6njqRkDnnJTp6u6ZFZVCPD3t31ZeDmDQ221Ys=.28b90e85-14c6-46f7-9ecc-aec3a4e8756e@github.com>

On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct ID in test @bug tag

Tiers 1-3 passed on the usual platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18901#issuecomment-2071221654

From darcy at openjdk.org  Tue Apr 23 02:29:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 Apr 2024 02:29:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <S6J882dLjdmFPXHVRQm77lTy73k9FIGC_-kDiBLael4=.0191a2c7-4f55-41b8-a389-e238c8b63f84@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2016121831

From iris at openjdk.org  Tue Apr 23 02:35:31 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 23 Apr 2024 02:35:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <QuHZeejL48phB87kuWRWzlunHQ6KGRSVvyNNCVjTFzk=.1edeb3eb-3cd6-4ed3-a0b5-1a39937dd7e3@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2016126206

From alanb at openjdk.org  Tue Apr 23 06:31:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Apr 2024 06:31:30 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
Message-ID: <JGki7Ey_BynKfNPoH4GavyoMVXBJKw8p0-G1x6hK1no=.7ad2a13c-e41d-4cd4-9cea-773d78ff4d52@github.com>

On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct ID in test @bug tag

As a temporary workaround then I think this is okay. It does mean there needs to a heap spec for the snapshot. Aside from that, the behavioral difference should only be observable to something that is relying on unspecified behavior. BAOS does not document anything about thread safety or that its methods are synchronized.

test/jdk/java/io/ByteArrayOutputStream/WriteToReleasesCarrier.java line 78:

> 76:                 }
> 77:             } finally {
> 78:                 LockSupport.unpark(vthread1);

It might be clearer if you add vthread1.join() after the unpark. It's not strictly needed here as scheduler::close will block until the carrier terminates so that will guarantee that the virtual thread has unmounted.

test/jdk/java/io/ByteArrayOutputStream/WriteToReleasesCarrier.java line 124:

> 122:      * Returns a builder to create virtual threads that use the given scheduler.
> 123:      */
> 124:     static Thread.Builder.OfVirtual virtualThreadBuilder(Executor scheduler) throws Exception {

At some point we will move some of the infrastructure for tests like this to a shared location in the test tree.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18901#pullrequestreview-2016331774
PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1575700125
PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1575700737

From dholmes at openjdk.org  Tue Apr 23 07:07:31 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Apr 2024 07:07:31 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
Message-ID: <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.5a6217f6-86e2-4eba-ac48-647b19052cda@github.com>

On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.

LGTM

Thanks

test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 1:

> 1: /*

There are further updates to this test in the pipeline (new deprecated flags in 23) so you will need to keep updating to reflect that.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2016422206
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1575750313

From jpai at openjdk.org  Tue Apr 23 07:09:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 Apr 2024 07:09:31 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
Message-ID: <DSv2hEvDDW4oLhKV1wRyoT916V_3V7DeyjudVKSikAc=.e7c227d6-093b-407e-965d-958d5f4c28a9@github.com>

On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in loom repo for some time.
>
> 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 five additional commits since the last revision:
> 
>  - Merge
>  - Sync up from loom repo, update copyright headers
>  - Merge
>  - Merge
>  - Initial commit

Hello Alan, the latest changes look fine to me. They also address the review comments from the previous iteration.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18598#pullrequestreview-2016427528

From vklang at openjdk.org  Tue Apr 23 07:14:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 23 Apr 2024 07:14:31 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
Message-ID: <gLwr3hGTHjri3A5fK0VRhBLBdawmDfbbnNFzraFTXBs=.08217301-93d1-4ad7-b561-e32a4853ec95@github.com>

On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct ID in test @bug tag

Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?) been explored/benchmarked?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18901#issuecomment-2071589121

From alanb at openjdk.org  Tue Apr 23 07:29:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Apr 2024 07:29:28 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <gLwr3hGTHjri3A5fK0VRhBLBdawmDfbbnNFzraFTXBs=.08217301-93d1-4ad7-b561-e32a4853ec95@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <gLwr3hGTHjri3A5fK0VRhBLBdawmDfbbnNFzraFTXBs=.08217301-93d1-4ad7-b561-e32a4853ec95@github.com>
Message-ID: <oPkKTd_JEiA3PRQtrvbaqVI94Z_XAZnkt8zMvc6z7Yc=.4082729a-7d4f-4e4d-9dc4-94f530662131@github.com>

On Tue, 23 Apr 2024 07:11:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?) been explored/benchmarked?

Yes, decided not to do because it's just guarding access to a byte[] and any changes can influence the inlining. Plus, it would need to continue to use monitors when extended as the subclass may assume synchronization in the super class. Limiting it to just the problematic writeTo method seem the least risky.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18901#issuecomment-2071613230

From jpai at openjdk.org  Tue Apr 23 07:30:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 Apr 2024 07:30:29 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc
In-Reply-To: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
Message-ID: <m_-qak7F0VghUYDLswlXAG9Rasi3jsO5t0FbrxHyEK0=.e5114c82-5642-445d-9bd2-cf080f69d658@github.com>

On Fri, 19 Apr 2024 11:33:48 GMT, Jin Kwon <duke at openjdk.org> wrote:

> Fix typos within the `DatabaseMetaData.java`.

These typo fixes look fine to me. Please update the copyright year on the file from `1996, 2022,` to `1996, 2024,`

-------------

PR Review: https://git.openjdk.org/jdk/pull/18860#pullrequestreview-2016467011

From asotona at openjdk.org  Tue Apr 23 07:48:54 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 Apr 2024 07:48:54 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while parsing
 certain class' bytes
Message-ID: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>

ClassFile API dives into the nested constant pool entries without type restrictions, while parsing a class file. Validation of the entry is performed post-parsing. Specifically corrupted constant pool entry may cause infinite loop during parsing and throws SOE.
This patch resolves the issue by providing specific implementations for the nested CP entries parsing, instead of sharing the common (post-checking) code.
Added test simulates the situation on inner-looped method reference entry.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - added bug#
 - 8330684: ClassFile API runs into StackOverflowError while parsing certain class' bytesactory.java

Changes: https://git.openjdk.org/jdk/pull/18907/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18907&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330684
  Stats: 84 lines in 2 files changed: 60 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/18907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18907/head:pull/18907

PR: https://git.openjdk.org/jdk/pull/18907

From mbaesken at openjdk.org  Tue Apr 23 07:55:39 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Apr 2024 07:55:39 GMT
Subject: RFR: 8330615: avoid signed integer overflows in zip_util.c readCen /
 hashN
Message-ID: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>

In the hashN usages of readCen from zip_util.c we see a lot of signed integer overflows.
For example in the java/util jtreg tests those are easily reproducable when compiling with -ftrapv (clang/gcc toolchains).
While those overflows never seem to cause crashes or similar errors, they are unwanted because
signed integer overflows in C cause undefined behavior.
See
https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html
>
> For signed integers, the result of overflow in C is in principle undefined, meaning that anything whatsoever could happen.
> Therefore, C compilers can do optimizations that treat the overflow case with total unconcern.

So we might still get unwanted results (maybe bad/strange hashing, depending on compiler and optimization level).

Compilation with -ftrapv causes/triggers this SIGILL on macOS showing the issue :
# Problematic frame:
# C [libzip.dylib+0x6362] hashN+0x32
#

Stack: [0x000070000c496000,0x000070000c596000], sp=0x000070000c5957e0, free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libzip.dylib+0x6362] hashN+0x32
C [libzip.dylib+0x5d5e] readCEN+0xd2e
C [libzip.dylib+0x4ee0] ZIP_Put_In_Cache0+0x160
V [libjvm.dylib+0x544b1e] ClassLoader::open_zip_file(char const*, char**, JavaThread*)+0x3e
V [libjvm.dylib+0x543fec] ClassLoader::create_class_path_entry(JavaThread*, char const*, stat const*, bool, bool)+0x6c
V [libjvm.dylib+0x543833] ClassLoader::setup_bootstrap_search_path_impl(JavaThread*, char const*)+0xf3
V [libjvm.dylib+0x54819b] classLoader_init1()+0x1b
V [libjvm.dylib+0x92602a] init_globals()+0x3a
V [libjvm.dylib+0x12b3b74] Threads::create_vm(JavaVMInitArgs*, bool*)+0x314
V [libjvm.dylib+0xa848f4] JNI_CreateJavaVM+0x64
C [libjli.dylib+0x4483] JavaMain+0x123
C [libjli.dylib+0x7529] ThreadJavaMain+0x9
C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0
C [libsystem_pthread.dylib+0x2443] thread_start+0xf

-------------

Commit messages:
 - JDK-8330615

Changes: https://git.openjdk.org/jdk/pull/18908/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18908&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330615
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18908.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18908/head:pull/18908

PR: https://git.openjdk.org/jdk/pull/18908

From redestad at openjdk.org  Tue Apr 23 08:02:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 23 Apr 2024 08:02:35 GMT
Subject: RFR: 8330802: Desugar switch in Locale::createLocale [v2]
In-Reply-To: <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
 <i-SyvrNL4xIDsQZy4CuLS94Ca24KIZsyMqeVUx3wqSg=.50c377ac-4334-425d-adb1-a42d091db332@github.com>
Message-ID: <G5oCjJ5912rJcszzwk9cJgJ8KNHjxR3niWOg3UHsc_Q=.01fac849-e400-47f8-a0e2-7ca30d649dbf@github.com>

On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
>> 
>> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
>> 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>>   * = significant
>> 
>> 
>> Comparing to a baseline without those recent improvements the overhead was almost the double: 
>> 
>> Name             Cnt          Base         Error           Test         Error         Unit  Change
>> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove InternalError in favor of CCE

Thanks for reviewing, everyone!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18882#issuecomment-2071666342

From redestad at openjdk.org  Tue Apr 23 08:02:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 23 Apr 2024 08:02:36 GMT
Subject: Integrated: 8330802: Desugar switch in Locale::createLocale
In-Reply-To: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
References: <uCxccvAzN7nC63KZ1h3Ilt-d1mvP03WXt9j2rp-CCVQ=.7da7c31c-eb01-41a1-b552-01659f569cf3@github.com>
Message-ID: <i82kD3ddS2RuyWh4tINv6BSWU8g_IhLd-ZdxrLTrRT4=.df426f28-7490-412b-826f-f62e008cddf3@github.com>

On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This switch expression in `Locale::createLocale` is causing a somewhat large startup regression on my local system. Desugaring to if statements seem like the right thing to do while we investigate ways to further reduce overheads in `SwitchBootstraps`.
> 
> These numbers are against a baseline which include #18865 and #18845, which already improved the situation:
> 
> 
> Name             Cnt          Base         Error           Test         Error         Unit  Change
> Perfstartup-Noop  20        40,500 ?       1,942         31,000 ?       2,673        ms/op   1,31x (p = 0,000*)
>   :.cycles           143254849,000 ? 3398321,355  102205427,650 ? 2192784,853       cycles   0,71x (p = 0,000*)
>   :.instructions     307138448,850 ? 2095834,550  219415574,800 ?  376992,067 instructions   0,71x (p = 0,000*)
>   :.taskclock               39,500 ?       1,942         22,500 ?       3,858           ms   0,57x (p = 0,000*)
>   * = significant
> 
> 
> Comparing to a baseline without those recent improvements the overhead was almost the double: 
> 
> Name             Cnt          Base         Error           Test         Error         Unit  Change
> Perfstartup-Noop  20        50,000 ?       0,000         31,000 ?       2,673        ms/op   1,61x (p = 0,000*)
>   :.cycles           187047932,000 ? 3330400,381  102205427,650 ? 2192784,853       cycles   0,55x (p = 0,000*)
>   :.instructions     408219060,350 ? 4031173,140  219415574,800 ?  376992,067 instructions   0,54x (p = 0,000*)
>   :.taskclock               53,500 ?       4,249         22,500 ?       3,858           ms   0,42x (p = 0,000*)
>   * = significant

This pull request has now been integrated.

Changeset: daa5a4bd
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/daa5a4bd124d539daa3c67a3e29dcd0eee20c44d
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8330802: Desugar switch in Locale::createLocale

Reviewed-by: alanb, liach, rriggs, naoto, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/18882

From vklang at openjdk.org  Tue Apr 23 08:07:35 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 23 Apr 2024 08:07:35 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
Message-ID: <03havZuXU3rRqqFBvZbQBiPCEZqGiNAZhosgXPmsBOs=.9ede81af-6aa9-4167-9fc5-5c9cd98969c2@github.com>

On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in loom repo for some time.
>
> 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 five additional commits since the last revision:
> 
>  - Merge
>  - Sync up from loom repo, update copyright headers
>  - Merge
>  - Merge
>  - Initial commit

src/java.base/share/classes/java/io/FileInputStream.java line 211:

> 209:      * @param name the name of the file
> 210:      */
> 211:     private void open(String name) throws FileNotFoundException {

If method such as this is private, and only delegates to the 0-suffixed native method, would't it be better to just call the 0-suffixed method directly?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1575825688

From alanb at openjdk.org  Tue Apr 23 08:11:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Apr 2024 08:11:30 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <03havZuXU3rRqqFBvZbQBiPCEZqGiNAZhosgXPmsBOs=.9ede81af-6aa9-4167-9fc5-5c9cd98969c2@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
 <03havZuXU3rRqqFBvZbQBiPCEZqGiNAZhosgXPmsBOs=.9ede81af-6aa9-4167-9fc5-5c9cd98969c2@github.com>
Message-ID: <ELfitihzx8ne8twVUMqNfB3704i0le6CkUpcBwuONuI=.fb4c9d46-a6e8-412e-9100-340c3aea8ff7@github.com>

On Tue, 23 Apr 2024 08:04:54 GMT, Viktor Klang <vklang 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 five additional commits since the last revision:
>> 
>>  - Merge
>>  - Sync up from loom repo, update copyright headers
>>  - Merge
>>  - Merge
>>  - Initial commit
>
> src/java.base/share/classes/java/io/FileInputStream.java line 211:
> 
>> 209:      * @param name the name of the file
>> 210:      */
>> 211:     private void open(String name) throws FileNotFoundException {
> 
> If method such as this is private, and only delegates to the 0-suffixed native method, would't it be better to just call the 0-suffixed method directly?

Historically these native methods were wrapped in order to support instrumentation, I didn't want to touch in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1575831563

From duke at openjdk.org  Tue Apr 23 09:32:40 2024
From: duke at openjdk.org (Jin Kwon)
Date: Tue, 23 Apr 2024 09:32:40 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v2]
In-Reply-To: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
Message-ID: <4WzkMQNiIjXh7EbjSbKgL71Xlw34jUF-pRJ1989m5kg=.b387fbd7-d191-4bd6-9429-f36a3806c93e@github.com>

> Fix typos within the `DatabaseMetaData.java`.

Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:

  [JDK-8330686] Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18860/files
  - new: https://git.openjdk.org/jdk/pull/18860/files/fbd41746..75f0b111

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18860&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18860&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18860/head:pull/18860

PR: https://git.openjdk.org/jdk/pull/18860

From duke at openjdk.org  Tue Apr 23 09:32:40 2024
From: duke at openjdk.org (Jin Kwon)
Date: Tue, 23 Apr 2024 09:32:40 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc
In-Reply-To: <77Nuy6hcSJ95ZGo9oYlqQIkdOp_0AbfYH5mraayr8fM=.f2738151-e479-4ae8-aa91-20ca3ec93bb8@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <WtqOulto50ud2yGKozJZu5-teIzxsl4hpQhnxP6YRC8=.c966d195-35aa-4359-84f7-616f192fbc87@github.com>
 <77Nuy6hcSJ95ZGo9oYlqQIkdOp_0AbfYH5mraayr8fM=.f2738151-e479-4ae8-aa91-20ca3ec93bb8@github.com>
Message-ID: <XWs-nX8a5qyVwpdrG0-Cy7j65WIpfF-rHGJMCdqNAcc=.0193759e-1898-4943-8274-915d9bb000e2@github.com>

On Sat, 20 Apr 2024 04:35:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @openjdk with issue from where?
>
> Hello @onacit, it appears a JBS issue has been filed for this https://bugs.openjdk.org/browse/JDK-8330686. Please change the title of this PR to `8330686: Fix typos in the DatabaseMetaData javadoc` so that it triggers the official review process.

@jaikiran Done. Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18860#issuecomment-2071843513

From vklang at openjdk.org  Tue Apr 23 09:45:30 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 23 Apr 2024 09:45:30 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <oPkKTd_JEiA3PRQtrvbaqVI94Z_XAZnkt8zMvc6z7Yc=.4082729a-7d4f-4e4d-9dc4-94f530662131@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <gLwr3hGTHjri3A5fK0VRhBLBdawmDfbbnNFzraFTXBs=.08217301-93d1-4ad7-b561-e32a4853ec95@github.com>
 <oPkKTd_JEiA3PRQtrvbaqVI94Z_XAZnkt8zMvc6z7Yc=.4082729a-7d4f-4e4d-9dc4-94f530662131@github.com>
Message-ID: <curNGHWGLpXJ5wpuo_Mm10JwX95nO4s2ygoZDt7J60Y=.79620e1c-c929-4def-880d-17c20ac04ee4@github.com>

On Tue, 23 Apr 2024 07:27:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?) been explored/benchmarked?
> 
> Yes, decided not to do because it's just guarding access to a byte[] and any changes can influence the inlining. Plus, it would need to continue to use monitors when extended as the subclass may assume synchronization in the super class. Limiting it to just the problematic writeTo method seem the least risky.

That's true, good points across the board.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18901#issuecomment-2071869067

From duke at openjdk.org  Tue Apr 23 11:18:29 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Tue, 23 Apr 2024 11:18:29 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
Message-ID: <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>

On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct ID in test @bug tag

src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:

> 162:     public void writeTo(OutputStream out) throws IOException {
> 163:         if (Thread.currentThread().isVirtual()) {
> 164:             out.write(toByteArray());

Would it be better to avoid calling a public method `toByteArray` encase subclass is overriding it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1576078358

From mbaesken at openjdk.org  Tue Apr 23 11:53:29 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Apr 2024 11:53:29 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <Mf1C2VKl5EMrdmjB7zOsD0xSZCkODHEdbtMgc_ynG7A=.e9424dd8-1e3b-4466-a0e6-8e6947ca7895@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
 <Mf1C2VKl5EMrdmjB7zOsD0xSZCkODHEdbtMgc_ynG7A=.e9424dd8-1e3b-4466-a0e6-8e6947ca7895@github.com>
Message-ID: <51LXFTVYQLedmpmzFuR9FZknSz9SF7uX4rp1Z89T0ns=.e9781dc9-2062-460e-85e4-bb6420dfdaf8@github.com>

On Mon, 22 Apr 2024 17:19:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> But that sounds like a very special case.

Not sure if it is really such a special case.  Currently both modes (getting the image path from launcher binary path , and getting the image path from 'the dll' / GetApplicationHomeFromDll  (libjli.so on Linux)  exist and are to my knowledge supported.  At least one jtreg test fails when the GetApplicationHomeFromDll  does not work any more.
So I think it is natural that both modes are also supported/augmented by some tracing.
We could probably reduce the trace message(s) added to just one if this is desired .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2072090837

From asotona at openjdk.org  Tue Apr 23 12:01:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 Apr 2024 12:01:37 GMT
Subject: RFR: 8322847: java.lang.classfile.BufWriter should specify @throws for
 its writeXXX methods
Message-ID: <LbGxj-m_26dMeRG6TgVNN16NSWtmutE5jW5pL4r1_7o=.84713a17-9ffe-435a-96e7-f1e9f5d8345a@github.com>

This patch adds missing `@throws` javadoc annotations to `java.lang.classfile.BufWriter`.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - 8322847: java.lang.classfile.BufWriter should specify @throws for its writeXXX methods

Changes: https://git.openjdk.org/jdk/pull/18913/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18913&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322847
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18913.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18913/head:pull/18913

PR: https://git.openjdk.org/jdk/pull/18913

From ecki at zusammenkunft.net  Tue Apr 23 12:11:14 2024
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 23 Apr 2024 14:11:14 +0200 (CEST)
Subject: Usage of iconv()
Message-ID: <20240423121114.EE241662C87@dd33810.kasserver.com>

Du to a glibc security alert about a charset in iconv() I checked OpenJDK (since I was quite sure encoding is handled in JCL), however there are a few utilities (related to libinstrument and splash Screens) which use iconv.

If I see it correctly it?s mostly used for utf8 so it should not expose this particular globe weakness, but I still wonder if that dependency is needed. For some platforms like AIX it even drags on an additional library dependency. (Not to mention different charger tables and especially ugly locale dependencies for containers).

Gru?
Bernd
? 
https://bernd.eckenfels.net

From jpai at openjdk.org  Tue Apr 23 12:51:37 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 Apr 2024 12:51:37 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v9]
In-Reply-To: <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
Message-ID: <7xf3ZQti4nxv7QkxAkD20lNMcRS5GpAyARjbcErXyXA=.5234fab0-c950-4fa7-a3e1-7b4c9a0a6d7a@github.com>

On Sun, 17 Mar 2024 22:53:55 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
>> 
>> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.
>
> Archie Cobbs 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:
> 
>  - Merge branch 'master' into JDK-7036144
>  - Back-out Javadoc addition; to be added in a separate issue.
>  - Document the handling of concatenated streams.
>  - Merge branch 'master' into JDK-7036144
>  - Merge branch 'master' into JDK-7036144
>  - Merge branch 'master' into JDK-7036144
>  - Address third round of review comments.
>  - Address second round of review comments.
>  - Address review comments.
>  - Fix bug in GZIPInputStream when underlying available() returns short.

Hello Archie, we forgot to create a release note for this one (there's still time). Would you be willing to create one, following the instructions here https://openjdk.org/guide/#release-notes? If you need any help, let us know. One of us will review that release note before you can Resolve it to Delivered.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2072214303

From viktor.klang at oracle.com  Tue Apr 23 12:56:54 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 23 Apr 2024 12:56:54 +0000
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB57741063D2F25A36BA7B5209FF112@MW4PR10MB5774.namprd10.prod.outlook.com>

Sadly, there is no way to define a short-circuiting collector :(

That was my first course of exploration for JEP-461, and unfortunately I found no great way of retrofitting that behavior, especially not in a backwards-compatibility-safe way.

You can have a short-circuiting Gatherer like this
  <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
    return Gatherer.ofSequential(
      () -> new Object() { int index; },
      Integrtor.ofGreedy((state, element, downstream) -> {
        var index = state.index++;
        if (predicate.test(element)) {
          return downstream.push(index);
        }
        return true;
      }));
  }

Since this would ne a short-circuiting Gatherer, it would not qualify as Greedy.

With that said, you could create something like:

public static <T, R> Gatherer<T, ?, Long> indiciesWhere(Predicate<T> p) {
       class Index { long at; }
       return Gatherer.ofSequential(
               Index::new,
               Integrator.ofGreedy((idx, e, d) -> {
                 var current = idx.at++;
                 return !p.test(e) || d.push(current);
               })
       );
}


So you could do: list.stream().gather(indiciesWhere(predicate)).findFirst()

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Friday, 19 April 2024 19:47
To: ??-24 ????????? ?????? <rotan.olexandr at gmail.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

Hello,
for me, it seems what you want is  Collector on Stream which is able to short-circuit,
so you can write
  list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
and in reverse
  list.reversed().stream().collect(Collectors.findFirst(s -> s.contains("o")))

Using a Stream here is more general and will work with other collections like a LinkedHashSet for example.
Sadly, there is no way to define a short-circuiting collector :(

You can have a short-circuiting Gatherer like this
  <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
    return Gatherer.ofSequential(
      () -> new Object() { int index; },
      Integrtor.ofGreedy((state, element, downstream) -> {
        var index = state.index++;
        if (predicate.test(element)) {
          return downstream.push(index);
        }
        return true;
      }));
  }

and use it like this:
  list.stream().gather(findIndex(s -> s.contains("o"))).findFirst().orElse(-1);

But it's more verbose.

I wonder if at the same time that the Gatherer API is introduced, the Collector API should be enhanced to support short-circuiting collectors ?

regards,
R?mi


________________________________
From: "??-24 ????????? ??????" <rotan.olexandr at gmail.com>
To: "core-libs-dev" <core-libs-dev at openjdk.org>
Sent: Friday, April 19, 2024 5:59:39 PM
Subject: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List
Subject
Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

Motivation
The motivation behind this proposal is to enhance the functionality of the List interface by providing a more flexible way to find the index of an element. Currently, the indexOf and lastIndexOf methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.

Here I want to propose methods that would accept a Predicate as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.

The changes I am proposing are implemented in this PR: https://github.com/openjdk/jdk/pull/18639. Here is a brief overview of the changes made in this pull request:

Added the findIndex  (Predicate<? super E> filter) method to the List interface.
Added the findLastIndex  (Predicate<? super E> filter) method to the List interface.
Implemented these methods in all non-abstract classes that implement the List interface, as well as List itself (default impl).
The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.

For example, consider the following test case:

List<String> list = new ArrayList<>();
list.add("Object one");
list.add("NotObject two");
list.add("NotObject three");

int index1 = list.findIndex(s -> s.contains("ct t"));
System.out.println(index1); // Expected output: 1
int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
System.out.println(index2); // Expected output: 2
Currently, to achieve the same result, we would have to use a more verbose approach:

int index1 = IntStream.range(0, list.size())
                     .filter(i -> list.get(i).contains("ct t"))
                     .findFirst()
                     .orElse(-1);
System.out.println(index1); // Output: 1
int index2 = IntStream.range(0, list.size())
                         .filter(i -> list.get(i).startsWith("NotObject"))
                         .reduce((first, second) -> second)
                         .orElse(-1);
System.out.println(index2); // Output: 2
Or other approaches that require additional instructions and, therefore, can`t be used in all scopes (like passing argument to method).

I believe these additions would greatly enhance the functionality and flexibility of the List interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.

The main reason I am publishing this proposal in the mailing system is to gather feedback from the Java developers community, especially about possible caveats related to backward compatibility of your projects. Would appreciate every opinion!

Best regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240423/3c1603e7/attachment-0001.htm>

From vklang at openjdk.org  Tue Apr 23 13:04:35 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 23 Apr 2024 13:04:35 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
Message-ID: <Eg5FqJDn1lnjNdsSTYCCrYoDPDduPdIhMh1vaj_YyRw=.a5edbf45-9579-4cd4-9481-68dca2ad630e@github.com>

On Thu, 21 Mar 2024 18:01:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>> 
>> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Use the improved form in forEach
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Null checks should probably be in the beginning...
>  - mark implicit null checks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Copyright year, revert changes for non-few element collections
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Merge branch 'feature/imm-coll-stream' of https://github.com/liachmodded/jdk into feature/imm-coll-stream
>  - Spliterator for 12, iterate/forEach benchmark
>  - fix comments
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d5b95a0e...69bd0e9c

@stuart-marks & @AlanBateman Specialization of forEach() and spliterator()?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2072240066

From asotona at openjdk.org  Tue Apr 23 13:04:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 Apr 2024 13:04:39 GMT
Subject: RFR: 8325373: Improve StackCounter error reporting for bad switch
 cases
Message-ID: <WMLtToC6NJi2EqmVr6S3LjYQ8S8gMLh4UBnL6asW8hE=.a04dd343-0635-44d5-9a26-65e5842a0a9f@github.com>

ClassFile API `StackMapGenerator` attaches print or hex dump of the method to an error message.
However there is no such attachment when the stack maps generation is  turned off.

This patch moves class print/dump to `impl.Util::dumpMethod`, so it is shared by `StackMapGenerator` and `StackCounter` to provide the same level of details in case of an error.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - 8325373: Improve StackCounter error reporting for bad switch cases

Changes: https://git.openjdk.org/jdk/pull/18914/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18914&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325373
  Stats: 97 lines in 3 files changed: 56 ins; 31 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18914/head:pull/18914

PR: https://git.openjdk.org/jdk/pull/18914

From rotan.olexandr at gmail.com  Tue Apr 23 13:10:04 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Tue, 23 Apr 2024 16:10:04 +0300
Subject: Addition of Predicate-based findIndex and findLastIndex methods
 to java.util.List
In-Reply-To: <MW4PR10MB57741063D2F25A36BA7B5209FF112@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAP=Y=q_RtwWntVv78LG85kjM9jxgh6A+sXCmt89GCWCJf68L1A@mail.gmail.com>
 <1258515579.9082066.1713548841012.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB57741063D2F25A36BA7B5209FF112@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAP=Y=q_ChYihXu+nz9hiHtFRB63OOHrrJWJ7rxKBANro-1UJBw@mail.gmail.com>

Hello there! As I see, your approach finds all matching indexes, not
just first. This would be much more suitable using enumerated streams.
Discussion about them has been moved to another thread (see
EnumeratedStream subject in mails).

 Few messages above I provided benchmarks indicating that for one element,
list-based approach drastically outperforms any stream-based, so if you
would like to contribute something to enumerated streams discussion
specifically, you are welcome, but I don't think such dramatic
performance loss is worth the flexibility your approach provides.

However, a gatherer-based enumerated streams approach has been discussed,
and your implementation looks really concie. I like it.

PS: little offtop regarding enumerated streams. In compiler-dev, I have
proposed to introduce extension methods (workin implementation is already
present). Those extensions could really ease Stream API development as well
as many others and also provide a more comfortable interface for Java
users. However, the compiler maintenance team seems to not even consider my
proposal (or at least I didn't get any feedback besides that it was
rejected previously, even though I provided some argumentation about why
pros outweigh cons of such proposal). If any core-libs-dev mainaiter or
enthusiast feels like such feature could be helpful for them, I encourage
you to state that in a related topic so that the compiler team knows there
is demand for extension methods.Thanks for your time!

??, 23 ???. 2024??. ? 15:57, Viktor Klang <viktor.klang at oracle.com>:

> Sadly, there is no way to define a short-circuiting collector :(
>
>
> That was my first course of exploration for JEP-461, and unfortunately I
> found no great way of retrofitting that behavior, especially not in a
> backwards-compatibility-safe way.
>
> You can have a short-circuiting Gatherer like this
>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
>     return Gatherer.ofSequential(
>       () -> new Object() { int index; },
>       Integrtor.ofGreedy((state, element, downstream) -> {
>         var index = state.index++;
>         if (predicate.test(element)) {
>           return downstream.push(index);
>         }
>         return true;
>       }));
>   }
>
>
> Since this would ne a short-circuiting Gatherer, it would not qualify as
> Greedy.
>
> With that said, you could create something like:
>
> public static <T, R> Gatherer<T, ?, Long> indiciesWhere(Predicate<T> p) {
>        class Index { long at; }
>        return Gatherer.ofSequential(
>                Index::new,
>                Integrator.ofGreedy((idx, e, d) -> {
>                  var current = idx.at++;
>                  return !p.test(e) || d.push(current);
>                })
>        );
> }
>
>
> So you could do: list.stream().gather(indiciesWhere(predicate)).findFirst()
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
>
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi
> Forax <forax at univ-mlv.fr>
> *Sent:* Friday, 19 April 2024 19:47
> *To:* ??-24 ????????? ?????? <rotan.olexandr at gmail.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Addition of Predicate-based findIndex and findLastIndex
> methods to java.util.List
>
> Hello,
> for me, it seems what you want is  Collector on Stream which is able to
> short-circuit,
> so you can write
>   list.stream().collect(Collectors.findFirst(s -> s.contains("o")))
> and in reverse
>   list.reversed().stream().collect(Collectors.findFirst(s ->
> s.contains("o")))
>
> Using a Stream here is more general and will work with other collections
> like a LinkedHashSet for example.
> Sadly, there is no way to define a short-circuiting collector :(
>
> You can have a short-circuiting Gatherer like this
>   <T> Gatherer<T, ?, Integer> findIndex(Predicate<? super T> predicate) {
>     return Gatherer.ofSequential(
>       () -> new Object() { int index; },
>       Integrtor.ofGreedy((state, element, downstream) -> {
>         var index = state.index++;
>         if (predicate.test(element)) {
>           return downstream.push(index);
>         }
>         return true;
>       }));
>   }
>
> and use it like this:
>   list.stream().gather(findIndex(s ->
> s.contains("o"))).findFirst().orElse(-1);
>
> But it's more verbose.
>
> I wonder if at the same time that the Gatherer API is introduced, the
> Collector API should be enhanced to support short-circuiting collectors ?
>
> regards,
> R?mi
>
>
> ------------------------------
>
> *From: *"??-24 ????????? ??????" <rotan.olexandr at gmail.com>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Friday, April 19, 2024 5:59:39 PM
> *Subject: *Addition of Predicate-based findIndex and findLastIndex
> methods to java.util.List
>
> Subject
> Addition of Predicate-based findIndex and findLastIndex methods to
> java.util.List
>
> Motivation
> The motivation behind this proposal is to enhance the functionality of the
> List interface by providing a more flexible way to find the index of an
> element. Currently, the indexOf and lastIndexOf methods only accept an
> object as a parameter. This limits the flexibility of these methods as they
> can only find the index of exact object matches.
>
> Here I want to propose methods that would accept a Predicate as a
> parameter, allowing users to define a condition that the desired element
> must meet. This would provide a more flexible and powerful way to find the
> index of an element in a list.
>
> The changes I am proposing are implemented in this PR:
> https://github.com/openjdk/jdk/pull/18639. Here is a brief overview of
> the changes made in this pull request:
>
> Added the findIndex  (Predicate<? super E> filter) method to the List
> interface.
> Added the findLastIndex  (Predicate<? super E> filter) method to the List
> interface.
> Implemented these methods in all non-abstract classes that implement the
> List interface, as well as List itself (default impl).
> The changes have been thoroughly tested to ensure they work as expected
> and do not introduce any regressions. The test cases cover a variety of
> scenarios to ensure the robustness of the implementation.
>
> For example, consider the following test case:
>
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
>
> int index1 = list.findIndex(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list. findLastIndex(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> Currently, to achieve the same result, we would have to use a more verbose
> approach:
>
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> Or other approaches that require additional instructions and, therefore,
> can`t be used in all scopes (like passing argument to method).
>
> I believe these additions would greatly enhance the functionality and
> flexibility of the List interface, making it more powerful and
> user-friendly. I look forward to your feedback and am open to making any
> necessary changes based on your suggestions.
>
> The main reason I am publishing this proposal in the mailing system is to
> gather feedback from the Java developers community, especially about
> possible caveats related to backward compatibility of your projects. Would
> appreciate every opinion!
>
> Best regards
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240423/83d2a036/attachment-0001.htm>

From pminborg at openjdk.org  Tue Apr 23 13:15:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 23 Apr 2024 13:15:30 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
Message-ID: <WJluiM0FQWMl1Qcd-vO1-1j19zPu7ZZqnzTwb5ylBEk=.7bd9f014-d4fc-451e-ad7c-8dab3969e5d2@github.com>

On Thu, 21 Mar 2024 18:01:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>> 
>> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Use the improved form in forEach
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Null checks should probably be in the beginning...
>  - mark implicit null checks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Copyright year, revert changes for non-few element collections
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Merge branch 'feature/imm-coll-stream' of https://github.com/liachmodded/jdk into feature/imm-coll-stream
>  - Spliterator for 12, iterate/forEach benchmark
>  - fix comments
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d5b95a0e...69bd0e9c

Do we need additional tests or are these modifications already covered by the existing tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2072289455

From ihse at openjdk.org  Tue Apr 23 13:41:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Apr 2024 13:41:34 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
Message-ID: <iPfTAOFpszIYzqx_KG49Na8tdzAQSGkHmuKunIDPDBI=.7c20c441-01fa-4917-a53b-95afdbc577e2@github.com>

On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove launcher executable path trace output

I agree; the launcher uses two different modes for discovery. If you want to troubleshoot, knowing which of these are attempted is helpful. 

@AlanBateman If this is not acceptable to add, I must once again iterate my question: What is the use case for the tracing functionality then?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2072349646

From duke at openjdk.org  Tue Apr 23 13:54:42 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:42 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with three additional commits since the last revision:

 - Added Objects import to sun List
 - Replaced on-demand import in com.sun....List
 - added non-null assertions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/de6e18e7..349ee6bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=10-11

  Stats: 29 lines in 8 files changed: 27 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
 <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>
Message-ID: <AfO9z_yJbNex4WQE2wfAdhONBy5z8g3jANcZXnUkWw0=.ef8fcd94-9e7c-4685-bcd2-0f3381058191@github.com>

On Fri, 19 Apr 2024 21:36:42 GMT, xxDark <duke at openjdk.org> wrote:

> I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.

Yeah, thats true. not sure if it has to throw NPE even if list is emply

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067350248

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (xxDark)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <AfO9z_yJbNex4WQE2wfAdhONBy5z8g3jANcZXnUkWw0=.ef8fcd94-9e7c-4685-bcd2-0f3381058191@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
 <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>
 <AfO9z_yJbNex4WQE2wfAdhONBy5z8g3jANcZXnUkWw0=.ef8fcd94-9e7c-4685-bcd2-0f3381058191@github.com>
Message-ID: <DAqbpSx_7kViagt7QXgN9nq_gMnS6wMGpvYLmJPVnw0=.690312db-6d76-4d74-8cf2-8c104339ab5b@github.com>

On Fri, 19 Apr 2024 22:20:48 GMT, Evemose <duke at openjdk.org> wrote:

> > I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.
> 
> Yeah, thats true. not sure if it has to throw NPE even if list is emply

Yes, it does. If it shouldn't, then why isn't code in the java.util.List is like this:

default int findIndex(Predicate<? super T> filter) {
	ListIterator<T> iterator = listIterator();
	if (!iterator.hasNext()) return -1;
	Objects.requireNonNull(filter);
	int index = 0;
	do {
		if (filter.test(iterator.next()))
			return index;
		index++;
	} while (iterator.hasNext());
	return -1;
}

Also see methods like `removveIf`. All methods should do checks even if they essentially do nothing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067354358

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
Message-ID: <oAk-msZ9ZOnUYgDlBRhg3HNxWulyaW5dAvCKBW7x8Rc=.e046fe83-fee9-4490-ba81-06a519f09f59@github.com>

On Fri, 19 Apr 2024 15:49:11 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted code style changes in Vector

> > > I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.
> > 
> > 
> > Yeah, thats true. not sure if it has to throw NPE even if list is emply
> 
> Yes, it does. If it shouldn't, then why isn't code in the java.util.List is like this:
> 
> ```java
> default int findIndex(Predicate<? super T> filter) {
> 	ListIterator<T> iterator = listIterator();
> 	if (!iterator.hasNext()) return -1;
> 	Objects.requireNonNull(filter);
> 	int index = 0;
> 	do {
> 		if (filter.test(iterator.next()))
> 			return index;
> 		index++;
> 	} while (iterator.hasNext());
> 	return -1;
> }
> ```
> 
> Also see methods like `removveIf`. All methods should do checks even if they essentially do nothing.

ok, i will fix this in a while

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067357432

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <DAqbpSx_7kViagt7QXgN9nq_gMnS6wMGpvYLmJPVnw0=.690312db-6d76-4d74-8cf2-8c104339ab5b@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
 <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>
 <AfO9z_yJbNex4WQE2wfAdhONBy5z8g3jANcZXnUkWw0=.ef8fcd94-9e7c-4685-bcd2-0f3381058191@github.com>
 <DAqbpSx_7kViagt7QXgN9nq_gMnS6wMGpvYLmJPVnw0=.690312db-6d76-4d74-8cf2-8c104339ab5b@github.com>
Message-ID: <ktLVMlLG87BOTOl0qzPZNUWZga6HTOYzFsmNCLS8x6w=.669e525b-acf3-4fd2-8c6b-ea2ad59092f8@github.com>

On Fri, 19 Apr 2024 22:27:15 GMT, xxDark <duke at openjdk.org> wrote:

>>> I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.
>> 
>> Yeah, thats true. not sure if it has to throw NPE even if list is emply
>
>> > I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.
>> 
>> Yeah, thats true. not sure if it has to throw NPE even if list is emply
> 
> Yes, it does. If it shouldn't, then why isn't code in the java.util.List is like this:
> 
> default int findIndex(Predicate<? super T> filter) {
> 	ListIterator<T> iterator = listIterator();
> 	if (!iterator.hasNext()) return -1;
> 	Objects.requireNonNull(filter);
> 	int index = 0;
> 	do {
> 		if (filter.test(iterator.next()))
> 			return index;
> 		index++;
> 	} while (iterator.hasNext());
> 	return -1;
> }
> 
> Also see methods like `removveIf`. All methods should do checks even if they essentially do nothing.

@xxDark Added null asserions everywhere except sublists that delegate execution to other lists, except for SynchroziedLsit so it doesnt acquire monitor with invalid predicate. I think this would be the best choice

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067762652

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v2]
In-Reply-To: <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
 <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>
Message-ID: <caLOGzz22aydXw3QajcmbXc_VzsPn7uWektkzCVYi9c=.9c71ee3d-cb92-4e4c-9ddf-69f287e713b5@github.com>

On Fri, 19 Apr 2024 12:10:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?
>
> @Evemose Please revert formatting changes in existing classes. Unfortunately there's no single code style across all of JDK, but you shouldn't try to format code/methods that's not touched by your new method addition.

@liach Seems like discussion in mails has came to some conclusion (or people just arent interested in it anymore). Therefore, i think its time to file for csr. Here is a draft request text, but Im not sure how to fill in some fields:
Summary: Add findIndex(Predicate) and findLastIndex(Predicate) to List
Problem: Modification of java.utilList interface by adding findIndex(Predicate) and findLastIndex(Predicate) methods might introduce behavioural or byteecode incompatibilities
Solution: // dont know what to write here tbh
Specification: // do i have to paste changed code here, or provide links, or what?
Alternatives: syntax line indexOf(Predicate) and lastIndexOf(Predicate) was concidered, but discarded due to behavioural incompatibilities with invokation indexOf(null)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2072079213

From liach at openjdk.org  Tue Apr 23 13:54:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Apr 2024 13:54:44 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
Message-ID: <psjMozqRXs2O-4JfHdX4nGN3DNvDT2ji_LkGsNBfgd0=.c17d4f2b-8c56-4411-9b74-df517553db62@github.com>

On Tue, 23 Apr 2024 13:51:54 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Added Objects import to sun List
>  - Replaced on-demand import in com.sun....List
>  - added non-null assertions

src/java.base/share/classes/java/util/LinkedList.java line 1507:

> 1505: 
> 1506:         public int findLastIndex(Predicate<? super E> filter) {
> 1507:             return rlist.findLastIndex(filter);

Hmm, this view is supposed to be reversed... so last and first need a swap. This is a bug in the current codebase, a good bug to fix indeed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1573456708

From liach at openjdk.org  Tue Apr 23 13:54:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Apr 2024 13:54:44 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <psjMozqRXs2O-4JfHdX4nGN3DNvDT2ji_LkGsNBfgd0=.c17d4f2b-8c56-4411-9b74-df517553db62@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
 <psjMozqRXs2O-4JfHdX4nGN3DNvDT2ji_LkGsNBfgd0=.c17d4f2b-8c56-4411-9b74-df517553db62@github.com>
Message-ID: <ntUATYnt_2faBDaVTQ8XQeM6_kisttUjgo97xtzQ8gI=.1d31af92-b479-41de-b7f0-67c1120115ba@github.com>

On Sat, 20 Apr 2024 23:11:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Added Objects import to sun List
>>  - Replaced on-demand import in com.sun....List
>>  - added non-null assertions
>
> src/java.base/share/classes/java/util/LinkedList.java line 1507:
> 
>> 1505: 
>> 1506:         public int findLastIndex(Predicate<? super E> filter) {
>> 1507:             return rlist.findLastIndex(filter);
> 
> Hmm, this view is supposed to be reversed... so last and first need a swap. This is a bug in the current codebase, a good bug to fix indeed.

Ignore my fault, it's just delegating methods to 2 different, already reversed views...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1573458008

From jwaters at openjdk.org  Tue Apr 23 14:00:38 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 23 Apr 2024 14:00:38 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis
Message-ID: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>

WIP

This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

-------------

Commit messages:
 - Implementation of hsdis for 8288293: Windows/gcc Port

Changes: https://git.openjdk.org/jdk/pull/18915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330988
  Stats: 347 lines in 28 files changed: 161 ins; 22 del; 164 mod
  Patch: https://git.openjdk.org/jdk/pull/18915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915

PR: https://git.openjdk.org/jdk/pull/18915

From alanb at openjdk.org  Tue Apr 23 14:10:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Apr 2024 14:10:30 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <T0TSnYbpR41LP2E33eSFApN5fX2Ok6Oo-bvvxLy9DEI=.ebd3cced-30a7-4f51-8a1c-45ad36c3862e@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
 <Pn-kFTRaSQ6zZEAFW72rzootAM3sSs-PnD21HBCn4Zg=.00979e95-518f-4c2e-afb6-f03f3b7071a4@github.com>
 <T0TSnYbpR41LP2E33eSFApN5fX2Ok6Oo-bvvxLy9DEI=.ebd3cced-30a7-4f51-8a1c-45ad36c3862e@github.com>
Message-ID: <FWznxBXkT4bhrtGVrRSjGF6nZPmQi1M_KgaSC20_A9c=.bb1621ad-5dab-4813-bc8a-661c1bc5acaf@github.com>

On Mon, 22 Apr 2024 11:57:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi, any additional comments / reviews ?
>> Thanks Matthias
>
>> Hi, any additional comments / reviews ? Thanks Matthias
> 
> It still looks like left over trace messages from a debugging session, need to think about about what tracing make sense here.

> @AlanBateman If this is not acceptable to add, I must once again iterate my question: What is the use case for the tracing functionality then?

The tracing was mostly for the options and timing when it was originally added.  I don't object to expanding the tracing. The issue is that the proposed additions are inconsistent with the existing trace messages, e.g.  GetJREPath's existing trace messages use "JRE path", the proposed messages switch to "JRE location".

BTW:  the vestiges of the "JRE" should really be removed. The GetJREPath function has no business looking for jre/lib as that location does not exist since JDK 9.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2072415065

From ihse at openjdk.org  Tue Apr 23 14:28:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Apr 2024 14:28:31 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>

On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

There's a huge amount of changes for just hsdis... You might have to separate out the infrastructure changes that seem to amount to most of the changes here.

This is going to take me a while to get through.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2072458273

From mbaesken at openjdk.org  Tue Apr 23 14:31:44 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Apr 2024 14:31:44 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v5]
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <gC_tj8pr-DjJpponY6WLeMAAMhrRObOyx5hgev_qd7s=.9fffb44f-129b-40f9-a50e-15db0cbf8faa@github.com>

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18699/files
  - new: https://git.openjdk.org/jdk/pull/18699/files/8b7a9d58..4d998244

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=03-04

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18699/head:pull/18699

PR: https://git.openjdk.org/jdk/pull/18699

From mbaesken at openjdk.org  Tue Apr 23 14:31:44 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Apr 2024 14:31:44 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
Message-ID: <XO3GjvTNzi6RAoxptfg1HhtZWQY5dN2dRjDNGRCy9z8=.21505b3a-57ef-4faa-9b77-525c97fa06d2@github.com>

On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove launcher executable path trace output

I adjusted the output ot 'JRE path' .

>  The GetJREPath function has no business looking for jre/lib as that location does not exist since JDK 9.

Is the at/below

`/* Does the app ship a private JRE in <apphome>/jre directory? */`

part meant? This looks indeed obsolete .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2072472623

From jwaters at openjdk.org  Tue Apr 23 14:34:27 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 23 Apr 2024 14:34:27 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>
Message-ID: <gC3MXf8nowx4TzNB4qHTC-fUoC-VTGMRn7EkZqsOLS0=.ab83679d-9b6c-4b86-ae74-3c0c05a44631@github.com>

On Tue, 23 Apr 2024 14:25:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There's a huge amount of changes for just hsdis... You might have to separate out the infrastructure changes that seem to amount to most of the changes here.
> 
> This is going to take me a while to get through.

Sorry, it's still a WIP, and I believe something broke and scattered changes from one of my other local branches into this current changeset

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2072483937

From acobbs at openjdk.org  Tue Apr 23 14:54:38 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Apr 2024 14:54:38 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v9]
In-Reply-To: <7xf3ZQti4nxv7QkxAkD20lNMcRS5GpAyARjbcErXyXA=.5234fab0-c950-4fa7-a3e1-7b4c9a0a6d7a@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
 <7xf3ZQti4nxv7QkxAkD20lNMcRS5GpAyARjbcErXyXA=.5234fab0-c950-4fa7-a3e1-7b4c9a0a6d7a@github.com>
Message-ID: <lpBMVQicAb4wHaAhzyNZL4nTiZ8clX3-0R_d6ss61Eo=.ad035b68-c162-4132-a374-7309b4f86bb2@github.com>

On Tue, 23 Apr 2024 12:49:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Archie Cobbs 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:
>> 
>>  - Merge branch 'master' into JDK-7036144
>>  - Back-out Javadoc addition; to be added in a separate issue.
>>  - Document the handling of concatenated streams.
>>  - Merge branch 'master' into JDK-7036144
>>  - Merge branch 'master' into JDK-7036144
>>  - Merge branch 'master' into JDK-7036144
>>  - Address third round of review comments.
>>  - Address second round of review comments.
>>  - Address review comments.
>>  - Fix bug in GZIPInputStream when underlying available() returns short.
>
> Hello Archie, we forgot to create a release note for this one (there's still time). Would you be willing to create one, following the instructions here https://openjdk.org/guide/#release-notes? If you need any help, let us know. One of us will review that release note before you can Resolve it to Delivered.

Hi @jaikiran,

No problem - please see [JDK-8330995](https://bugs.openjdk.org/browse/JDK-8330995) and let me know if anything else is needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2072563144

From liach at openjdk.org  Tue Apr 23 16:07:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Apr 2024 16:07:29 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <WJluiM0FQWMl1Qcd-vO1-1j19zPu7ZZqnzTwb5ylBEk=.7bd9f014-d4fc-451e-ad7c-8dab3969e5d2@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
 <WJluiM0FQWMl1Qcd-vO1-1j19zPu7ZZqnzTwb5ylBEk=.7bd9f014-d4fc-451e-ad7c-8dab3969e5d2@github.com>
Message-ID: <RllzXVb1iOH2kDwSuZIoJVj693XOyFEkpF6Om1vzaas=.f1458add-4f48-4a4f-8794-95af0be9813b@github.com>

On Tue, 23 Apr 2024 13:13:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Do we need additional tests or are these modifications already covered by the existing tests?

Thanks for the note, upon review it seems the default method overrides aren't covered by existing Collection tests. I should add them to ensure the single/double element List/Set are tested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2072824367

From alanb at openjdk.org  Tue Apr 23 16:10:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Apr 2024 16:10:29 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>
Message-ID: <PxAXBDKAD3I_TuonCTyL5cgOfFevrj7fqAnf5914x34=.7493eaa1-75ba-4469-80d2-0ff6dba158ed@github.com>

On Tue, 23 Apr 2024 11:16:01 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct ID in test @bug tag
>
> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
> 
>> 162:     public void writeTo(OutputStream out) throws IOException {
>> 163:         if (Thread.currentThread().isVirtual()) {
>> 164:             out.write(toByteArray());
> 
> Would it be better to avoid calling a public method `toByteArray` encase subclass is overriding it?

A good question. The buf/count fields are protected so the subclass has direct access to the bytes. So while it could Arrays.copy the bytes, it doesn't help with a buggy subclass that is changing bytes while synchronization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1576523112

From alanb at openjdk.org  Tue Apr 23 16:12:34 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Apr 2024 16:12:34 GMT
Subject: Integrated: 8329593: Drop adjustments to target parallelism when
 virtual threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <QVHrpvn_QcrlxtgtnNksCzYq5HfWB5hbS2lYAdCeR9o=.3ae2fd39-7131-439b-ab7a-78a4ab80d51f@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in loom repo for some time.

This pull request has now been integrated.

Changeset: 412e306d
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/412e306d81209c05f55aee7663f7abb80286e361
Stats:     1084 lines in 28 files changed: 215 ins; 624 del; 245 mod

8329593: Drop adjustments to target parallelism when virtual threads do I/O on files opened for buffered I/O

Reviewed-by: bpb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/18598

From bpb at openjdk.org  Tue Apr 23 16:40:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Apr 2024 16:40:33 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <ELfitihzx8ne8twVUMqNfB3704i0le6CkUpcBwuONuI=.fb4c9d46-a6e8-412e-9100-340c3aea8ff7@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
 <03havZuXU3rRqqFBvZbQBiPCEZqGiNAZhosgXPmsBOs=.9ede81af-6aa9-4167-9fc5-5c9cd98969c2@github.com>
 <ELfitihzx8ne8twVUMqNfB3704i0le6CkUpcBwuONuI=.fb4c9d46-a6e8-412e-9100-340c3aea8ff7@github.com>
Message-ID: <03_OsWfkX-FXOY2u43wIHhSvJZ3rF3CqV5VJfdnA-ao=.113839a2-147e-42c1-8e7b-5e0d2ca02aa7@github.com>

On Tue, 23 Apr 2024 08:09:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileInputStream.java line 211:
>> 
>>> 209:      * @param name the name of the file
>>> 210:      */
>>> 211:     private void open(String name) throws FileNotFoundException {
>> 
>> If method such as this is private, and only delegates to the 0-suffixed native method, would't it be better to just call the 0-suffixed method directly?
>
> Historically these native methods were wrapped in order to support instrumentation, I didn't want to touch in this PR.

And presumably all these 0-suffixed methods will eventually be replaced with FFM calls anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1576561165

From duke at openjdk.org  Tue Apr 23 17:38:31 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Tue, 23 Apr 2024 17:38:31 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <PxAXBDKAD3I_TuonCTyL5cgOfFevrj7fqAnf5914x34=.7493eaa1-75ba-4469-80d2-0ff6dba158ed@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>
 <PxAXBDKAD3I_TuonCTyL5cgOfFevrj7fqAnf5914x34=.7493eaa1-75ba-4469-80d2-0ff6dba158ed@github.com>
Message-ID: <QkHuWdLgnhfh_fdf8PcihECq7m13uQ-AbFOefsJBGMI=.19d83752-5c8d-4f50-9d53-2d1894bf2543@github.com>

On Tue, 23 Apr 2024 16:08:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>> 
>>> 162:     public void writeTo(OutputStream out) throws IOException {
>>> 163:         if (Thread.currentThread().isVirtual()) {
>>> 164:             out.write(toByteArray());
>> 
>> Would it be better to avoid calling a public method `toByteArray` encase subclass is overriding it?
>
> A good question. The buf/count fields are protected so the subclass has direct access to the bytes. So while it could Arrays.copy the bytes, it doesn't help with a buggy subclass that is changing bytes while synchronization.

I was thinking more of a subclass that counted invocations to public methods or metering which would cause subclass to double the counts when calling via virtual thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1576637177

From bpb at openjdk.org  Tue Apr 23 18:11:29 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Apr 2024 18:11:29 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <QkHuWdLgnhfh_fdf8PcihECq7m13uQ-AbFOefsJBGMI=.19d83752-5c8d-4f50-9d53-2d1894bf2543@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>
 <PxAXBDKAD3I_TuonCTyL5cgOfFevrj7fqAnf5914x34=.7493eaa1-75ba-4469-80d2-0ff6dba158ed@github.com>
 <QkHuWdLgnhfh_fdf8PcihECq7m13uQ-AbFOefsJBGMI=.19d83752-5c8d-4f50-9d53-2d1894bf2543@github.com>
Message-ID: <3S8kR1JCUOVEEYIH1qhEkYesSDXosbI5hQ9uIEr-Sbk=.d992e898-4085-4d72-a94c-2ff07e6fb977@github.com>

On Tue, 23 Apr 2024 17:35:42 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> A good question. The buf/count fields are protected so the subclass has direct access to the bytes. So while it could Arrays.copy the bytes, it doesn't help with a buggy subclass that is changing bytes without synchronization.
>
> I was thinking more of a subclass that counted invocations to public methods or metering which would cause subclass to double the counts when calling via virtual thread.

So do we think it better not to invoke `toByteArray` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1576686390

From mchung at openjdk.org  Tue Apr 23 18:19:29 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 23 Apr 2024 18:19:29 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v6]
In-Reply-To: <vPR0NJdw8vtr8S2wolfVqEZEbzTWJikDJn7l2QVv1Yk=.6f614488-f841-48ec-85ce-44f0820929af@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <3m2NeLy-0IjoU414JSSzSSUaLfauwUAXbIQ8ueofgsE=.d2e3d01e-e580-4368-9bdb-8d7b4b54af01@github.com>
 <vPR0NJdw8vtr8S2wolfVqEZEbzTWJikDJn7l2QVv1Yk=.6f614488-f841-48ec-85ce-44f0820929af@github.com>
Message-ID: <tbOiomk49TcTkO1AAOzqDwcnv1AZNDp1fn_1ZKxV9Mo=.03392f12-387b-460c-8fbd-4eceedfa41c7@github.com>

On Mon, 22 Apr 2024 08:59:33 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> @mlchung @asotona: Alan asked me to use the ClassFile API here. As it's only used in what's effectively a slow path it shouldn't be blocked by the startup investigations we're doing there, right?

I agree that this should not be blocked by the startup investigation for ClassFile API.  It only affects high arity expressions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2073085437

From szaldana at openjdk.org  Tue Apr 23 18:21:42 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 23 Apr 2024 18:21:42 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v4]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <uXrKbWr_sbGY74QJdjkcvNOZkMPiB8kuZSjz8HtS8mY=.101cb1e1-161a-4daf-bf96-90543a9387e6@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:

  Changes based on feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/79c70343..66942238

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=02-03

  Stats: 65 lines in 2 files changed: 8 ins; 7 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/18786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786

PR: https://git.openjdk.org/jdk/pull/18786

From szaldana at openjdk.org  Tue Apr 23 18:24:30 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 23 Apr 2024 18:24:30 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <JGexro9ukP8dyTCTNxYkhnde73SLC7def5rZBIFIuzg=.9ce10baf-a892-4b85-a570-f614978ef729@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <61FmMvHyAQXcl_ZWYGEWwLDU7O8a-vdHTlu56rnKzqo=.cd118172-6497-4963-ad3b-b8f865009638@github.com>
 <Nvef5H6yg7TlYjDyCTYh1qTZoZB4B2nYvmV1d6BCnxs=.62b96873-a553-4c95-8a5a-eaf2fb6bc8a2@github.com>
 <JGexro9ukP8dyTCTNxYkhnde73SLC7def5rZBIFIuzg=.9ce10baf-a892-4b85-a570-f614978ef729@github.com>
Message-ID: <yC-vO8l_RPw8Nz94rBeiKyyq44Fb8xnL0eF6ZHfxmD0=.12c4264c-5268-483d-8808-36f286efec76@github.com>

On Fri, 19 Apr 2024 17:04:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @lahodaj 
>> 
>>> I would suggest to take the test from 18753 though - doing a change like this without a test may lead to hard-to-find regressions in the future. (Note the current test should guard against both JDK-8329420 and JDK-8329581.)
>> 
>> Agreed. I?ll add the test case if this PR proceeds (see my comment above). 
>> 
>>> as Mandy points out, `LaucherHelper` already reads/has variables for "is-static" and "no-arguments" in `validateMainMethod`, so it should be possible to just use that values; 
>> 
>> Just to clarify, this would still mean converting ?isStatic? and ?noArgs? from local variables to fields so I am able to read them on the C side of things. Did I understand this correctly?
>> 
>>> also as Mandy points out, we can probably get rid of `CHECK_EXCEPTION_FAIL` and `CHECK_EXCEPTION_NULL_FAIL`, and use the `..._LEAVE` variants, no? (The `..._FAIL` variants where needed so that the launcher could continue with the next variant, but since we now only call the correct variant, we can just stop if something goes wrong?)
>> 
>> Agreed, I?ve updated that on my side of things.
>
>> Just to clarify, this would still mean converting ?isStatic? and ?noArgs? from local variables to fields so I am able to read them on the C side of things. Did I understand this correctly?
> 
> I'm okay with adding static boolean fields and read by the native code and the name can be explicit like `isStaticMain` and `mainWithNoArg`.

Hi @mlchung, thanks for the feedback! I?ve pushed the updates.

Just a question about ```NULL_CHECK0```. 

```NULL_CHECK0``` reports the error message and then the exception is described in ```CHECK_EXCEPTION_LEAVE```. This results in a stack trace that looks like this: 


Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: DemoSonia$SomeDependency
	at DemoSonia.<clinit>(DemoSonia.java:3)
Caused by: java.lang.ClassNotFoundException: DemoSonia$SomeDependency
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)
	... 1 more



The JNI error message didn?t previously get reported before the regression was introduced, so I just wanted to make sure we were okay with this. 

Looking forward to your comments!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2073092870

From duke at openjdk.org  Tue Apr 23 18:45:30 2024
From: duke at openjdk.org (Bernd)
Date: Tue, 23 Apr 2024 18:45:30 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <yC-vO8l_RPw8Nz94rBeiKyyq44Fb8xnL0eF6ZHfxmD0=.12c4264c-5268-483d-8808-36f286efec76@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <61FmMvHyAQXcl_ZWYGEWwLDU7O8a-vdHTlu56rnKzqo=.cd118172-6497-4963-ad3b-b8f865009638@github.com>
 <Nvef5H6yg7TlYjDyCTYh1qTZoZB4B2nYvmV1d6BCnxs=.62b96873-a553-4c95-8a5a-eaf2fb6bc8a2@github.com>
 <JGexro9ukP8dyTCTNxYkhnde73SLC7def5rZBIFIuzg=.9ce10baf-a892-4b85-a570-f614978ef729@github.com>
 <yC-vO8l_RPw8Nz94rBeiKyyq44Fb8xnL0eF6ZHfxmD0=.12c4264c-5268-483d-8808-36f286efec76@github.com>
Message-ID: <Lhu_6cy7MQrzMIjFQDghdjVq_jVnzGxEXC2TW6xNKyI=.e9bfc555-9059-4648-b15a-6805322f604e@github.com>

On Tue, 23 Apr 2024 18:21:30 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> The JNI error message didn?t previously get reported before the regression was introduced, so I just wanted to make sure we were okay with this.

I think such errors have a very high potential to confuse the hell out of the poor ops people looking for binary corruptions and stuff when it?s ?only? a regular Java level error condition. So I think it should not talk about JNI in this case (even when the rest of the exception makes it obvious)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2073171918

From jjg at openjdk.org  Tue Apr 23 18:46:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 18:46:34 GMT
Subject: Integrated: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <Hf-QMEmB4eLr-CA0UEIiWRwxxplcD-ZKUVbOJ44BPsc=.20073ab8-4ece-463c-a4e4-afdba6586f28@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

This pull request has now been integrated.

Changeset: 9cc163a9
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9cc163a999eb8e9597d45b095b642c25071043bd
Stats:     134 lines in 23 files changed: 50 ins; 56 del; 28 mod

8330178: Clean up non-standard use of /** comments in `java.base`

Reviewed-by: darcy, iris, dfuchs, aivanov, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18846

From mchung at openjdk.org  Tue Apr 23 18:49:30 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 23 Apr 2024 18:49:30 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v4]
In-Reply-To: <uXrKbWr_sbGY74QJdjkcvNOZkMPiB8kuZSjz8HtS8mY=.101cb1e1-161a-4daf-bf96-90543a9387e6@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <uXrKbWr_sbGY74QJdjkcvNOZkMPiB8kuZSjz8HtS8mY=.101cb1e1-161a-4daf-bf96-90543a9387e6@github.com>
Message-ID: <xxKavpHzJDsjtMQCX4TkjGR87LqV9OE2RaDUssoYNIE=.211b8993-1bfb-44b8-abeb-8fb4fa11137c@github.com>

On Tue, 23 Apr 2024 18:21:42 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes based on feedback

I missed that `NULL_CHECK0` prints that JNI error, sorry.  We should avoid using it then.   What do you think having a check macro to return 0 if exception occurred or the given object is null?   No exception cleared as it will be described in JavaMain.


#define CHECK_EXCEPTION_NULL_FAIL(obj) \
    do { \
        if ((*env)->ExceptionOccurred(env)) { \
            return 0; \
        } else if (obj == NULL) { \
            return 0; \
        } \
    } while (JNI_FALSE)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2073184282

From mullan at openjdk.org  Tue Apr 23 18:53:29 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 23 Apr 2024 18:53:29 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v4]
In-Reply-To: <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
Message-ID: <-T6DkIlqo7mrLr5h_mNTdO1ffZOTPfwIyNw14QNQGUE=.d8171909-e6d1-4e9f-99f5-a6650bd8cf5b@github.com>

On Fri, 19 Apr 2024 21:55:09 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes description of jaxp-compat and jaxp-strict after discussing with Lance

It might just be me, but the word "sample" is too related to programming examples that it makes this feel like something that users may not take seriously. But I think this is something that you really want users to take seriously and try out. Perhaps just drop the word "sample"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2073191426

From mullan at openjdk.org  Tue Apr 23 19:00:29 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 23 Apr 2024 19:00:29 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v4]
In-Reply-To: <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
Message-ID: <Z-826DUQkeBqsX1w1082b3BYgvv_1RtlyOOmASoI-b8=.d71d1637-6173-4088-bbc8-fcac6b4f43ad@github.com>

On Fri, 19 Apr 2024 21:55:09 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes description of jaxp-compat and jaxp-strict after discussing with Lance

A few other comments/questions:

Does this need a CSR since you are adding new property files?

Are there any tests to ensure the property files are working correctly?

Also, how does one try out these property files? Is there a system property that needs to be set? Can you add more details to the RN on that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2073203196

From lancea at openjdk.org  Tue Apr 23 19:09:31 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 23 Apr 2024 19:09:31 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v4]
In-Reply-To: <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
Message-ID: <O_pbXacuEdWODodxzBZYTmijSs-9Rzr4XtWU1yw16bw=.9d1aeffb-ef3c-440c-bd48-9ebf59f2ec6a@github.com>

On Fri, 19 Apr 2024 21:55:09 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes description of jaxp-compat and jaxp-strict after discussing with Lance

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2018094529

From lancea at openjdk.org  Tue Apr 23 19:28:30 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 23 Apr 2024 19:28:30 GMT
Subject: RFR: 8330542: Add two sample configuration files in preparation
 for a more secure by default configuration [v4]
In-Reply-To: <Z-826DUQkeBqsX1w1082b3BYgvv_1RtlyOOmASoI-b8=.d71d1637-6173-4088-bbc8-fcac6b4f43ad@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
 <Z-826DUQkeBqsX1w1082b3BYgvv_1RtlyOOmASoI-b8=.d71d1637-6173-4088-bbc8-fcac6b4f43ad@github.com>
Message-ID: <tSGPaSgL99x4g6cjVsyhphxVOcfSKVjmvyxXP0igkss=.cda28f0f-486c-47e7-9dc6-b20727a45546@github.com>

On Tue, 23 Apr 2024 18:57:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> A few other comments/questions:
> 
> Does this need a CSR since you are adding new property files?

Not sure it does, but Joe will follow up with Joe Darcy
> 
> Are there any tests to ensure the property files are working correctly?

There are tests that Joe added as part of the JDK 22 work for custom config files
> 
> Also, how does one try out these property files? Is there a system property that needs to be set? Can you add more details to the RN on that?

java -Djava.xml.config.file=$JAVA_HOME/conf/jaxp-compat.properties

The property was added in JDK 22 see: https://docs.oracle.com/en/java/javase/22/docs/api/java.xml/module-summary.html#Conf_CF_SP

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2073248701

From shade at openjdk.org  Tue Apr 23 19:40:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Apr 2024 19:40:29 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v6]
In-Reply-To: <3m2NeLy-0IjoU414JSSzSSUaLfauwUAXbIQ8ueofgsE=.d2e3d01e-e580-4368-9bdb-8d7b4b54af01@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <3m2NeLy-0IjoU414JSSzSSUaLfauwUAXbIQ8ueofgsE=.d2e3d01e-e580-4368-9bdb-8d7b4b54af01@github.com>
Message-ID: <CkGFsk69xak9u6NVjqtKrHgH6FIFUJLrC9daKL37rmU=.b1a5ec2e-40aa-47ea-9603-628685290b3a@github.com>

On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor SimpleStringBuilderStrategy::<clinit> overhead reduction

I really wish this change was not done with ClassFile API, but with a simple bundled ASM, so it would be easily backportable, if we decide to. It does not look like CFA buys us a lot here readability/complexity wise: https://github.com/openjdk/jdk/pull/18690/commits/d99b1596c5ca57b110c1db88be430c6c54c3d599

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2073284920

From jlahoda at openjdk.org  Tue Apr 23 20:06:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 23 Apr 2024 20:06:43 GMT
Subject: RFR: 8328481: Implement Module Imports [v12]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <-ouD9nIv2qwF1P1KJmrFi8K-WKx3wdrzx4qcT5BxN6M=.19abc97e-05b9-47ac-8620-aa0121bbb27c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing Imports test on Windows.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/cbc363ab..1a621447

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=10-11

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

PR: https://git.openjdk.org/jdk/pull/18614

From ascarpino at openjdk.org  Tue Apr 23 20:09:30 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 23 Apr 2024 20:09:30 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v3]
In-Reply-To: <-64Xlhk6ln43-xTmlv_cvloS-gzDrKMyiPUdPbMNlIM=.2b524654-ca5b-4a7a-a7da-316e99cfea35@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <-64Xlhk6ln43-xTmlv_cvloS-gzDrKMyiPUdPbMNlIM=.2b524654-ca5b-4a7a-a7da-316e99cfea35@github.com>
Message-ID: <emmi01IrP7E6eQWjWoQIm1hZKqnAsMasII_lgAUSVro=.20a4a8c0-2c37-4466-b123-77c7f2f1978c@github.com>

On Mon, 15 Apr 2024 22:12:30 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments from Jatin and Tony

src/java.base/share/classes/sun/security/ec/ECOperations.java line 204:

> 202:      * @return the product
> 203:      */
> 204:     public MutablePoint multiply(AffinePoint affineP, byte[] s) {

It seems like there could be some combining of both `multiply()`.  If `multiply(AffinePoint, ...)` is called, it can call `DefaultMultiplier` with the `affineP`, but internally call the other `multiply(ECPoint, ...)` for the other situations.  I'd rather not have two methods doing most of the same code, but different methods.

src/java.base/share/classes/sun/security/ec/ECOperations.java line 467:

> 465:     sealed static abstract class SmallWindowMultiplier implements PointMultiplier
> 466:         permits DefaultMultiplier, DefaultMontgomeryMultiplier {
> 467:         private final AffinePoint affineP;

I don't think `affineP` needs to be a class variable anymore.  It's only used in the constructor

src/java.base/share/classes/sun/security/ec/ECOperations.java line 592:

> 590:         }
> 591: 
> 592:         private final ProjectivePoint.Immutable[][] points;

Can you define this at the top please.

src/java.base/share/classes/sun/security/ec/ECOperations.java line 668:

> 666:         }
> 667: 
> 668:         private final BigInteger[] base;

Can you define this at the top.  You use it in the constructor but it's defined later on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1576821201
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1575499019
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1575495263
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1575491814

From ascarpino at openjdk.org  Tue Apr 23 20:09:32 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 23 Apr 2024 20:09:32 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
Message-ID: <BehQ1WJbv6EvBcC5JovQec15Waqqv1W2ZLCluZvRlwU=.69b4cf32-0c2d-4df5-953d-22f72a4aa7aa@github.com>

On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove use of jdk.crypto.ec

src/java.base/share/classes/sun/security/ec/ECOperations.java line 308:

> 306: 
> 307:     /*
> 308:      * public Point addition. Used by ECDSAOperations

Was the old description not applicable anymore?   It would be nice to improve on the existing description that shortening it.

src/java.base/share/classes/sun/security/ec/ECOperations.java line 321:

> 319:         ECOperations ops = this;
> 320:         if (this.montgomeryOps != null) {
> 321:             assert p.getField() instanceof IntegerMontgomeryFieldModuloP;

This should throw a ProviderException, I believe this would throw an AssertionException

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1556740469
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1558824543

From jjg at openjdk.org  Tue Apr 23 20:26:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 20:26:57 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v7]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <RHregxT5ye-XTQEWzPqLPVZXgm2Id82FV--QqNLAJMc=.4c5c4e64-3a6c-438f-a877-e6f9689986fd@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons 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 with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

-------------

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=06
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From duke at openjdk.org  Tue Apr 23 20:35:33 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 23 Apr 2024 20:35:33 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
Message-ID: <-0V3ZTaf1NcBXcx0uNaIwPEx8VH5fR0b8avQZTaxr2E=.d258b611-d6ab-4271-acd3-9a802026fe12@github.com>

On Tue, 23 Apr 2024 13:54:42 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Added Objects import to sun List
>  - Replaced on-demand import in com.sun....List
>  - added non-null assertions

These?can be?`private` as?they?re not?used?outside the?`ArrayList` class?nest:

src/java.base/share/classes/java/util/ArrayList.java line 324:

> 322:     }
> 323: 
> 324:     int findIndexInRange(Predicate<? super E> filter, int start, int end) {

Suggestion:

    private int findIndexInRange(Predicate<? super E> filter, int start, int end) {

src/java.base/share/classes/java/util/ArrayList.java line 380:

> 378:     }
> 379: 
> 380:     int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {

Suggestion:

    private int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {

-------------

PR Review: https://git.openjdk.org/jdk/pull/18639#pullrequestreview-2018246257
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1576858232
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1576858391

From mchung at openjdk.org  Tue Apr 23 20:56:30 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 23 Apr 2024 20:56:30 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v6]
In-Reply-To: <3m2NeLy-0IjoU414JSSzSSUaLfauwUAXbIQ8ueofgsE=.d2e3d01e-e580-4368-9bdb-8d7b4b54af01@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <3m2NeLy-0IjoU414JSSzSSUaLfauwUAXbIQ8ueofgsE=.d2e3d01e-e580-4368-9bdb-8d7b4b54af01@github.com>
Message-ID: <_9DDdZKZ9GnprtmvB0TIAbSZZoQgV-1CFq8AqSRMuOQ=.26f0d7ea-d672-420e-997a-bb861c71d1b9@github.com>

On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor SimpleStringBuilderStrategy::<clinit> overhead reduction

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1108:

> 1106:                 DUMPER.dumpClass(innerClass.getName(), innerClass, classBytes);
> 1107:                 MethodHandle mh = hiddenLookup.findStatic(innerClass, METHOD_NAME, args);
> 1108:                 return mh;

An alternative way to define a hidden class that will detect if the dumper is enabled and dump the classfile. 

Suggestion:

                Lookup hiddenLookup = lookup.makeHiddenClassDefiner(className, classBytes, Set.of(STRONG), DUMPER)
                                            .defineClassAsLookup(true);
                Class<?> innerClass = hiddenLookup.lookupClass();
                return hiddenLookup.findStatic(innerClass, METHOD_NAME, args);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1576880600

From jlu at openjdk.org  Tue Apr 23 21:13:33 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Apr 2024 21:13:33 GMT
Subject: Integrated: 8329222: java.text.NumberFormat (and subclasses) spec
 updates
In-Reply-To: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
References: <zgxPjUJ6o5HQp2yvdOAGeYfX3ml1OFzQTgu0qnA1fh4=.7ff0d8fe-13cb-45e7-9ed3-d0e24c5cc8d2@github.com>
Message-ID: <s72vcSF0sHnV9yELRvcrmSkXzvZPzrfgTxt7Q1yJQNo=.69a1a6cf-79e3-4682-b024-5e2a9df23f51@github.com>

On Wed, 10 Apr 2024 20:16:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a large spec reformatting for _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat and CompactNumberFormat.
> 
> The motivation for this change was the difficulty of readability for these classes. This PR consists of changes such as better separating the text into sections with headers, advising to skip the pattern related sections if not needed, and general wording improvements.
> 
> To help with reviewing I have attached a [specdiff](https://cr.openjdk.org/~jlu/JDK-8329222/java.base/java/text/package-summary.html) as well as the built docs: [nFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/NumberFormat.html), [dFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/DecimalFormat.html), and [cnFmt](https://cr.openjdk.org/~jlu/api/java.base/java/text/CompactNumberFormat.html);
> 
> I will update the CSR once the wording is finalized.

This pull request has now been integrated.

Changeset: f60798a3
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f60798a30e9a3e0b666fed5384b6ac92a8a283dd
Stats:     598 lines in 3 files changed: 234 ins; 204 del; 160 mod

8329222: java.text.NumberFormat (and subclasses) spec updates

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18731

From bchristi at openjdk.org  Tue Apr 23 21:46:58 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 23 Apr 2024 21:46:58 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v24]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <SpaKOhzknZ3HjItuj5eCLJwkXI_zq8gTlElSn_ZoZPs=.c5cc1020-9770-4786-8499-6e42c85f7d33@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  move reachability section before notification; update section header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/27d0c249..cc21d296

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=22-23

  Stats: 67 lines in 1 file changed: 33 ins; 33 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From duke at openjdk.org  Wed Apr 24 00:48:59 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 24 Apr 2024 00:48:59 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v17]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <MirysJQWI4HKe8tdyPz3wkSqa0FK2qhKXuvsfmeKthY=.8934a721-5129-45eb-bc77-fcd7ce2ba655@github.com>

> The current BigDecimal(String) constructor calls String#toCharArray, which has a memory allocation.
> 
> 
> public BigDecimal(String val) {
>     this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
> 
> 
> When the length is greater than 18, create a char[]
> 
> 
> boolean isCompact = (len <= MAX_COMPACT_DIGITS); // 18
> if (!isCompact) {
>     // ...
> } else {
>     char[] coeff = new char[len]; // allocate char[]
>     // ...
> }
> 
> 
> This PR eliminates the two memory allocations mentioned above, resulting in an approximate 60% increase in performance..

Shaojin Wen 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 21 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_dec_new
 - use while instead for
 - Update src/java.base/share/classes/java/math/BigDecimal.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - bug fix for CharArraySequence#charAt
 - bug fix for CharArraySequence
 - fix benchmark
 - one CharArraySequence
 - restore comment
 - easier to compare
 - fix CharArraySequence
 - ... and 11 more: https://git.openjdk.org/jdk/compare/886ef758...e516b580

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/17f0a736..e516b580

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=15-16

  Stats: 562957 lines in 6174 files changed: 85928 ins; 137051 del; 339978 mod
  Patch: https://git.openjdk.org/jdk/pull/18177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18177/head:pull/18177

PR: https://git.openjdk.org/jdk/pull/18177

From bpb at openjdk.org  Wed Apr 24 01:04:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Apr 2024 01:04:05 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v3]
In-Reply-To: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
Message-ID: <rYu6y3x-57Vym8XhGmRsTqBfuxDj8kK_JeS6nB8aJ58=.bd12e827-b12c-40d6-9c69-df65134fcedf@github.com>

> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8330748: Add vthread1.join() in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18901/files
  - new: https://git.openjdk.org/jdk/pull/18901/files/57e4917b..1dd59b7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18901&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18901&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18901/head:pull/18901

PR: https://git.openjdk.org/jdk/pull/18901

From bpb at openjdk.org  Wed Apr 24 01:04:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Apr 2024 01:04:05 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <JGki7Ey_BynKfNPoH4GavyoMVXBJKw8p0-G1x6hK1no=.7ad2a13c-e41d-4cd4-9cea-773d78ff4d52@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <JGki7Ey_BynKfNPoH4GavyoMVXBJKw8p0-G1x6hK1no=.7ad2a13c-e41d-4cd4-9cea-773d78ff4d52@github.com>
Message-ID: <my8TLiqnQ5AMM1XE6zk-sB0vrH1L8z_8n4B29psyU3U=.c437f6a7-4d6b-4acb-b978-99c227f8f877@github.com>

On Tue, 23 Apr 2024 06:20:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct ID in test @bug tag
>
> test/jdk/java/io/ByteArrayOutputStream/WriteToReleasesCarrier.java line 78:
> 
>> 76:                 }
>> 77:             } finally {
>> 78:                 LockSupport.unpark(vthread1);
> 
> It might be clearer if you add vthread1.join() after the unpark. It's not strictly needed here as scheduler::close will block until the carrier terminates so that will guarantee that the virtual thread has unmounted.

Added `vthread1.join()` after the unpark in 1dd59b7bf7aa2087845ad7806a5afbed2b5ea1b5.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1577076109

From jpai at openjdk.org  Wed Apr 24 06:09:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Apr 2024 06:09:30 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v2]
In-Reply-To: <4WzkMQNiIjXh7EbjSbKgL71Xlw34jUF-pRJ1989m5kg=.b387fbd7-d191-4bd6-9429-f36a3806c93e@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <4WzkMQNiIjXh7EbjSbKgL71Xlw34jUF-pRJ1989m5kg=.b387fbd7-d191-4bd6-9429-f36a3806c93e@github.com>
Message-ID: <tLtf7BJlA7-K4rm6Oyqcs97yxfXBRNxtzk5qyPypYG0=.dd1b8bb9-d7b6-4011-8de7-351a0c969200@github.com>

On Tue, 23 Apr 2024 09:32:40 GMT, Jin Kwon <duke at openjdk.org> wrote:

>> Fix typos within the `DatabaseMetaData.java`.
>
> Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [JDK-8330686] Update copyright year

Thank you for the update. The changes look fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18860#pullrequestreview-2018924833

From alanb at openjdk.org  Wed Apr 24 07:10:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Apr 2024 07:10:27 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <3S8kR1JCUOVEEYIH1qhEkYesSDXosbI5hQ9uIEr-Sbk=.d992e898-4085-4d72-a94c-2ff07e6fb977@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>
 <PxAXBDKAD3I_TuonCTyL5cgOfFevrj7fqAnf5914x34=.7493eaa1-75ba-4469-80d2-0ff6dba158ed@github.com>
 <QkHuWdLgnhfh_fdf8PcihECq7m13uQ-AbFOefsJBGMI=.19d83752-5c8d-4f50-9d53-2d1894bf2543@github.com>
 <3S8kR1JCUOVEEYIH1qhEkYesSDXosbI5hQ9uIEr-Sbk=.d992e898-4085-4d72-a94c-2ff07e6fb977@github.com>
Message-ID: <dDMFmXOQple4ByVYQ_A06qjb_9EBEPami7F9hIzCsW8=.3a3a7556-1a15-4468-9287-fd387486200f@github.com>

On Tue, 23 Apr 2024 18:08:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I was thinking more of a subclass that counted invocations to public methods or metering which would cause subclass to double the counts when calling via virtual thread.
>
> So do we think it better not to invoke `toByteArray` here?

Using a subclass to count the number of invocations of toByteArray seems a bit strange but in general it is more robust to not rely on a method that may be overridden by a subclass. So I think the suggestion is good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1577388594

From duke at openjdk.org  Wed Apr 24 08:32:37 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 24 Apr 2024 08:32:37 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <-0V3ZTaf1NcBXcx0uNaIwPEx8VH5fR0b8avQZTaxr2E=.d258b611-d6ab-4271-acd3-9a802026fe12@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
 <-0V3ZTaf1NcBXcx0uNaIwPEx8VH5fR0b8avQZTaxr2E=.d258b611-d6ab-4271-acd3-9a802026fe12@github.com>
Message-ID: <dQpbKfwIB2lTj3HPrHmT-ts4LhUvA2LiHWJvEl3j71o=.0dade48e-407e-4f81-8002-23c3f705d106@github.com>

On Tue, 23 Apr 2024 20:30:22 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Added Objects import to sun List
>>  - Replaced on-demand import in com.sun....List
>>  - added non-null assertions
>
> src/java.base/share/classes/java/util/ArrayList.java line 380:
> 
>> 378:     }
>> 379: 
>> 380:     int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {
> 
> Suggestion:
> 
>     private int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {

Yeah i though about it but indexOfRange arent private here so either there is a point in it or its just legacy without any particular meaning

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1577501340

From duke at openjdk.org  Wed Apr 24 08:54:53 2024
From: duke at openjdk.org (Jin Kwon)
Date: Wed, 24 Apr 2024 08:54:53 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v3]
In-Reply-To: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
Message-ID: <hic8RDyVJogp_RyJKZuVFh2SM5TD2LeSd33TSJQwO0M=.2a0c300f-e985-4079-a74a-9ef486a9e57e@github.com>

> Fix typos within the `DatabaseMetaData.java`.

Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:

  8330686: Fix typos in the DatabaseMetaData javadoc
  
  Reviewed-by: jpai

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18860/files
  - new: https://git.openjdk.org/jdk/pull/18860/files/75f0b111..c8cf9728

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18860&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18860&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18860/head:pull/18860

PR: https://git.openjdk.org/jdk/pull/18860

From thartmann at openjdk.org  Wed Apr 24 09:08:43 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 24 Apr 2024 09:08:43 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory [v26]
In-Reply-To: <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>
References: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@github.com>
 <GtxutWj0tM2Ie5BXDJhTD5BFl8QJcbbAvKe4xATR7X0=.a9d10ab6-e84e-4e69-a0a2-ed942890754a@github.com>
Message-ID: <XE0YPBDJRdk4BrI4i2CBud_l4CZDqpuzmWlvI8vr-kQ=.2fe23bd2-105c-4919-be61-c9dc09cb2a1c@github.com>

On Sat, 20 Apr 2024 22:31:48 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this change.
>> 
>> Overall, making this an intrinsic improves overall performance of `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge branch 'openjdk:master' into setMemory
>  - Fix UnsafeCopyMemoryMark scope issue
>  - Long to short jmp; other cleanup
>  - Review comments
>  - Address review comments; update copyright years
>  - Add enter() and leave(); remove Windows-specific register stuff
>  - Fix memory mark after sync to upstream
>  - Merge branch 'openjdk:master' into setMemory
>  - Set memory test (#23)
>    
>    * Even more review comments
>    
>    * Re-write of atomic copy loops
>    
>    * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
>    
>    * Only add a memory mark for byte unaligned fill
>    
>    * Remove MUSL_LIBC ifdef
>    
>    * Remove MUSL_LIBC ifdef
>  - Set memory test (#22)
>    
>    * Even more review comments
>    
>    * Re-write of atomic copy loops
>    
>    * Change name of UnsafeCopyMemory{,Mark} to UnsafeMemory{Access,Mark}
>    
>    * Only add a memory mark for byte unaligned fill
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/6d569961...1122b500

This introduced a regression, see [JDK-8331033](https://bugs.openjdk.org/browse/JDK-8331033).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2074459781

From ihse at openjdk.org  Wed Apr 24 09:17:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 24 Apr 2024 09:17:28 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>

On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

Please mark the PR as draft it is not intended for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2074481887

From redestad at openjdk.org  Wed Apr 24 09:57:42 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 24 Apr 2024 09:57:42 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v7]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <QqaVCWUEgegmBhAGkQoqohz7m9odq37wuzEDuYi9vGY=.9130de89-f279-4d0c-aaae-e90ea0da6b06@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18690/files
  - new: https://git.openjdk.org/jdk/pull/18690/files/83f4048f..e7cbaaf5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=05-06

  Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From duke at openjdk.org  Wed Apr 24 09:57:43 2024
From: duke at openjdk.org (Louis Wasserman)
Date: Wed, 24 Apr 2024 09:57:43 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v7]
In-Reply-To: <0UsnNhF9Vebfzbp6bCmhNspgiGB0cXyYtB888ODwR_o=.c7eee3ee-c51e-40f2-befe-99b5ad7365c8@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <iB3-M1Zqko_5S8dh67o0tGxQYcd0kbDCqroGFmK0GAA=.d59284b1-c058-42df-abe9-83c016939f44@github.com>
 <pQIn1JZl2AUsIWkksGjJG7SDHfDVYYOE_TcvWBJx6x8=.556ffd4f-053c-490c-a046-0e125083923e@github.com>
 <mWu8_L884G_BSe-S8svNeUqy-x_ha5BsPRqqGnfZ59I=.99e0cab6-5d82-4a9f-81f9-b7cf2415acf3@github.com>
 <0UsnNhF9Vebfzbp6bCmhNspgiGB0cXyYtB888ODwR_o=.c7eee3ee-c51e-40f2-befe-99b5ad7365c8@github.com>
Message-ID: <EqJ84A5vXJVGDYd2hFtRYS1tL-awDFdl48hEFtAsboI=.20e93556-3d89-4645-bf2c-784dd242d9fb@github.com>

On Sun, 14 Apr 2024 14:33:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> What are the scenarios which had regressions? 
>> Given the conservative growth for StringBuilder, it surprises me a bit that any scenario would regress.
>
> I took a second look and it turns out that there were neither regressions nor improvements in my test, only a few false positives: For C2 the SB chain is recognized by the (fragile) C2 OptimizeStringConcat pass and transformed into a shape where the initial size in java bytecode - if any - is ignored.
> 
> With C1 having an initial size can have a significant effect. One way to provoke a regression there is to have a huge constant suffix while underestimating the size of the operands, which can lead to excessive allocation:
> 
> 
> Name                             Cnt     Base    Error       Test    Error   Unit  Change
> StringConcat.concat23StringConst   5  385,268 ?  5,238    341,251 ?  2,606  ns/op   1,13x (p = 0,000*)
>   :gc.alloc.rate                     6039,095 ? 82,309  12764,169 ? 97,146 MB/sec   2,11x (p = 0,000*)
>   :gc.alloc.rate.norm                2440,003 ?  0,000   4568,002 ?  0,000   B/op   1,87x (p = 0,000*)
> 
> 
> Still a bit better on throughput from less actual copying.
> 
> *If* the `StringBuilder` is sized sufficiently (constants + args * N) things look much better, of course: 
> 
> -XX:TieredStopAtLevel=1
> Name                             Cnt     Base    Error      Test    Error   Unit  Change
> StringConcat.concat23StringConst   5  385,268 ?  5,238   259,628 ?  2,515  ns/op   1,48x (p = 0,000*)
>   :gc.alloc.rate                     6039,095 ? 82,309  8902,803 ? 86,563 MB/sec   1,47x (p = 0,000*)
>   :gc.alloc.rate.norm                2440,003 ?  0,000  2424,002 ?  0,000   B/op   0,99x (p = 0,000*)
> 
> 
> For most cases having a size based on the sum of the constants plus some small factor per argument seem to be a decent heuristic - for C1. Since this adds just one bytecode to the generated method I guess it wouldn't hurt.

Presizing this StringBuilder is a thing I looked into once upon a time, discussed here: https://mail.openjdk.org/pipermail/compiler-dev/2015-March/009356.html  This work, I understand, the indyfication of string concatenation in the first place.

Primitive values can get bounded at appropriate lengths for their types (see e.g. https://stackoverflow.com/a/21146952/869736).  It sounds like you're trying to conserve bytecode length, so maybe you don't want to presize the StringBuilder with the exact Object.toString() lengths, though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1576819289

From redestad at openjdk.org  Wed Apr 24 10:04:30 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 24 Apr 2024 10:04:30 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v7]
In-Reply-To: <QqaVCWUEgegmBhAGkQoqohz7m9odq37wuzEDuYi9vGY=.9130de89-f279-4d0c-aaae-e90ea0da6b06@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <QqaVCWUEgegmBhAGkQoqohz7m9odq37wuzEDuYi9vGY=.9130de89-f279-4d0c-aaae-e90ea0da6b06@github.com>
Message-ID: <rsk58VsvHp5ZeBZ-LwcnYdcCQUidXR-iTm7CQrEeNy4=.fc909e58-d5f9-4b39-b827-c040463c99dc@github.com>

On Wed, 24 Apr 2024 09:57:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

> I really wish this change was not done with ClassFile API, but with a simple bundled ASM, so it would be easily backportable, if we decide to. It does not look like CFA buys us a lot here readability/complexity wise: [d99b159](https://github.com/openjdk/jdk/commit/d99b1596c5ca57b110c1db88be430c6c54c3d599)

I would be open to splitting out and pushing the ASM version first and do this CFA port as a follow-up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2074577669

From redestad at openjdk.org  Wed Apr 24 10:08:42 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 24 Apr 2024 10:08:42 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v8]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <DSStd2ej9fAwNZ8X8Z8VNU2-HZDqw-v2X8H3JdFHwiY=.0a01e9e0-41dd-46cb-9b54-817f4bf18c44@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Make Set.of(STRONG) a constant, fix compilation, minor code improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18690/files
  - new: https://git.openjdk.org/jdk/pull/18690/files/e7cbaaf5..9742f074

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=06-07

  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From shade at openjdk.org  Wed Apr 24 10:08:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 Apr 2024 10:08:42 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v7]
In-Reply-To: <rsk58VsvHp5ZeBZ-LwcnYdcCQUidXR-iTm7CQrEeNy4=.fc909e58-d5f9-4b39-b827-c040463c99dc@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <QqaVCWUEgegmBhAGkQoqohz7m9odq37wuzEDuYi9vGY=.9130de89-f279-4d0c-aaae-e90ea0da6b06@github.com>
 <rsk58VsvHp5ZeBZ-LwcnYdcCQUidXR-iTm7CQrEeNy4=.fc909e58-d5f9-4b39-b827-c040463c99dc@github.com>
Message-ID: <IZQ3b3Au-9AEuy_yxPa-5oUwc8WuwvWXHPmLxv3LeVU=.455872b1-affe-46dd-a430-c3cd3e61d5e7@github.com>

On Wed, 24 Apr 2024 10:01:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > I really wish this change was not done with ClassFile API, but with a simple bundled ASM, so it would be easily backportable, if we decide to. It does not look like CFA buys us a lot here readability/complexity wise: [d99b159](https://github.com/openjdk/jdk/commit/d99b1596c5ca57b110c1db88be430c6c54c3d599)
> 
> I would be open to splitting out and pushing the ASM version first and do this CFA port as a follow-up.

That would be good, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2074585421

From dnsimon at openjdk.org  Wed Apr 24 10:50:44 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 Apr 2024 10:50:44 GMT
Subject: RFR: 8330755: ProblemList files have entries referring to
 non-existent tests [v2]
In-Reply-To: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
References: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
Message-ID: <vI3xkUAHKmVbuRrCBuSbUuJYlCHfKH-f9hPY1E0dhmc=.c9ac9fea-bea5-4bd1-ac98-020a0893bf25@github.com>

> This PR adds a check for the format of ProblemList files and ensures they only have entries referring to existing tests.
> 
> The cleanups in the second commit of this PR were done based on the output of `CheckProblemLists`:
> 
>> make test TEST=build/problemLists/CheckProblemLists.java
> ...
> STDOUT:
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Virtual.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Xcomp.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-generational-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jaxp/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Xcomp.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-generational-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/langtools/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/lib-test/ProblemList.txt
> Checked 13 problem list files
> Test roots:
>   /Users/dnsimon/dev/jdk-jdk/open/test/jdk
>   /Users/dnsimon/dev/jdk-jdk/open/test/lib-test
>   /Users/dnsimon/dev/jdk-jdk/open/test/failure_handler/test
>   /Users/dnsimon/dev/jdk-jdk/open/test/jaxp
>   /Users/dnsimon/dev/jdk-jdk/open/test/langtools
>   /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg
> Following errors found:
> /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt:174: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java does not exist under any test root
> vmTestbase/gc/lock/jni/jnilock002/TestDescription.java 8192647 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:77: TestAndIssue[test=java/util/Properties/StoreReproducibilityTest.java, issueId=0000000] duplicates /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:76
> java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:516: java/lang/management/MemoryMXBean/PendingAllGC.sh does not exist under any test root
> java/lang/management/MemoryMXBean/PendingAllGC.sh               8158837 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:667: javax/swing/JFi...

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  removed CheckProblemLists.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18879/files
  - new: https://git.openjdk.org/jdk/pull/18879/files/49a1a58e..22ffae05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18879&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18879&range=00-01

  Stats: 211 lines in 1 file changed: 0 ins; 211 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18879/head:pull/18879

PR: https://git.openjdk.org/jdk/pull/18879

From dnsimon at openjdk.org  Wed Apr 24 10:50:44 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 Apr 2024 10:50:44 GMT
Subject: RFR: 8330755: ProblemList files have entries referring to
 non-existent tests
In-Reply-To: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
References: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
Message-ID: <Vms188bOcQJxve8eFGsQQcCOJF1HeMV0rE7Jgf-VGwk=.b0699edf-b68a-46a0-9a49-152abdca13f4@github.com>

On Sun, 21 Apr 2024 22:00:52 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds a check for the format of ProblemList files and ensures they only have entries referring to existing tests.
> 
> The cleanups in the second commit of this PR were done based on the output of `CheckProblemLists`:
> 
>> make test TEST=build/problemLists/CheckProblemLists.java
> ...
> STDOUT:
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Virtual.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Xcomp.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-generational-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jaxp/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Xcomp.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-generational-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/langtools/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/lib-test/ProblemList.txt
> Checked 13 problem list files
> Test roots:
>   /Users/dnsimon/dev/jdk-jdk/open/test/jdk
>   /Users/dnsimon/dev/jdk-jdk/open/test/lib-test
>   /Users/dnsimon/dev/jdk-jdk/open/test/failure_handler/test
>   /Users/dnsimon/dev/jdk-jdk/open/test/jaxp
>   /Users/dnsimon/dev/jdk-jdk/open/test/langtools
>   /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg
> Following errors found:
> /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt:174: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java does not exist under any test root
> vmTestbase/gc/lock/jni/jnilock002/TestDescription.java 8192647 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:77: TestAndIssue[test=java/util/Properties/StoreReproducibilityTest.java, issueId=0000000] duplicates /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:76
> java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:516: java/lang/management/MemoryMXBean/PendingAllGC.sh does not exist under any test root
> java/lang/management/MemoryMXBean/PendingAllGC.sh               8158837 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:667: javax/swing/JFi...

I've removed `CheckProblemLists.java` as it overlaps with https://bugs.openjdk.org/browse/CODETOOLS-7903659.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18879#issuecomment-2074660269

From lucy at openjdk.org  Wed Apr 24 11:21:27 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 24 Apr 2024 11:21:27 GMT
Subject: RFR: 8330615: avoid signed integer overflows in zip_util.c readCen
 / hashN
In-Reply-To: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
References: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
Message-ID: <K1o6aBG6POGPZXtAbDtYiTWasMYvvh-dzlJy-n1pqaM=.d3474ec8-0280-43d3-a0c3-7edcd0b11c92@github.com>

On Tue, 23 Apr 2024 07:51:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the hashN usages of readCen from zip_util.c we see a lot of signed integer overflows.
> For example in the java/util jtreg tests those are easily reproducable when compiling with -ftrapv (clang/gcc toolchains).
> While those overflows never seem to cause crashes or similar errors, they are unwanted because
> signed integer overflows in C cause undefined behavior.
> See
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html
>>
>> For signed integers, the result of overflow in C is in principle undefined, meaning that anything whatsoever could happen.
>> Therefore, C compilers can do optimizations that treat the overflow case with total unconcern.
> 
> So we might still get unwanted results (maybe bad/strange hashing, depending on compiler and optimization level).
> 
> Compilation with -ftrapv causes/triggers this SIGILL on macOS showing the issue :
> # Problematic frame:
> # C [libzip.dylib+0x6362] hashN+0x32
> #
> 
> Stack: [0x000070000c496000,0x000070000c596000], sp=0x000070000c5957e0, free space=1021k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libzip.dylib+0x6362] hashN+0x32
> C [libzip.dylib+0x5d5e] readCEN+0xd2e
> C [libzip.dylib+0x4ee0] ZIP_Put_In_Cache0+0x160
> V [libjvm.dylib+0x544b1e] ClassLoader::open_zip_file(char const*, char**, JavaThread*)+0x3e
> V [libjvm.dylib+0x543fec] ClassLoader::create_class_path_entry(JavaThread*, char const*, stat const*, bool, bool)+0x6c
> V [libjvm.dylib+0x543833] ClassLoader::setup_bootstrap_search_path_impl(JavaThread*, char const*)+0xf3
> V [libjvm.dylib+0x54819b] classLoader_init1()+0x1b
> V [libjvm.dylib+0x92602a] init_globals()+0x3a
> V [libjvm.dylib+0x12b3b74] Threads::create_vm(JavaVMInitArgs*, bool*)+0x314
> V [libjvm.dylib+0xa848f4] JNI_CreateJavaVM+0x64
> C [libjli.dylib+0x4483] JavaMain+0x123
> C [libjli.dylib+0x7529] ThreadJavaMain+0x9
> C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0
> C [libsystem_pthread.dylib+0x2443] thread_start+0xf

LGTM.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18908#pullrequestreview-2019585061

From magnus.ihse.bursie at oracle.com  Wed Apr 24 11:24:32 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 24 Apr 2024 13:24:32 +0200
Subject: Usage of iconv()
In-Reply-To: <20240423121114.EE241662C87@dd33810.kasserver.com>
References: <20240423121114.EE241662C87@dd33810.kasserver.com>
Message-ID: <e9f7107a-4f9c-4511-9270-9bb08f7bca87@oracle.com>

That is a good question. libiconv is used only on macOS and AIX, for a 
few libraries, as you say. I just tried removing -liconv from the macOS 
dependencies and recompiled, just to see what would happen. There were 
three instances for macOS: libsplashscreen, libjdwp and libinstrument.

Out of these, libinstrument compiled and linked fine without the -liconv 
argument. It looks like iconv is referenced in 
unix/.../EncodingSupport_md.c, but otoh it looks like it is as much (or 
as little) referenced on macOS as on linux (where we never have linked 
with -liconv) so it is perhaps just dead code. I did not study it in 
detail. The code looks very much duplicated from libjdwp.

The other two actually failed linking, so they do use libiconv.

libsplashscreen uses it in splashscreen_sys.m, where it is used to 
convert the jar file name.

libjdwp uses it in utf_util.c, where it is used to convert file name and 
command lines, iiuc.

It is likely that we have similar (but better) ways to convert charsets 
elsewhere in our libraries that can be used instead of libiconv. I guess 
these are not the only two places where a filename must be converted 
from the platform charset to UTF8.

/Magnus

On 2024-04-23 14:11, Bernd Eckenfels wrote:
> Du to a glibc security alert about a charset in iconv() I checked OpenJDK (since I was quite sure encoding is handled in JCL), however there are a few utilities (related to libinstrument and splash Screens) which use iconv.
>
> If I see it correctly it?s mostly used for utf8 so it should not expose this particular globe weakness, but I still wonder if that dependency is needed. For some platforms like AIX it even drags on an additional library dependency. (Not to mention different charger tables and especially ugly locale dependencies for containers).
>
> Gru?
> Bernd
> ?
> https://bernd.eckenfels.net

From liach at openjdk.org  Wed Apr 24 11:53:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Apr 2024 11:53:33 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <dQpbKfwIB2lTj3HPrHmT-ts4LhUvA2LiHWJvEl3j71o=.0dade48e-407e-4f81-8002-23c3f705d106@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
 <-0V3ZTaf1NcBXcx0uNaIwPEx8VH5fR0b8avQZTaxr2E=.d258b611-d6ab-4271-acd3-9a802026fe12@github.com>
 <dQpbKfwIB2lTj3HPrHmT-ts4LhUvA2LiHWJvEl3j71o=.0dade48e-407e-4f81-8002-23c3f705d106@github.com>
Message-ID: <i0i_w2N83Dr4fTr6Hsi_sE3gvpqzHmOEzn38Rg9MeBA=.919fd23d-1d94-4947-a475-ced2a3c9d38f@github.com>

On Wed, 24 Apr 2024 08:29:56 GMT, Evemose <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ArrayList.java line 380:
>> 
>>> 378:     }
>>> 379: 
>>> 380:     int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {
>> 
>> Suggestion:
>> 
>>     private int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {
>
> Yeah i thought about it but indexOfRange isnt private here so either there is a point in it or its just legacy without any particular meaning

It is legacy to avoid bridge generation from the SubList.

Before introduction of nestmates in JDK 11, private methods and fields called by inner classes should be declared package-private, as javac has to generate bridge methods at each call site to abide to JVM rules (inner classes are just another class in the package so couldn't call private methods).

This is also the reason you can see patterns like

private static class Holder {
    static final Value instance = Value.initialize();
}

where the `static final` is not `private` qualified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1577751899

From duke at openjdk.org  Wed Apr 24 12:00:47 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 24 Apr 2024 12:00:47 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v13]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <CM_IToa4rOZMEFp_FsVEorJ6u0R3_d4ORrlB-qxP-08=.7a7527e0-1a24-4d54-8944-4a13ce9dee09@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with two additional commits since the last revision:

 - ArrayList made findIndexInRange private
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - ArrayList made findLastIndexInRange private
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/349ee6bd..d2f358b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=11-12

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From pminborg at openjdk.org  Wed Apr 24 12:00:55 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 24 Apr 2024 12:00:55 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v8]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <pPLDryemgOYiiTFVA0-bkRUKQaHhfS0V0wFJrZcXS1E=.2756273a-3b5d-47da-b732-a6136f82a12c@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/0e06e0d6..31d92589

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=06-07

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18474/head:pull/18474

PR: https://git.openjdk.org/jdk/pull/18474

From duke at openjdk.org  Wed Apr 24 12:00:48 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 24 Apr 2024 12:00:48 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
Message-ID: <f1IZW8YZtGsA3RlglXKwXy-ILXuvOUhHjpFS4ygmMNs=.c9c6b76b-8c0a-490c-b961-200333419414@github.com>

On Tue, 23 Apr 2024 13:54:42 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Added Objects import to sun List
>  - Replaced on-demand import in com.sun....List
>  - added non-null assertions

Commited proposed changes. Also still would appreciate any help about what to write it csr template (you can see what I figured a few messages above)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2074774403

From pminborg at openjdk.org  Wed Apr 24 12:00:58 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 24 Apr 2024 12:00:58 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v7]
In-Reply-To: <YqMHwwkz2Lezr2Mvaav4QLyOAaO1OrjMCq8R3nhBpdA=.6ad77975-989f-42eb-9644-f3b576b68f00@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <lj7O4Bv1QYMArWAyHkuzZ8zbXQ7mj2WF7b_fDEt8hpk=.e22d8bb2-5dc3-4f8a-b4e1-261aab5c8b00@github.com>
 <YqMHwwkz2Lezr2Mvaav4QLyOAaO1OrjMCq8R3nhBpdA=.6ad77975-989f-42eb-9644-f3b576b68f00@github.com>
Message-ID: <BIdnoOqZEAdovGv_MHq69c-Woe2IUEeMuXdcVbB7rK4=.6ba4fd05-f162-473c-8a49-74b26a51d427@github.com>

On Mon, 22 Apr 2024 13:46:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg 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:
>> 
>>  - Simplify tests
>>  - Add a test for null arg
>>  - Add a test for findOrThrow()
>>  - Merge branch 'master' into symbol-lookup-findorthrow
>>  - Change exception type
>>  - Update src/java.base/share/classes/java/lang/foreign/package-info.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>>  - Fix typo
>>  - Update after PR comments
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/099a64e8...0e06e0d6
>
> test/jdk/java/foreign/loaderLookup/TestSymbolLookupFindOrThrow.java line 41:
> 
>> 39: 
>> 40:     static {
>> 41:         System.loadLibrary("Foo");
> 
> Where is this lib defined?

it is defined in the sub-folder `lookup` in the file `libFoo.c`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1577755855

From pminborg at openjdk.org  Wed Apr 24 12:00:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 24 Apr 2024 12:00:59 GMT
Subject: Integrated: 8314592: Add shortcut to SymbolLookup::find
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <bk3WBv4WulMnN77g5mkOQyS-2cOiugC00NKt6oUQr2E=.053e25c8-7bbe-4f9c-935b-189664448965@github.com>

On Mon, 25 Mar 2024 14:56:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

This pull request has now been integrated.

Changeset: e923dfe4
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e923dfe4c51291099d9b7411e6c9f20be79b9a53
Stats:     151 lines in 22 files changed: 88 ins; 0 del; 63 mod

8314592: Add shortcut to SymbolLookup::find

Reviewed-by: jvernee, prr

-------------

PR: https://git.openjdk.org/jdk/pull/18474

From lujaniuk at openjdk.org  Wed Apr 24 13:16:28 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 24 Apr 2024 13:16:28 GMT
Subject: RFR: 8330755: ProblemList files have entries referring to
 non-existent tests [v2]
In-Reply-To: <vI3xkUAHKmVbuRrCBuSbUuJYlCHfKH-f9hPY1E0dhmc=.c9ac9fea-bea5-4bd1-ac98-020a0893bf25@github.com>
References: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
 <vI3xkUAHKmVbuRrCBuSbUuJYlCHfKH-f9hPY1E0dhmc=.c9ac9fea-bea5-4bd1-ac98-020a0893bf25@github.com>
Message-ID: <aHMcmRSYmLOlYTY3w00acRetM8zdEGGEU_GOqaJMMrw=.7dc66f9e-48ad-4c9f-a3aa-ee543269b187@github.com>

On Wed, 24 Apr 2024 10:50:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds a check for the format of ProblemList files and ensures they only have entries referring to existing tests.
>> 
>> The cleanups in the second commit of this PR were done based on the output of `CheckProblemLists`:
>> 
>>> make test TEST=build/problemLists/CheckProblemLists.java
>> ...
>> STDOUT:
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Virtual.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Xcomp.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-generational-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jaxp/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Xcomp.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-generational-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/langtools/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/lib-test/ProblemList.txt
>> Checked 13 problem list files
>> Test roots:
>>   /Users/dnsimon/dev/jdk-jdk/open/test/jdk
>>   /Users/dnsimon/dev/jdk-jdk/open/test/lib-test
>>   /Users/dnsimon/dev/jdk-jdk/open/test/failure_handler/test
>>   /Users/dnsimon/dev/jdk-jdk/open/test/jaxp
>>   /Users/dnsimon/dev/jdk-jdk/open/test/langtools
>>   /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg
>> Following errors found:
>> /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt:174: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java does not exist under any test root
>> vmTestbase/gc/lock/jni/jnilock002/TestDescription.java 8192647 generic-all
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:77: TestAndIssue[test=java/util/Properties/StoreReproducibilityTest.java, issueId=0000000] duplicates /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:76
>> java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:516: java/lang/management/MemoryMXBean/PendingAllGC.sh does not exist under any test root
>> java/lang/management/MemoryMXBean/PendingAllGC.sh               8158837 generic-all
>> 
>> ...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed CheckProblemLists.java

While not a blocker IMO, I'm curious about the issues for the removed lines. Taking the first one as an example, I see it's "unresolved" (JDK-8192647) but the file was removed in JDK-8289764.
I don't see any other mentions of "problemlist" in JDK-8192647 so the "problemlist" label should probably also be removed.

I think it would be good to just do a check through the other issues and see if any other bookkeeping needs to be done, or if any surprises pop up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18879#issuecomment-2074921452

From dnsimon at openjdk.org  Wed Apr 24 13:28:30 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 Apr 2024 13:28:30 GMT
Subject: RFR: 8330755: ProblemList files have entries referring to
 non-existent tests [v2]
In-Reply-To: <aHMcmRSYmLOlYTY3w00acRetM8zdEGGEU_GOqaJMMrw=.7dc66f9e-48ad-4c9f-a3aa-ee543269b187@github.com>
References: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
 <vI3xkUAHKmVbuRrCBuSbUuJYlCHfKH-f9hPY1E0dhmc=.c9ac9fea-bea5-4bd1-ac98-020a0893bf25@github.com>
 <aHMcmRSYmLOlYTY3w00acRetM8zdEGGEU_GOqaJMMrw=.7dc66f9e-48ad-4c9f-a3aa-ee543269b187@github.com>
Message-ID: <RhhwKKzxwCwCFiLjhg3RnfC-savol5VpqceLfLfuHTk=.f3c6093c-0800-4846-b4bc-cb3f6ff41060@github.com>

On Wed, 24 Apr 2024 13:14:02 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> While not a blocker IMO, I'm curious about the issues for the removed lines. Taking the first one as an example, I see it's "unresolved" (JDK-8192647) but the file was removed in JDK-8289764. I don't see any other mentions of "problemlist" in JDK-8192647 so the "problemlist" label should probably also be removed.
> 
> I think it would be good to just do a check through the other issues and see if any other bookkeeping needs to be done, or if any surprises pop up.

Ok, I'm pinging people here who git blame associates with some of the removed entries: @walulyai , @lmesnik @kumarabhi006

However, I don't see how removing these entries can cause any problems. Someone who have noticed failing problem listed tests by now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18879#issuecomment-2074947452

From jpai at openjdk.org  Wed Apr 24 13:46:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Apr 2024 13:46:29 GMT
Subject: RFR: 8330615: avoid signed integer overflows in zip_util.c readCen
 / hashN
In-Reply-To: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
References: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
Message-ID: <C_99WcSWLkjCZFP1oNcUABrbDjMfa8RFTJ-BMJIRQUo=.c1c40331-cf57-49bf-9054-606d969ad53b@github.com>

On Tue, 23 Apr 2024 07:51:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the hashN usages of readCen from zip_util.c we see a lot of signed integer overflows.
> For example in the java/util jtreg tests those are easily reproducable when compiling with -ftrapv (clang/gcc toolchains).
> While those overflows never seem to cause crashes or similar errors, they are unwanted because
> signed integer overflows in C cause undefined behavior.
> See
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html
>>
>> For signed integers, the result of overflow in C is in principle undefined, meaning that anything whatsoever could happen.
>> Therefore, C compilers can do optimizations that treat the overflow case with total unconcern.
> 
> So we might still get unwanted results (maybe bad/strange hashing, depending on compiler and optimization level).
> 
> Compilation with -ftrapv causes/triggers this SIGILL on macOS showing the issue :
> # Problematic frame:
> # C [libzip.dylib+0x6362] hashN+0x32
> #
> 
> Stack: [0x000070000c496000,0x000070000c596000], sp=0x000070000c5957e0, free space=1021k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libzip.dylib+0x6362] hashN+0x32
> C [libzip.dylib+0x5d5e] readCEN+0xd2e
> C [libzip.dylib+0x4ee0] ZIP_Put_In_Cache0+0x160
> V [libjvm.dylib+0x544b1e] ClassLoader::open_zip_file(char const*, char**, JavaThread*)+0x3e
> V [libjvm.dylib+0x543fec] ClassLoader::create_class_path_entry(JavaThread*, char const*, stat const*, bool, bool)+0x6c
> V [libjvm.dylib+0x543833] ClassLoader::setup_bootstrap_search_path_impl(JavaThread*, char const*)+0xf3
> V [libjvm.dylib+0x54819b] classLoader_init1()+0x1b
> V [libjvm.dylib+0x92602a] init_globals()+0x3a
> V [libjvm.dylib+0x12b3b74] Threads::create_vm(JavaVMInitArgs*, bool*)+0x314
> V [libjvm.dylib+0xa848f4] JNI_CreateJavaVM+0x64
> C [libjli.dylib+0x4483] JavaMain+0x123
> C [libjli.dylib+0x7529] ThreadJavaMain+0x9
> C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0
> C [libsystem_pthread.dylib+0x2443] thread_start+0xf

Thank you Matthias, for this change. Lance has run some internal CI tests and they have come back fine. I am in the process of running some more CI tests with this change and I should have the results, very likely by tomorrow. Please wait for those results before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18908#issuecomment-2074986166

From duke at openjdk.org  Wed Apr 24 13:47:32 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 24 Apr 2024 13:47:32 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v13]
In-Reply-To: <CM_IToa4rOZMEFp_FsVEorJ6u0R3_d4ORrlB-qxP-08=.7a7527e0-1a24-4d54-8944-4a13ce9dee09@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <CM_IToa4rOZMEFp_FsVEorJ6u0R3_d4ORrlB-qxP-08=.7a7527e0-1a24-4d54-8944-4a13ce9dee09@github.com>
Message-ID: <qVDxVbDzhmsJ3jJmOlsVMusrzGK2fPpskzFD75r_OUI=.1e449c41-f235-4228-8fea-4cbc3758d621@github.com>

On Wed, 24 Apr 2024 12:00:47 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - ArrayList made findIndexInRange private
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - ArrayList made findLastIndexInRange private
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Seems like run failed due to internal problems of openjdk. I will trigger rerun a bit later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2074989809

From rgiulietti at openjdk.org  Wed Apr 24 13:55:51 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 24 Apr 2024 13:55:51 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module
Message-ID: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>

Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

-------------

Commit messages:
 - 8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module

Changes: https://git.openjdk.org/jdk/pull/18932/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330005
  Stats: 78 lines in 12 files changed: 11 ins; 65 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18932/head:pull/18932

PR: https://git.openjdk.org/jdk/pull/18932

From mbaesken at openjdk.org  Wed Apr 24 13:58:28 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 24 Apr 2024 13:58:28 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v5]
In-Reply-To: <gC_tj8pr-DjJpponY6WLeMAAMhrRObOyx5hgev_qd7s=.9fffb44f-129b-40f9-a50e-15db0cbf8faa@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <gC_tj8pr-DjJpponY6WLeMAAMhrRObOyx5hgev_qd7s=.9fffb44f-129b-40f9-a50e-15db0cbf8faa@github.com>
Message-ID: <BdkUWQySX4EnK7DueMJVL6c4KpPCrRd429mjEVrw5NI=.de11516b-470f-47c1-97f8-b97ac90590ff@github.com>

On Tue, 23 Apr 2024 14:31:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust output

I changed the added output to 'JRE path' to have more consistency with the existing JLI trace messages.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2075012914

From mullan at openjdk.org  Wed Apr 24 14:10:30 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 24 Apr 2024 14:10:30 GMT
Subject: RFR: 8330542: Add two JAXP configuration files in preparation for
 a secure by default configuration [v4]
In-Reply-To: <tSGPaSgL99x4g6cjVsyhphxVOcfSKVjmvyxXP0igkss=.cda28f0f-486c-47e7-9dc6-b20727a45546@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
 <Z-826DUQkeBqsX1w1082b3BYgvv_1RtlyOOmASoI-b8=.d71d1637-6173-4088-bbc8-fcac6b4f43ad@github.com>
 <tSGPaSgL99x4g6cjVsyhphxVOcfSKVjmvyxXP0igkss=.cda28f0f-486c-47e7-9dc6-b20727a45546@github.com>
Message-ID: <Oyf_6Q2lfF8GNeCKQunLk9lQyl0rS4F1Wy6YJL9LnSk=.834a7d05-9ac2-4d80-8f4d-6afd751834f1@github.com>

On Tue, 23 Apr 2024 19:26:05 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > Also, how does one try out these property files? Is there a system property that needs to be set? Can you add more details to the RN on that?
> 
> java -Djava.xml.config.file=$JAVA_HOME/conf/jaxp-compat.properties
> 
> The property was added in JDK 22 see: https://docs.oracle.com/en/java/javase/22/docs/api/java.xml/module-summary.html#Conf_CF_SP

Sounds good, can you add an example to the RN using the above system property?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2075040607

From alanb at openjdk.org  Wed Apr 24 14:42:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Apr 2024 14:42:28 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <64yQe-gZVZBpWqvR8IWLi27T7KV5VkKjGABzoABou40=.7d5e0763-e261-4d43-8172-7a967688d83b@github.com>

On Wed, 24 Apr 2024 13:50:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

What is the footprint implications for this? I'm trying to recall what the reasons were for doing this split in the first place.

If the implementations are moving to java.base then I suppose they go into jdk.internal.random rather than jdk.random.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2075112923

From szaldana at openjdk.org  Wed Apr 24 14:49:55 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 24 Apr 2024 14:49:55 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v5]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <42Zzss3ttXArFmUCG-dzEoNu5AFHUzOU2VFeaIDb84M=.67b8ab1a-b97e-4caf-a02a-2b43d801c124@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:

  Using new macro to avoid reporting JNI error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/66942238..3ea56c5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=03-04

  Stats: 19 lines in 1 file changed: 9 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786

PR: https://git.openjdk.org/jdk/pull/18786

From bpb at openjdk.org  Wed Apr 24 14:57:30 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Apr 2024 14:57:30 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <dDMFmXOQple4ByVYQ_A06qjb_9EBEPami7F9hIzCsW8=.3a3a7556-1a15-4468-9287-fd387486200f@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>
 <PxAXBDKAD3I_TuonCTyL5cgOfFevrj7fqAnf5914x34=.7493eaa1-75ba-4469-80d2-0ff6dba158ed@github.com>
 <QkHuWdLgnhfh_fdf8PcihECq7m13uQ-AbFOefsJBGMI=.19d83752-5c8d-4f50-9d53-2d1894bf2543@github.com>
 <3S8kR1JCUOVEEYIH1qhEkYesSDXosbI5hQ9uIEr-Sbk=.d992e898-4085-4d72-a94c-2ff07e6fb977@github.com>
 <dDMFmXOQple4ByVYQ_A06qjb_9EBEPami7F9hIzCsW8=.3a3a7556-1a15-4468-9287-fd387486200f@github.com>
Message-ID: <XHpn9KLJxNKf8t5M5Ca_1OBOufJaqW_TyIp45KGgO7A=.08a1ab7f-c4ee-43a5-b0b1-85ad0d3eccf9@github.com>

On Wed, 24 Apr 2024 07:08:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So do we think it better not to invoke `toByteArray` here?
>
> Using a subclass to count the number of invocations of toByteArray seems a bit strange but in general it is more robust to not rely on a method that may be overridden by a subclass. So I think the suggestion is good.

Currently we have

    public void writeTo(OutputStream out) throws IOException {
        if (Thread.currentThread().isVirtual()) {
            out.write(toByteArray());
        } else synchronized (this) {
            out.write(buf, 0, count);
        }
    }

where `toByteArray()` is `synchronized`, but here I would think that we'd want to replace it with simply `Arrays.copyOf(buf, count)` without the `synchronized`, no?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1578031656

From vklang at openjdk.org  Wed Apr 24 14:57:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 24 Apr 2024 14:57:31 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <XHpn9KLJxNKf8t5M5Ca_1OBOufJaqW_TyIp45KGgO7A=.08a1ab7f-c4ee-43a5-b0b1-85ad0d3eccf9@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>
 <PxAXBDKAD3I_TuonCTyL5cgOfFevrj7fqAnf5914x34=.7493eaa1-75ba-4469-80d2-0ff6dba158ed@github.com>
 <QkHuWdLgnhfh_fdf8PcihECq7m13uQ-AbFOefsJBGMI=.19d83752-5c8d-4f50-9d53-2d1894bf2543@github.com>
 <3S8kR1JCUOVEEYIH1qhEkYesSDXosbI5hQ9uIEr-Sbk=.d992e898-4085-4d72-a94c-2ff07e6fb977@github.com>
 <dDMFmXOQple4ByVYQ_A06qjb_9EBEPami7F9hIzCsW8=.3a3a7556-1a15-4468-9287-fd387486200f@github.com>
 <XHpn9KLJxNKf8t5M5Ca_1OBOufJaqW_TyIp45KGgO7A=.08a1ab7f-c4ee-43a5-b0b1-85ad0d3eccf9@github.com>
Message-ID: <aSfTNQoemDpgpvOXmmlLNflXLMxp777ate2hxSOPfHc=.9b443256-477c-4ad9-9094-47db4c6b06cf@github.com>

On Wed, 24 Apr 2024 14:52:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Using a subclass to count the number of invocations of toByteArray seems a bit strange but in general it is more robust to not rely on a method that may be overridden by a subclass. So I think the suggestion is good.
>
> Currently we have
> 
>     public void writeTo(OutputStream out) throws IOException {
>         if (Thread.currentThread().isVirtual()) {
>             out.write(toByteArray());
>         } else synchronized (this) {
>             out.write(buf, 0, count);
>         }
>     }
> 
> where `toByteArray()` is `synchronized`, but here I would think that we'd want to replace it with simply `Arrays.copyOf(buf, count)` without the `synchronized`, no?

@bplb My interpretation was that we didn't want to hold the monitor *during* out.write().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1578034781

From vromero at openjdk.org  Wed Apr 24 15:03:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Apr 2024 15:03:34 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v10]
In-Reply-To: <dlqD_1CkX1z3xkuRCTaXPWBbeMx5Ey1l5GsHIC36sEY=.086ee49b-8506-41e0-b4db-c988eb4f91a7@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <dlqD_1CkX1z3xkuRCTaXPWBbeMx5Ey1l5GsHIC36sEY=.086ee49b-8506-41e0-b4db-c988eb4f91a7@github.com>
Message-ID: <t44ByAFdjP2pxnEIIGGXBNyrRmwkz7op5aeOhDU06hY=.07e5a0af-24f1-4fa8-999f-f82ef8a99163@github.com>

On Thu, 14 Dec 2023 04:00:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comment to jcod file

test

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-2075158188

From rgiulietti at openjdk.org  Wed Apr 24 15:27:26 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 24 Apr 2024 15:27:26 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <cKUSf6JxAorsSkFBSFJbxdwvrDSFXw9GBilM0AMzmxY=.341253f5-17dd-48f1-9e8c-a193a111a257@github.com>

On Wed, 24 Apr 2024 13:50:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

In terms of .jmod, the footprint of java.base.jmod is 20'542'561 bytes in the OpenJDK 22.0.1 build, and 20'552'354 bytes on my local 23 build, a difference of about 10 KB, or around 0.05%.

Just renamed the package to `jdk.internal.random`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2075209956

From rgiulietti at openjdk.org  Wed Apr 24 15:27:23 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 24 Apr 2024 15:27:23 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v2]
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <Bg1VtHLH-BTCQtkDYkqMclbYOWAs0ZnzvWv83GaAi4M=.cfafe4bf-aabc-456d-b319-fdf43250ce70@github.com>

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Renamed package jdk.random to jdk.internal.random.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18932/files
  - new: https://git.openjdk.org/jdk/pull/18932/files/7f45c525..ba6d052c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=00-01

  Stats: 30 lines in 11 files changed: 0 ins; 0 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/18932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18932/head:pull/18932

PR: https://git.openjdk.org/jdk/pull/18932

From bpb at openjdk.org  Wed Apr 24 15:45:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Apr 2024 15:45:58 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v2]
In-Reply-To: <aSfTNQoemDpgpvOXmmlLNflXLMxp777ate2hxSOPfHc=.9b443256-477c-4ad9-9094-47db4c6b06cf@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <i_Rhdx_IOrFAI9wvyoNsWTXYZWeDghrihEJe65QGT-k=.2d9ee0ac-4274-4209-b589-d776c1949cf0@github.com>
 <QsntettMR80vJgAWmJeBomUSjQpnpxVTG7YeU7MsKes=.10a828dd-4674-4e43-b17a-33cb10c932e3@github.com>
 <PxAXBDKAD3I_TuonCTyL5cgOfFevrj7fqAnf5914x34=.7493eaa1-75ba-4469-80d2-0ff6dba158ed@github.com>
 <QkHuWdLgnhfh_fdf8PcihECq7m13uQ-AbFOefsJBGMI=.19d83752-5c8d-4f50-9d53-2d1894bf2543@github.com>
 <3S8kR1JCUOVEEYIH1qhEkYesSDXosbI5hQ9uIEr-Sbk=.d992e898-4085-4d72-a94c-2ff07e6fb977@github.com>
 <dDMFmXOQple4ByVYQ_A06qjb_9EBEPami7F9hIzCsW8=.3a3a7556-1a15-4468-9287-fd387486200f@github.com>
 <XHpn9KLJxNKf8t5M5Ca_1OBOufJaqW_TyIp45KGgO7A=.08a1ab7f-c4ee-43a5-b0b1-85ad0d3eccf9@github.com>
 <aSfTNQoemDpgpvOXmmlLNflXLMxp777ate2hxSOPfHc=.9b443256-477c-4ad9-9094-47db4c6b06cf@github.com>
Message-ID: <gujUAsd4VismRAsG3x5uY85GWsxX_zWpBERKtpJ5Sv0=.ef5d87ff-ad43-47c7-a928-5501c545c6ee@github.com>

On Wed, 24 Apr 2024 14:54:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Currently we have
>> 
>>     public void writeTo(OutputStream out) throws IOException {
>>         if (Thread.currentThread().isVirtual()) {
>>             out.write(toByteArray());
>>         } else synchronized (this) {
>>             out.write(buf, 0, count);
>>         }
>>     }
>> 
>> where `toByteArray()` is `synchronized`, but here I would think that we'd want to replace it with simply `Arrays.copyOf(buf, count)` without the `synchronized`, no?
>
> @bplb My interpretation was that we didn't want to hold the monitor *during* out.write().

Please see 8076291fb3d097ef67d0b59b9be3c8b762aad7cf.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18901#discussion_r1578116805

From bpb at openjdk.org  Wed Apr 24 15:45:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Apr 2024 15:45:58 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v4]
In-Reply-To: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
Message-ID: <I3kmSotinvVbUWiBXZZMhmf8nWD6jQVEERPZLjqFdkk=.7a625b2d-59e0-4b66-9319-05e6b3d3fbdb@github.com>

> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.

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 five additional commits since the last revision:

 - 8330748: Modify writeTo() not to invoke toByteArray()
 - Merge
 - 8330748: Add vthread1.join() in test
 - Correct ID in test @bug tag
 - 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18901/files
  - new: https://git.openjdk.org/jdk/pull/18901/files/1dd59b7b..8076291f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18901&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18901&range=02-03

  Stats: 8598 lines in 278 files changed: 4899 ins; 2693 del; 1006 mod
  Patch: https://git.openjdk.org/jdk/pull/18901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18901/head:pull/18901

PR: https://git.openjdk.org/jdk/pull/18901

From joehw at openjdk.org  Wed Apr 24 16:07:33 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 24 Apr 2024 16:07:33 GMT
Subject: RFR: 8330542: Add two JAXP configuration files in preparation for
 a secure by default configuration [v4]
In-Reply-To: <Oyf_6Q2lfF8GNeCKQunLk9lQyl0rS4F1Wy6YJL9LnSk=.834a7d05-9ac2-4d80-8f4d-6afd751834f1@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <3aMgJb08NOSMZmZIuvq60hOdmL6v-OBkyMYwI_1SVvg=.e9527ae4-37a4-47b7-ae3e-3a9914a44428@github.com>
 <Z-826DUQkeBqsX1w1082b3BYgvv_1RtlyOOmASoI-b8=.d71d1637-6173-4088-bbc8-fcac6b4f43ad@github.com>
 <tSGPaSgL99x4g6cjVsyhphxVOcfSKVjmvyxXP0igkss=.cda28f0f-486c-47e7-9dc6-b20727a45546@github.com>
 <Oyf_6Q2lfF8GNeCKQunLk9lQyl0rS4F1Wy6YJL9LnSk=.834a7d05-9ac2-4d80-8f4d-6afd751834f1@github.com>
Message-ID: <IbbLa3pTCI98mZBUdl7i3lDG5M1r4nQ2wv1JIcyHXno=.320a19a0-a9eb-4fb7-86c6-2e272978b08a@github.com>

On Wed, 24 Apr 2024 14:07:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> 
> Sounds good, can you add an example to the RN using the above system property?

Added. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2075305341

From alanb at openjdk.org  Wed Apr 24 16:10:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Apr 2024 16:10:30 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v4]
In-Reply-To: <I3kmSotinvVbUWiBXZZMhmf8nWD6jQVEERPZLjqFdkk=.7a625b2d-59e0-4b66-9319-05e6b3d3fbdb@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <I3kmSotinvVbUWiBXZZMhmf8nWD6jQVEERPZLjqFdkk=.7a625b2d-59e0-4b66-9319-05e6b3d3fbdb@github.com>
Message-ID: <FoSxEmeXozxDyJm5CRaDOoeljuQplLdvSrxrCsYWr0w=.7e1ce74d-8dc7-428c-88fd-8b72a915cea4@github.com>

On Wed, 24 Apr 2024 15:45:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> 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 five additional commits since the last revision:
> 
>  - 8330748: Modify writeTo() not to invoke toByteArray()
>  - Merge
>  - 8330748: Add vthread1.join() in test
>  - Correct ID in test @bug tag
>  - 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier

Updated version looks fine.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18901#pullrequestreview-2020325265

From jpai at openjdk.org  Wed Apr 24 16:14:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Apr 2024 16:14:39 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v9]
In-Reply-To: <7xf3ZQti4nxv7QkxAkD20lNMcRS5GpAyARjbcErXyXA=.5234fab0-c950-4fa7-a3e1-7b4c9a0a6d7a@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
 <7xf3ZQti4nxv7QkxAkD20lNMcRS5GpAyARjbcErXyXA=.5234fab0-c950-4fa7-a3e1-7b4c9a0a6d7a@github.com>
Message-ID: <4lx_gvjlByVG_7NPxUc3Yk8zsR54p376EFVcQDhpDhA=.7d3c5f05-e16e-4949-b443-43389c1e2c44@github.com>

On Tue, 23 Apr 2024 12:49:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Archie Cobbs 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:
>> 
>>  - Merge branch 'master' into JDK-7036144
>>  - Back-out Javadoc addition; to be added in a separate issue.
>>  - Document the handling of concatenated streams.
>>  - Merge branch 'master' into JDK-7036144
>>  - Merge branch 'master' into JDK-7036144
>>  - Merge branch 'master' into JDK-7036144
>>  - Address third round of review comments.
>>  - Address second round of review comments.
>>  - Address review comments.
>>  - Fix bug in GZIPInputStream when underlying available() returns short.
>
> Hello Archie, we forgot to create a release note for this one (there's still time). Would you be willing to create one, following the instructions here https://openjdk.org/guide/#release-notes? If you need any help, let us know. One of us will review that release note before you can Resolve it to Delivered.

> Hi @jaikiran,
> 
> No problem - please see [JDK-8330995](https://bugs.openjdk.org/browse/JDK-8330995) and let me know if anything else is needed.

Thank you Archie. With inputs from Lance, I've updated the text and the summary of the release note as per the guidelines. You can now mark it as "Resolved", "Delivered".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2075318205

From vromero at openjdk.org  Wed Apr 24 16:18:05 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Apr 2024 16:18:05 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v11]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <1MU1dWTzLyrpro01HaeMYKIObPi88ObO6sGpBN5-ZQQ=.85f08bcf-3c1f-4f82-9a8f-2cb034e44127@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'master' into JDK-8320575
 - adding comment to jcod file
 - adding a comment to the test
 - addressing review comments
 - fixing comment
 - simplifying code
 - removing comment
 - javadoc
 - javadoc
 - javadoc adjustments
 - ... and 1 more: https://git.openjdk.org/jdk/compare/23c8a258...508f0199

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/f6e837d3..508f0199

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=09-10

  Stats: 682824 lines in 8459 files changed: 153181 ins; 165583 del; 364060 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From acobbs at openjdk.org  Wed Apr 24 16:22:40 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Apr 2024 16:22:40 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v9]
In-Reply-To: <4lx_gvjlByVG_7NPxUc3Yk8zsR54p376EFVcQDhpDhA=.7d3c5f05-e16e-4949-b443-43389c1e2c44@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
 <7xf3ZQti4nxv7QkxAkD20lNMcRS5GpAyARjbcErXyXA=.5234fab0-c950-4fa7-a3e1-7b4c9a0a6d7a@github.com>
 <4lx_gvjlByVG_7NPxUc3Yk8zsR54p376EFVcQDhpDhA=.7d3c5f05-e16e-4949-b443-43389c1e2c44@github.com>
Message-ID: <21GWVOMkhHUopvYSRJL-V3ppJ07NdqW38YcLYlPFlkI=.66731c92-2228-484e-8e75-5acfb9970efd@github.com>

On Wed, 24 Apr 2024 16:11:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> With inputs from Lance, I've updated the text and the summary of the release note as per the guidelines. You can now mark it as "Resolved", "Delivered".

Done - thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2075354891

From mchung at openjdk.org  Wed Apr 24 16:24:31 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 24 Apr 2024 16:24:31 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v8]
In-Reply-To: <DSStd2ej9fAwNZ8X8Z8VNU2-HZDqw-v2X8H3JdFHwiY=.0a01e9e0-41dd-46cb-9b54-817f4bf18c44@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <DSStd2ej9fAwNZ8X8Z8VNU2-HZDqw-v2X8H3JdFHwiY=.0a01e9e0-41dd-46cb-9b54-817f4bf18c44@github.com>
Message-ID: <LjUZ9nvzUhqLkLYetLec_Z-feTO7pMo4o3kXSBGU71U=.38cde494-6db6-49b3-8035-38a11c4c7a26@github.com>

On Wed, 24 Apr 2024 10:08:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make Set.of(STRONG) a constant, fix compilation, minor code improvements

Looks fine to me.   Indeed, splitting this with ASM and then convert it to ClassFile API would help the backport.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1077:

> 1075: 
> 1076:         /**
> 1077:          * Ensure a capacity in the initial StringBuilder to accommodate all constants plus this factor times the number

Nit: wrap long line.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1085:

> 1083: 
> 1084:         static {
> 1085:             DUMPER = ClassFileDumper.getInstance("java.lang.invoke.StringConcatFactory.dump", "stringConcatClasses");

Nit: this static block isn't strictly needed.  Can assign at the declaration of the static variable.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1112:

> 1110:                 return hiddenLookup.findStatic(innerClass, METHOD_NAME, args);
> 1111:             } catch (Exception e) {
> 1112:                 DUMPER.dumpFailedClass(className, classBytes);

This line is no longer needed.   The bytes will be dumped if it's enabled for both success and failing case.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18690#pullrequestreview-2020345792
PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1578178759
PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1578176295
PR Review Comment: https://git.openjdk.org/jdk/pull/18690#discussion_r1578173742

From bpb at openjdk.org  Wed Apr 24 16:42:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Apr 2024 16:42:28 GMT
Subject: RFR: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier [v4]
In-Reply-To: <I3kmSotinvVbUWiBXZZMhmf8nWD6jQVEERPZLjqFdkk=.7a625b2d-59e0-4b66-9319-05e6b3d3fbdb@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
 <I3kmSotinvVbUWiBXZZMhmf8nWD6jQVEERPZLjqFdkk=.7a625b2d-59e0-4b66-9319-05e6b3d3fbdb@github.com>
Message-ID: <oV6QmOKWcpU58x9oaMGWMnJuQMqP4jMW5Yj16ocOOeo=.13af88b2-8602-4b69-b4f3-ee32a9ad1c37@github.com>

On Wed, 24 Apr 2024 15:45:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> 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 five additional commits since the last revision:
> 
>  - 8330748: Modify writeTo() not to invoke toByteArray()
>  - Merge
>  - 8330748: Add vthread1.join() in test
>  - Correct ID in test @bug tag
>  - 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier

Running tests now. Assuming those pan out, will likely integrate tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18901#issuecomment-2075392686

From mchung at openjdk.org  Wed Apr 24 16:49:29 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 24 Apr 2024 16:49:29 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v5]
In-Reply-To: <42Zzss3ttXArFmUCG-dzEoNu5AFHUzOU2VFeaIDb84M=.67b8ab1a-b97e-4caf-a02a-2b43d801c124@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <42Zzss3ttXArFmUCG-dzEoNu5AFHUzOU2VFeaIDb84M=.67b8ab1a-b97e-4caf-a02a-2b43d801c124@github.com>
Message-ID: <L0pDkTFMHNfSfgNC_J5I99gdNjMAb98LzCqF4pGwdV0=.da1b84fb-e155-4579-aa70-fe0e27b78795@github.com>

On Wed, 24 Apr 2024 14:49:55 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using new macro to avoid reporting JNI error

Looks good.  Can you add a new test for this?   You can reference MainClassCantBeLoadedTest.java which does something similar to what you need.

src/java.base/share/native/libjli/java.c line 621:

> 619:     helperClass = GetLauncherHelperClass(env);
> 620:     isStaticMainField =
> 621:         (*env)->GetStaticFieldID(env, helperClass, "isStaticMain", "Z");

Nit: this line isn't long.  Can do in 1 line.

Same for line 623-624, 626-627.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18786#pullrequestreview-2020321074
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1578158252

From duke at openjdk.org  Wed Apr 24 17:01:59 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 24 Apr 2024 17:01:59 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v4]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <Mq466NlnMT1sLnD0pYlzzr_n1n7FNXSsbehTveXm58g=.6c2f674f-63d2-4859-a1a2-ad0e10b3f125@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  Comments from Tony and Jatin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/6f9ac046..c93a71f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=02-03

  Stats: 48 lines in 2 files changed: 20 ins; 20 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

PR: https://git.openjdk.org/jdk/pull/18583

From duke at openjdk.org  Wed Apr 24 17:01:59 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 24 Apr 2024 17:01:59 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <LVQPV5Qrqx33ddDPJqvnFNhBj1Qmn7SV95tQE9Zvt0E=.ba94ddda-fa4c-473d-9811-365168b1a0db@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <YwzqZOEDfuKsay4D10uJVN77llZhRvIZxRApbPiAHz8=.a9e83ea8-7e18-437b-bc2d-3e2759558a25@github.com>
 <If_Wx-2kNpOPUBiyjADlyB1OjeEULjJ3kB8o_5NY-TQ=.ee2de277-f0b1-4121-8e31-6ae467e84d8d@github.com>
 <LVQPV5Qrqx33ddDPJqvnFNhBj1Qmn7SV95tQE9Zvt0E=.ba94ddda-fa4c-473d-9811-365168b1a0db@github.com>
Message-ID: <i4LwTg016D8AXk4ssuSqRSC3oeI-CQ07j7xZWF4D65g=.c7199b7c-c050-4565-82ff-3aa2288f02ea@github.com>

On Tue, 16 Apr 2024 02:26:57 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Per-above, this is a switch statement (`UNLIKELY`) fallback. I can still add alignment and loop rotation, but being a fallback figured its more important to keep it small&readable...
>
> It's all part of intrinsic, no harm in polishing it.

Done (normalized loop/backedge). There was actually a problem in the loop counter.. (`i-=1` instead of `i-=16`). Can't include a test since classes are sealed, but verified manually.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1578172873

From duke at openjdk.org  Wed Apr 24 17:02:00 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 24 Apr 2024 17:02:00 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v3]
In-Reply-To: <emmi01IrP7E6eQWjWoQIm1hZKqnAsMasII_lgAUSVro=.20a4a8c0-2c37-4466-b123-77c7f2f1978c@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <-64Xlhk6ln43-xTmlv_cvloS-gzDrKMyiPUdPbMNlIM=.2b524654-ca5b-4a7a-a7da-316e99cfea35@github.com>
 <emmi01IrP7E6eQWjWoQIm1hZKqnAsMasII_lgAUSVro=.20a4a8c0-2c37-4466-b123-77c7f2f1978c@github.com>
Message-ID: <6lemy0F_PaECRhIOAlCkUCSvGeE8kaAZ7RpqoB1nJeQ=.721e6902-76b3-4112-923f-4dcbeeebb94f@github.com>

On Tue, 23 Apr 2024 19:55:57 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comments from Jatin and Tony
>
> src/java.base/share/classes/sun/security/ec/ECOperations.java line 204:
> 
>> 202:      * @return the product
>> 203:      */
>> 204:     public MutablePoint multiply(AffinePoint affineP, byte[] s) {
> 
> It seems like there could be some combining of both `multiply()`.  If `multiply(AffinePoint, ...)` is called, it can call `DefaultMultiplier` with the `affineP`, but internally call the other `multiply(ECPoint, ...)` for the other situations.  I'd rather not have two methods doing most of the same code, but different methods.

Thanks, they indeed look identical, didnt notice. Fixed. (repeated the same hashmap refactoring and didnt notice I produced identical code twice)

> src/java.base/share/classes/sun/security/ec/ECOperations.java line 467:
> 
>> 465:     sealed static abstract class SmallWindowMultiplier implements PointMultiplier
>> 466:         permits DefaultMultiplier, DefaultMontgomeryMultiplier {
>> 467:         private final AffinePoint affineP;
> 
> I don't think `affineP` needs to be a class variable anymore.  It's only used in the constructor

Didn't notice, thanks, fixed.

> src/java.base/share/classes/sun/security/ec/ECOperations.java line 592:
> 
>> 590:         }
>> 591: 
>> 592:         private final ProjectivePoint.Immutable[][] points;
> 
> Can you define this at the top please.

Done

> src/java.base/share/classes/sun/security/ec/ECOperations.java line 668:
> 
>> 666:         }
>> 667: 
>> 668:         private final BigInteger[] base;
> 
> Can you define this at the top.  You use it in the constructor but it's defined later on.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1578117929
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1578147190
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1578148562
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1578150303

From duke at openjdk.org  Wed Apr 24 17:02:00 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 24 Apr 2024 17:02:00 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v2]
In-Reply-To: <BehQ1WJbv6EvBcC5JovQec15Waqqv1W2ZLCluZvRlwU=.69b4cf32-0c2d-4df5-953d-22f72a4aa7aa@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <X8CdTxs1BMGKJWhgV43mq6TWWHPcM4brSxuxKWKhp4g=.5b6920b1-79a8-46ce-9add-bcf3e36bb4d3@github.com>
 <BehQ1WJbv6EvBcC5JovQec15Waqqv1W2ZLCluZvRlwU=.69b4cf32-0c2d-4df5-953d-22f72a4aa7aa@github.com>
Message-ID: <KjkjTueEA4vihM2WTGpLALy4MTaJwEGg9Usk6KmF6Ik=.ba1b7e5e-7feb-418b-a2c7-553983d662f1@github.com>

On Tue, 9 Apr 2024 02:01:36 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove use of jdk.crypto.ec
>
> src/java.base/share/classes/sun/security/ec/ECOperations.java line 308:
> 
>> 306: 
>> 307:     /*
>> 308:      * public Point addition. Used by ECDSAOperations
> 
> Was the old description not applicable anymore?   It would be nice to improve on the existing description that shortening it.

Forgot to go back and fix the comment. Fixed..

As for the 'meaning'. Notice the signature of the function changed (i.e. no longer a 'mixed point', but two ProjectivePoints. This is a good idea regardless of Montgomery, but it affects montgomery particularly badly (need to compute zInv for 'no reason'. )

For sake of completeness. Apart from constructor, the 'API' for ECOperations (i.e. as used by ECDHE, ECDSAOperations and KeyGeneration) are these three functions (everything else is used internally by this class)

public void setSum(MutablePoint p, MutablePoint p2)
public MutablePoint multiply(AffinePoint affineP, byte[] s)
public MutablePoint multiply(ECPoint ecPoint, byte[] s)

> src/java.base/share/classes/sun/security/ec/ECOperations.java line 321:
> 
>> 319:         ECOperations ops = this;
>> 320:         if (this.montgomeryOps != null) {
>> 321:             assert p.getField() instanceof IntegerMontgomeryFieldModuloP;
> 
> This should throw a ProviderException, I believe this would throw an AssertionException

Missed this comment. No longer applicable (this.montgomeryOps got refactored away)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1578144125
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1578161140

From vromero at openjdk.org  Wed Apr 24 17:15:43 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Apr 2024 17:15:43 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v12]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <qybguXxWzGMmcwaftLKBuCKDRW66_26hlJgFw_JRrsA=.27a059da-8369-4fee-bd89-ede339cfe62f@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  making the javadoc less general

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/508f0199..589f3ff5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=10-11

  Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From naoto at openjdk.org  Wed Apr 24 17:20:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 Apr 2024 17:20:42 GMT
Subject: RFR: 8330276: Console methods with explicit Locale
Message-ID: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>

Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

-------------

Commit messages:
 - Not using System.err
 - spacing
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/18923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330276
  Stats: 370 lines in 7 files changed: 289 ins; 0 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

PR: https://git.openjdk.org/jdk/pull/18923

From lancea at openjdk.org  Wed Apr 24 18:05:28 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 24 Apr 2024 18:05:28 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v2]
In-Reply-To: <4WzkMQNiIjXh7EbjSbKgL71Xlw34jUF-pRJ1989m5kg=.b387fbd7-d191-4bd6-9429-f36a3806c93e@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <4WzkMQNiIjXh7EbjSbKgL71Xlw34jUF-pRJ1989m5kg=.b387fbd7-d191-4bd6-9429-f36a3806c93e@github.com>
Message-ID: <mmxwUu7e7Vf-Q_kPo6oDnoyzv8sF1sAcsiLTa7juiak=.22657eb1-592c-4716-87e6-729eaac4da64@github.com>

On Tue, 23 Apr 2024 09:32:40 GMT, Jin Kwon <duke at openjdk.org> wrote:

>> Fix typos within the `DatabaseMetaData.java`.
>
> Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [JDK-8330686] Update copyright year

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18860#pullrequestreview-2020585117

From brett.okken.os at gmail.com  Wed Apr 24 19:08:44 2024
From: brett.okken.os at gmail.com (Brett Okken)
Date: Wed, 24 Apr 2024 14:08:44 -0500
Subject: large longs to string
Message-ID: <CANBJVOHvX51APRTg+fCRYnDbuQuYfVKLyxV=pNE3J0+ASvGniw@mail.gmail.com>

Is there interest in optimizing StringLatin1.getChars(long, int, byte[])
for large (larger than int) long values[1]?
We can change this to work with 8 digits at a time, which reduces the
amount of 64 bit arithmetic required.

if (i <= -1_000_000_000) {

long q = i / 100_000_000;

charPos -= 8;

write4DigitPairs(buf, charPos, (int) ((q * 100_000_000) - i));

i = q;

if (i <= -1_000_000_000) {

q = i / 100_000_000;

charPos -= 8;

write4DigitPairs(buf, charPos, (int) ((q * 100_000_000) - i));

i = q;

}

}


A simple implementation of write4DigitPairs would just call the existing
writeDigitPair method 4 times:


private static void write4DigitPairs(byte[] buf, int idx, int value) {

int v = value;

int v2 = v / 100;

writeDigitPair(buf, idx + 6, v - (v2 * 100));

v = v2;


v2 = v / 100;

writeDigitPair(buf, idx + 4, v - (v2 * 100));

v = v2;


v2 = v / 100;

writeDigitPair(buf, idx + 2, v - (v2 * 100));

v = v2;


v2 = v / 100;

writeDigitPair(buf, idx, v - (v2 * 100));

}

There is the option to OR the 4 short values together into a long and
leverage a ByteArrayLittleEndian.setLong call, but I see that the previous
usage of ByteArrayLittleEndian.setShort was removed[2].

A small benchmark of longs which would qualify shows up to 20% improvement.

Presumably a similar change could make sense for StringUTF16, but I have
not spent any time benchmarking it.

Brett

[1] -
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L163-L168
[2] -
https://github.com/openjdk/jdk/commit/913e43fea995b746fb9e1b25587d254396c7c3c9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240424/2cdb9acf/attachment.htm>

From redestad at openjdk.org  Wed Apr 24 19:13:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 24 Apr 2024 19:13:43 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v9]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <QfuKEnxxCeRzBKjFcTNkFmPcv81YgiXbHIiWsIcmnRo=.d241bab3-ff1b-4ab6-8f01-c759a24f51cd@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Nits, clean up constant, introduce missing constant MethodTypeDesc for toString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18690/files
  - new: https://git.openjdk.org/jdk/pull/18690/files/9742f074..0ac8f24b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=07-08

  Stats: 13 lines in 1 file changed: 2 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From redestad at openjdk.org  Wed Apr 24 19:13:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 24 Apr 2024 19:13:43 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v8]
In-Reply-To: <DSStd2ej9fAwNZ8X8Z8VNU2-HZDqw-v2X8H3JdFHwiY=.0a01e9e0-41dd-46cb-9b54-817f4bf18c44@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <DSStd2ej9fAwNZ8X8Z8VNU2-HZDqw-v2X8H3JdFHwiY=.0a01e9e0-41dd-46cb-9b54-817f4bf18c44@github.com>
Message-ID: <9W54jJjk5-5rHd0vwgUeqUJ5tAu0Nr3Wu8Tom-j2_JQ=.82fabf22-26ad-4f3c-9b33-cbf8f169abd2@github.com>

On Wed, 24 Apr 2024 10:08:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make Set.of(STRONG) a constant, fix compilation, minor code improvements

Thanks for reviewing! I'll split out and PR an ASM version as a subtask and rebase this PR on top of that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2075654943

From szaldana at openjdk.org  Wed Apr 24 19:25:51 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 24 Apr 2024 19:25:51 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v6]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <wc3qRnOhGAXizKEmbQYPeajArod9fgNvb4N3gQkOTQc=.898df05f-1f49-4893-85c1-c03d9feb7a5e@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision:

 - Adding test case
 - Removing long lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/3ea56c5c..e2ef2a51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=04-05

  Stats: 112 lines in 2 files changed: 106 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786

PR: https://git.openjdk.org/jdk/pull/18786

From szaldana at openjdk.org  Wed Apr 24 19:32:47 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 24 Apr 2024 19:32:47 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v7]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <DjgFanFcYvtbjGeloLAl5LsLkQT7wOhERKkKpIj2Hlk=.2f1a5a47-f494-4168-a8d4-00418c3e459e@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:

  Make deleting file OS agnostic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/e2ef2a51..ca03ead2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18786&range=05-06

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786

PR: https://git.openjdk.org/jdk/pull/18786

From claes.redestad at oracle.com  Wed Apr 24 19:39:27 2024
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 24 Apr 2024 19:39:27 +0000
Subject: large longs to string
In-Reply-To: <CANBJVOHvX51APRTg+fCRYnDbuQuYfVKLyxV=pNE3J0+ASvGniw@mail.gmail.com>
References: <CANBJVOHvX51APRTg+fCRYnDbuQuYfVKLyxV=pNE3J0+ASvGniw@mail.gmail.com>
Message-ID: <59600078-F134-46C4-9846-C081A94244D6@oracle.com>

Hi,

IIUC this optimization leans on 4 long divs being slower than 1 long div + 4 int divs, which might not be true on all platforms, nor stay true in the future. Long values will in practice likely be biased towards lower values, so it?s important that any optimization to .. longer values doesn?t regress inputs in the int range. Since it?s all guarded by a test that is already there there shouldn?t be much room for a difference, but adding code can cause interesting issues so it?s always worth measuring to make sure. Have you run any benchmark for inputs smaller than the threshold? And for a healthy mix of values?

Thanks!
/Claes

24 apr. 2024 kl. 21:08 skrev Brett Okken <brett.okken.os at gmail.com>:

Is there interest in optimizing StringLatin1.getChars(long, int, byte[]) for large (larger than int) long values[1]?
We can change this to work with 8 digits at a time, which reduces the amount of 64 bit arithmetic required.

if (i <= -1_000_000_000) {
long q = i / 100_000_000;
charPos -= 8;
write4DigitPairs(buf, charPos, (int) ((q * 100_000_000) - i));
i = q;
if (i <= -1_000_000_000) {
q = i / 100_000_000;
charPos -= 8;
write4DigitPairs(buf, charPos, (int) ((q * 100_000_000) - i));
i = q;
}
}


A simple implementation of write4DigitPairs would just call the existing writeDigitPair method 4 times:


private static void write4DigitPairs(byte[] buf, int idx, int value) {
int v = value;
int v2 = v / 100;
writeDigitPair(buf, idx + 6, v - (v2 * 100));
v = v2;

v2 = v / 100;
writeDigitPair(buf, idx + 4, v - (v2 * 100));
v = v2;

v2 = v / 100;
writeDigitPair(buf, idx + 2, v - (v2 * 100));
v = v2;

v2 = v / 100;
writeDigitPair(buf, idx, v - (v2 * 100));
}

There is the option to OR the 4 short values together into a long and leverage a ByteArrayLittleEndian.setLong call, but I see that the previous usage of ByteArrayLittleEndian.setShort was removed[2].

A small benchmark of longs which would qualify shows up to 20% improvement.

Presumably a similar change could make sense for StringUTF16, but I have not spent any time benchmarking it.

Brett

[1] - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L163-L168
[2] - https://github.com/openjdk/jdk/commit/913e43fea995b746fb9e1b25587d254396c7c3c9

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240424/317781c5/attachment-0001.htm>

From vromero at openjdk.org  Wed Apr 24 19:53:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Apr 2024 19:53:41 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v13]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <u7jo_N2Jz5E89twEe3cRHxb6e3JZcCyievxNyZR6iUs=.95f606c2-ba80-4eb1-a7cf-0eb9f7b95664@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/reflect/records/RecordReflectionTest.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/589f3ff5..4c3d4e1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Wed Apr 24 19:56:29 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Apr 2024 19:56:29 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v10]
In-Reply-To: <t44ByAFdjP2pxnEIIGGXBNyrRmwkz7op5aeOhDU06hY=.07e5a0af-24f1-4fa8-999f-f82ef8a99163@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <dlqD_1CkX1z3xkuRCTaXPWBbeMx5Ey1l5GsHIC36sEY=.086ee49b-8506-41e0-b4db-c988eb4f91a7@github.com>
 <t44ByAFdjP2pxnEIIGGXBNyrRmwkz7op5aeOhDU06hY=.07e5a0af-24f1-4fa8-999f-f82ef8a99163@github.com>
Message-ID: <JSv24qzDuS5NtTFaygFXXIe_fac1dIA9zcjvDDlcLUw=.386d0d15-fd23-45aa-8327-ef6d28bb1da8@github.com>

On Wed, 24 Apr 2024 15:00:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding comment to jcod file
>
> test

> Will this fix be backported to JDK 21? @vicente-romero-oracle

not sure right now tbh

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-2075730082

From iris at openjdk.org  Wed Apr 24 21:01:29 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 24 Apr 2024 21:01:29 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v3]
In-Reply-To: <hic8RDyVJogp_RyJKZuVFh2SM5TD2LeSd33TSJQwO0M=.2a0c300f-e985-4079-a74a-9ef486a9e57e@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <hic8RDyVJogp_RyJKZuVFh2SM5TD2LeSd33TSJQwO0M=.2a0c300f-e985-4079-a74a-9ef486a9e57e@github.com>
Message-ID: <Nl0HoQuVfQX9FqM1_2GltZ41NWk0BnozHa9FW9vDyxU=.753ce698-f750-4eac-b7b3-7a4afd63efbe@github.com>

On Wed, 24 Apr 2024 08:54:53 GMT, Jin Kwon <duke at openjdk.org> wrote:

>> Fix typos within the `DatabaseMetaData.java`.
>
> Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8330686: Fix typos in the DatabaseMetaData javadoc
>   
>   Reviewed-by: jpai

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18860#pullrequestreview-2020930726

From liach at openjdk.org  Wed Apr 24 21:22:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Apr 2024 21:22:29 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v13]
In-Reply-To: <u7jo_N2Jz5E89twEe3cRHxb6e3JZcCyievxNyZR6iUs=.95f606c2-ba80-4eb1-a7cf-0eb9f7b95664@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <u7jo_N2Jz5E89twEe3cRHxb6e3JZcCyievxNyZR6iUs=.95f606c2-ba80-4eb1-a7cf-0eb9f7b95664@github.com>
Message-ID: <wQ1CLEU-k_gWX8nPgK2yVNoJSCKK2Io2s4bRIqyqe3o=.684c76b7-651e-4689-8cdf-f3eea002475d@github.com>

On Wed, 24 Apr 2024 19:53:41 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/lang/reflect/records/RecordReflectionTest.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Is it possible for us to check the length of `genericParamTypes`, so if `genericParamTypes.length == getParameterCount()`, then we assume the generic parameters are the real generic parameters. This approach would fix the record canonical constructors, and it would benefit other JVM languages that plan to declare generic types on mandated/synthetic parameters for Java's core reflection.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-2075865476

From psandoz at openjdk.org  Wed Apr 24 21:54:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 Apr 2024 21:54:27 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes
In-Reply-To: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
Message-ID: <xhnphsmt74pb52uEUwOarr0LZNHSlE3StvAdBelc61Y=.1f7bb136-3f2b-4499-b87d-916e0479162f@github.com>

On Tue, 23 Apr 2024 07:39:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API dives into the nested constant pool entries without type restrictions, while parsing a class file. Validation of the entry is performed post-parsing. Specifically corrupted constant pool entry may cause infinite loop during parsing and throws SOE.
> This patch resolves the issue by providing specific implementations for the nested CP entries parsing, instead of sharing the common (post-checking) code.
> Added test simulates the situation on inner-looped method reference entry.
> 
> Please review.
> 
> Thank you,
> Adam

Rather than duplicating some checks I wonder if it is possible to add a private method `entryByIndex(int index, int expectedTag)` that the existing `entryByIndex` defers to. If the `expectedTag` is non-negative then it checks `tag` against `expectedTag` before proceeding to the switch expression. Then the implementations of `readClassEntry` etc can be adjusted to pass along the expected tag.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18907#pullrequestreview-2021009969

From psandoz at openjdk.org  Wed Apr 24 22:45:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 Apr 2024 22:45:27 GMT
Subject: RFR: 8322847: java.lang.classfile.BufWriter should specify @throws
 for its writeXXX methods
In-Reply-To: <LbGxj-m_26dMeRG6TgVNN16NSWtmutE5jW5pL4r1_7o=.84713a17-9ffe-435a-96e7-f1e9f5d8345a@github.com>
References: <LbGxj-m_26dMeRG6TgVNN16NSWtmutE5jW5pL4r1_7o=.84713a17-9ffe-435a-96e7-f1e9f5d8345a@github.com>
Message-ID: <TwrCOKn9SLx_P9lxuUpw4HAJBc6ZASlhLlSUzh93vIc=.e977b8c9-2d0d-4676-aedd-49e75c41bbaf@github.com>

On Tue, 23 Apr 2024 11:56:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch adds missing `@throws` javadoc annotations to `java.lang.classfile.BufWriter`.
> 
> Please review.
> 
> Thank you,
> Adam

This looks good, but for completeness it will need a CSR.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18913#pullrequestreview-2021068931

From psandoz at openjdk.org  Wed Apr 24 22:52:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 Apr 2024 22:52:27 GMT
Subject: RFR: 8325373: Improve StackCounter error reporting for bad switch
 cases
In-Reply-To: <WMLtToC6NJi2EqmVr6S3LjYQ8S8gMLh4UBnL6asW8hE=.a04dd343-0635-44d5-9a26-65e5842a0a9f@github.com>
References: <WMLtToC6NJi2EqmVr6S3LjYQ8S8gMLh4UBnL6asW8hE=.a04dd343-0635-44d5-9a26-65e5842a0a9f@github.com>
Message-ID: <oIu7dm6XJEzeRcfwSywSpVPtS0xiRy9Y2SJQkxFa56E=.2f91b65d-7214-4ae9-ab70-9ce34ff07950@github.com>

On Tue, 23 Apr 2024 12:59:18 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API `StackMapGenerator` attaches print or hex dump of the method to an error message.
> However there is no such attachment when the stack maps generation is  turned off.
> 
> This patch moves class print/dump to `impl.Util::dumpMethod`, so it is shared by `StackMapGenerator` and `StackCounter` to provide the same level of details in case of an error.
> 
> Please review.
> 
> Thank you,
> Adam

Looks good, just update the copy write date in Util.java.

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 229:

> 227:                     }))));
> 228:             ClassPrinter.toYaml(clm.methods().get(0).code().get(), ClassPrinter.Verbosity.TRACE_ALL, dump);
> 229:         } catch (Error | Exception suppresed) {

If you like you can replace `suppresed` [sic] with `_`.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18914#pullrequestreview-2021078844
PR Review Comment: https://git.openjdk.org/jdk/pull/18914#discussion_r1578604408

From bchristi at openjdk.org  Wed Apr 24 23:15:45 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 24 Apr 2024 23:15:45 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v25]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <jkZ-gpxv7E1Eov1_7RJFiBhtXs0gy1WUkxNdGZ1j4EU=.3860f93c-b8c3-4628-acc9-e3be1405b461@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  package spec updates, mostly about reference queues and dequeueing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/cc21d296..16fcc764

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=23-24

  Stats: 15 lines in 1 file changed: 0 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From joehw at openjdk.org  Wed Apr 24 23:16:58 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 24 Apr 2024 23:16:58 GMT
Subject: RFR: 8330542: Add two JAXP configuration files in preparation for
 a secure by default configuration [v5]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <XFmSoPfJP-LycD7VJdTw1hECad6LLDULTTauAWwhszY=.e0fb8501-f1a1-437c-a101-769eb0e6e7ec@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add warning msg that the config files can change or be removed.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/019c2aee..93b66312

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=03-04

  Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From brett.okken.os at gmail.com  Wed Apr 24 23:42:44 2024
From: brett.okken.os at gmail.com (Brett Okken)
Date: Wed, 24 Apr 2024 18:42:44 -0500
Subject: large longs to string
In-Reply-To: <59600078-F134-46C4-9846-C081A94244D6@oracle.com>
References: <CANBJVOHvX51APRTg+fCRYnDbuQuYfVKLyxV=pNE3J0+ASvGniw@mail.gmail.com>
 <59600078-F134-46C4-9846-C081A94244D6@oracle.com>
Message-ID: <CANBJVOHCbom4csrT9Gc_F81jkFSNoZ2fYcqMRaRwY0dNqU1zkQ@mail.gmail.com>

Claes,

> IIUC this optimization leans on 4 long divs being slower than 1 long div + 4 int divs

Exactly. I think there is also some benefit from unrolling the 4 int
digit pair operations.

> which might not be true on all platforms, nor stay true in the future

Agreed, but I am not sure how to reason about that.

> Long values will in practice likely be biased towards lower values, so it?s important that any optimization to .. longer values doesn?t regress inputs in the int range. Since it?s all guarded by a test that is already there there shouldn?t be much room for a difference, but adding code can cause interesting issues so it?s always worth measuring to make sure. Have you run any benchmark for inputs smaller than the threshold? And for a healthy mix of values?

I had been focused on "longer" values, as I have uses which are
effectively guaranteed to have some bits from 53-63 set.
I added some tests for "int" values as well as a mix with 2 "longs"
and 3 "ints". This showed a pretty small regression for the int and
mixed case. That regression went away by changing back to a while loop
comparing to Integer.MIN_VALUE, and that did not give up much of the
gain.

private static final long[] ints = new long[] {Integer.MAX_VALUE,
12345, -5432, 654321, 5};
private static final long[] longs = new long[] {235789987235L,
235789987235326L, -98975433216803632L, Long.MAX_VALUE};
private static final long[] mixed = new long[] {5, Long.MIN_VALUE,
654321, 9876543210L, 543};


Benchmark                         (type)  Mode  Cnt   Score    Error  Units
LongToStringBenchmark.baseline       int  avgt    3  24.105 ?? 11.751  ns/op
LongToStringBenchmark.baseline      long  avgt    3  51.223 ?? 21.069  ns/op
LongToStringBenchmark.baseline       mix  avgt    3  34.849 ??  7.270  ns/op
LongToStringBenchmark.change         int  avgt    3  25.846 ??  2.012  ns/op
LongToStringBenchmark.change        long  avgt    3  43.053 ?? 13.886  ns/op
LongToStringBenchmark.change         mix  avgt    3  35.826 ??  2.901  ns/op
LongToStringBenchmark.changeLoop     int  avgt    3  24.261 ??  7.325  ns/op
LongToStringBenchmark.changeLoop    long  avgt    3  44.254 ?? 22.921  ns/op
LongToStringBenchmark.changeLoop     mix  avgt    3  29.501 ??  8.693  ns/op


"change" is what I had proposed originally and "changeLoop" is:

while (i <= Integer.MIN_VALUE) {
  long q = i / 100_000_000;
  charPos -= 8;
  write4DigitPairs(buf, charPos, (int) ((q * 100_000_000) - i));
  v = q;
}

Brett


On Wed, Apr 24, 2024 at 2:39?PM Claes Redestad
<claes.redestad at oracle.com> wrote:
>
> Hi,
>
> IIUC this optimization leans on 4 long divs being slower than 1 long div + 4 int divs, which might not be true on all platforms, nor stay true in the future. Long values will in practice likely be biased towards lower values, so it?s important that any optimization to .. longer values doesn?t regress inputs in the int range. Since it?s all guarded by a test that is already there there shouldn?t be much room for a difference, but adding code can cause interesting issues so it?s always worth measuring to make sure. Have you run any benchmark for inputs smaller than the threshold? And for a healthy mix of values?
>
> Thanks!
> /Claes
>
> 24 apr. 2024 kl. 21:08 skrev Brett Okken <brett.okken.os at gmail.com>:
>
> Is there interest in optimizing StringLatin1.getChars(long, int, byte[]) for large (larger than int) long values[1]?
> We can change this to work with 8 digits at a time, which reduces the amount of 64 bit arithmetic required.
>
> if (i <= -1_000_000_000) {
> long q = i / 100_000_000;
> charPos -= 8;
> write4DigitPairs(buf, charPos, (int) ((q * 100_000_000) - i));
> i = q;
> if (i <= -1_000_000_000) {
> q = i / 100_000_000;
> charPos -= 8;
> write4DigitPairs(buf, charPos, (int) ((q * 100_000_000) - i));
> i = q;
> }
> }
>
>
> A simple implementation of write4DigitPairs would just call the existing writeDigitPair method 4 times:
>
>
> private static void write4DigitPairs(byte[] buf, int idx, int value) {
> int v = value;
> int v2 = v / 100;
> writeDigitPair(buf, idx + 6, v - (v2 * 100));
> v = v2;
>
> v2 = v / 100;
> writeDigitPair(buf, idx + 4, v - (v2 * 100));
> v = v2;
>
> v2 = v / 100;
> writeDigitPair(buf, idx + 2, v - (v2 * 100));
> v = v2;
>
> v2 = v / 100;
> writeDigitPair(buf, idx, v - (v2 * 100));
> }
>
> There is the option to OR the 4 short values together into a long and leverage a ByteArrayLittleEndian.setLong call, but I see that the previous usage of ByteArrayLittleEndian.setShort was removed[2].
>
> A small benchmark of longs which would qualify shows up to 20% improvement.
>
> Presumably a similar change could make sense for StringUTF16, but I have not spent any time benchmarking it.
>
> Brett
>
> [1] - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringLatin1.java#L163-L168
> [2] - https://github.com/openjdk/jdk/commit/913e43fea995b746fb9e1b25587d254396c7c3c9
>
>

From asotona at openjdk.org  Thu Apr 25 00:54:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 Apr 2024 00:54:37 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes
In-Reply-To: <xhnphsmt74pb52uEUwOarr0LZNHSlE3StvAdBelc61Y=.1f7bb136-3f2b-4499-b87d-916e0479162f@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
 <xhnphsmt74pb52uEUwOarr0LZNHSlE3StvAdBelc61Y=.1f7bb136-3f2b-4499-b87d-916e0479162f@github.com>
Message-ID: <Yq-gg4AoITsJrHMj_WV-LrwDENnQv1JqFro6Zj5KYM8=.66871edd-de1f-4fea-a38d-05ae7bf91d26@github.com>

On Wed, 24 Apr 2024 21:52:11 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Rather than duplicating some checks I wonder if it is possible to add a private method `entryByIndex(int index, int expectedTag)` that the existing `entryByIndex` defers to. If the `expectedTag` is non-negative then it checks `tag` against `expectedTag` before proceeding to the switch expression. Then the implementations of `readClassEntry` etc can be adjusted to pass along the expected tag.

Unfortunately it would have to be an expected tags list or an extra constructed bit mask, due to the multiple tags allowed for MemberRefEntry and it would slightly affect the performance. Also an additional info for the exception message would have to be passed down (or the exception would have to be re-thrown), as the tag mask is not very informative.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18907#issuecomment-2076114167

From jkratochvil at openjdk.org  Thu Apr 25 03:36:34 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 25 Apr 2024 03:36:34 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
Message-ID: <J30-OzJ-gEFc2G_YS3GPTaAbDrLk_OttJoJIf_rIUv4=.734ee302-f8e6-4512-b954-f3493867a1f2@github.com>

On Sun, 10 Mar 2024 14:40:09 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Fix whitespace
>  - Merge branch 'master' into master-cgroup
>    
>    Conflicts:
>    	test/hotspot/gtest/os/linux/test_cgroupSubsystem_linux.cpp
>  - Fix gtest
>  - Update the Java part
>  - Fix cgroup1 backward compatibility message
>  - Merge remote-tracking branch 'centos79/master-cgroup' into master-cgroup
>  - Disable cgroup.subtree_control testcase on cgroup1
>  - Fix gtest
>  - Merge branch 'master' into master-cgroup
>  - Merge remote-tracking branch 'f38crac/master-cgroup' into master-cgroup
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/243cb098...39c90162

ping, it is already 6+ weeks since last change

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2076286758

From imediava at gmail.com  Thu Apr 25 04:29:57 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Thu, 25 Apr 2024 06:29:57 +0200
Subject: Need for a sponsor for JDK-8313674
Message-ID: <CA+wBRWDnd8xCpb5VaL5sS78Ga+3Gyo=D-05n3EFgnkNVgyYjfw@mail.gmail.com>

Hello,

For my first contribution to OpenJDK, I've started looking into
JDK-8313674, an issue that falls into core-libs. According to the OpenJDK
Developers? Guide I'd need a sponsor to help me through the contribution
process, would anyone be available to help me ?

Thanks in advance

??igo Mediavilla Saiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240425/ce30e440/attachment.htm>

From Alan.Bateman at oracle.com  Thu Apr 25 05:32:43 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Apr 2024 06:32:43 +0100
Subject: Need for a sponsor for JDK-8313674
In-Reply-To: <CA+wBRWDnd8xCpb5VaL5sS78Ga+3Gyo=D-05n3EFgnkNVgyYjfw@mail.gmail.com>
References: <CA+wBRWDnd8xCpb5VaL5sS78Ga+3Gyo=D-05n3EFgnkNVgyYjfw@mail.gmail.com>
Message-ID: <b9fad670-1e7e-47ef-80a7-d08a6a388df0@oracle.com>

On 25/04/2024 05:29, I?igo Mediavilla wrote:
> Hello,
>
> For my first contribution to OpenJDK, I've started looking into 
> JDK-8313674, an issue that falls into core-libs. According to the 
> OpenJDK Developers? Guide I'd need a sponsor to help me through the 
> contribution process, would anyone be available to help me ?

That's a request to update a test test to have it check for NVMe 
devices, the place to discuss that is nio-dev. I see it has recently 
been assigned to someone so it would be polite to check with this person 
in case they are already working on it.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240425/ba867e93/attachment.htm>

From imediava at gmail.com  Thu Apr 25 05:40:26 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Thu, 25 Apr 2024 07:40:26 +0200
Subject: Need for a sponsor for JDK-8313674
In-Reply-To: <b9fad670-1e7e-47ef-80a7-d08a6a388df0@oracle.com>
References: <CA+wBRWDnd8xCpb5VaL5sS78Ga+3Gyo=D-05n3EFgnkNVgyYjfw@mail.gmail.com>
 <b9fad670-1e7e-47ef-80a7-d08a6a388df0@oracle.com>
Message-ID: <CA+wBRWDpzTNZfxTwk3SqCyvGwgbhDJ4CtNUCAQQ1JLUrKbN==w@mail.gmail.com>

Thank Alan.

I will redirect my email to the other mailing list and include the person
who has been assigned to that ticket to see if we can collaborate or he
already has a fix.

??igo


El jue, 25 abr 2024, 7:32, Alan Bateman <Alan.Bateman at oracle.com> escribi?:

> On 25/04/2024 05:29, I?igo Mediavilla wrote:
>
> Hello,
>
> For my first contribution to OpenJDK, I've started looking into
> JDK-8313674, an issue that falls into core-libs. According to the OpenJDK
> Developers? Guide I'd need a sponsor to help me through the contribution
> process, would anyone be available to help me ?
>
>
> That's a request to update a test test to have it check for NVMe devices,
> the place to discuss that is nio-dev. I see it has recently been assigned
> to someone so it would be polite to check with this person in case they are
> already working on it.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240425/2bde374e/attachment-0001.htm>

From jai.forums2013 at gmail.com  Thu Apr 25 05:44:19 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 25 Apr 2024 11:14:19 +0530
Subject: Need for a sponsor for JDK-8313674
In-Reply-To: <CA+wBRWDnd8xCpb5VaL5sS78Ga+3Gyo=D-05n3EFgnkNVgyYjfw@mail.gmail.com>
References: <CA+wBRWDnd8xCpb5VaL5sS78Ga+3Gyo=D-05n3EFgnkNVgyYjfw@mail.gmail.com>
Message-ID: <cd555ab7-7973-4a18-bf20-374d454c3a06@gmail.com>

Hello ??igo,

https://bugs.openjdk.org/browse/JDK-8313674 is already assigned to 
someone else. Have you checked with them if it's OK to work on this one?

-Jaikiran

On 25/04/24 9:59 am, I?igo Mediavilla wrote:
> Hello,
>
> For my first contribution to OpenJDK, I've started looking into 
> JDK-8313674, an issue that falls into core-libs. According to the 
> OpenJDK Developers? Guide I'd need a sponsor to help me through the 
> contribution process, would anyone be available to help me ?
>
> Thanks in advance
>
> ??igo Mediavilla Saiz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240425/f3752b0c/attachment.htm>

From asotona at openjdk.org  Thu Apr 25 06:59:27 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 Apr 2024 06:59:27 GMT
Subject: RFR: 8322847: java.lang.classfile.BufWriter should specify @throws
 for its writeXXX methods
In-Reply-To: <TwrCOKn9SLx_P9lxuUpw4HAJBc6ZASlhLlSUzh93vIc=.e977b8c9-2d0d-4676-aedd-49e75c41bbaf@github.com>
References: <LbGxj-m_26dMeRG6TgVNN16NSWtmutE5jW5pL4r1_7o=.84713a17-9ffe-435a-96e7-f1e9f5d8345a@github.com>
 <TwrCOKn9SLx_P9lxuUpw4HAJBc6ZASlhLlSUzh93vIc=.e977b8c9-2d0d-4676-aedd-49e75c41bbaf@github.com>
Message-ID: <nY8dTtV6IW9PgXp1BDbmE6Vnmjx3_QG22hVmHsXpP9k=.2678939c-a9ee-4d14-a3be-f327d1fde7ed@github.com>

On Wed, 24 Apr 2024 22:43:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This looks good, but for completeness it will need a CSR.

CSR created, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18913#issuecomment-2076498451

From asotona at openjdk.org  Thu Apr 25 07:07:43 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 Apr 2024 07:07:43 GMT
Subject: RFR: 8325373: Improve StackCounter error reporting for bad switch
 cases [v2]
In-Reply-To: <WMLtToC6NJi2EqmVr6S3LjYQ8S8gMLh4UBnL6asW8hE=.a04dd343-0635-44d5-9a26-65e5842a0a9f@github.com>
References: <WMLtToC6NJi2EqmVr6S3LjYQ8S8gMLh4UBnL6asW8hE=.a04dd343-0635-44d5-9a26-65e5842a0a9f@github.com>
Message-ID: <UXvQn6GouKNhI4liY0C62J4FrW588bd5_3r_C9BMIoI=.009ee01e-597c-4272-a099-d79dd71dc48e@github.com>

> ClassFile API `StackMapGenerator` attaches print or hex dump of the method to an error message.
> However there is no such attachment when the stack maps generation is  turned off.
> 
> This patch moves class print/dump to `impl.Util::dumpMethod`, so it is shared by `StackMapGenerator` and `StackCounter` to provide the same level of details in case of an error.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  applied suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18914/files
  - new: https://git.openjdk.org/jdk/pull/18914/files/f59654be..1824d1fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18914&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18914&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18914/head:pull/18914

PR: https://git.openjdk.org/jdk/pull/18914

From asotona at openjdk.org  Thu Apr 25 07:07:43 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 Apr 2024 07:07:43 GMT
Subject: RFR: 8325373: Improve StackCounter error reporting for bad switch
 cases [v2]
In-Reply-To: <oIu7dm6XJEzeRcfwSywSpVPtS0xiRy9Y2SJQkxFa56E=.2f91b65d-7214-4ae9-ab70-9ce34ff07950@github.com>
References: <WMLtToC6NJi2EqmVr6S3LjYQ8S8gMLh4UBnL6asW8hE=.a04dd343-0635-44d5-9a26-65e5842a0a9f@github.com>
 <oIu7dm6XJEzeRcfwSywSpVPtS0xiRy9Y2SJQkxFa56E=.2f91b65d-7214-4ae9-ab70-9ce34ff07950@github.com>
Message-ID: <WyLfl-3pkqArS6miTq7j3t2jLyy1wXqFTIr11XUgLAc=.f3fe5618-3f11-4f7a-9104-2dabd4595c8c@github.com>

On Wed, 24 Apr 2024 22:48:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 229:
> 
>> 227:                     }))));
>> 228:             ClassPrinter.toYaml(clm.methods().get(0).code().get(), ClassPrinter.Verbosity.TRACE_ALL, dump);
>> 229:         } catch (Error | Exception suppresed) {
> 
> If you like you can replace `suppresed` [sic] with `_`.

Both fixed, thanks for the review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18914#discussion_r1578982248

From asotona at openjdk.org  Thu Apr 25 07:07:43 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 Apr 2024 07:07:43 GMT
Subject: Integrated: 8325373: Improve StackCounter error reporting for bad
 switch cases
In-Reply-To: <WMLtToC6NJi2EqmVr6S3LjYQ8S8gMLh4UBnL6asW8hE=.a04dd343-0635-44d5-9a26-65e5842a0a9f@github.com>
References: <WMLtToC6NJi2EqmVr6S3LjYQ8S8gMLh4UBnL6asW8hE=.a04dd343-0635-44d5-9a26-65e5842a0a9f@github.com>
Message-ID: <Lv1pdYEuterKRXjB-v6PwN_phduTlOhEq532ROU1GL8=.71a24da7-5ead-459b-bf05-77831b90e555@github.com>

On Tue, 23 Apr 2024 12:59:18 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API `StackMapGenerator` attaches print or hex dump of the method to an error message.
> However there is no such attachment when the stack maps generation is  turned off.
> 
> This patch moves class print/dump to `impl.Util::dumpMethod`, so it is shared by `StackMapGenerator` and `StackCounter` to provide the same level of details in case of an error.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: ccc0d0f7
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ccc0d0f7b194a9941e2cadba1c389aa0834c52e4
Stats:     98 lines in 3 files changed: 56 ins; 31 del; 11 mod

8325373: Improve StackCounter error reporting for bad switch cases

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/18914

From asotona at openjdk.org  Thu Apr 25 08:03:54 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 Apr 2024 08:03:54 GMT
Subject: RFR: 8331097: Tests build is broken after pr/18914
Message-ID: <U3GNg5bOb7G-zW6N0lH-kf5mDJOci0973PFv2c3ejkY=.77574529-b057-4315-becf-ad843007e6bf@github.com>

Pr/18914 broke tests build.
This patch fixes `test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools`

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8331097: Tests build is broken after pr/18914

Changes: https://git.openjdk.org/jdk/pull/18943/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18943&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331097
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18943/head:pull/18943

PR: https://git.openjdk.org/jdk/pull/18943

From alanb at openjdk.org  Thu Apr 25 08:08:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Apr 2024 08:08:29 GMT
Subject: RFR: 8331097: Tests build is broken after pr/18914
In-Reply-To: <U3GNg5bOb7G-zW6N0lH-kf5mDJOci0973PFv2c3ejkY=.77574529-b057-4315-becf-ad843007e6bf@github.com>
References: <U3GNg5bOb7G-zW6N0lH-kf5mDJOci0973PFv2c3ejkY=.77574529-b057-4315-becf-ad843007e6bf@github.com>
Message-ID: <HDrVU7kXfGcK2qVkjcb5fkzrV92EuN-eRNSx3ehDPAw=.6115a623-b5b8-4aa3-b12b-8a674bb8d241@github.com>

On Thu, 25 Apr 2024 07:56:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Pr/18914 broke tests build.
> This patch fixes `test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools`
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18943#pullrequestreview-2021821209

From asotona at openjdk.org  Thu Apr 25 08:12:34 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 Apr 2024 08:12:34 GMT
Subject: Integrated: 8331097: Tests build is broken after pr/18914
In-Reply-To: <U3GNg5bOb7G-zW6N0lH-kf5mDJOci0973PFv2c3ejkY=.77574529-b057-4315-becf-ad843007e6bf@github.com>
References: <U3GNg5bOb7G-zW6N0lH-kf5mDJOci0973PFv2c3ejkY=.77574529-b057-4315-becf-ad843007e6bf@github.com>
Message-ID: <j14fpeJaz3NYfdYAvaZoWZpZ7FvCB9tGmB3U28TBbss=.386a7b90-2641-43c2-a0d0-49656f0e4c3a@github.com>

On Thu, 25 Apr 2024 07:56:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Pr/18914 broke tests build.
> This patch fixes `test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools`
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ef745a6c
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef745a6c6e4068e786a70fc5574d272140c01e0f
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8331097: Tests build is broken after pr/18914

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/18943

From vklang at openjdk.org  Thu Apr 25 08:28:35 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 25 Apr 2024 08:28:35 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v25]
In-Reply-To: <jkZ-gpxv7E1Eov1_7RJFiBhtXs0gy1WUkxNdGZ1j4EU=.3860f93c-b8c3-4628-acc9-e3be1405b461@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <jkZ-gpxv7E1Eov1_7RJFiBhtXs0gy1WUkxNdGZ1j4EU=.3860f93c-b8c3-4628-acc9-e3be1405b461@github.com>
Message-ID: <QYPKvVXtbok97VG4G8lbQOihzUBsO0aaeEyf6gaYihU=.7eb88222-132e-43f9-892a-80af9ab3f8b8@github.com>

On Wed, 24 Apr 2024 23:15:45 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   package spec updates, mostly about reference queues and dequeueing

src/java.base/share/classes/java/lang/ref/package-info.java line 153:

> 151:  * <li> The enqueueing of a reference (by the garbage collector, or
> 152:  * by a successful call to {@link Reference#enqueue}) <i>happens-before</i>
> 153:  * the reference is removed from the queue (<em>dequeued</em>).</li>

@bchristi-git I wonder if it makes sense to use the same style when referring to "dequeue", so either always within quotes or only using <em>em</em> (see line 108)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1579082626

From redestad at openjdk.org  Thu Apr 25 09:45:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 09:45:36 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString
Message-ID: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>

When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.

Performance improves across the board in existing microbenchmarks:

Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
  * = significant


The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:

Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
  * = significant
  ```
  
 I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.

-------------

Commit messages:
 - Optimize MethodTypeDescImpl::toString

Changes: https://git.openjdk.org/jdk/pull/18945/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331114
  Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18945/head:pull/18945

PR: https://git.openjdk.org/jdk/pull/18945

From mdoerr at openjdk.org  Thu Apr 25 11:04:28 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 25 Apr 2024 11:04:28 GMT
Subject: RFR: 8330615: avoid signed integer overflows in zip_util.c readCen
 / hashN
In-Reply-To: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
References: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
Message-ID: <TRu1NXhdPKEHf5KeJs6aHx7AhHLCrL_LIkNiPta2y14=.c3fd24d8-a3da-4906-9476-2dbc7fd6d4d5@github.com>

On Tue, 23 Apr 2024 07:51:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the hashN usages of readCen from zip_util.c we see a lot of signed integer overflows.
> For example in the java/util jtreg tests those are easily reproducable when compiling with -ftrapv (clang/gcc toolchains).
> While those overflows never seem to cause crashes or similar errors, they are unwanted because
> signed integer overflows in C cause undefined behavior.
> See
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html
>>
>> For signed integers, the result of overflow in C is in principle undefined, meaning that anything whatsoever could happen.
>> Therefore, C compilers can do optimizations that treat the overflow case with total unconcern.
> 
> So we might still get unwanted results (maybe bad/strange hashing, depending on compiler and optimization level).
> 
> Compilation with -ftrapv causes/triggers this SIGILL on macOS showing the issue :
> # Problematic frame:
> # C [libzip.dylib+0x6362] hashN+0x32
> #
> 
> Stack: [0x000070000c496000,0x000070000c596000], sp=0x000070000c5957e0, free space=1021k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libzip.dylib+0x6362] hashN+0x32
> C [libzip.dylib+0x5d5e] readCEN+0xd2e
> C [libzip.dylib+0x4ee0] ZIP_Put_In_Cache0+0x160
> V [libjvm.dylib+0x544b1e] ClassLoader::open_zip_file(char const*, char**, JavaThread*)+0x3e
> V [libjvm.dylib+0x543fec] ClassLoader::create_class_path_entry(JavaThread*, char const*, stat const*, bool, bool)+0x6c
> V [libjvm.dylib+0x543833] ClassLoader::setup_bootstrap_search_path_impl(JavaThread*, char const*)+0xf3
> V [libjvm.dylib+0x54819b] classLoader_init1()+0x1b
> V [libjvm.dylib+0x92602a] init_globals()+0x3a
> V [libjvm.dylib+0x12b3b74] Threads::create_vm(JavaVMInitArgs*, bool*)+0x314
> V [libjvm.dylib+0xa848f4] JNI_CreateJavaVM+0x64
> C [libjli.dylib+0x4483] JavaMain+0x123
> C [libjli.dylib+0x7529] ThreadJavaMain+0x9
> C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0
> C [libsystem_pthread.dylib+0x2443] thread_start+0xf

Undefined behavior should always get fixed. Thanks for doing it!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18908#pullrequestreview-2022189272

From duke at openjdk.org  Thu Apr 25 11:14:27 2024
From: duke at openjdk.org (Florent Guillaume)
Date: Thu, 25 Apr 2024 11:14:27 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString
In-Reply-To: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
Message-ID: <mPbuwP4S3uP29_2Gx4pYqMYqQk1d0clLDC_eRtScaQM=.4ef37726-ad08-4a8c-968d-d9d1745b1c1b@github.com>

On Thu, 25 Apr 2024 09:41:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
> 
> Performance improves across the board in existing microbenchmarks:
> 
> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>   * = significant
> 
> 
> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
> 
> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>   * = significant
>   ```
>   
>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.

src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 210:

> 208:         StringBuilder sb = new StringBuilder(24).append('(');
> 209:         for (int i = 0; i < count; i++) {
> 210:             sb.append(parameterType(i).displayName());

Aren't you forgetting the comma?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18945#discussion_r1579294651

From duke at openjdk.org  Thu Apr 25 11:33:34 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 25 Apr 2024 11:33:34 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <3bVBncVGIg7Wh46TGgEevHt9AWqNvAcU2Cke8iQNn9A=.8d40431e-c578-4d5b-9dbd-c9e9fd55bb91@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <EraXrOvD8Jm9Yy6ZwOB448SUHswYn9Nu_X_FMMQrTYc=.7c049574-d1c8-4c1f-9b2d-a6cd68f7f2c0@github.com>
 <UeTlF6XlFqMijlqRAt_EBrPYzMSOjLmvqPXej5m4Qz8=.c54e472c-1b98-4817-9c09-34b6188f7797@github.com>
 <3bVBncVGIg7Wh46TGgEevHt9AWqNvAcU2Cke8iQNn9A=.8d40431e-c578-4d5b-9dbd-c9e9fd55bb91@github.com>
Message-ID: <9EJL-cRnLZCgMBlQwAmrCRgtUWxshmL-lpuEUyN5XE4=.b4bd83ee-6cc5-4c2d-8f4d-09aa7f8522c0@github.com>

On Tue, 19 Mar 2024 19:32:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I think splitting `CharArraySequence` into two versions is somewhat dubious as more observable types at call sites may mean the performance gain in targeted micros is lost. How much of an improvement did you observe from this? Again the `char[]` constructors is probably less performance sensitive than the others.
>
>> @cl4es @jddarcy All feedback has been fixed, can it be integrated?
> 
> Hello @wenshao ,
> 
> This change will need additional review from myself or others who maintain BigDecimal before it can be integrated.

@jddarcy Sorry for the pings, Can you review this PR for me?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2076967334

From mbaesken at openjdk.org  Thu Apr 25 12:09:30 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Apr 2024 12:09:30 GMT
Subject: RFR: 8330615: avoid signed integer overflows in zip_util.c readCen
 / hashN
In-Reply-To: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
References: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
Message-ID: <8nCaPi5-N-hDqUSLcQ1QdkAnzETlg5i_FP3hIeDhMeA=.d2fd8a30-57f0-46a0-ab78-fa3e07674f54@github.com>

On Tue, 23 Apr 2024 07:51:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the hashN usages of readCen from zip_util.c we see a lot of signed integer overflows.
> For example in the java/util jtreg tests those are easily reproducable when compiling with -ftrapv (clang/gcc toolchains).
> While those overflows never seem to cause crashes or similar errors, they are unwanted because
> signed integer overflows in C cause undefined behavior.
> See
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html
>>
>> For signed integers, the result of overflow in C is in principle undefined, meaning that anything whatsoever could happen.
>> Therefore, C compilers can do optimizations that treat the overflow case with total unconcern.
> 
> So we might still get unwanted results (maybe bad/strange hashing, depending on compiler and optimization level).
> 
> Compilation with -ftrapv causes/triggers this SIGILL on macOS showing the issue :
> # Problematic frame:
> # C [libzip.dylib+0x6362] hashN+0x32
> #
> 
> Stack: [0x000070000c496000,0x000070000c596000], sp=0x000070000c5957e0, free space=1021k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libzip.dylib+0x6362] hashN+0x32
> C [libzip.dylib+0x5d5e] readCEN+0xd2e
> C [libzip.dylib+0x4ee0] ZIP_Put_In_Cache0+0x160
> V [libjvm.dylib+0x544b1e] ClassLoader::open_zip_file(char const*, char**, JavaThread*)+0x3e
> V [libjvm.dylib+0x543fec] ClassLoader::create_class_path_entry(JavaThread*, char const*, stat const*, bool, bool)+0x6c
> V [libjvm.dylib+0x543833] ClassLoader::setup_bootstrap_search_path_impl(JavaThread*, char const*)+0xf3
> V [libjvm.dylib+0x54819b] classLoader_init1()+0x1b
> V [libjvm.dylib+0x92602a] init_globals()+0x3a
> V [libjvm.dylib+0x12b3b74] Threads::create_vm(JavaVMInitArgs*, bool*)+0x314
> V [libjvm.dylib+0xa848f4] JNI_CreateJavaVM+0x64
> C [libjli.dylib+0x4483] JavaMain+0x123
> C [libjli.dylib+0x7529] ThreadJavaMain+0x9
> C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0
> C [libsystem_pthread.dylib+0x2443] thread_start+0xf

Hi Lutz and Martin, thanks for the reviews!
Jaikiran, are you done with your additional tests ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18908#issuecomment-2077026022

From alanb at openjdk.org  Thu Apr 25 12:18:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Apr 2024 12:18:31 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v2]
In-Reply-To: <Bg1VtHLH-BTCQtkDYkqMclbYOWAs0ZnzvWv83GaAi4M=.cfafe4bf-aabc-456d-b319-fdf43250ce70@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <Bg1VtHLH-BTCQtkDYkqMclbYOWAs0ZnzvWv83GaAi4M=.cfafe4bf-aabc-456d-b319-fdf43250ce70@github.com>
Message-ID: <xqxOlYsBtb_H0IZ9ssDOYM_w47MJO73aw1ha2PXNVLY=.571b56ce-4000-4c58-932e-e5c49f94133f@github.com>

On Wed, 24 Apr 2024 15:27:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed package jdk.random to jdk.internal.random.

I wish I could remember, or find the JBS issue or PR with the discussion, to remind us as to why the implementations were put into a separate module in the first place.

The changes in the PR looks okay. I'm just wondering if we also need to re-examine the wording in RandomGeneratorFactory methods where it documents  "uses the service provider API". I'm surprised this is documented as an implementation requirement. Also "service provider API" should really be ServiceLoader API.

One other thing is that we'll need a release note for this change. It's possible there are scripts somewhere in the wild that use jlink and specify the jdk.random module in the sets of modules to include. These scrips will break with this change. I don't think it's worth leaving a hollowed out module in its place but we should at least document that it has been removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2077043094

From stuefe at openjdk.org  Thu Apr 25 12:50:29 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Apr 2024 12:50:29 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v5]
In-Reply-To: <gC_tj8pr-DjJpponY6WLeMAAMhrRObOyx5hgev_qd7s=.9fffb44f-129b-40f9-a50e-15db0cbf8faa@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <gC_tj8pr-DjJpponY6WLeMAAMhrRObOyx5hgev_qd7s=.9fffb44f-129b-40f9-a50e-15db0cbf8faa@github.com>
Message-ID: <kILXOWMKMQCcsldaA_b7m5uDmg3M1zAzwGyxw34nGAk=.2af3ca8f-c6fb-4991-b756-e5e2f5b8f38b@github.com>

On Tue, 23 Apr 2024 14:31:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust output

LGTM

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18699#pullrequestreview-2022399268

From alanb at openjdk.org  Thu Apr 25 13:00:34 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Apr 2024 13:00:34 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v4]
In-Reply-To: <XO3GjvTNzi6RAoxptfg1HhtZWQY5dN2dRjDNGRCy9z8=.21505b3a-57ef-4faa-9b77-525c97fa06d2@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <-bdz0tYFAoe3A4ohijJ57S5JvxXqCA_EnVZdCbjqGTI=.4957b13d-02d9-419f-8546-7c587160ef5c@github.com>
 <XO3GjvTNzi6RAoxptfg1HhtZWQY5dN2dRjDNGRCy9z8=.21505b3a-57ef-4faa-9b77-525c97fa06d2@github.com>
Message-ID: <M4l0FMwq-XPF7TeXa8QaSHUA7lN6YNcuGjs-QbFm2SQ=.5ef8d079-6d97-4f21-a1a7-0289f8554589@github.com>

On Tue, 23 Apr 2024 14:29:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 
> `/* Does the app ship a private JRE in <apphome>/jre directory? */`
> 
> part meant? This looks indeed obsolete .

Yes, this is code that doesn't make sense since JDK 9 and should be removed/cleanup at some point. I suspect we had to leave it at the time because of the issue of installers copying java.exe into a shared location and expecting it to work with any JRE or JDK release, something that doesn't make sense now of course.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2077120542

From duke at openjdk.org  Thu Apr 25 13:16:58 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 25 Apr 2024 13:16:58 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v14]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <LwzO6nUOoNgMbKew4G1rhQV0hplhXg3AFAYygSH1pfY=.0cfb0df6-407a-496f-ba28-c3546cdd1711@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with one additional commit since the last revision:

  Empty commit to rerun checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/d2f358b3..59cbeb69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=12-13

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From mbaesken at openjdk.org  Thu Apr 25 13:22:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Apr 2024 13:22:01 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v6]
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove /jre path check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18699/files
  - new: https://git.openjdk.org/jdk/pull/18699/files/4d998244..4d8b6802

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18699&range=04-05

  Stats: 24 lines in 2 files changed: 0 ins; 24 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18699/head:pull/18699

PR: https://git.openjdk.org/jdk/pull/18699

From mbaesken at openjdk.org  Thu Apr 25 13:22:02 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Apr 2024 13:22:02 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v5]
In-Reply-To: <gC_tj8pr-DjJpponY6WLeMAAMhrRObOyx5hgev_qd7s=.9fffb44f-129b-40f9-a50e-15db0cbf8faa@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <gC_tj8pr-DjJpponY6WLeMAAMhrRObOyx5hgev_qd7s=.9fffb44f-129b-40f9-a50e-15db0cbf8faa@github.com>
Message-ID: <rk9SWljzgkvPpacUzjy4ghQWxShrcf3H-zzUoBr7-eU=.53731655-8b5a-43f2-842e-910cf5692cdd@github.com>

On Tue, 23 Apr 2024 14:31:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust output

I removed the mentioned 'private JRE'  check and also the related size check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2077160938

From redestad at openjdk.org  Thu Apr 25 13:34:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 13:34:50 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
Message-ID: <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>

> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
> 
> Performance improves across the board in existing microbenchmarks:
> 
> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>   * = significant
> 
> 
> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
> 
> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>   * = significant
>   ```
>   
>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  comma-separated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18945/files
  - new: https://git.openjdk.org/jdk/pull/18945/files/06947305..2979847c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18945/head:pull/18945

PR: https://git.openjdk.org/jdk/pull/18945

From redestad at openjdk.org  Thu Apr 25 13:34:51 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 13:34:51 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <mPbuwP4S3uP29_2Gx4pYqMYqQk1d0clLDC_eRtScaQM=.4ef37726-ad08-4a8c-968d-d9d1745b1c1b@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <mPbuwP4S3uP29_2Gx4pYqMYqQk1d0clLDC_eRtScaQM=.4ef37726-ad08-4a8c-968d-d9d1745b1c1b@github.com>
Message-ID: <Sxdi4ovLhbgdWv-Q4F7nAppyeZAm9HEQgekz4BYxAa0=.bafac12d-d280-4560-a317-4d1167a3c6c3@github.com>

On Thu, 25 Apr 2024 11:11:48 GMT, Florent Guillaume <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comma-separated
>
> src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 210:
> 
>> 208:         StringBuilder sb = new StringBuilder(24).append('(');
>> 209:         for (int i = 0; i < count; i++) {
>> 210:             sb.append(parameterType(i).displayName());
> 
> Aren't you forgetting the comma?

Well spotted - fixed!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18945#discussion_r1579476846

From liach at openjdk.org  Thu Apr 25 13:38:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 Apr 2024 13:38:37 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
Message-ID: <XFaPKReMDXYVSCXeE5lGXEAylsd9foJ2Y8-CZcNiUwU=.607258f3-6de7-405b-ae08-a55c50936bea@github.com>

On Thu, 25 Apr 2024 13:34:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comma-separated

Do we have any research on the average length of method descriptor strings? I wonder if manual pre-allocation works better (iterating all descriptor strings, allocate the sum of their sizes plus 2 (for parentheses), as descriptor strings won't be re-calculated after initial allocation.)
Especially in case of user code, as many user classes have very long package names that can easily make the string much longer than the 24-char default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18945#issuecomment-2077206533

From vklang at openjdk.org  Thu Apr 25 13:41:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 25 Apr 2024 13:41:32 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
Message-ID: <BBy5kHQM9u64ywMJ9nU7N3ztRZffOosEJNgBWQW034E=.a405d1ce-acf0-431e-abc8-56a76f7dbfc3@github.com>

On Thu, 25 Apr 2024 13:34:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comma-separated

src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 208:

> 206:     default String displayDescriptor() {
> 207:         int count = parameterCount();
> 208:         StringBuilder sb = new StringBuilder(24).append('(');

24 is chosen by fair dice-roll? :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18945#discussion_r1579491160

From duke at openjdk.org  Thu Apr 25 13:57:07 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 25 Apr 2024 13:57:07 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v15]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <IBQeFmwGaZDKSCf58qcZqDw4RH4QLya705fJoWo03jU=.5023f535-6293-4ff6-bbd4-c01b2ef516b2@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with one additional commit since the last revision:

  Revert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/59cbeb69..9166be30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

PR: https://git.openjdk.org/jdk/pull/18639

From sgehwolf at openjdk.org  Thu Apr 25 14:00:36 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 25 Apr 2024 14:00:36 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
Message-ID: <SKsDLJyYeH7JIFjyCHzh9xJ76ngLu3lc3LFUBL4xnxw=.2ca1f741-8d97-4136-b8b7-454eda22037f@github.com>

On Sun, 10 Mar 2024 14:40:09 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Fix whitespace
>  - Merge branch 'master' into master-cgroup
>    
>    Conflicts:
>    	test/hotspot/gtest/os/linux/test_cgroupSubsystem_linux.cpp
>  - Fix gtest
>  - Update the Java part
>  - Fix cgroup1 backward compatibility message
>  - Merge remote-tracking branch 'centos79/master-cgroup' into master-cgroup
>  - Disable cgroup.subtree_control testcase on cgroup1
>  - Fix gtest
>  - Merge branch 'master' into master-cgroup
>  - Merge remote-tracking branch 'f38crac/master-cgroup' into master-cgroup
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/243cb098...39c90162

Thanks for the updates. I like that we have consistency between cgv1 and cgv2 in the latest version in terms of hierarchical limit. What would be even better is to get consistency between CPU and memory lookup (if the restriction is enforced higher up the hierarchy). That is, it would be ideal to make `initialize_hierarchy()` controller specific.

Meanwhile I've been working on [some refactoring](https://github.com/jerboaa/jdk/commit/92aaa6fd7e3ff8b64de064fecfcd725a157cb5bb) which builds on top of [JDK-8302744](https://bugs.openjdk.org/browse/JDK-8302744) so as to make the code a bit nicer once this integrates. Then, the idea would be to use scratch controllers (`CgroupCpuController` and `CgroupMemoryController`) to determine whether or not there is a limit and figure out the actual path on a per-controller specific way - (use `CgroupMemoryController->read_memory_limit_in_bytes(phys_mem)` and `CgroupUtil::processor_count(CgroupCpuController* cpu_ctrl, int host_cpus)` in the process). Does that make sense?

A few other observations:

- The common case is when the JVM runs in a container. Then, the cgroup path is `/` on cgv2 and the and `root_mount == cgroup_path` on cgv1. We don't need to do the extra processing on those systems as the limit will be at the leaf.
- The (fairly) uncommon case is the host case where the cgroup limit is applied elsewhere (e.g. systemd slice). This is where we'd need the hierarchy walk.
- When we need to walk the hierarchy, we start at the longest path and only traverse if there is _NO_ limit. A system which sets a higher, limit (that isn't `max`), seems ill-defined and I've not come across one.
   As soon as we've found a lower value than unlimited (`-1`), we stop.
   Since cg2 is hierarchical, the lowest limit will affect the entire tree (corollary: higher values further down from that point won't have an effect):
   ```
   /a/b --> memory.max 300
      `- /c --> memory.max max (this wouldn't have any effect, therefore can be ignored).
    ```

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2077263573

From redestad at openjdk.org  Thu Apr 25 14:04:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 14:04:34 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <BBy5kHQM9u64ywMJ9nU7N3ztRZffOosEJNgBWQW034E=.a405d1ce-acf0-431e-abc8-56a76f7dbfc3@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
 <BBy5kHQM9u64ywMJ9nU7N3ztRZffOosEJNgBWQW034E=.a405d1ce-acf0-431e-abc8-56a76f7dbfc3@github.com>
Message-ID: <g2_BVj52eakUuVGaZPZuV4y0dV1Fx8yj0IARxQdDCuM=.0b1de203-9d45-45f7-900c-55f0eb7be774@github.com>

On Thu, 25 Apr 2024 13:38:56 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comma-separated
>
> src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 208:
> 
>> 206:     default String displayDescriptor() {
>> 207:         int count = parameterCount();
>> 208:         StringBuilder sb = new StringBuilder(24).append('(');
> 
> 24 is chosen by fair dice-roll? :)

More or less: default capacity is 16, 24 is 1.5x that - a pretty typical growth factor. It also happens to be enough for very common descriptors such as `()Ljava/lang/Object;` while not too large to cause a regression on very small (and also very common) descriptors such as `()V`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18945#discussion_r1579533391

From clanger at openjdk.org  Thu Apr 25 14:09:33 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 14:09:33 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v6]
In-Reply-To: <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
Message-ID: <ic3P6n4DJlf7CD_Xoxh5hKSnF8JVJcDujafw1tsIuZ0=.556b9dff-4962-4828-9dce-8e4e27a27791@github.com>

On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove /jre path check

Still looks good. We should maybe change the synopsis (title) of the bug to something like "libjli GetApplicationHome cleanups"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2077289573

From redestad at openjdk.org  Thu Apr 25 14:20:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 14:20:35 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v7]
In-Reply-To: <IZQ3b3Au-9AEuy_yxPa-5oUwc8WuwvWXHPmLxv3LeVU=.455872b1-affe-46dd-a430-c3cd3e61d5e7@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <QqaVCWUEgegmBhAGkQoqohz7m9odq37wuzEDuYi9vGY=.9130de89-f279-4d0c-aaae-e90ea0da6b06@github.com>
 <rsk58VsvHp5ZeBZ-LwcnYdcCQUidXR-iTm7CQrEeNy4=.fc909e58-d5f9-4b39-b827-c040463c99dc@github.com>
 <IZQ3b3Au-9AEuy_yxPa-5oUwc8WuwvWXHPmLxv3LeVU=.455872b1-affe-46dd-a430-c3cd3e61d5e7@github.com>
Message-ID: <iGBJ_lc4zYbiaC6Uq6qAp7d4X7GWzNj-7ofV21zvxP8=.cbcdf333-a4de-4783-b3e9-ad1f409f0039@github.com>

On Wed, 24 Apr 2024 10:05:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> I really wish this change was not done with ClassFile API, but with a simple bundled ASM, so it would be easily backportable, if we decide to. It does not look like CFA buys us a lot here readability/complexity wise: [d99b159](https://github.com/openjdk/jdk/commit/d99b1596c5ca57b110c1db88be430c6c54c3d599)
>> 
>> I would be open to splitting out and pushing the ASM version first and do this CFA port as a follow-up.
>
>> > I really wish this change was not done with ClassFile API, but with a simple bundled ASM, so it would be easily backportable, if we decide to. It does not look like CFA buys us a lot here readability/complexity wise: [d99b159](https://github.com/openjdk/jdk/commit/d99b1596c5ca57b110c1db88be430c6c54c3d599)
>> 
>> I would be open to splitting out and pushing the ASM version first and do this CFA port as a follow-up.
> 
> That would be good, thanks.

@shipilev @mlchung opened new PR #18953 for pushing the ASM-based version. Adapted applicable code changes from this PR so it should be equivalent in behavior.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2077319721

From redestad at openjdk.org  Thu Apr 25 14:20:58 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 14:20:58 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
Message-ID: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>

Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.

-------------

Commit messages:
 - Adapt main PR feedback to ASM version
 - ASM fallback version

Changes: https://git.openjdk.org/jdk/pull/18953/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18953&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327247
  Stats: 300 lines in 2 files changed: 294 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18953/head:pull/18953

PR: https://git.openjdk.org/jdk/pull/18953

From duke at openjdk.org  Thu Apr 25 14:32:56 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Thu, 25 Apr 2024 14:32:56 GMT
Subject: RFR: 8326951: Missing `@since` tags [v7]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <uxcHyxMQujj7fdLTM-k6ctt1CtD5BWSomXi6eD0yp7M=.87b40f9e-cf37-401c-a9e5-197e89395761@github.com>

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  deal with methods with different return types - added some spaces for readability

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/390a21f9..670acaec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=05-06

  Stats: 13 lines in 5 files changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055

PR: https://git.openjdk.org/jdk/pull/18055

From redestad at openjdk.org  Thu Apr 25 14:33:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 14:33:34 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <XFaPKReMDXYVSCXeE5lGXEAylsd9foJ2Y8-CZcNiUwU=.607258f3-6de7-405b-ae08-a55c50936bea@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
 <XFaPKReMDXYVSCXeE5lGXEAylsd9foJ2Y8-CZcNiUwU=.607258f3-6de7-405b-ae08-a55c50936bea@github.com>
Message-ID: <TMi_HSuHSSIy-NOOBykbk3gvRGsDV9bMYcQROt_lhfo=.030110e3-3e30-4fdf-9a27-408e5b30449c@github.com>

On Thu, 25 Apr 2024 13:35:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> Do we have any research on the average length of method descriptor strings? I wonder if manual pre-allocation works better (iterating all descriptor strings, allocate the sum of their sizes plus 2 (for parentheses), as descriptor strings won't be re-calculated after initial allocation.) Especially in case of user code, as many user classes have very long package names that can easily make the string much longer than the 24-char default.

I don't know of any systematic research on this, but in the code generators we have in the JDK short method signatures outweigh more complex ones by far. So if we can improve for small descriptors without regressing large ones then that's a pretty good win.

I've done some micro-benchmarking on longer descriptors and there's still a gain from the proposed patch:


MethodTypeDescFactories.ofDesc -p descString=(Lorg/openjdk/bench/java/lang/constant/MethodTypeDescFactories;Lorg/openjdk/bench/java/lang/constant/MethodTypeDescFactories;Lorg/openjdk/bench/java/lang/constant/MethodTypeDescFactories;)Lorg/openjdk/bench/java/lang/constant/MethodTypeDescFactories;

Name                                 Cnt    Base    Error     Test   Error  Unit  Change
MethodTypeDescFactories.ofDescriptor   6 442,112 ? 16,175  423,926 ? 6,245 ns/op   1,04x (p = 0,000*)
  * = significant


I'd be happy to add a variant that stresses larger descriptors.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18945#issuecomment-2077348963

From rriggs at openjdk.org  Thu Apr 25 14:38:37 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 25 Apr 2024 14:38:37 GMT
Subject: RFR: 8330624: Inconsistent use of semicolon in the code snippet of
 java.io.Serializable javadoc
In-Reply-To: <I2DZ3fh2RKeDrHs8Uyr4ky6YDHwCdo6t-UvOYAtkiK8=.1f90a822-8aed-4556-bc9a-ad70acbf12c0@github.com>
References: <I2DZ3fh2RKeDrHs8Uyr4ky6YDHwCdo6t-UvOYAtkiK8=.1f90a822-8aed-4556-bc9a-ad70acbf12c0@github.com>
Message-ID: <zj2G4exWeo0W3f-0SS1YHX6hdsSDwUuN-vDk72yXV54=.f0a70b6d-6e88-4216-a742-0a3fe0ae8cba@github.com>

On Sat, 20 Apr 2024 11:49:30 GMT, Korov <duke at openjdk.org> wrote:

> Fix the description of java.io.Serializable.

LGTM; trivial fix of example javadoc code

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18874#pullrequestreview-2022703632

From rriggs at openjdk.org  Thu Apr 25 14:40:39 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 25 Apr 2024 14:40:39 GMT
Subject: Integrated: 8329805: Deprecate for removal
 ObjectOutputStream.PutField.write
In-Reply-To: <jJX_F7zdz-XzBzmPjHkq3sOxW3N-I9Pff1vKO2TIn1M=.5d0b6e21-2614-44b0-b1d6-a6c9d57b9b4d@github.com>
References: <jJX_F7zdz-XzBzmPjHkq3sOxW3N-I9Pff1vKO2TIn1M=.5d0b6e21-2614-44b0-b1d6-a6c9d57b9b4d@github.com>
Message-ID: <W9u1pbxZLc5nVedV3bP1kf-RJR0jn_Fk1FPDC6HN8GU=.e91a9cb3-6199-4208-a9c6-da8874c0714e@github.com>

On Tue, 16 Apr 2024 19:44:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The method `java.io.ObjectOutputStream.PutField.write` has been deprecated since 1.4 and should be deprecated for removal. The Deprecation annotation is updated to indicate the intention to remov the method.

This pull request has now been integrated.

Changeset: 4dfaa9b5
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4dfaa9b5bd4f9733e5a67d7c5b55eaa5ad4e27e4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8329805: Deprecate for removal ObjectOutputStream.PutField.write

Reviewed-by: naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/18802

From duke at openjdk.org  Thu Apr 25 15:05:18 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 25 Apr 2024 15:05:18 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v5]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <5HhjM9q2E4xtZVQitu5UGkNgdyBbqZbQOwnvJIUIr2U=.778a6d07-fe5d-4c6b-8bdf-353342df5904@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/c93a71f0..a1984501

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

PR: https://git.openjdk.org/jdk/pull/18583

From jpai at openjdk.org  Thu Apr 25 15:14:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 15:14:32 GMT
Subject: RFR: 8330615: avoid signed integer overflows in zip_util.c readCen
 / hashN
In-Reply-To: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
References: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
Message-ID: <9N5148zrl0MSmt7lCGkv92dFcm3A6r6dQG1dlm9YyBU=.5bbd5781-238d-4e29-adf7-2163fdc12f12@github.com>

On Tue, 23 Apr 2024 07:51:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the hashN usages of readCen from zip_util.c we see a lot of signed integer overflows.
> For example in the java/util jtreg tests those are easily reproducable when compiling with -ftrapv (clang/gcc toolchains).
> While those overflows never seem to cause crashes or similar errors, they are unwanted because
> signed integer overflows in C cause undefined behavior.
> See
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html
>>
>> For signed integers, the result of overflow in C is in principle undefined, meaning that anything whatsoever could happen.
>> Therefore, C compilers can do optimizations that treat the overflow case with total unconcern.
> 
> So we might still get unwanted results (maybe bad/strange hashing, depending on compiler and optimization level).
> 
> Compilation with -ftrapv causes/triggers this SIGILL on macOS showing the issue :
> # Problematic frame:
> # C [libzip.dylib+0x6362] hashN+0x32
> #
> 
> Stack: [0x000070000c496000,0x000070000c596000], sp=0x000070000c5957e0, free space=1021k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libzip.dylib+0x6362] hashN+0x32
> C [libzip.dylib+0x5d5e] readCEN+0xd2e
> C [libzip.dylib+0x4ee0] ZIP_Put_In_Cache0+0x160
> V [libjvm.dylib+0x544b1e] ClassLoader::open_zip_file(char const*, char**, JavaThread*)+0x3e
> V [libjvm.dylib+0x543fec] ClassLoader::create_class_path_entry(JavaThread*, char const*, stat const*, bool, bool)+0x6c
> V [libjvm.dylib+0x543833] ClassLoader::setup_bootstrap_search_path_impl(JavaThread*, char const*)+0xf3
> V [libjvm.dylib+0x54819b] classLoader_init1()+0x1b
> V [libjvm.dylib+0x92602a] init_globals()+0x3a
> V [libjvm.dylib+0x12b3b74] Threads::create_vm(JavaVMInitArgs*, bool*)+0x314
> V [libjvm.dylib+0xa848f4] JNI_CreateJavaVM+0x64
> C [libjli.dylib+0x4483] JavaMain+0x123
> C [libjli.dylib+0x7529] ThreadJavaMain+0x9
> C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0
> C [libsystem_pthread.dylib+0x2443] thread_start+0xf

Hello Matthias, the tests completed a couple of hours back and no failures related to this change have been observed. Thank you for waiting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18908#issuecomment-2077527559

From mbaesken at openjdk.org  Thu Apr 25 15:26:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Apr 2024 15:26:42 GMT
Subject: Integrated: 8330615: avoid signed integer overflows in zip_util.c
 readCen / hashN
In-Reply-To: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
References: <0aroFlGUQPqUGevldTgMZm1EF-jNolMQLUxoAPU7t3E=.5eeb7a71-4dae-4d76-b762-95cb3b434d8e@github.com>
Message-ID: <DCFxO9jU1YHunWj9sYVH7EAwLcRNGElERUZqj5OyKsM=.6857eeff-66e7-40dc-b457-61883dca2702@github.com>

On Tue, 23 Apr 2024 07:51:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the hashN usages of readCen from zip_util.c we see a lot of signed integer overflows.
> For example in the java/util jtreg tests those are easily reproducable when compiling with -ftrapv (clang/gcc toolchains).
> While those overflows never seem to cause crashes or similar errors, they are unwanted because
> signed integer overflows in C cause undefined behavior.
> See
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html
>>
>> For signed integers, the result of overflow in C is in principle undefined, meaning that anything whatsoever could happen.
>> Therefore, C compilers can do optimizations that treat the overflow case with total unconcern.
> 
> So we might still get unwanted results (maybe bad/strange hashing, depending on compiler and optimization level).
> 
> Compilation with -ftrapv causes/triggers this SIGILL on macOS showing the issue :
> # Problematic frame:
> # C [libzip.dylib+0x6362] hashN+0x32
> #
> 
> Stack: [0x000070000c496000,0x000070000c596000], sp=0x000070000c5957e0, free space=1021k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libzip.dylib+0x6362] hashN+0x32
> C [libzip.dylib+0x5d5e] readCEN+0xd2e
> C [libzip.dylib+0x4ee0] ZIP_Put_In_Cache0+0x160
> V [libjvm.dylib+0x544b1e] ClassLoader::open_zip_file(char const*, char**, JavaThread*)+0x3e
> V [libjvm.dylib+0x543fec] ClassLoader::create_class_path_entry(JavaThread*, char const*, stat const*, bool, bool)+0x6c
> V [libjvm.dylib+0x543833] ClassLoader::setup_bootstrap_search_path_impl(JavaThread*, char const*)+0xf3
> V [libjvm.dylib+0x54819b] classLoader_init1()+0x1b
> V [libjvm.dylib+0x92602a] init_globals()+0x3a
> V [libjvm.dylib+0x12b3b74] Threads::create_vm(JavaVMInitArgs*, bool*)+0x314
> V [libjvm.dylib+0xa848f4] JNI_CreateJavaVM+0x64
> C [libjli.dylib+0x4483] JavaMain+0x123
> C [libjli.dylib+0x7529] ThreadJavaMain+0x9
> C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0
> C [libsystem_pthread.dylib+0x2443] thread_start+0xf

This pull request has now been integrated.

Changeset: 5af6b45e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5af6b45eefd227e3e046ca22a404ae8a23174160
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8330615: avoid signed integer overflows in zip_util.c readCen / hashN

Reviewed-by: lucy, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/18908

From liach at openjdk.org  Thu Apr 25 15:42:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 Apr 2024 15:42:33 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
Message-ID: <7SCkNWkTEcikK0jqNnpehnJYvSThDBNj_DXgp7oCgyE=.9f4d654f-3acc-4aac-a68c-8209d30eea13@github.com>

On Thu, 25 Apr 2024 13:34:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comma-separated

What if we replace `24` with a precalculated value:

int size = 2 + returnType().descriptorString().length();
for (var param : argTypes)
    size += param.descriptorString().length();

(Would be even better if we can just trust the internal array to avoid copy allocation)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18945#issuecomment-2077600166

From naoto at openjdk.org  Thu Apr 25 16:22:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 Apr 2024 16:22:44 GMT
Subject: Integrated: 8319990: Update CLDR to Version 45.0
In-Reply-To: <Wyp4kxo3jyIf17I182D5xPZt_4g1dVgv9yxMTSP18gg=.80be586b-01d2-4cca-a12d-4b63ed7eedb0@github.com>
References: <Wyp4kxo3jyIf17I182D5xPZt_4g1dVgv9yxMTSP18gg=.80be586b-01d2-4cca-a12d-4b63ed7eedb0@github.com>
Message-ID: <qQySh34WAtF5qDbl61rdW601eid29JgAaBSQTmy6Zx8=.864d136a-6741-4737-a7e2-f8784f32a9c9@github.com>

On Mon, 22 Apr 2024 18:44:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to version 45.0. We now have versions specified in the javadoc (`LocaleServiceProvider`), a corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 1c238d43
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c238d43e81acf516297f26660059d0bab5b5b8a
Stats:     7401 lines in 1075 files changed: 307 ins; 4640 del; 2454 mod

8319990: Update CLDR to Version 45.0

Reviewed-by: joehw, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/18900

From liach at openjdk.org  Thu Apr 25 16:52:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 Apr 2024 16:52:40 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases
In-Reply-To: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
Message-ID: <TZ0FKsuB_6AJnmWzK-bawcgB0DZrzJxqiQbjDXSo3LM=.6b31c8f3-6a84-41ca-9724-b2247feb072c@github.com>

On Thu, 25 Apr 2024 14:15:56 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.

Only with ASM can we realize how concise ClassFile API is!

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1059:

> 1057:      */
> 1058:     private static final class SimpleStringBuilderStrategy {
> 1059:         static final int CLASSFILE_VERSION = ClassFile.latestMajorVersion();

Still breaks backward ASM port, we should use a fixed version like 52 for JAVA_8 and convert to latest only in the CF conversion later.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18953#pullrequestreview-2023078249
PR Review Comment: https://git.openjdk.org/jdk/pull/18953#discussion_r1579822765

From philip.race at oracle.com  Thu Apr 25 18:30:43 2024
From: philip.race at oracle.com (Philip Race)
Date: Thu, 25 Apr 2024 11:30:43 -0700
Subject: Usage of iconv()
In-Reply-To: <e9f7107a-4f9c-4511-9270-9bb08f7bca87@oracle.com>
References: <20240423121114.EE241662C87@dd33810.kasserver.com>
 <e9f7107a-4f9c-4511-9270-9bb08f7bca87@oracle.com>
Message-ID: <91874482-df68-4e76-99e9-4fb90ef2c7a7@oracle.com>



On 4/24/24 4:24 AM, Magnus Ihse Bursie wrote:
> That is a good question. libiconv is used only on macOS and AIX, for a 
> few libraries, as you say. I just tried removing -liconv from the 
> macOS dependencies and recompiled, just to see what would happen. 
> There were three instances for macOS: libsplashscreen, libjdwp and 
> libinstrument.
>
>
>
> libsplashscreen uses it in splashscreen_sys.m, where it is used to 
> convert the jar file name.

This is called from the launcher, in java.base/share/native/libjli/java.c


>
> libjdwp uses it in utf_util.c, where it is used to convert file name 
> and command lines, iiuc.
>
> It is likely that we have similar (but better) ways to convert 
> charsets elsewhere in our libraries that can be used instead of 
> libiconv. I guess these are not the only two places where a filename 
> must be converted from the platform charset to UTF8.

So whatever replacement there might be, it needs to be something that is 
available very early in the life of the VM, in fact before there is a VM 
running.

-phil.

From david.lloyd at redhat.com  Thu Apr 25 18:41:16 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 25 Apr 2024 13:41:16 -0500
Subject: Generalizing binary search
Message-ID: <CANghgrR9d524yo7pPKNmvG_LU0hzxrFhQZZPdC1TF7Y_Q_rMeA@mail.gmail.com>

The JDK contains a few collection- and array-oriented implementations of
binary search. For the most part, they all work the same way: search the
target "thing" by index using the obvious bisection strategy, returning
either /index/ or /-index-1/ depending on whether it was found at the end
of the search.

However, if you're doing a binary search on a thing that is not a list or
an array, you have two choices: try to make the thing you're searching on
implement List (often infeasible) or write your own binary search.

I'm really tired of writing my own binary search. I've probably done it 50
times by now, each one using a slightly different access and/or compare
strategy, and every time is a new chance to typo something or get something
backwards, leading to irritating debugging sessions and higher
dentist bills.

It got me to thinking that it wouldn't be too hard to make a "general"
binary search which can search on anything, so that's what I did. I was
thinking that it might be interesting to try adding this into the JDK
somehow.

This implementation is more or less what I now copy & paste to different
projects at the moment:

    public static <C, T> int binarySearch(C collection, int start, int end,
T key, Comparator<? super T> cmp, IntGetter<C, T> getter) {
        int low = start;
        int high = end - 1;
        while (low <= high) {
            int mid = low + high >>> 1;
            int res = cmp.compare(getter.get(collection, mid), key);
            if (res < 0) {
                low = mid + 1;
            } else if (res > 0) {
                high = mid - 1;
            } else {
                return mid;
            }
        }
        return -low - 1;
    }
    // (Plus variations for `Comparable` keys and long indices)

A key problem with this approach is that in the JDK, there is no
`ObjIntFunction<T, R>` or `ObjLongFunction<T, R>` which would be necessary
to implement the "getter" portion of the algorithm (despite the existence
of the analogous `ObjIntConsumer<T>` and `ObjLongConsumer<T>`). So, I also
have to copy/paste a `IntGetter<T, R>`/`LongGetter<T, R>` as well, which is
annoying.

A slightly less-good approach is for the general `binarySearch` method to
accept a `IntFunction<T>`/`LongFunction<T>`, and drop the `C collection`
parameter, like this:

    public static <T> int binarySearch(int start, int end, T key,
Comparator<? super T> cmp, IntFunction<T> getter) { ... }

In this case, we can use the function types that the JDK already provides,
but we would very likely have to also create a capturing lambda (e.g.
`myList::get` instead of `List::get`). Maybe this isn't that bad of a
compromise.

It would be possible to replace the existing `binarySearch` implementations
with delegating calls to a generalized implementation. For `Collections`,
the indexed version uses `List::get` and the iterator version uses a helper
lambda to move the iterator and get the result. For arrays, a lambda would
be provided which gets the corresponding array element. If the
non-capturing variant is used, then (on paper at least) this version should
perform similarly to the existing implementations, with less code needed
overall. However, if a capturing lambda is required (due to the
aforementioned lack of `ObjXFunction`), then this could be slightly
worse-performing than the existing implementation due to the construction
(and maybe dispatch) overhead of the lambda. Some real-world benchmarks
would have to be written with various-sized data sets.

It would also be possible to produce primitive variations which operate on
int, float, long, and double values, using existing functions if capturing
is deemed "OK". It is also possible to produce a variation which uses a
`long` for the index, for huge data sets (for example, very large mapped
files using `MemorySegment`).

Also unclear is: where would it live? `Collections`? Somewhere else?

Any thoughts/opinions would be appreciated (even if they are along the
lines of "it's not worth the effort"). Particularly, any insight would be
appreciated as to whether or not this kind of hypothetical enhancement
would warrant a JEP (I wouldn't think so, but I'm no expert at such
assessments).

--
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240425/f5b89ba3/attachment.htm>

From kak at google.com  Thu Apr 25 18:56:21 2024
From: kak at google.com (Kurt Alfred Kluever)
Date: Thu, 25 Apr 2024 14:56:21 -0400
Subject: In support of Instant.minus(Instant)
Message-ID: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>

Hi core-libs-dev,

The java.time API already supports subtracting two Instants (end - start)
via Duration.between(Temporal, Temporal), but we've found the parameter
ordering (which requires a bit of "mental gymnastics") and API location to
be a bit unnatural.

Parameter Ordering

We very often see folks write code like this: Duration elapsed =
Duration.ofMillis(end.toEpochMilli() - start.toEpochMilli());

This closely matches the mental model of what they're trying to accomplish,
but it is longer (and more complex) than it needs to be, it drops
sub-millisecond precision, and it requires decomposing the java.time types
(which we strongly discourage). If you want to "simplify" the above
statement, you must remember to swap the argument order: Duration elapsed =
Duration.between(start, end);

Many of us find representing (end - start) as between(start, end) to be
confusing.

API Location

We do not believe Duration is the most obvious place to find this method;
if you want a way to subtract two Instant values, an instance method on
Instant is a more obvious place to look. Pushing what could be an instance
method to a static utility method feels unnatural.

JDK-8276624 (https://bugs.openjdk.org/browse/JDK-8276624) proposes to add
Temporal.minus(Temporal) as a default method (which would effectively
accomplish the same thing), but we do not recommend implementing that
proposal as specified. A default method on Temporal would require runtime
exceptions to be thrown from other Temporal types like LocalDate or Year.
It would also allow oddities like instant.minus(year) to compile (but
presumably throw at runtime). Conceptually, this API would not make sense
for certain types (e.g., LocalDate ? the difference between two LocalDates
is a Period, not a Duration).

Instead, we recommend adding a new instance method: instant.minus(instant)
(which returns a Duration), and possibly also adding
localDate.minus(localDate) (which returns a Period). However note that
we've seen a lot of confusion using the Period API (but that's a separate
discussion).

While we generally don't like having 2 public APIs that accomplish the same
thing, in this case we feel the discoverability and simplicity of the new
API(s) outweighs the cost of an additional public API.

Please consider this a +1 from our team to add instant.minus(instant).

Regards,

-Kurt Alfred Kluever (kak at google.com)
(on behalf of Google's Java and Kotlin Ecosystem Team, aka the Guava team)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240425/ebbdba5a/attachment-0001.htm>

From pavel.rappo at oracle.com  Thu Apr 25 19:09:04 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 25 Apr 2024 19:09:04 +0000
Subject: Generalizing binary search
In-Reply-To: <CANghgrR9d524yo7pPKNmvG_LU0hzxrFhQZZPdC1TF7Y_Q_rMeA@mail.gmail.com>
References: <CANghgrR9d524yo7pPKNmvG_LU0hzxrFhQZZPdC1TF7Y_Q_rMeA@mail.gmail.com>
Message-ID: <0B6F859C-1B4C-4FCD-87CA-82B2A5072C99@oracle.com>



> On 25 Apr 2024, at 19:41, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> The JDK contains a few collection- and array-oriented implementations of binary search. For the most part, they all work the same way: search the target "thing" by index using the obvious bisection strategy, returning either /index/ or /-index-1/ depending on whether it was found at the end of the search.
> 
> However, if you're doing a binary search on a thing that is not a list or an array, you have two choices: try to make the thing you're searching on implement List (often infeasible) or write your own binary search.
> 
> I'm really tired of writing my own binary search. I've probably done it 50 times by now, each one using a slightly different access and/or compare strategy, and every time is a new chance to typo something or get something backwards, leading to irritating debugging sessions and higher dentist bills.

Can we safely say that it sets your teeth on edge?

> It got me to thinking that it wouldn't be too hard to make a "general" binary search which can search on anything, so that's what I did. I was thinking that it might be interesting to try adding this into the JDK somehow.
> 
> This implementation is more or less what I now copy & paste to different projects at the moment:
> 
>     public static <C, T> int binarySearch(C collection, int start, int end, T key, Comparator<? super T> cmp, IntGetter<C, T> getter) {
>         int low = start;
>         int high = end - 1;
>         while (low <= high) {
>             int mid = low + high >>> 1;
>             int res = cmp.compare(getter.get(collection, mid), key);
>             if (res < 0) {
>                 low = mid + 1;
>             } else if (res > 0) {
>                 high = mid - 1;
>             } else {
>                 return mid;
>             }
>         }
>         return -low - 1;
>     }
>     // (Plus variations for `Comparable` keys and long indices)
> 
> A key problem with this approach is that in the JDK, there is no `ObjIntFunction<T, R>` or `ObjLongFunction<T, R>` which would be necessary to implement the "getter" portion of the algorithm (despite the existence of the analogous `ObjIntConsumer<T>` and `ObjLongConsumer<T>`). So, I also have to copy/paste a `IntGetter<T, R>`/`LongGetter<T, R>` as well, which is annoying.
> 
> A slightly less-good approach is for the general `binarySearch` method to accept a `IntFunction<T>`/`LongFunction<T>`, and drop the `C collection` parameter, like this:
> 
>     public static <T> int binarySearch(int start, int end, T key, Comparator<? super T> cmp, IntFunction<T> getter) { ... }
> 
> In this case, we can use the function types that the JDK already provides, but we would very likely have to also create a capturing lambda (e.g. `myList::get` instead of `List::get`). Maybe this isn't that bad of a compromise.
> 
> It would be possible to replace the existing `binarySearch` implementations with delegating calls to a generalized implementation. For `Collections`, the indexed version uses `List::get` and the iterator version uses a helper lambda to move the iterator and get the result. For arrays, a lambda would be provided which gets the corresponding array element. If the non-capturing variant is used, then (on paper at least) this version should perform similarly to the existing implementations, with less code needed overall. However, if a capturing lambda is required (due to the aforementioned lack of `ObjXFunction`), then this could be slightly worse-performing than the existing implementation due to the construction (and maybe dispatch) overhead of the lambda. Some real-world benchmarks would have to be written with various-sized data sets.
> 
> It would also be possible to produce primitive variations which operate on int, float, long, and double values, using existing functions if capturing is deemed "OK". It is also possible to produce a variation which uses a `long` for the index, for huge data sets (for example, very large mapped files using `MemorySegment`).
> 
> Also unclear is: where would it live? `Collections`? Somewhere else?
> 
> Any thoughts/opinions would be appreciated (even if they are along the lines of "it's not worth the effort"). Particularly, any insight would be appreciated as to whether or not this kind of hypothetical enhancement would warrant a JEP (I wouldn't think so, but I'm no expert at such assessments).
> 
> --
> - DML ? he/him

Have a look at this recently filed issue: https://bugs.openjdk.org/browse/JDK-8326330

-Pavel



From redestad at openjdk.org  Thu Apr 25 19:53:46 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 19:53:46 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
Message-ID: <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>

> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove accidental use of java.lang.classfile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18953/files
  - new: https://git.openjdk.org/jdk/pull/18953/files/d8d5e5d3..a4dfbfca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18953&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18953&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18953/head:pull/18953

PR: https://git.openjdk.org/jdk/pull/18953

From redestad at openjdk.org  Thu Apr 25 19:53:48 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 19:53:48 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <TZ0FKsuB_6AJnmWzK-bawcgB0DZrzJxqiQbjDXSo3LM=.6b31c8f3-6a84-41ca-9724-b2247feb072c@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <TZ0FKsuB_6AJnmWzK-bawcgB0DZrzJxqiQbjDXSo3LM=.6b31c8f3-6a84-41ca-9724-b2247feb072c@github.com>
Message-ID: <gPVxCp6wJnFMf8uKNtGn2Ufe4yg-fVByTM_N9nOpMk4=.cd991989-6f35-428e-a1cb-043446fe77c4@github.com>

On Thu, 25 Apr 2024 16:46:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove accidental use of java.lang.classfile
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1059:
> 
>> 1057:      */
>> 1058:     private static final class SimpleStringBuilderStrategy {
>> 1059:         static final int CLASSFILE_VERSION = ClassFile.latestMajorVersion();
> 
> Still breaks backward ASM port, we should use a fixed version like 52 for JAVA_8 and convert to latest only in the CF conversion later.

Good catch. In the code I am [reviving](https://github.com/cl4es/jdk/commit/36c4b11bc6cf5a008d5935934aa75f2d2bbe6a23#diff-1339c269a3729d849799d29a7431ccd508a034ced91c1796b952795396843891L771) this field was simply set to `52`. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18953#discussion_r1580047931

From psandoz at openjdk.org  Thu Apr 25 20:18:35 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 25 Apr 2024 20:18:35 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes
In-Reply-To: <Yq-gg4AoITsJrHMj_WV-LrwDENnQv1JqFro6Zj5KYM8=.66871edd-de1f-4fea-a38d-05ae7bf91d26@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
 <xhnphsmt74pb52uEUwOarr0LZNHSlE3StvAdBelc61Y=.1f7bb136-3f2b-4499-b87d-916e0479162f@github.com>
 <Yq-gg4AoITsJrHMj_WV-LrwDENnQv1JqFro6Zj5KYM8=.66871edd-de1f-4fea-a38d-05ae7bf91d26@github.com>
Message-ID: <B5NAWPrB09r6Z938sTcAH80r7u77R5fN_SuKYuKibIg=.a0c1fd4f-4426-4650-a773-c5f58f3282bd@github.com>

On Thu, 25 Apr 2024 00:51:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Unfortunately it would have to be an expected tags list or an extra constructed bit mask, due to the multiple tags allowed for MemberRefEntry and it would slightly affect the performance. 

Ah yes, i missed that. It could be two tags, a lower and upper bound, because TAG_FIELDREF, TAG_METHODREF, and TAG_INTERFACEMETHODREF are consecutive values (9 to 11).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18907#issuecomment-2078099914

From psandoz at openjdk.org  Thu Apr 25 20:20:34 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 25 Apr 2024 20:20:34 GMT
Subject: RFR: 8322847: java.lang.classfile.BufWriter should specify @throws
 for its writeXXX methods
In-Reply-To: <LbGxj-m_26dMeRG6TgVNN16NSWtmutE5jW5pL4r1_7o=.84713a17-9ffe-435a-96e7-f1e9f5d8345a@github.com>
References: <LbGxj-m_26dMeRG6TgVNN16NSWtmutE5jW5pL4r1_7o=.84713a17-9ffe-435a-96e7-f1e9f5d8345a@github.com>
Message-ID: <pUeNkBr8SnfVcTCejYxzAhlKwPIncjSvnRhW-H4Im3M=.06411605-21ac-40bd-a8f6-97e43158e30f@github.com>

On Tue, 23 Apr 2024 11:56:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch adds missing `@throws` javadoc annotations to `java.lang.classfile.BufWriter`.
> 
> Please review.
> 
> Thank you,
> Adam

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18913#pullrequestreview-2023498303

From scolebourne at joda.org  Thu Apr 25 20:53:23 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 25 Apr 2024 21:53:23 +0100
Subject: In support of Instant.minus(Instant)
In-Reply-To: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
Message-ID: <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>

java.time.* already has the `until(ChronoLocalDate)` method on
LocalDate. It would be reasonable to add a similar method to various
other classes. This potentially gives you

 Duration dur = start.until(end)

I'm wary of adding the opposite (given until() is already there). I'm
particularly wary of using minus() as the verb for the opposite as
minus() means something different in other parts of the API (minus()
is used to subtract a TemporalAmounrt, not a Temporal).

Stephen


On Thu, 25 Apr 2024 at 19:57, Kurt Alfred Kluever <kak at google.com> wrote:
>
> Hi core-libs-dev,
>
> The java.time API already supports subtracting two Instants (end - start) via Duration.between(Temporal, Temporal), but we've found the parameter ordering (which requires a bit of "mental gymnastics") and API location to be a bit unnatural.
>
> Parameter Ordering
>
> We very often see folks write code like this: Duration elapsed = Duration.ofMillis(end.toEpochMilli() - start.toEpochMilli());
>
> This closely matches the mental model of what they're trying to accomplish, but it is longer (and more complex) than it needs to be, it drops sub-millisecond precision, and it requires decomposing the java.time types (which we strongly discourage). If you want to "simplify" the above statement, you must remember to swap the argument order: Duration elapsed = Duration.between(start, end);
>
> Many of us find representing (end - start) as between(start, end) to be confusing.
>
> API Location
>
> We do not believe Duration is the most obvious place to find this method; if you want a way to subtract two Instant values, an instance method on Instant is a more obvious place to look. Pushing what could be an instance method to a static utility method feels unnatural.
>
> JDK-8276624 (https://bugs.openjdk.org/browse/JDK-8276624) proposes to add Temporal.minus(Temporal) as a default method (which would effectively accomplish the same thing), but we do not recommend implementing that proposal as specified. A default method on Temporal would require runtime exceptions to be thrown from other Temporal types like LocalDate or Year. It would also allow oddities like instant.minus(year) to compile (but presumably throw at runtime). Conceptually, this API would not make sense for certain types (e.g., LocalDate ? the difference between two LocalDates is a Period, not a Duration).
>
> Instead, we recommend adding a new instance method: instant.minus(instant) (which returns a Duration), and possibly also adding localDate.minus(localDate) (which returns a Period). However note that we've seen a lot of confusion using the Period API (but that's a separate discussion).
>
> While we generally don't like having 2 public APIs that accomplish the same thing, in this case we feel the discoverability and simplicity of the new API(s) outweighs the cost of an additional public API.
>
> Please consider this a +1 from our team to add instant.minus(instant).
>
> Regards,
>
> -Kurt Alfred Kluever (kak at google.com)
> (on behalf of Google's Java and Kotlin Ecosystem Team, aka the Guava team)

From david.lloyd at redhat.com  Thu Apr 25 21:17:40 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 25 Apr 2024 16:17:40 -0500
Subject: Generalizing binary search
In-Reply-To: <0B6F859C-1B4C-4FCD-87CA-82B2A5072C99@oracle.com>
References: <CANghgrR9d524yo7pPKNmvG_LU0hzxrFhQZZPdC1TF7Y_Q_rMeA@mail.gmail.com>
 <0B6F859C-1B4C-4FCD-87CA-82B2A5072C99@oracle.com>
Message-ID: <CANghgrRWLOBipqG-Uf=MiE6L5pWQU_0rx6iO1wWL-g9M5Dz=Xw@mail.gmail.com>

On Thu, Apr 25, 2024 at 2:09?PM Pavel Rappo <pavel.rappo at oracle.com> wrote:

>
>
> > On 25 Apr 2024, at 19:41, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> > The JDK contains a few collection- and array-oriented implementations of
> binary search. For the most part, they all work the same way: search the
> target "thing" by index using the obvious bisection strategy, returning
> either /index/ or /-index-1/ depending on whether it was found at the end
> of the search.
> >
> > However, if you're doing a binary search on a thing that is not a list
> or an array, you have two choices: try to make the thing you're searching
> on implement List (often infeasible) or write your own binary search.
> >
> > I'm really tired of writing my own binary search. I've probably done it
> 50 times by now, each one using a slightly different access and/or compare
> strategy, and every time is a new chance to typo something or get something
> backwards, leading to irritating debugging sessions and higher dentist
> bills.
>
> Can we safely say that it sets your teeth on edge?
>

You could say that. :)

Have a look at this recently filed issue:
> https://bugs.openjdk.org/browse/JDK-8326330


Oh, nice, I didn't see that come across. It's even more general than my
version: I like that. My only complaint is (once again) that the lambda
must be capturing in order to work with a plain
`IntPredicate`/`LongPredicate`.

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240425/da217131/attachment-0001.htm>

From darcy at openjdk.org  Thu Apr 25 21:37:57 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Apr 2024 21:37:57 GMT
Subject: RFR: 8331108: Unused Math.abs call in
 java.lang.FdLibm.Expm1#compute
In-Reply-To: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
References: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
Message-ID: <ssZGjMOQyDwlrz-wOtdQR0bkJcp9nSxg28iqbXIIV9I=.390a2299-ae89-4c35-83e2-6e09d9e05dea@github.com>

On Thu, 25 Apr 2024 21:32:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Remove unnecessary setting of variable y, found by an IDE inspection noted in the bug report.

All Math and StrictMath regression tests pass with this change. Examining the code, y does look to be overwritten on all the code paths where it factors into the returned result.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18963#issuecomment-2078210519

From darcy at openjdk.org  Thu Apr 25 21:37:57 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 25 Apr 2024 21:37:57 GMT
Subject: RFR: 8331108: Unused Math.abs call in java.lang.FdLibm.Expm1#compute
Message-ID: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>

Remove unnecessary setting of variable y, found by an IDE inspection noted in the bug report.

-------------

Commit messages:
 - JDK-8331108: Unused Math.abs call in java.lang.FdLibm.Expm1#compute

Changes: https://git.openjdk.org/jdk/pull/18963/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331108
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18963/head:pull/18963

PR: https://git.openjdk.org/jdk/pull/18963

From naoto at openjdk.org  Thu Apr 25 22:21:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 Apr 2024 22:21:34 GMT
Subject: RFR: 8331108: Unused Math.abs call in
 java.lang.FdLibm.Expm1#compute
In-Reply-To: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
References: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
Message-ID: <OM75DF43irs3bhfDddYyu_EGLQCYqhzyoR-jbJiT75M=.34b039d3-5598-432d-b1ca-b495bad8cd5f@github.com>

On Thu, 25 Apr 2024 21:32:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Remove unnecessary setting of variable y, found by an IDE inspection noted in the bug report.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18963#pullrequestreview-2023687212

From redestad at openjdk.org  Thu Apr 25 22:26:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 22:26:05 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <Yqh4aUOvfxvOdrnNcRRfoOqLyq0ChSUqcYAk57cmZ9M=.3c9974ce-cffa-4281-b203-75424cd53334@github.com>
Message-ID: <YVeuKg5th9zcuER_ON0a7keSxbZ513pj-mfB5k31MfI=.b83117a8-d658-412b-919d-49c7b8db85df@github.com>

On Thu, 25 Apr 2024 13:34:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comma-separated

Correction: I ran the wrong benchmark for that long descriptor test! ?? On the `descriptorString` benchmark there _is_ a regression with my patch on longer descriptors, -30% on that example. Since the strings are all readily available pre-calculating the size is cheap enough to make sense. This makes the patch more or less neutral on large descriptors, extends the gain on few-arg methods, but reduces the win on cases where there are no args (due an extra branch et.c.). On balance this seems like an improvement:


Name                                                                 (descString) Cnt    Base   Error    Test    Error  Unit  Change
MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6  43,180 ? 0,575   30,547 ? 0,387 ns/op   1,41x (p = 0,000*)
MethodTypeDescFactories.descriptorString                                      ()V   6  20,717 ? 0,128   17,233 ? 0,242 ns/op   1,20x (p = 0,000*)
MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6  89,834 ? 1,951   40,149 ? 0,326 ns/op   2,24x (p = 0,000*)
MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6  21,438 ? 0,490   15,937 ? 0,263 ns/op   1,35x (p = 0,000*)
MethodTypeDescFactories.descriptorString                                 (..IIJ)V   6  52,429 ? 0,117   49,396 ? 0,153 ns/op   1,06x (p = 0,000*)
MethodTypeDescFactories.descriptorString                 (.....................).   6 178,205 ? 0,518  176,856 ? 5,577 ns/op   1,01x (p = 0,158 )
  * = significant


`.` is illegal in descriptor strings I used this as wildcard to be replaced with the descriptor string for the benchmark class as a ways to produce very large descriptors.

Since this strays a bit from what's doable in `MethodTypeDesc::displayDescriptor` I'm reverting those changes and focus this PR on the relevant piece of machinery.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18945#issuecomment-2078267325

From redestad at openjdk.org  Thu Apr 25 22:26:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 25 Apr 2024 22:26:04 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v3]
In-Reply-To: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
Message-ID: <0n5R0DMwOTSJx8WKPOYIW65c6BNzFxrffMMQd-fVc4c=.85003aac-491b-48b8-8a59-3f06ecc012db@github.com>

> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
> 
> Performance improves across the board in existing microbenchmarks:
> 
> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>   * = significant
> 
> 
> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
> 
> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>   * = significant
>   ```
>   
>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Calculate length precisely

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18945/files
  - new: https://git.openjdk.org/jdk/pull/18945/files/2979847c..15c8d39c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=01-02

  Stats: 22 lines in 3 files changed: 8 ins; 4 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18945/head:pull/18945

PR: https://git.openjdk.org/jdk/pull/18945

From bpb at openjdk.org  Thu Apr 25 22:36:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Apr 2024 22:36:35 GMT
Subject: RFR: 8331108: Unused Math.abs call in
 java.lang.FdLibm.Expm1#compute
In-Reply-To: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
References: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
Message-ID: <3e5EKlObvGufauPtd7nuHLUEPl3LsxXgsi9QfvgFxX4=.20ecccf9-b432-4366-b621-ff82d0c0bf8c@github.com>

On Thu, 25 Apr 2024 21:32:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Remove unnecessary setting of variable y, found by an IDE inspection noted in the bug report.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18963#pullrequestreview-2023708504

From jjg at openjdk.org  Thu Apr 25 22:53:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 22:53:04 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v8]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <l0Wf7Ng-zjDRAZwhsOY9wf2dytL6ctdsMmLCL3tkgdc=.670a964c-af86-4c75-9d5a-4f6e479ac598@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons 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 8303689.dangling-comments # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
   commit.
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - ... and 1 more: https://git.openjdk.org/jdk/compare/1c238d43...16a265a2

-------------

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=07
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From duke at openjdk.org  Thu Apr 25 23:00:40 2024
From: duke at openjdk.org (Florent Guillaume)
Date: Thu, 25 Apr 2024 23:00:40 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v3]
In-Reply-To: <0n5R0DMwOTSJx8WKPOYIW65c6BNzFxrffMMQd-fVc4c=.85003aac-491b-48b8-8a59-3f06ecc012db@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <0n5R0DMwOTSJx8WKPOYIW65c6BNzFxrffMMQd-fVc4c=.85003aac-491b-48b8-8a59-3f06ecc012db@github.com>
Message-ID: <EZgs7xuYHy0ofvoUNrYjJ53j12hV3akPnVoY099zKus=.9cfd4477-5d8c-436a-acf1-2cace4b91047@github.com>

On Thu, 25 Apr 2024 22:26:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calculate length precisely

src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 181:

> 179:             sb.append(argType.descriptorString());
> 180:         }
> 181:         desc = sb.append(')').append(returnType().descriptorString()).toString();

Nit: the rest of the code (and even the new sizing part you added) uses `returnType` instead of `returnType()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18945#discussion_r1580229759

From liach at openjdk.org  Thu Apr 25 23:08:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 Apr 2024 23:08:33 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v3]
In-Reply-To: <0n5R0DMwOTSJx8WKPOYIW65c6BNzFxrffMMQd-fVc4c=.85003aac-491b-48b8-8a59-3f06ecc012db@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <0n5R0DMwOTSJx8WKPOYIW65c6BNzFxrffMMQd-fVc4c=.85003aac-491b-48b8-8a59-3f06ecc012db@github.com>
Message-ID: <oqtPjYnk4Yvat7gaN-6oLCFVN11t00KTraomMP9febs=.937f7ef6-837e-4473-b62d-7daa3fbaf36c@github.com>

On Thu, 25 Apr 2024 22:26:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calculate length precisely

For the precise-length approach, do you have the results? I guess if we can avoid copying the stringbuilder array, we can make this even faster.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18945#issuecomment-2078311772

From liach at openjdk.org  Thu Apr 25 23:08:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 Apr 2024 23:08:35 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v3]
In-Reply-To: <EZgs7xuYHy0ofvoUNrYjJ53j12hV3akPnVoY099zKus=.9cfd4477-5d8c-436a-acf1-2cace4b91047@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <0n5R0DMwOTSJx8WKPOYIW65c6BNzFxrffMMQd-fVc4c=.85003aac-491b-48b8-8a59-3f06ecc012db@github.com>
 <EZgs7xuYHy0ofvoUNrYjJ53j12hV3akPnVoY099zKus=.9cfd4477-5d8c-436a-acf1-2cace4b91047@github.com>
Message-ID: <OqCfdRV70zOjkiOdciHWSVkv5GALav2Ji0JJN2vdKb0=.b04c6bff-00ca-4915-b12f-f2685cc7ef0e@github.com>

On Thu, 25 Apr 2024 22:57:50 GMT, Florent Guillaume <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Calculate length precisely
>
> src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 181:
> 
>> 179:             sb.append(argType.descriptorString());
>> 180:         }
>> 181:         desc = sb.append(')').append(returnType().descriptorString()).toString();
> 
> Nit: the rest of the code (and even the new sizing part you added) uses `returnType` instead of `returnType()`

Think the `returnType()` call was for parity with displayDescriptor changes; now that we are just in the impl class, either way is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18945#discussion_r1580235742

From bchristi at openjdk.org  Thu Apr 25 23:12:42 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 25 Apr 2024 23:12:42 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v25]
In-Reply-To: <QYPKvVXtbok97VG4G8lbQOihzUBsO0aaeEyf6gaYihU=.7eb88222-132e-43f9-892a-80af9ab3f8b8@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <jkZ-gpxv7E1Eov1_7RJFiBhtXs0gy1WUkxNdGZ1j4EU=.3860f93c-b8c3-4628-acc9-e3be1405b461@github.com>
 <QYPKvVXtbok97VG4G8lbQOihzUBsO0aaeEyf6gaYihU=.7eb88222-132e-43f9-892a-80af9ab3f8b8@github.com>
Message-ID: <gxXNVxA9GK__kmeHQkgq5VDtIg0gAHdhhNh_RKsOAks=.5fcdc2e8-e241-4642-946c-56725db7fcfa@github.com>

On Thu, 25 Apr 2024 08:25:39 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   package spec updates, mostly about reference queues and dequeueing
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 153:
> 
>> 151:  * <li> The enqueueing of a reference (by the garbage collector, or
>> 152:  * by a successful call to {@link Reference#enqueue}) <i>happens-before</i>
>> 153:  * the reference is removed from the queue (<em>dequeued</em>).</li>
> 
> @bchristi-git I wonder if it makes sense to use the same style when referring to "dequeue", so either always within quotes or only using <em>em</em> (see line 108)

Sure; I'll remove the quotes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1580238810

From bchristi at openjdk.org  Thu Apr 25 23:23:58 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 25 Apr 2024 23:23:58 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v26]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <JOeZ7G7Ig0sNcFbLX2vN6SdZWR3w3qupGEG7jT7qPyg=.81516b8b-89e9-484c-8376-f3016c83d871@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  remove quotes from dequeue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/16fcc764..0b9d3efc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=24-25

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From jjg at openjdk.org  Thu Apr 25 23:24:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 23:24:07 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  revert need to disable warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/16a265a2..39689a52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From vromero at openjdk.org  Fri Apr 26 00:23:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 00:23:33 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
Message-ID: <txquEDIJ7YBKTZ6-EggzWEHSYzFxMXIBbwTuexdYXro=.af5bb232-dbd4-4099-9fc7-3bc22aacdd07@github.com>

On Thu, 25 Apr 2024 23:24:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert need to disable warning

looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 583:

> 581:      *     dangling comments are also attached to the tree node
> 582:      *     by registering them using the {@link #deferredLintHandler}.
> 583:      *  5. (Later) Warnings may be genereated for the dangling

typo: generated

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2023792395
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1580263826

From bchristi at openjdk.org  Fri Apr 26 00:26:56 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 26 Apr 2024 00:26:56 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v27]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <vtU4DokSNlYxRCaBzdfudb1lcgsK0pHhQomQvPWQqA8=.31fe6496-3118-4c75-88d8-8772b7e10a0c@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  add memviz bullet for finalization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/0b9d3efc..77d53818

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=25-26

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From darcy at openjdk.org  Fri Apr 26 01:35:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Apr 2024 01:35:56 GMT
Subject: RFR: 8331108: Unused Math.abs call in
 java.lang.FdLibm.Expm1#compute [v2]
In-Reply-To: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
References: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
Message-ID: <RIrpm7Q9H6QSS6qAzGBja5IqTskMoXJhqgdF7ZJI5Ns=.45a78322-25c3-4965-a573-78f6bf34ee60@github.com>

> Remove unnecessary setting of variable y, found by an IDE inspection noted in the bug report.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18963/files
  - new: https://git.openjdk.org/jdk/pull/18963/files/e8f5c334..f0ed7d5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18963&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18963&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18963/head:pull/18963

PR: https://git.openjdk.org/jdk/pull/18963

From darcy at openjdk.org  Fri Apr 26 02:07:39 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 Apr 2024 02:07:39 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <3bVBncVGIg7Wh46TGgEevHt9AWqNvAcU2Cke8iQNn9A=.8d40431e-c578-4d5b-9dbd-c9e9fd55bb91@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <EraXrOvD8Jm9Yy6ZwOB448SUHswYn9Nu_X_FMMQrTYc=.7c049574-d1c8-4c1f-9b2d-a6cd68f7f2c0@github.com>
 <UeTlF6XlFqMijlqRAt_EBrPYzMSOjLmvqPXej5m4Qz8=.c54e472c-1b98-4817-9c09-34b6188f7797@github.com>
 <3bVBncVGIg7Wh46TGgEevHt9AWqNvAcU2Cke8iQNn9A=.8d40431e-c578-4d5b-9dbd-c9e9fd55bb91@github.com>
Message-ID: <I4UxKi3g8mXU0fouihGHUPgsIZJg1XPDnAIYcGk_TY0=.7e0e82dc-1b89-4bd1-af5b-25fe642f2e19@github.com>

On Tue, 19 Mar 2024 19:32:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I think splitting `CharArraySequence` into two versions is somewhat dubious as more observable types at call sites may mean the performance gain in targeted micros is lost. How much of an improvement did you observe from this? Again the `char[]` constructors is probably less performance sensitive than the others.
>
>> @cl4es @jddarcy All feedback has been fixed, can it be integrated?
> 
> Hello @wenshao ,
> 
> This change will need additional review from myself or others who maintain BigDecimal before it can be integrated.

> @jddarcy Sorry for the pings, Can you review this PR for me?

Hi @wenshao ,
Can you provide some additional context about the benefits of this change beyond the micro/nano bechmark results that have been discussed. For example, is there interesting workload the change improves, etc.? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2078497794

From mchung at openjdk.org  Fri Apr 26 02:21:42 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 02:21:42 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
Message-ID: <FrKwZ0qSPO--Emunr1v_WG-aEFCUPs0BA2UosKOBOTI=.1bb59a4c-0e51-447f-8d51-1277b4912f93@github.com>

On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidental use of java.lang.classfile

Nit: the copyright header needs update before integration.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18953#pullrequestreview-2023964506

From mchung at openjdk.org  Fri Apr 26 02:23:34 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 02:23:34 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v9]
In-Reply-To: <QfuKEnxxCeRzBKjFcTNkFmPcv81YgiXbHIiWsIcmnRo=.d241bab3-ff1b-4ab6-8f01-c759a24f51cd@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <QfuKEnxxCeRzBKjFcTNkFmPcv81YgiXbHIiWsIcmnRo=.d241bab3-ff1b-4ab6-8f01-c759a24f51cd@github.com>
Message-ID: <YcoWAsUEHq5LWp4JhQPx9-RXQgaq8_PSDHnmKY692Kg=.8e37a153-4dc8-4a85-8f98-b72ccda31803@github.com>

On Wed, 24 Apr 2024 19:13:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Nits, clean up constant, introduce missing constant MethodTypeDesc for toString

It's a little confusing for JDK-8327247 to have 2 PRs but it's okay.   We can add a note in JDK-8327247 to clarify.  I assume you plan to use PR to convert to use ClassFile API after you pull from JDK-8327247 once integrated?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2078512445

From liach at openjdk.org  Fri Apr 26 02:39:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 02:39:37 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
Message-ID: <NW81JqQGlj1tTwKciycY0uFtN1NyVsHYkAxsuNEyg0w=.f265fef0-73be-45b0-b152-4f8c1ffb9677@github.com>

On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidental use of java.lang.classfile

Also a side note for backport: ClassFileDumper exists only since JDK 21, so for earlier backports you need to use an alternative dumping method or remove dumping ability.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18953#issuecomment-2078532971

From mchung at openjdk.org  Fri Apr 26 03:17:34 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 03:17:34 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
Message-ID: <oWSJww3ZwiWTMuGWXRb190hq9nY32FtrMzIINJZbftY=.1dacc93f-d74e-4964-8d98-39dfbfd9f1e0@github.com>

On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidental use of java.lang.classfile

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1057:

> 1055:      */
> 1056:     private static final class SimpleStringBuilderStrategy {
> 1057:         static final int CLASSFILE_VERSION = 52; // JDK 8

Alternatively, this can use `ClassFileFormatVersion.latest().major()` which exists since JDK 20.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18953#discussion_r1580432036

From duke at openjdk.org  Fri Apr 26 04:54:37 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 26 Apr 2024 04:54:37 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <I4UxKi3g8mXU0fouihGHUPgsIZJg1XPDnAIYcGk_TY0=.7e0e82dc-1b89-4bd1-af5b-25fe642f2e19@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <EraXrOvD8Jm9Yy6ZwOB448SUHswYn9Nu_X_FMMQrTYc=.7c049574-d1c8-4c1f-9b2d-a6cd68f7f2c0@github.com>
 <UeTlF6XlFqMijlqRAt_EBrPYzMSOjLmvqPXej5m4Qz8=.c54e472c-1b98-4817-9c09-34b6188f7797@github.com>
 <3bVBncVGIg7Wh46TGgEevHt9AWqNvAcU2Cke8iQNn9A=.8d40431e-c578-4d5b-9dbd-c9e9fd55bb91@github.com>
 <I4UxKi3g8mXU0fouihGHUPgsIZJg1XPDnAIYcGk_TY0=.7e0e82dc-1b89-4bd1-af5b-25fe642f2e19@github.com>
Message-ID: <kaBDXxXjmyBFO7W5vde4Cpe1r_YaoRfyZW7BRL4MAQ0=.023ff22a-1d5d-4a29-ac26-4fe4a231bf7c@github.com>

On Fri, 26 Apr 2024 02:04:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> @cl4es @jddarcy All feedback has been fixed, can it be integrated?
>> 
>> Hello @wenshao ,
>> 
>> This change will need additional review from myself or others who maintain BigDecimal before it can be integrated.
>
>> @jddarcy Sorry for the pings, Can you review this PR for me?
> 
> Hi @wenshao ,
> Can you provide some additional context about the benefits of this change beyond the micro/nano bechmark results that have been discussed. For example, is there interesting workload the change improves, etc.? Thanks.

Thanks @jddarcy, I will provide new performance test data tomorrow (Saturday, April 26th)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2078625327

From duke at openjdk.org  Fri Apr 26 05:48:03 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 26 Apr 2024 05:48:03 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v18]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <Yw4kcTjZKxBKUDXIf0DFZLJ-ZA-axRJwUTv51jOnFic=.abb52ebf-e0a6-468d-aba5-11e123c172ed@github.com>

> The current BigDecimal(String) constructor calls String#toCharArray, which has a memory allocation.
> 
> 
> public BigDecimal(String val) {
>     this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
> 
> 
> When the length is greater than 18, create a char[]
> 
> 
> boolean isCompact = (len <= MAX_COMPACT_DIGITS); // 18
> if (!isCompact) {
>     // ...
> } else {
>     char[] coeff = new char[len]; // allocate char[]
>     // ...
> }
> 
> 
> This PR eliminates the two memory allocations mentioned above, resulting in an approximate 60% increase in performance..

Shaojin Wen 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 22 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_dec_new
 - Merge remote-tracking branch 'upstream/master' into optim_dec_new
 - use while instead for
 - Update src/java.base/share/classes/java/math/BigDecimal.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - bug fix for CharArraySequence#charAt
 - bug fix for CharArraySequence
 - fix benchmark
 - one CharArraySequence
 - restore comment
 - easier to compare
 - ... and 12 more: https://git.openjdk.org/jdk/compare/1701be36...bb620ba3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/e516b580..bb620ba3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=16-17

  Stats: 6763 lines in 129 files changed: 5031 ins; 1483 del; 249 mod
  Patch: https://git.openjdk.org/jdk/pull/18177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18177/head:pull/18177

PR: https://git.openjdk.org/jdk/pull/18177

From stuefe at openjdk.org  Fri Apr 26 07:02:37 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 26 Apr 2024 07:02:37 GMT
Subject: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll
 enhance jli tracing [v6]
In-Reply-To: <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
Message-ID: <UWXjxmTCKFpbTkfqbssRvvd6qwMQ3TFJGL1B63EbFVY=.198260a6-1ec2-4af6-9c06-e0098fd843c1@github.com>

On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove /jre path check

Change still good

> Still looks good. We should maybe change the synopsis (title) of the bug to something like "libjli GetApplicationHome cleanups"?

Well, it does enhance tracing, so the title is not lying :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2078751493

From asotona at openjdk.org  Fri Apr 26 07:05:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 26 Apr 2024 07:05:38 GMT
Subject: Integrated: 8322847: java.lang.classfile.BufWriter should specify
 @throws for its writeXXX methods
In-Reply-To: <LbGxj-m_26dMeRG6TgVNN16NSWtmutE5jW5pL4r1_7o=.84713a17-9ffe-435a-96e7-f1e9f5d8345a@github.com>
References: <LbGxj-m_26dMeRG6TgVNN16NSWtmutE5jW5pL4r1_7o=.84713a17-9ffe-435a-96e7-f1e9f5d8345a@github.com>
Message-ID: <rMBwCeZXasVBc6XG7R8S9frmBmx4rcyTXrfPrdGA6Cw=.8725109f-0191-41ef-889d-35be7fbfd4e8@github.com>

On Tue, 23 Apr 2024 11:56:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch adds missing `@throws` javadoc annotations to `java.lang.classfile.BufWriter`.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: ea061298
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea06129851be7bd9876685f74e35392874154179
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8322847: java.lang.classfile.BufWriter should specify @throws for its writeXXX methods

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/18913

From asotona at openjdk.org  Fri Apr 26 07:43:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 26 Apr 2024 07:43:01 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes [v2]
In-Reply-To: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
Message-ID: <dB7knUFZ3kJZ2NOc524OqlrO0_6rcnkKTzf5EgIU6mM=.8d4f3c0d-f4cb-43d8-8b49-c9ffc8015829@github.com>

> ClassFile API dives into the nested constant pool entries without type restrictions, while parsing a class file. Validation of the entry is performed post-parsing. Specifically corrupted constant pool entry may cause infinite loop during parsing and throws SOE.
> This patch resolves the issue by providing specific implementations for the nested CP entries parsing, instead of sharing the common (post-checking) code.
> Added test simulates the situation on inner-looped method reference entry.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  implemented proposed simpler solution with lower and upper bound tags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18907/files
  - new: https://git.openjdk.org/jdk/pull/18907/files/ce3bd205..e706346b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18907&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18907&range=00-01

  Stats: 91 lines in 1 file changed: 17 ins; 53 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/18907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18907/head:pull/18907

PR: https://git.openjdk.org/jdk/pull/18907

From mbaesken at openjdk.org  Fri Apr 26 07:48:35 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Apr 2024 07:48:35 GMT
Subject: RFR: 8329862: libjli GetApplicationHome cleanups and enhance jli
 tracing [v6]
In-Reply-To: <UWXjxmTCKFpbTkfqbssRvvd6qwMQ3TFJGL1B63EbFVY=.198260a6-1ec2-4af6-9c06-e0098fd843c1@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
 <UWXjxmTCKFpbTkfqbssRvvd6qwMQ3TFJGL1B63EbFVY=.198260a6-1ec2-4af6-9c06-e0098fd843c1@github.com>
Message-ID: <hv2ytz7FXa74H3fn5TVilN5ljDsr8Vi9uWtVP_Wef58=.5e86526e-cc97-4ec3-aafb-2f38e2fa3b32@github.com>

On Fri, 26 Apr 2024 07:00:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Still looks good. We should maybe change the synopsis (title) of the bug to something like "libjli GetApplicationHome cleanups"?

I changed the synopsis because it was indeed now not really reflecting any more what the change does.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2078821181

From asotona at openjdk.org  Fri Apr 26 07:54:31 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 26 Apr 2024 07:54:31 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes [v2]
In-Reply-To: <B5NAWPrB09r6Z938sTcAH80r7u77R5fN_SuKYuKibIg=.a0c1fd4f-4426-4650-a773-c5f58f3282bd@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
 <xhnphsmt74pb52uEUwOarr0LZNHSlE3StvAdBelc61Y=.1f7bb136-3f2b-4499-b87d-916e0479162f@github.com>
 <Yq-gg4AoITsJrHMj_WV-LrwDENnQv1JqFro6Zj5KYM8=.66871edd-de1f-4fea-a38d-05ae7bf91d26@github.com>
 <B5NAWPrB09r6Z938sTcAH80r7u77R5fN_SuKYuKibIg=.a0c1fd4f-4426-4650-a773-c5f58f3282bd@github.com>
Message-ID: <FeJmUg9p98NdfxQPT5c9BGMgUafWmqRhG-c2bUOyIJo=.e132dfba-72ed-47ff-86dc-f8012d100b7b@github.com>

On Thu, 25 Apr 2024 20:16:09 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> It could be two tags, a lower and upper bound, because TAG_FIELDREF, TAG_METHODREF, and TAG_INTERFACEMETHODREF are consecutive values (9 to 11).

OK, I've implemented it with lower and upper bound tags. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18907#issuecomment-2078828894

From clanger at openjdk.org  Fri Apr 26 07:55:37 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 26 Apr 2024 07:55:37 GMT
Subject: RFR: 8329862: libjli GetApplicationHome cleanups and enhance jli
 tracing [v6]
In-Reply-To: <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
Message-ID: <5bdOr2kfwtaSrQbEP6Dg5d_TZmm6hDulP2GwHcZlj0o=.7d0069d5-7593-47c5-9e92-65ab91ea73c8@github.com>

On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove /jre path check

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18699#pullrequestreview-2024359622

From redestad at openjdk.org  Fri Apr 26 08:07:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 08:07:04 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v4]
In-Reply-To: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
Message-ID: <tz_5xaSN3AugzCJryL9yXlrmuo31I8BbVUYJn7wsN8k=.4a89290d-9c44-4562-a7fd-74452260279b@github.com>

> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
> 
> Performance improves across the board in existing microbenchmarks:
> 
> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>   * = significant
> 
> 
> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
> 
> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>   * = significant
>   ```
>   
>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Use returnType field directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18945/files
  - new: https://git.openjdk.org/jdk/pull/18945/files/15c8d39c..6ff505f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18945/head:pull/18945

PR: https://git.openjdk.org/jdk/pull/18945

From redestad at openjdk.org  Fri Apr 26 08:10:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 08:10:34 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v3]
In-Reply-To: <oqtPjYnk4Yvat7gaN-6oLCFVN11t00KTraomMP9febs=.937f7ef6-837e-4473-b62d-7daa3fbaf36c@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <0n5R0DMwOTSJx8WKPOYIW65c6BNzFxrffMMQd-fVc4c=.85003aac-491b-48b8-8a59-3f06ecc012db@github.com>
 <oqtPjYnk4Yvat7gaN-6oLCFVN11t00KTraomMP9febs=.937f7ef6-837e-4473-b62d-7daa3fbaf36c@github.com>
Message-ID: <TEDdv3soEukF0Uud-mUfH5wJs2IW5sl9r2bjlS90N4c=.a13ad285-c48b-4bcd-8539-597c45adc5f4@github.com>

On Thu, 25 Apr 2024 23:06:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> For the precise-length approach, do you have the results? I guess if we can avoid copying the stringbuilder array, we can make this even faster.

Not sure what you mean - the latest performance numbers I posted are for the precise length version (15c8d39) if that was unclear.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18945#issuecomment-2078854535

From redestad at openjdk.org  Fri Apr 26 08:10:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 08:10:35 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v3]
In-Reply-To: <OqCfdRV70zOjkiOdciHWSVkv5GALav2Ji0JJN2vdKb0=.b04c6bff-00ca-4915-b12f-f2685cc7ef0e@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <0n5R0DMwOTSJx8WKPOYIW65c6BNzFxrffMMQd-fVc4c=.85003aac-491b-48b8-8a59-3f06ecc012db@github.com>
 <EZgs7xuYHy0ofvoUNrYjJ53j12hV3akPnVoY099zKus=.9cfd4477-5d8c-436a-acf1-2cace4b91047@github.com>
 <OqCfdRV70zOjkiOdciHWSVkv5GALav2Ji0JJN2vdKb0=.b04c6bff-00ca-4915-b12f-f2685cc7ef0e@github.com>
Message-ID: <z2nA6xn4A0gnAwtghxSUCDnJwADPW8mGu5wO-nOFPH0=.fcd63214-db42-4d68-8e8d-c3b7ea1bf9ab@github.com>

On Thu, 25 Apr 2024 23:03:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 181:
>> 
>>> 179:             sb.append(argType.descriptorString());
>>> 180:         }
>>> 181:         desc = sb.append(')').append(returnType().descriptorString()).toString();
>> 
>> Nit: the rest of the code (and even the new sizing part you added) uses `returnType` instead of `returnType()`
>
> Think the `returnType()` call was for parity with displayDescriptor changes; now that we are just in the impl class, either way is fine.

Thanks, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18945#discussion_r1580645953

From vklang at openjdk.org  Fri Apr 26 08:12:58 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 26 Apr 2024 08:12:58 GMT
Subject: RFR: 8296543: Update exception documentation for
 ExecutorService.invokeAll overriders as required
Message-ID: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>

This PR adds the exception documentation as per the ExecutorService API contract. I also took the liberty of adding @Override-annotations to be clear about intent.

-------------

Commit messages:
 - 8296543 - adding javadoc for thrown exceptions from AbstractExecutorService methods

Changes: https://git.openjdk.org/jdk/pull/18966/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18966&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296543
  Stats: 31 lines in 1 file changed: 31 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18966.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18966/head:pull/18966

PR: https://git.openjdk.org/jdk/pull/18966

From vklang at openjdk.org  Fri Apr 26 08:12:58 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 26 Apr 2024 08:12:58 GMT
Subject: RFR: 8296543: Update exception documentation for
 ExecutorService.invokeAll overriders as required
In-Reply-To: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
References: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
Message-ID: <l7z3q-Gvc5vPOVu9L77O4-4Fmsu6JoFWo2sRrOiSG3g=.07030fc2-aabf-4622-8ae8-69974f522129@github.com>

On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR adds the exception documentation as per the ExecutorService API contract. I also took the liberty of adding @Override-annotations to be clear about intent.

@pavelrappo @DougLea Looks good?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18966#issuecomment-2078859260

From mbaesken at openjdk.org  Fri Apr 26 08:14:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Apr 2024 08:14:42 GMT
Subject: RFR: 8329862: libjli GetApplicationHome cleanups and enhance jli
 tracing [v6]
In-Reply-To: <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <olJ-wKcMOESAmJ5kDs9l1zBvmnJJLT8oImUXLm6ZTB0=.dea73982-ccd0-4284-9dde-4ff7ec55122b@github.com>
Message-ID: <gP5stCcKCu9Uy3Anm52zvwmfaymXIdwQPI0DMwjPfr4=.188e3603-4803-4aac-84c7-6c375661f8b8@github.com>

On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove /jre path check

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2078867092

From mbaesken at openjdk.org  Fri Apr 26 08:14:43 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Apr 2024 08:14:43 GMT
Subject: Integrated: 8329862: libjli GetApplicationHome cleanups and enhance
 jli tracing
In-Reply-To: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
Message-ID: <nbIf8gmIgixMexzWvu5mp9PFlLHnFZvFzzdypzh-HHE=.a04c24e6-2be0-4b5b-89b5-40ef7f44277c@github.com>

On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have already good JLI tracing capabilities. But GetApplicationHome and GetApplicationHomeFromDll lack some tracing and should be enhanced.

This pull request has now been integrated.

Changeset: 377f2e53
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/377f2e538ae0fc94fc5483700a3ae70175017741
Stats:     46 lines in 2 files changed: 8 ins; 36 del; 2 mod

8329862: libjli GetApplicationHome cleanups and enhance jli tracing

Reviewed-by: clanger, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/18699

From redestad at openjdk.org  Fri Apr 26 08:17:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 08:17:33 GMT
Subject: RFR: 8331134: Port SimpleStringBuilderStrategy to use ClassFile
 API [v9]
In-Reply-To: <YcoWAsUEHq5LWp4JhQPx9-RXQgaq8_PSDHnmKY692Kg=.8e37a153-4dc8-4a85-8f98-b72ccda31803@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <QfuKEnxxCeRzBKjFcTNkFmPcv81YgiXbHIiWsIcmnRo=.d241bab3-ff1b-4ab6-8f01-c759a24f51cd@github.com>
 <YcoWAsUEHq5LWp4JhQPx9-RXQgaq8_PSDHnmKY692Kg=.8e37a153-4dc8-4a85-8f98-b72ccda31803@github.com>
Message-ID: <rmv0NMJfGtFk6O7xc8pEE_bUS6ZfJEf0AAP7WgkCmKE=.4f4355c1-f4e7-45ac-a192-7325553fe54e@github.com>

On Fri, 26 Apr 2024 02:20:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> It's a little confusing for JDK-8327247 to have 2 PRs but it's okay. We can add a note in JDK-8327247 to clarify. I assume you plan to use PR to convert to use ClassFile API after you pull from JDK-8327247 once integrated?

Yes, this PR will be rebased on top of the changes I want to push in #18953 and retargeted as [JDK-8331134](https://bugs.openjdk.org/browse/JDK-8331134)
Port SimpleStringBuilderStrategy to use ClassFile API. I'll go ahead an rename this and prepare the rebasing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2078875808

From redestad at openjdk.org  Fri Apr 26 08:39:32 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 08:39:32 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <NW81JqQGlj1tTwKciycY0uFtN1NyVsHYkAxsuNEyg0w=.f265fef0-73be-45b0-b152-4f8c1ffb9677@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
 <NW81JqQGlj1tTwKciycY0uFtN1NyVsHYkAxsuNEyg0w=.f265fef0-73be-45b0-b152-4f8c1ffb9677@github.com>
Message-ID: <0SR5pkOS8wqYZop2zmqGww585ck26wvivMLXXu9XO3k=.f31d69f7-503a-432d-9c9d-c11c516728cf@github.com>

On Fri, 26 Apr 2024 02:36:22 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also a side note for backport: ClassFileDumper exists only since JDK 21, so for earlier backports you need to use an alternative dumping method or remove dumping ability.

Yes, original code used ProxyClassDumper, which was renamed/reworked in 21 by [JDK-8304846](https://bugs.openjdk.org/browse/JDK-8304846). I think we've gone as far as we can code-wise in ensuring this is cleanly backportable to at least 21. I'll add a comment about ProxyClassDumper.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18953#issuecomment-2078910803

From redestad at openjdk.org  Fri Apr 26 08:39:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 08:39:34 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <oWSJww3ZwiWTMuGWXRb190hq9nY32FtrMzIINJZbftY=.1dacc93f-d74e-4964-8d98-39dfbfd9f1e0@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
 <oWSJww3ZwiWTMuGWXRb190hq9nY32FtrMzIINJZbftY=.1dacc93f-d74e-4964-8d98-39dfbfd9f1e0@github.com>
Message-ID: <FVW7M9aGdzQMTf6L_GYj_qFDRkqtsATO4rWoam7A6ek=.3d6db963-b93b-4924-b6a1-2a721acde93a@github.com>

On Fri, 26 Apr 2024 03:14:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove accidental use of java.lang.classfile
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1057:
> 
>> 1055:      */
>> 1056:     private static final class SimpleStringBuilderStrategy {
>> 1057:         static final int CLASSFILE_VERSION = 52; // JDK 8
> 
> Alternatively, this can use `ClassFileFormatVersion.latest().major()` which exists since JDK 20.

As the original code just had 52 verbatim and I don't know how far we'll want to backport this I think it's fine to leave this at 52.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18953#discussion_r1580682911

From alanb at openjdk.org  Fri Apr 26 08:40:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Apr 2024 08:40:42 GMT
Subject: RFR: 8329862: libjli GetApplicationHome cleanups and enhance jli
 tracing [v5]
In-Reply-To: <rk9SWljzgkvPpacUzjy4ghQWxShrcf3H-zzUoBr7-eU=.53731655-8b5a-43f2-842e-910cf5692cdd@github.com>
References: <4o3yxCDNatEHR5THbF6be-abo4HkCkxtSzqck-b0XxQ=.4c9926bb-f5a6-46e0-bada-6dc59ae1c497@github.com>
 <gC_tj8pr-DjJpponY6WLeMAAMhrRObOyx5hgev_qd7s=.9fffb44f-129b-40f9-a50e-15db0cbf8faa@github.com>
 <rk9SWljzgkvPpacUzjy4ghQWxShrcf3H-zzUoBr7-eU=.53731655-8b5a-43f2-842e-910cf5692cdd@github.com>
Message-ID: <Podus6yCeUs5QW7AeBV3L8-8dC1fsuigLQR0zD-CCI8=.38170af4-113a-4562-bbb1-094bcaed19b4@github.com>

On Thu, 25 Apr 2024 13:17:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I removed the mentioned 'private JRE' check and also the related size check.

Good, I'll look at it as soon as I can. I suspect we'll need some follow on issues as there are several issues here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18699#issuecomment-2078914259

From redestad at openjdk.org  Fri Apr 26 08:45:45 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 08:45:45 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v3]
In-Reply-To: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
Message-ID: <5WbLD01cK3txEAeGRKcQPsMOD1VZ6XQNL00nydhvQqU=.6467f456-0720-403f-96bb-8c3bdf6b7abb@github.com>

> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Copyright and comment about ProxyClassDumper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18953/files
  - new: https://git.openjdk.org/jdk/pull/18953/files/a4dfbfca..591d2d1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18953&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18953&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18953/head:pull/18953

PR: https://git.openjdk.org/jdk/pull/18953

From redestad at openjdk.org  Fri Apr 26 08:45:46 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 08:45:46 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v2]
In-Reply-To: <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <EN03yr27rISkvUggvuQ-D7MCnWoJObtjm7WaYhHRipc=.59f1b835-2b1c-475d-8b00-49acb17f5c45@github.com>
Message-ID: <IseyxyKyN0-uAYQszUHSS7joRw69LShPgb71lqiiHH4=.fef2e9f6-ff22-4ef1-bf4b-cc038813e4ed@github.com>

On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidental use of java.lang.classfile

@shipilev are you OK with this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18953#issuecomment-2078922183

From rgiulietti at openjdk.org  Fri Apr 26 09:08:33 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 26 Apr 2024 09:08:33 GMT
Subject: RFR: 8331108: Unused Math.abs call in
 java.lang.FdLibm.Expm1#compute [v2]
In-Reply-To: <RIrpm7Q9H6QSS6qAzGBja5IqTskMoXJhqgdF7ZJI5Ns=.45a78322-25c3-4965-a573-78f6bf34ee60@github.com>
References: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
 <RIrpm7Q9H6QSS6qAzGBja5IqTskMoXJhqgdF7ZJI5Ns=.45a78322-25c3-4965-a573-78f6bf34ee60@github.com>
Message-ID: <LuY_dJtxMDMARbT9TdtmICJxUOAY8pLOL9LoGpbE3Dc=.ae64231b-62e4-4037-9eb9-91cb49110e1d@github.com>

On Fri, 26 Apr 2024 01:35:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Remove unnecessary setting of variable y, found by an IDE inspection noted in the bug report.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18963#pullrequestreview-2024512783

From shade at openjdk.org  Fri Apr 26 09:11:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Apr 2024 09:11:34 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v3]
In-Reply-To: <5WbLD01cK3txEAeGRKcQPsMOD1VZ6XQNL00nydhvQqU=.6467f456-0720-403f-96bb-8c3bdf6b7abb@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <5WbLD01cK3txEAeGRKcQPsMOD1VZ6XQNL00nydhvQqU=.6467f456-0720-403f-96bb-8c3bdf6b7abb@github.com>
Message-ID: <0ExAntUZ0qo9xaZhEwQZeAGhjlE8FAkbp8d6s-uFkVo=.39d809f9-2b14-4986-b318-9231a6ca11fb@github.com>

On Fri, 26 Apr 2024 08:45:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright and comment about ProxyClassDumper

Looks okay, thanks. Only cosmetic nits:

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 108:

> 106:     static {
> 107:         String highArity = VM.getSavedProperty("java.lang.invoke.StringConcat.highArityThreshold");
> 108:         HIGH_ARITY_THRESHOLD = Integer.parseInt(highArity != null ? highArity : "20");

Maybe write this as `= (highArity != null) ? Integer.parseInt(highArity) : 20` to help interpreter a bit.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1105:

> 1103:             for (int c = 0; c < constants.length; c++) {
> 1104:                 if (constants[c] != null)
> 1105:                     len += constants[c].length();

Braces?

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1118:

> 1116:             );
> 1117: 
> 1118: 

Extra new-line?

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1164:

> 1162:         }
> 1163: 
> 1164: 

Extra new-line?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18953#pullrequestreview-2024514742
PR Review Comment: https://git.openjdk.org/jdk/pull/18953#discussion_r1580723293
PR Review Comment: https://git.openjdk.org/jdk/pull/18953#discussion_r1580723981
PR Review Comment: https://git.openjdk.org/jdk/pull/18953#discussion_r1580724174
PR Review Comment: https://git.openjdk.org/jdk/pull/18953#discussion_r1580724568

From rgiulietti at openjdk.org  Fri Apr 26 09:41:21 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 26 Apr 2024 09:41:21 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v3]
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <PIaR6T0MKovlJXXxEzbFCoeP_YTpk2r21a0iT9ZCh4s=.779da8bf-abcd-42d1-bf5c-8f410cd0e26d@github.com>

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Terminology changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18932/files
  - new: https://git.openjdk.org/jdk/pull/18932/files/ba6d052c..fd84a28b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=01-02

  Stats: 12 lines in 2 files changed: 2 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18932/head:pull/18932

PR: https://git.openjdk.org/jdk/pull/18932

From redestad at openjdk.org  Fri Apr 26 09:42:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 09:42:06 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v4]
In-Reply-To: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
Message-ID: <NuMarpRCuziKXVaC53JGQH7EioWyRxNii_kviqcm7dk=.4bffa9b2-cef7-448c-92a7-b2b407299153@github.com>

> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Fix nits, use iconst as intended

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18953/files
  - new: https://git.openjdk.org/jdk/pull/18953/files/591d2d1c..9b083f4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18953&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18953&range=02-03

  Stats: 9 lines in 1 file changed: 1 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18953/head:pull/18953

PR: https://git.openjdk.org/jdk/pull/18953

From redestad at openjdk.org  Fri Apr 26 09:42:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 09:42:07 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v3]
In-Reply-To: <5WbLD01cK3txEAeGRKcQPsMOD1VZ6XQNL00nydhvQqU=.6467f456-0720-403f-96bb-8c3bdf6b7abb@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <5WbLD01cK3txEAeGRKcQPsMOD1VZ6XQNL00nydhvQqU=.6467f456-0720-403f-96bb-8c3bdf6b7abb@github.com>
Message-ID: <d6Dhay4zOY0VbJXhzxbsMsd9kxEGx5DUMM5mFncMM6o=.9105b13e-c609-476b-a8f8-2a2d37da2026@github.com>

On Fri, 26 Apr 2024 08:45:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright and comment about ProxyClassDumper

Thanks, nits resolved. Also some minor improvement (improved for; use iconst(mv, len) as originally intended)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18953#issuecomment-2079016011

From redestad at openjdk.org  Fri Apr 26 09:54:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 09:54:34 GMT
Subject: RFR: 8327247: C2 uses up to 2GB of RAM to compile complex string
 concat in extreme cases [v4]
In-Reply-To: <NuMarpRCuziKXVaC53JGQH7EioWyRxNii_kviqcm7dk=.4bffa9b2-cef7-448c-92a7-b2b407299153@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
 <NuMarpRCuziKXVaC53JGQH7EioWyRxNii_kviqcm7dk=.4bffa9b2-cef7-448c-92a7-b2b407299153@github.com>
Message-ID: <-n0xxJGoysb8zqq-wkXUH_6yKEA4uFMzC2Qfs32tgsc=.7c50bf03-4bcc-4df6-b6b1-adec389c05b3@github.com>

On Fri, 26 Apr 2024 09:42:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix nits, use iconst as intended

Running another round of sanity testing (tier1+2) before integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18953#issuecomment-2079038010

From redestad at openjdk.org  Fri Apr 26 10:32:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 10:32:02 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor for
 primitive types
Message-ID: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>

This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 

Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:


Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
  :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
  :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
  :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
  :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
  :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
  :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36,010 ?   3,882  ns/op   0,97x (p = 0,146 )
  :gc.alloc.rate.norm                                                              104,000 ?   0,000    104,000 ?   0,000   B/op   1,00x (p = 0,140 )
  * = significant

-------------

Commit messages:
 - Restructure micros
 - Update ConstantUtils.parseMethodDescriptor
 - Merge in ClassDescriptor micro

Changes: https://git.openjdk.org/jdk/pull/18971/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331187
  Stats: 126 lines in 6 files changed: 88 ins; 9 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/18971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18971/head:pull/18971

PR: https://git.openjdk.org/jdk/pull/18971

From redestad at openjdk.org  Fri Apr 26 10:54:49 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 10:54:49 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v2]
In-Reply-To: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
Message-ID: <5YIerTL-tD8IhFMDCHr6CzPo40EOvoHv65ziF-dK2gQ=.5067dc3f-e6f0-4a24-b962-59f45bdeba2c@github.com>

> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
> 
> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
> 
> 
> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36,010 ?   3,882  ns/op   0,97x (p = 0,1...

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Fix ClassDescTest; remove redundant validation performed by ReferenceClassDescImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18971/files
  - new: https://git.openjdk.org/jdk/pull/18971/files/96aa846b..257dc547

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18971&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18971&range=00-01

  Stats: 14 lines in 2 files changed: 1 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18971/head:pull/18971

PR: https://git.openjdk.org/jdk/pull/18971

From jvernee at openjdk.org  Fri Apr 26 11:30:32 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 26 Apr 2024 11:30:32 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v2]
In-Reply-To: <5YIerTL-tD8IhFMDCHr6CzPo40EOvoHv65ziF-dK2gQ=.5067dc3f-e6f0-4a24-b962-59f45bdeba2c@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <5YIerTL-tD8IhFMDCHr6CzPo40EOvoHv65ziF-dK2gQ=.5067dc3f-e6f0-4a24-b962-59f45bdeba2c@github.com>
Message-ID: <JWYdGeUq2SxXhGB087WbEo-_o3U5IHOkHMTdCDdcfog=.4a1b3dc2-26bd-48a7-b65b-55689981b981@github.com>

On Fri, 26 Apr 2024 10:54:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
>> 
>> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
>> 
>> 
>> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
>> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
>> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ClassDescTest; remove redundant validation performed by ReferenceClassDescImpl

Looks like your `MethodTypeDescFactories` benchmark is missing form the PR?

Does removing the explicit null checks make that much difference for performance? They are kind of nice for clarity.

Also, looks like the copyright year still needs to be updated on some of the files.

src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 97:

> 95:         int args = ptypes.size() - 1;
> 96:         ClassDesc[] paramTypes = args > 0
> 97:                 ? ptypes.subList(1, args + 1).toArray(new ClassDesc[0])

I suppose this could also use `EMPTY_CLASSDESC` instead of creating a new array

-------------

PR Review: https://git.openjdk.org/jdk/pull/18971#pullrequestreview-2024805435
PR Review Comment: https://git.openjdk.org/jdk/pull/18971#discussion_r1580881761

From vklang at openjdk.org  Fri Apr 26 11:48:57 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 26 Apr 2024 11:48:57 GMT
Subject: RFR: 8278255: add more warning text in ReentrantLock and
 ReentrantReadWriteLock
Message-ID: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>

This is an attempt to be more clear about recommendations on Lock usage.

-------------

Commit messages:
 - Adding more clarification to proper usage of locks

Changes: https://git.openjdk.org/jdk/pull/18974/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18974&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278255
  Stats: 9 lines in 3 files changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18974/head:pull/18974

PR: https://git.openjdk.org/jdk/pull/18974

From vklang at openjdk.org  Fri Apr 26 11:48:57 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 26 Apr 2024 11:48:57 GMT
Subject: RFR: 8278255: add more warning text in ReentrantLock and
 ReentrantReadWriteLock
In-Reply-To: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
Message-ID: <nZWvcFwBun63fhJHIcmTLK572hz5e1hrZwwCZ-WdSqE=.2485ab5f-860d-4cec-b7a7-0819bbab38c2@github.com>

On Fri, 26 Apr 2024 11:43:06 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is an attempt to be more clear about recommendations on Lock usage.

@stuart-marks Would this be better? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2079225009

From redestad at openjdk.org  Fri Apr 26 11:51:52 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 11:51:52 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v2]
In-Reply-To: <JWYdGeUq2SxXhGB087WbEo-_o3U5IHOkHMTdCDdcfog=.4a1b3dc2-26bd-48a7-b65b-55689981b981@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <5YIerTL-tD8IhFMDCHr6CzPo40EOvoHv65ziF-dK2gQ=.5067dc3f-e6f0-4a24-b962-59f45bdeba2c@github.com>
 <JWYdGeUq2SxXhGB087WbEo-_o3U5IHOkHMTdCDdcfog=.4a1b3dc2-26bd-48a7-b65b-55689981b981@github.com>
Message-ID: <7T4DF0e9ynQajCvbXT0aeToYGsRVrnj72ZAF3_GJBss=.b83ade15-ce62-40d1-ba0c-1a0cc530b383@github.com>

On Fri, 26 Apr 2024 11:27:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Looks like your `MethodTypeDescFactories` benchmark is missing form the PR?
>

Pre-existing.

> Does removing the explicit null checks make that much difference for performance? They are kind of nice for clarity.
> 

It helps startup at least. The redundant array depth check mattered a bit for peak performance, but not much. I don't have a strong opinion really, just find them a bit superfluous when there's a dereference on the next line.

> Also, looks like the copyright year still needs to be updated on some of the files.

Fixed, along with using `EMPTY_CLASSDESC` in the `toArray` call.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18971#issuecomment-2079232756

From redestad at openjdk.org  Fri Apr 26 11:51:51 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 11:51:51 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
Message-ID: <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>

> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
> 
> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
> 
> 
> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36,010 ?   3,882  ns/op   0,97x (p = 0,1...

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Copyrights and other comments from @JornVernee

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18971/files
  - new: https://git.openjdk.org/jdk/pull/18971/files/257dc547..6a16a577

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18971&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18971&range=01-02

  Stats: 8 lines in 5 files changed: 1 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18971/head:pull/18971

PR: https://git.openjdk.org/jdk/pull/18971

From duke at openjdk.org  Fri Apr 26 11:53:35 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 26 Apr 2024 11:53:35 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes [v2]
In-Reply-To: <dB7knUFZ3kJZ2NOc524OqlrO0_6rcnkKTzf5EgIU6mM=.8d4f3c0d-f4cb-43d8-8b49-c9ffc8015829@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
 <dB7knUFZ3kJZ2NOc524OqlrO0_6rcnkKTzf5EgIU6mM=.8d4f3c0d-f4cb-43d8-8b49-c9ffc8015829@github.com>
Message-ID: <CkXYNGBQ1YaQGlB3zgLH240PSgv1qHAa1spf7RkwXQw=.c5aa5969-4c37-49ed-a839-85a99a7cc731@github.com>

On Fri, 26 Apr 2024 07:43:01 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API dives into the nested constant pool entries without type restrictions, while parsing a class file. Validation of the entry is performed post-parsing. Specifically corrupted constant pool entry may cause infinite loop during parsing and throws SOE.
>> This patch resolves the issue by providing specific implementations for the nested CP entries parsing, instead of sharing the common (post-checking) code.
>> Added test simulates the situation on inner-looped method reference entry.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implemented proposed simpler solution with lower and upper bound tags

Maybe?also?add a?`readEntry`?overload which?takes a?single expected `TAG_*`?value for?use by?`readModuleEntry`, `readPackageEntry`, `readClassEntry`, `readNameAndTypeEntry`, and?`readMethodHandleEntry`:

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 437:

> 435:     }
> 436: 
> 437:     private <T extends PoolEntry> T readEntry(int pos, Class<T> cls, int lowerBoundTag, int upperBoundTag) {

Suggestion:

    private <T extends PoolEntry> T readEntry(int pos, Class<T> cls, int expectedTag) {
        return readEntry(pos, cls, expectedTag, expectedTag);
    }

    private <T extends PoolEntry> T readEntry(int pos, Class<T> cls, int lowerBoundTag, int upperBoundTag) {

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 469:

> 467:     @Override
> 468:     public ModuleEntry readModuleEntry(int pos) {
> 469:         return readEntry(pos, ModuleEntry.class, TAG_MODULE, TAG_MODULE);

Suggestion:

        return readEntry(pos, ModuleEntry.class, TAG_MODULE);

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 474:

> 472:     @Override
> 473:     public PackageEntry readPackageEntry(int pos) {
> 474:         return readEntry(pos, PackageEntry.class, TAG_PACKAGE, TAG_PACKAGE);

Suggestion:

        return readEntry(pos, PackageEntry.class, TAG_PACKAGE);

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 479:

> 477:     @Override
> 478:     public ClassEntry readClassEntry(int pos) {
> 479:         return readEntry(pos, ClassEntry.class, TAG_CLASS, TAG_CLASS);

Suggestion:

        return readEntry(pos, ClassEntry.class, TAG_CLASS);

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 484:

> 482:     @Override
> 483:     public NameAndTypeEntry readNameAndTypeEntry(int pos) {
> 484:         return readEntry(pos, NameAndTypeEntry.class, TAG_NAMEANDTYPE, TAG_NAMEANDTYPE);

Suggestion:

        return readEntry(pos, NameAndTypeEntry.class, TAG_NAMEANDTYPE);

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 489:

> 487:     @Override
> 488:     public MethodHandleEntry readMethodHandleEntry(int pos) {
> 489:         return readEntry(pos, MethodHandleEntry.class, TAG_METHODHANDLE, TAG_METHODHANDLE);

Suggestion:

        return readEntry(pos, MethodHandleEntry.class, TAG_METHODHANDLE);

-------------

PR Review: https://git.openjdk.org/jdk/pull/18907#pullrequestreview-2024849063
PR Review Comment: https://git.openjdk.org/jdk/pull/18907#discussion_r1580909095
PR Review Comment: https://git.openjdk.org/jdk/pull/18907#discussion_r1580909748
PR Review Comment: https://git.openjdk.org/jdk/pull/18907#discussion_r1580909800
PR Review Comment: https://git.openjdk.org/jdk/pull/18907#discussion_r1580909914
PR Review Comment: https://git.openjdk.org/jdk/pull/18907#discussion_r1580910028
PR Review Comment: https://git.openjdk.org/jdk/pull/18907#discussion_r1580910141

From dl at openjdk.org  Fri Apr 26 11:57:31 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 26 Apr 2024 11:57:31 GMT
Subject: RFR: 8296543: Update exception documentation for
 ExecutorService.invokeAll overriders as required
In-Reply-To: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
References: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
Message-ID: <ShFGpjdQEUjUVIMvBJswNV8PB4vakonu7rkvqivnOBA=.6aeb7d75-998c-4445-8ad0-ae0b85ceaf35@github.com>

On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR adds the exception documentation as per the ExecutorService API contract. I also took the liberty of adding @Override-annotations to be clear about intent.

This seems OK, but could someone read the generated javadoc to make sure there are no surprises? Sometimes inheritDocs don't come out as expected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18966#issuecomment-2079239771

From jvernee at openjdk.org  Fri Apr 26 12:04:31 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 26 Apr 2024 12:04:31 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
Message-ID: <hOyP0qmMXNcSGbCunr1PWg2yTBDUAXYyjj0ao-pSDHk=.f96a6577-b479-4c97-9dec-04d0c3c73621@github.com>

On Fri, 26 Apr 2024 11:51:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
>> 
>> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
>> 
>> 
>> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
>> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
>> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights and other comments from @JornVernee

LGTM

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18971#pullrequestreview-2024881469

From jvernee at openjdk.org  Fri Apr 26 12:04:32 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 26 Apr 2024 12:04:32 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v2]
In-Reply-To: <7T4DF0e9ynQajCvbXT0aeToYGsRVrnj72ZAF3_GJBss=.b83ade15-ce62-40d1-ba0c-1a0cc530b383@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <5YIerTL-tD8IhFMDCHr6CzPo40EOvoHv65ziF-dK2gQ=.5067dc3f-e6f0-4a24-b962-59f45bdeba2c@github.com>
 <JWYdGeUq2SxXhGB087WbEo-_o3U5IHOkHMTdCDdcfog=.4a1b3dc2-26bd-48a7-b65b-55689981b981@github.com>
 <7T4DF0e9ynQajCvbXT0aeToYGsRVrnj72ZAF3_GJBss=.b83ade15-ce62-40d1-ba0c-1a0cc530b383@github.com>
Message-ID: <IuNtDKiuQrIx6nH8mXDrHOAR5EaU0Dkq8_VzyCqB4hI=.a804c08e-5085-4da2-ad9b-1de1bf77bdf2@github.com>

On Fri, 26 Apr 2024 11:49:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > Does removing the explicit null checks make that much difference for performance? They are kind of nice for clarity.
> 
> It helps startup at least. The redundant array depth check mattered a bit for peak performance, but not much. I don't have a strong opinion really, just find them a bit superfluous when there's a dereference on the next line.

Sure, I'm mostly talking about cases where the value is passed to another method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18971#issuecomment-2079249354

From prappo at openjdk.org  Fri Apr 26 12:09:32 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 26 Apr 2024 12:09:32 GMT
Subject: RFR: 8296543: Update exception documentation for
 ExecutorService.invokeAll overriders as required
In-Reply-To: <ShFGpjdQEUjUVIMvBJswNV8PB4vakonu7rkvqivnOBA=.6aeb7d75-998c-4445-8ad0-ae0b85ceaf35@github.com>
References: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
 <ShFGpjdQEUjUVIMvBJswNV8PB4vakonu7rkvqivnOBA=.6aeb7d75-998c-4445-8ad0-ae0b85ceaf35@github.com>
Message-ID: <RDl7_5fzSRbaU6r6OQWwx43MvEKlGHIvpZ5RGOgPtd0=.8b113af8-d979-40c7-9fe9-019553738e2d@github.com>

On Fri, 26 Apr 2024 11:54:15 GMT, Doug Lea <dl at openjdk.org> wrote:

> This seems OK, but could someone read the generated javadoc to make sure there are no surprises? Sometimes inheritDocs don't come out as expected.

I'll make sure it's as expected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18966#issuecomment-2079258586

From redestad at openjdk.org  Fri Apr 26 12:39:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 12:39:40 GMT
Subject: Integrated: 8327247: C2 uses up to 2GB of RAM to compile complex
 string concat in extreme cases
In-Reply-To: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
References: <iZRztzHswBizuD1N7vr8WxRGFxmOZCWvCttE4nwdDiU=.6ea0517e-e249-4770-9622-abd9aa807019@github.com>
Message-ID: <kV7kpebX-v776z9AkHbJ4VFpptVu2OpBNm0ZfVgu64c=.b06382fa-b713-4218-99ba-3183d70c921b@github.com>

On Thu, 25 Apr 2024 14:15:56 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Splitting out the ASM-based version from #18690 to push that first under the JBS (to help backporting). Keeping #18690 open to rebase and follow-up on this as a subtask. See discussion in that #18690 for more details, discussion and motivation for this.

This pull request has now been integrated.

Changeset: 5e2ced4b
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e2ced4b9e1c9953e459dc152076520e5ef9d76c
Stats:     300 lines in 2 files changed: 292 ins; 3 del; 5 mod

8327247: C2 uses up to 2GB of RAM to compile complex string concat in extreme cases

Reviewed-by: mchung, shade

-------------

PR: https://git.openjdk.org/jdk/pull/18953

From prappo at openjdk.org  Fri Apr 26 12:42:32 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 26 Apr 2024 12:42:32 GMT
Subject: RFR: 8296543: Update exception documentation for
 ExecutorService.invokeAll overriders as required
In-Reply-To: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
References: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
Message-ID: <FScMfOYQaIacTfSIlaVO_vdiKiQXLKlZEODjO-6l3iU=.f935c9d3-8bcb-46c4-ba22-1fd75381cce9@github.com>

On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR adds the exception documentation as per the ExecutorService API contract. I also took the liberty of adding @Override-annotations to be clear about intent.

Both markup and generated documentation look good.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18966#pullrequestreview-2024947956

From liach at openjdk.org  Fri Apr 26 12:46:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 12:46:30 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
Message-ID: <Qj4Rfw6DhHe3_XdBGrGI2ZiI0xj7sG2ZzBQyp01WNuk=.8101132e-0b27-40cc-a1ca-f4095ee10cd2@github.com>

On Fri, 26 Apr 2024 11:51:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
>> 
>> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
>> 
>> 
>> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
>> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
>> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights and other comments from @JornVernee

Primitive class desc sharing should be really helpful, especially considering that they are represented as condy and their `equals` is thus quite inefficient.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18971#issuecomment-2079315179

From liach at openjdk.org  Fri Apr 26 12:56:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 12:56:35 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
Message-ID: <EZHoMCTk9e70IS1jjEkBEn7FtGIPdG4JqnxtAr1rQPA=.a0ad4207-09e2-4940-a4c0-e27f6bd8205b@github.com>

On Fri, 26 Apr 2024 11:51:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
>> 
>> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
>> 
>> 
>> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
>> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
>> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights and other comments from @JornVernee

Changes requested by liach (Author).

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 163:

> 161:         // implicit null-check
> 162:         return (descriptor.length() == 1)
> 163:                ? Wrapper.forPrimitiveType(descriptor.charAt(0)).primitiveClassDescriptor()

Wait a second, it seems `ClassDesc.ofDescriptor("L")` will return `ConstantDescs.CD_Object` now. Might be good to have a test to verify this doesn't happen.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18971#pullrequestreview-2024985611
PR Review Comment: https://git.openjdk.org/jdk/pull/18971#discussion_r1580996421

From liach at openjdk.org  Fri Apr 26 13:01:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 13:01:34 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
Message-ID: <yQXFct9TcQsu8paEgqS42xAlaafl-qrJ0HhWcieB4z8=.212181fa-0dff-444b-8e73-a2b1a8f18bfc@github.com>

On Fri, 26 Apr 2024 11:51:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
>> 
>> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
>> 
>> 
>> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
>> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
>> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights and other comments from @JornVernee

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18971#pullrequestreview-2024995460

From dl at openjdk.org  Fri Apr 26 13:33:15 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 26 Apr 2024 13:33:15 GMT
Subject: RFR: 8278255: add more warning text in ReentrantLock and
 ReentrantReadWriteLock
In-Reply-To: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
Message-ID: <ojvTKrQ7dwMd3xoLYEZ71Q_GXKPMerhDLA0TEQmqKNQ=.6e0f9ac2-9581-4670-a5d9-6be1f5689210@github.com>

On Fri, 26 Apr 2024 11:43:06 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is an attempt to be more clear about recommendations on Lock usage.

Thanks for finally processing this after we let this good suggestion sit for too long!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2079380493

From asotona at openjdk.org  Fri Apr 26 13:34:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 26 Apr 2024 13:34:08 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes [v3]
In-Reply-To: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
Message-ID: <5QHSQId1FON-8xKWxr1ixK0ydOXPDsKvqFeCFaTG0QE=.91a7370f-d61d-4256-9f2f-f4d0c52b0b62@github.com>

> ClassFile API dives into the nested constant pool entries without type restrictions, while parsing a class file. Validation of the entry is performed post-parsing. Specifically corrupted constant pool entry may cause infinite loop during parsing and throws SOE.
> This patch resolves the issue by providing specific implementations for the nested CP entries parsing, instead of sharing the common (post-checking) code.
> Added test simulates the situation on inner-looped method reference entry.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18907/files
  - new: https://git.openjdk.org/jdk/pull/18907/files/e706346b..4a28694f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18907&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18907&range=01-02

  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18907/head:pull/18907

PR: https://git.openjdk.org/jdk/pull/18907

From redestad at openjdk.org  Fri Apr 26 13:34:45 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 13:34:45 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <d_neS2dLV7xMYFc19aTRwAUIHFIoi6vRkTsfI4c4mwQ=.0dfc941d-6ee9-4312-adb2-28eac93542f8@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
 <EZHoMCTk9e70IS1jjEkBEn7FtGIPdG4JqnxtAr1rQPA=.a0ad4207-09e2-4940-a4c0-e27f6bd8205b@github.com>
 <d_neS2dLV7xMYFc19aTRwAUIHFIoi6vRkTsfI4c4mwQ=.0dfc941d-6ee9-4312-adb2-28eac93542f8@github.com>
Message-ID: <8StMTMsvxw9lvKXrQaaW-uTgFFmsc14tmMVP-J3Ti6s=.8917a0e6-151f-4db1-89b9-025808f3476e@github.com>

On Fri, 26 Apr 2024 12:58:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 163:
>> 
>>> 161:         // implicit null-check
>>> 162:         return (descriptor.length() == 1)
>>> 163:                ? Wrapper.forPrimitiveType(descriptor.charAt(0)).primitiveClassDescriptor()
>> 
>> Wait a second, it seems `ClassDesc.ofDescriptor("L")` will return `ConstantDescs.CD_Object` now. Might be good to have a test to verify this doesn't happen.
>
> Ignore me, `Wrapper.ofPrimitiveType` doesn't return Object.

No, `Wrapper.forPrimitiveType` throws IAE if passed `L`, same exception as today with a slightly different message. 

And yes, if this does not happen there's a test that fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18971#discussion_r1581042861

From alanb at openjdk.org  Fri Apr 26 13:34:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Apr 2024 13:34:41 GMT
Subject: RFR: 8296543: Update exception documentation for
 ExecutorService.invokeAll overriders as required
In-Reply-To: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
References: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
Message-ID: <MeSLbiVRHBf17D-tibZJEmTXUfVshYuOsuxDZcqYTWA=.7e92c651-6804-48e2-ad1b-dd00d68bca06@github.com>

On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR adds the exception documentation as per the ExecutorService API contract. I also took the liberty of adding @Override-annotations to be clear about intent.

Marked as reviewed by alanb (Reviewer).

I think this is okay. The throws description for the checked exceptions is already inherited, it's the unchecked that don't appear in the subclass.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18966#pullrequestreview-2025063608
PR Comment: https://git.openjdk.org/jdk/pull/18966#issuecomment-2079403775

From redestad at openjdk.org  Fri Apr 26 13:40:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 13:40:24 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <Qj4Rfw6DhHe3_XdBGrGI2ZiI0xj7sG2ZzBQyp01WNuk=.8101132e-0b27-40cc-a1ca-f4095ee10cd2@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
 <Qj4Rfw6DhHe3_XdBGrGI2ZiI0xj7sG2ZzBQyp01WNuk=.8101132e-0b27-40cc-a1ca-f4095ee10cd2@github.com>
Message-ID: <Fc46EzwtpYzkDjmiXp6loiL7tf3yTw5o1gmSdbpEYf0=.00753a12-e444-4500-9685-17131306c775@github.com>

On Fri, 26 Apr 2024 12:43:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Primitive class desc sharing should be really helpful, especially considering that they are represented as condy and their `equals` is thus quite inefficient.

Ok. We could consider overriding `equals` in `PrimitiveClassDescImpl` if this is an issue (in a follow-up). With guarantees that they are unique we could even have such a method be implemented as a reference equality check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18971#issuecomment-2079415480

From prappo at openjdk.org  Fri Apr 26 13:46:17 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 26 Apr 2024 13:46:17 GMT
Subject: RFR: 8278255: add more warning text in ReentrantLock and
 ReentrantReadWriteLock
In-Reply-To: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
Message-ID: <o3gsD7z0PscP7HJXJ0ZdCvbpSGSCXjQZZIcOe-DxXLU=.ee8f52c3-e05d-405a-bfad-73f59e0cf51b@github.com>

On Fri, 26 Apr 2024 11:43:06 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is an attempt to be more clear about recommendations on Lock usage.

src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java line 162:

> 160:  *       }
> 161:  *     }
> 162:  *     // Make sure that code which could throw is executed inside the try block

Nit:
Suggestion:

 *     // Make sure that code that could throw is executed inside the try block

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18974#discussion_r1581059299

From alanb at openjdk.org  Fri Apr 26 13:48:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Apr 2024 13:48:02 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v3]
In-Reply-To: <PIaR6T0MKovlJXXxEzbFCoeP_YTpk2r21a0iT9ZCh4s=.779da8bf-abcd-42d1-bf5c-8f410cd0e26d@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <PIaR6T0MKovlJXXxEzbFCoeP_YTpk2r21a0iT9ZCh4s=.779da8bf-abcd-42d1-bf5c-8f410cd0e26d@github.com>
Message-ID: <bRklCE0QPxh8YRlNu2h2YtGUUnEz31OKh9I1YTtdPto=.25f1a3b3-8a1f-4467-86dc-8145fd8fcf17@github.com>

On Fri, 26 Apr 2024 09:41:21 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Terminology changes.

One thing that bothers me is that the use of ServiceLoader is specified as "Implementation Requirements". I wonder if we can check the original CSR and discussions on the PR to see if we can dig up more of the original intent. How useful is it to deploy with additional RandomGeneratorFactory implementations on the class path or module path? If a standard provider interface then I would have expected to see more in the javadoc and to see the `@uses` tags in the module declaration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2079429549

From redestad at openjdk.org  Fri Apr 26 14:10:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 14:10:09 GMT
Subject: Integrated: 8331187: Optimize MethodTypeDesc and
 ClassDesc.ofDescriptor for primitive types
In-Reply-To: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
Message-ID: <zMV8zBUZEtwoB1cG86DC8sAO6rp_LGqJklRcNLGW9T8=.871c78dc-8c54-4a4f-853d-a67c2be8df30@github.com>

On Fri, 26 Apr 2024 10:27:16 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
> 
> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
> 
> 
> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36,010 ?   3,882  ns/op   0,97x (p = 0,1...

This pull request has now been integrated.

Changeset: 8bbd7251
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8bbd7251a596c6fad1a6675c077deb9fd7c8ff95
Stats:     140 lines in 6 files changed: 87 ins; 19 del; 34 mod

8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor for primitive types

Reviewed-by: jvernee, liach

-------------

PR: https://git.openjdk.org/jdk/pull/18971

From duke at openjdk.org  Fri Apr 26 14:16:01 2024
From: duke at openjdk.org (Korov)
Date: Fri, 26 Apr 2024 14:16:01 GMT
Subject: Integrated: 8330624: Inconsistent use of semicolon in the code snippet
 of java.io.Serializable javadoc
In-Reply-To: <I2DZ3fh2RKeDrHs8Uyr4ky6YDHwCdo6t-UvOYAtkiK8=.1f90a822-8aed-4556-bc9a-ad70acbf12c0@github.com>
References: <I2DZ3fh2RKeDrHs8Uyr4ky6YDHwCdo6t-UvOYAtkiK8=.1f90a822-8aed-4556-bc9a-ad70acbf12c0@github.com>
Message-ID: <fyWEZPpgO-dhK1cwHs4kU999k91IsII3fe_98xhXxvA=.d8553c06-a628-4d8f-b9c5-fa1268441d02@github.com>

On Sat, 20 Apr 2024 11:49:30 GMT, Korov <duke at openjdk.org> wrote:

> Fix the description of java.io.Serializable.

This pull request has now been integrated.

Changeset: 0bf516f7
Author:    Korov <korov9 at 163.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bf516f7ba8425134ca42d856648ab19f5c69a86
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8330624: Inconsistent use of semicolon in the code snippet of java.io.Serializable javadoc

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/18874

From mli at openjdk.org  Fri Apr 26 14:20:04 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 26 Apr 2024 14:20:04 GMT
Subject: RFR: 8331196: vector api: Remove unnecessary index check in
 Byte/ShortVector.fromArray/fromArray0Template
Message-ID: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>

Hi,
Can you help to review this simple patch?
Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not necessary, could be removed.
Thanks

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/18977/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18977&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331196
  Stats: 36 lines in 3 files changed: 0 ins; 12 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/18977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18977/head:pull/18977

PR: https://git.openjdk.org/jdk/pull/18977

From mli at openjdk.org  Fri Apr 26 14:32:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 26 Apr 2024 14:32:06 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v12]
In-Reply-To: <OkxoClDmm5mt0sjlXiJga9em7uXiUfeZi836lRzVtOI=.dfc347ea-1e93-45a6-9fba-bd16fa6d6328@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
 <OkxoClDmm5mt0sjlXiJga9em7uXiUfeZi836lRzVtOI=.dfc347ea-1e93-45a6-9fba-bd16fa6d6328@github.com>
Message-ID: <RkQyvmydPwhUBTpsWZefSFGXUqyDu2pBaz6Mk9dEC9A=.35a69ba9-d9d0-4a82-8783-3ef7fb72ebf4@github.com>

On Tue, 23 Apr 2024 09:46:08 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> HI,
>> Can you have a look at this patch adding some tests for Math.round instrinsics?
>> Thanks!
>> 
>> ### FYI:
>> During the development of RoundVF/RoundF, we faced the issues which were only spotted by running test exhaustively against 32/64 bits range of int/long.
>> It's helpful to add these exhaustive tests in jdk for future possible usage, rather than build it everytime when needed.
>> Of course, we need to put it in `manual` mode, so it's not run when `-automatic` jtreg option is specified which I guess is the mode CI used, please correct me if I'm assume incorrectly.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add vectorized and scalar version Float tests checking full 32 bits range

Hey, Is someone available to have a look at this pure test addition? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17753#issuecomment-2079508769

From liach at openjdk.org  Fri Apr 26 14:50:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 14:50:02 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
Message-ID: <XW23eI3Fy-_cTR06TxNUr2p0Yh4wsCZQPZT8GAcJ730=.2333fb61-d6b0-4b36-883b-5823e96f07f6@github.com>

On Fri, 26 Apr 2024 11:51:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
>> 
>> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
>> 
>> 
>> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
>> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
>> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights and other comments from @JornVernee

For the `equals` remark, it's that DynamicConstantDesc's equals is final so subclasses cannot provide a faster implementation. But that's another topic.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18971#issuecomment-2079541972

From redestad at openjdk.org  Fri Apr 26 14:57:00 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 14:57:00 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <XW23eI3Fy-_cTR06TxNUr2p0Yh4wsCZQPZT8GAcJ730=.2333fb61-d6b0-4b36-883b-5823e96f07f6@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
 <XW23eI3Fy-_cTR06TxNUr2p0Yh4wsCZQPZT8GAcJ730=.2333fb61-d6b0-4b36-883b-5823e96f07f6@github.com>
Message-ID: <mLD2DpvxbgojSaqx6VGC0TntYqp85bT7WDjn0CyAnOw=.d29da185-50b6-4a29-9e68-0aac8cec5617@github.com>

On Fri, 26 Apr 2024 14:47:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> For the `equals` remark, it's that DynamicConstantDesc's equals is final so subclasses cannot provide a faster implementation. But that's another topic.

Hmm, that is unfortunate, yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18971#issuecomment-2079553992

From redestad at openjdk.org  Fri Apr 26 14:57:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 14:57:07 GMT
Subject: RFR: 8331134: Port SimpleStringBuilderStrategy to use ClassFile
 API [v10]
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <yhrkajl4_8lFBx69sfOyLCI93e1gMxRJsO1SJ4X5DcI=.37117424-bccf-4a96-beec-c118cbc6fa2f@github.com>

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Rebase after integration of #18953
 - Nits, clean up constant, introduce missing constant MethodTypeDesc for toString
 - Make Set.of(STRONG) a constant, fix compilation, minor code improvements
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Minor SimpleStringBuilderStrategy::<clinit> overhead reduction
 - Merge master, resolve conflicts due pr/18688
 - Dump using the hidden class name
 - Pre-size stringbuilders based on constant size and a small argument factor
 - @liach feedback
 - Bump threshold after experiments
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5e2ced4b...f87fa1d7

-------------

Changes: https://git.openjdk.org/jdk/pull/18690/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18690&range=09
  Stats: 253 lines in 2 files changed: 80 ins; 142 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/18690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18690/head:pull/18690

PR: https://git.openjdk.org/jdk/pull/18690

From redestad at openjdk.org  Fri Apr 26 15:02:56 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 15:02:56 GMT
Subject: RFR: 8331134: Port SimpleStringBuilderStrategy to use ClassFile
 API [v9]
In-Reply-To: <YcoWAsUEHq5LWp4JhQPx9-RXQgaq8_PSDHnmKY692Kg=.8e37a153-4dc8-4a85-8f98-b72ccda31803@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <QfuKEnxxCeRzBKjFcTNkFmPcv81YgiXbHIiWsIcmnRo=.d241bab3-ff1b-4ab6-8f01-c759a24f51cd@github.com>
 <YcoWAsUEHq5LWp4JhQPx9-RXQgaq8_PSDHnmKY692Kg=.8e37a153-4dc8-4a85-8f98-b72ccda31803@github.com>
Message-ID: <Z1IOmBaJNoDme5qo7N4d4h0Odt0bbvY5_mkjyvFOQ4M=.625daa6a-f1ab-41a6-863c-e35c3ebef545@github.com>

On Fri, 26 Apr 2024 02:20:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Nits, clean up constant, introduce missing constant MethodTypeDesc for toString
>
> It's a little confusing for JDK-8327247 to have 2 PRs but it's okay.   We can add a note in JDK-8327247 to clarify.  I assume you plan to use PR to convert to use ClassFile API after you pull from JDK-8327247 once integrated?

Rebased. @mlchung: there should be no changes compared to the previously reviewed version, but a quick re-review is probably in order.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2079565171

From roger.riggs at oracle.com  Fri Apr 26 15:07:45 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 26 Apr 2024 11:07:45 -0400
Subject: In support of Instant.minus(Instant)
In-Reply-To: <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
Message-ID: <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>

A constructive API enhancement.
Created JDK-8331202 <https://bugs.openjdk.org/browse/JDK-8331202> 
Support for duration between Instants

Regards, Roger

On 4/25/24 4:53 PM, Stephen Colebourne wrote:
> java.time.* already has the `until(ChronoLocalDate)` method on
> LocalDate. It would be reasonable to add a similar method to various
> other classes. This potentially gives you
>
>   Duration dur = start.until(end)
>
> I'm wary of adding the opposite (given until() is already there). I'm
> particularly wary of using minus() as the verb for the opposite as
> minus() means something different in other parts of the API (minus()
> is used to subtract a TemporalAmounrt, not a Temporal).
>
> Stephen
>
>
> On Thu, 25 Apr 2024 at 19:57, Kurt Alfred Kluever<kak at google.com>  wrote:
>> Hi core-libs-dev,
>>
>> The java.time API already supports subtracting two Instants (end - start) via Duration.between(Temporal, Temporal), but we've found the parameter ordering (which requires a bit of "mental gymnastics") and API location to be a bit unnatural.
>>
>> Parameter Ordering
>>
>> We very often see folks write code like this: Duration elapsed = Duration.ofMillis(end.toEpochMilli() - start.toEpochMilli());
>>
>> This closely matches the mental model of what they're trying to accomplish, but it is longer (and more complex) than it needs to be, it drops sub-millisecond precision, and it requires decomposing the java.time types (which we strongly discourage). If you want to "simplify" the above statement, you must remember to swap the argument order: Duration elapsed = Duration.between(start, end);
>>
>> Many of us find representing (end - start) as between(start, end) to be confusing.
>>
>> API Location
>>
>> We do not believe Duration is the most obvious place to find this method; if you want a way to subtract two Instant values, an instance method on Instant is a more obvious place to look. Pushing what could be an instance method to a static utility method feels unnatural.
>>
>> JDK-8276624 (https://bugs.openjdk.org/browse/JDK-8276624) proposes to add Temporal.minus(Temporal) as a default method (which would effectively accomplish the same thing), but we do not recommend implementing that proposal as specified. A default method on Temporal would require runtime exceptions to be thrown from other Temporal types like LocalDate or Year. It would also allow oddities like instant.minus(year) to compile (but presumably throw at runtime). Conceptually, this API would not make sense for certain types (e.g., LocalDate ? the difference between two LocalDates is a Period, not a Duration).
>>
>> Instead, we recommend adding a new instance method: instant.minus(instant) (which returns a Duration), and possibly also adding localDate.minus(localDate) (which returns a Period). However note that we've seen a lot of confusion using the Period API (but that's a separate discussion).
>>
>> While we generally don't like having 2 public APIs that accomplish the same thing, in this case we feel the discoverability and simplicity of the new API(s) outweighs the cost of an additional public API.
>>
>> Please consider this a +1 from our team to add instant.minus(instant).
>>
>> Regards,
>>
>> -Kurt Alfred Kluever (kak at google.com)
>> (on behalf of Google's Java and Kotlin Ecosystem Team, aka the Guava team)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240426/5813edf9/attachment-0001.htm>

From rgiulietti at openjdk.org  Fri Apr 26 15:24:30 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 26 Apr 2024 15:24:30 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v4]
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <bgzgSyhfSw7ZJPUq36C5_khMuJXfqv_o55OWiu0VGBE=.c882a00c-a3a0-4fcb-994f-ed6a0f044456@github.com>

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Added @uses javadoc tag for j.u.r.RandomGenerator in java.base.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18932/files
  - new: https://git.openjdk.org/jdk/pull/18932/files/fd84a28b..d502b245

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18932/head:pull/18932

PR: https://git.openjdk.org/jdk/pull/18932

From rgiulietti at openjdk.org  Fri Apr 26 15:24:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 26 Apr 2024 15:24:31 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v3]
In-Reply-To: <PIaR6T0MKovlJXXxEzbFCoeP_YTpk2r21a0iT9ZCh4s=.779da8bf-abcd-42d1-bf5c-8f410cd0e26d@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <PIaR6T0MKovlJXXxEzbFCoeP_YTpk2r21a0iT9ZCh4s=.779da8bf-abcd-42d1-bf5c-8f410cd0e26d@github.com>
Message-ID: <lnSo1NTdaI05vKwRf9iwDcGoVUioX8vWd5oP3brISTE=.0353a931-f662-4909-8aa7-15558b05ae95@github.com>

On Fri, 26 Apr 2024 09:41:21 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Terminology changes.

I don't think that there's any intent

> to deploy with additional RandomGeneratorFactory implementations

as this is a final class.

The service provider interface `RandomGenerator` is exposed in the module by means of a `uses` clause. For some reason, however, it wasn't documented by a `@uses` javadoc tag. Added in last commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2079603835

From mchung at openjdk.org  Fri Apr 26 15:56:56 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 15:56:56 GMT
Subject: RFR: 8331134: Port SimpleStringBuilderStrategy to use ClassFile
 API [v10]
In-Reply-To: <yhrkajl4_8lFBx69sfOyLCI93e1gMxRJsO1SJ4X5DcI=.37117424-bccf-4a96-beec-c118cbc6fa2f@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <yhrkajl4_8lFBx69sfOyLCI93e1gMxRJsO1SJ4X5DcI=.37117424-bccf-4a96-beec-c118cbc6fa2f@github.com>
Message-ID: <xdTs43Vi_o0klYbQQ87gsVfwvy2k6G8kIATIcT06ajY=.edff92ee-5eed-4133-8aec-a15ae183e0f0@github.com>

On Fri, 26 Apr 2024 14:57:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Rebase after integration of #18953
>  - Nits, clean up constant, introduce missing constant MethodTypeDesc for toString
>  - Make Set.of(STRONG) a constant, fix compilation, minor code improvements
>  - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Minor SimpleStringBuilderStrategy::<clinit> overhead reduction
>  - Merge master, resolve conflicts due pr/18688
>  - Dump using the hidden class name
>  - Pre-size stringbuilders based on constant size and a small argument factor
>  - @liach feedback
>  - Bump threshold after experiments
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/5e2ced4b...f87fa1d7

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18690#pullrequestreview-2025374446

From jjg at openjdk.org  Fri Apr 26 16:04:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 16:04:09 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/39689a52..48e8b0a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From psandoz at openjdk.org  Fri Apr 26 16:16:53 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 26 Apr 2024 16:16:53 GMT
Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes [v3]
In-Reply-To: <5QHSQId1FON-8xKWxr1ixK0ydOXPDsKvqFeCFaTG0QE=.91a7370f-d61d-4256-9f2f-f4d0c52b0b62@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
 <5QHSQId1FON-8xKWxr1ixK0ydOXPDsKvqFeCFaTG0QE=.91a7370f-d61d-4256-9f2f-f4d0c52b0b62@github.com>
Message-ID: <gdHDys9gOXUM-d6jAyhTC99eGBMVSxgtBRGlcWAboRI=.d7b8b419-9a15-40c1-889b-e78a16148c2f@github.com>

On Fri, 26 Apr 2024 13:34:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API dives into the nested constant pool entries without type restrictions, while parsing a class file. Validation of the entry is performed post-parsing. Specifically corrupted constant pool entry may cause infinite loop during parsing and throws SOE.
>> This patch resolves the issue by providing specific implementations for the nested CP entries parsing, instead of sharing the common (post-checking) code.
>> Added test simulates the situation on inner-looped method reference entry.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Very nice. I think we got lucky this worked out :-)

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18907#pullrequestreview-2025411091

From duke at openjdk.org  Fri Apr 26 17:46:10 2024
From: duke at openjdk.org (Louis Bergelson)
Date: Fri, 26 Apr 2024 17:46:10 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v9]
In-Reply-To: <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
Message-ID: <yovztF-C7k6GrgjVpYKBkZ4XtjdomoKCeU4Kb1eC9Sg=.8b8afcbf-c740-47d6-8763-d1b7381a60e7@github.com>

On Sun, 17 Mar 2024 22:53:55 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
>> 
>> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.
>
> Archie Cobbs 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:
> 
>  - Merge branch 'master' into JDK-7036144
>  - Back-out Javadoc addition; to be added in a separate issue.
>  - Document the handling of concatenated streams.
>  - Merge branch 'master' into JDK-7036144
>  - Merge branch 'master' into JDK-7036144
>  - Merge branch 'master' into JDK-7036144
>  - Address third round of review comments.
>  - Address second round of review comments.
>  - Address review comments.
>  - Fix bug in GZIPInputStream when underlying available() returns short.

Is there any chance of backporting this to java 17 or 21?  What's involved in doing that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2079818795

From jlu at openjdk.org  Fri Apr 26 17:56:08 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Apr 2024 17:56:08 GMT
Subject: RFR: 8331207: Misleading example in DateFormat#parse docs
Message-ID: <PzYWWISxajrykTl0YTjEWeK0ZtpeMlB21RkfCvl_jX0=.628983e0-8e10-4400-8963-9b6e0b50bbac@github.com>

Correct a misleading example in the DateFormat parse documentation. 

Common usage is to use a factory instance. The original example provided assumes a pattern provided by a COMPAT factory instance, and does not work with a CLDR instance. 

The example should be updated to use a pattern provided by a CLDR instance, and also explicitly list this pattern for better clarification.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/18983/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18983&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331207
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18983/head:pull/18983

PR: https://git.openjdk.org/jdk/pull/18983

From bchristi at openjdk.org  Fri Apr 26 17:59:39 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 26 Apr 2024 17:59:39 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v28]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <b9F3NTIjnmwisjT9eVzz_gfD6Nkeu9mRJpAqFX1ZbYU=.64e9c467-56a7-47d0-baa6-e8c29408ea4a@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  new section for finalizer memviz

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/77d53818..5f90b5d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=26-27

  Stats: 22 lines in 1 file changed: 14 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From mchung at openjdk.org  Fri Apr 26 18:01:03 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 18:01:03 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
Message-ID: <vClcU0-l_R6r9xTYr0I0wl4FnmZkF701Fw-0an6xgqc=.b33b666b-930f-44eb-bd69-92c74f22fa08@github.com>

On Fri, 26 Apr 2024 11:51:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive descriptor strings ("I" etc..), and leverages this further by refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for primitives. 
>> 
>> Microbenchmarks results look good with expected speedups and allocation reductions any time a primitive is part of the descriptor string, and a non-significant cost otherwise:
>> 
>> 
>> Name                                                             (descString) Cnt     Base     Error       Test     Error   Unit  Change
>> ClassDescFactories.ofDescriptor                            Ljava/lang/Object;   6   13,941 ?   1,643     14,071 ?   1,333  ns/op   0,99x (p = 0,681 )
>>   :gc.alloc.rate.norm                                                               16,000 ?   0,000     16,000 ?   0,000   B/op   1,00x (p = 0,617 )
>> ClassDescFactories.ofDescriptor                                             V   6    9,212 ?   1,045      1,405 ?   0,049  ns/op   6,55x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> ClassDescFactories.ofDescriptor                                             I   6    9,009 ?   0,035      1,431 ?   0,192  ns/op   6,30x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                               48,000 ?   0,000      0,000 ?   0,000   B/op   0,00x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  182,050 ?   4,333    141,644 ?   2,685  ns/op   1,29x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              360,001 ?   0,000    264,001 ?   0,000   B/op   0,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   17,169 ?   2,008      9,915 ?   0,018  ns/op   1,73x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              120,000 ?   0,000    104,000 ?   0,000   B/op   0,87x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  270,372 ?   3,624    217,050 ?   3,170  ns/op   1,25x (p = 0,000*)
>>   :gc.alloc.rate.norm                                                              520,002 ?   0,000    328,001 ?   0,000   B/op   0,63x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   35,036 ?   0,351     36...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights and other comments from @JornVernee

src/java.base/share/classes/sun/invoke/util/Wrapper.java line 384:

> 382: 
> 383:     /** A nominal descriptor of the primitive type */
> 384:     public ClassDesc primitiveClassDescriptor() { return primitiveTypeDesc; }

As this method is named as `primitiveClassDescriptor`, I expect this should either throw or return null for `OBJECT` and even `VOID` wrapper.   Or should be named "classDescriptor".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18971#discussion_r1581352160

From jlu at openjdk.org  Fri Apr 26 18:15:12 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Apr 2024 18:15:12 GMT
Subject: RFR: 8331207: Misleading example in DateFormat#parse docs [v2]
In-Reply-To: <PzYWWISxajrykTl0YTjEWeK0ZtpeMlB21RkfCvl_jX0=.628983e0-8e10-4400-8963-9b6e0b50bbac@github.com>
References: <PzYWWISxajrykTl0YTjEWeK0ZtpeMlB21RkfCvl_jX0=.628983e0-8e10-4400-8963-9b6e0b50bbac@github.com>
Message-ID: <_8nDYe3AzKsukxSrsOay8BgseHB9gtdz4B9Jpd_58hI=.984e9fe6-250a-4af3-a355-26a257999517@github.com>

> Correct a misleading example in the DateFormat parse documentation. 
> 
> Common usage is to use a factory instance. The original example provided assumes a pattern provided by a COMPAT factory instance. The pattern itself should be explicitly provided. This is chosen over using a CLDR pattern, as it uses a NBSP.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  use COMPAT example, CLDR NBSP is problematic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18983/files
  - new: https://git.openjdk.org/jdk/pull/18983/files/e5e93258..48978166

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18983&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18983&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18983/head:pull/18983

PR: https://git.openjdk.org/jdk/pull/18983

From cushon at openjdk.org  Fri Apr 26 18:22:54 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 26 Apr 2024 18:22:54 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <DVRBMAkRlg8KBtAmByPbWtsCv_a7zpE5KpcSn0Ig_Nk=.6af69f4b-5705-40a3-8a70-5d69d4b7dccc@github.com>

On Wed, 27 Mar 2024 17:36:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Please keep this open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2079906047

From mchung at openjdk.org  Fri Apr 26 18:23:52 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 18:23:52 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v4]
In-Reply-To: <tz_5xaSN3AugzCJryL9yXlrmuo31I8BbVUYJn7wsN8k=.4a89290d-9c44-4562-a7fd-74452260279b@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <tz_5xaSN3AugzCJryL9yXlrmuo31I8BbVUYJn7wsN8k=.4a89290d-9c44-4562-a7fd-74452260279b@github.com>
Message-ID: <max2DGRcF_TMsg9-GmfPkhKWSIwD9LBS2pxbySex8_w=.083c9ca9-6b1c-445a-a747-8bb7ce748b13@github.com>

On Fri, 26 Apr 2024 08:07:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use returnType field directly

I am glad that this only focuses on the descriptor string as `MethodTypeDesc::displayDescriptor` is typically used for debugging and exception message and not performance-sensitive.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18945#pullrequestreview-2025627526

From redestad at openjdk.org  Fri Apr 26 18:45:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 18:45:01 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <vClcU0-l_R6r9xTYr0I0wl4FnmZkF701Fw-0an6xgqc=.b33b666b-930f-44eb-bd69-92c74f22fa08@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
 <vClcU0-l_R6r9xTYr0I0wl4FnmZkF701Fw-0an6xgqc=.b33b666b-930f-44eb-bd69-92c74f22fa08@github.com>
Message-ID: <PDpAtIkoil5lTnCAu5h_jvUy79WmrJaQ9_M5JANk7D4=.47d60bc0-4813-4c1c-96ce-123f1112f55c@github.com>

On Fri, 26 Apr 2024 17:57:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyrights and other comments from @JornVernee
>
> src/java.base/share/classes/sun/invoke/util/Wrapper.java line 384:
> 
>> 382: 
>> 383:     /** A nominal descriptor of the primitive type */
>> 384:     public ClassDesc primitiveClassDescriptor() { return primitiveTypeDesc; }
> 
> As this method is named as `primitiveClassDescriptor`, I expect this should either throw or return null for `OBJECT` and even `VOID` wrapper.   Or should be named "classDescriptor".

While I agree it may seem non-sensical to define `CD_Object` for `Object`, there's precedent in that `Wrapper.primitiveType` is `Object.class` - so for consistency I wired it up the same way. For the usage patterns introduced with this patch we'll never call `primitiveClassDescriptor()` on `Wrapper.OBJECT`, though - and `Wrapper.forPrimitiveType` will throw an `IAE` if you try - so we can always revisit this. 
 
`void.class` is the primitive type for `Void.class`, allowed as a return type and recognized by `Wrapper.forPrimitiveType`. There are checks in for example `ConstantUtils.parseMethodDescriptor` which disallows `void.class` anywhere but as a return type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18971#discussion_r1581404597

From liach at openjdk.org  Fri Apr 26 19:33:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 19:33:50 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v4]
In-Reply-To: <tz_5xaSN3AugzCJryL9yXlrmuo31I8BbVUYJn7wsN8k=.4a89290d-9c44-4562-a7fd-74452260279b@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <tz_5xaSN3AugzCJryL9yXlrmuo31I8BbVUYJn7wsN8k=.4a89290d-9c44-4562-a7fd-74452260279b@github.com>
Message-ID: <wNhvcuDmkqJD4WnvRz1HZbPd3X4rKFn872r8IvYyr2Q=.217f5110-d934-4e01-873b-22e04a6ebd92@github.com>

On Fri, 26 Apr 2024 08:07:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use returnType field directly

Marked as reviewed by liach (Author).

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18945#pullrequestreview-2025741971
PR Review: https://git.openjdk.org/jdk/pull/18945#pullrequestreview-2025743039

From prr at openjdk.org  Fri Apr 26 19:34:00 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 19:34:00 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
Message-ID: <SD0S716mdRSViTfaViQgFYEkmR7WmBalQQe3_FI7VQc=.b83407a8-0c84-4ed9-8b56-adf6db1a2e0c@github.com>

On Fri, 26 Apr 2024 16:04:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2025744069

From redestad at openjdk.org  Fri Apr 26 19:43:48 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 19:43:48 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v4]
In-Reply-To: <max2DGRcF_TMsg9-GmfPkhKWSIwD9LBS2pxbySex8_w=.083c9ca9-6b1c-445a-a747-8bb7ce748b13@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <tz_5xaSN3AugzCJryL9yXlrmuo31I8BbVUYJn7wsN8k=.4a89290d-9c44-4562-a7fd-74452260279b@github.com>
 <max2DGRcF_TMsg9-GmfPkhKWSIwD9LBS2pxbySex8_w=.083c9ca9-6b1c-445a-a747-8bb7ce748b13@github.com>
Message-ID: <nOpQ8G_vXuMH_vQnDKAPckz9t2uVSw0WoQqL0Cj7_9Q=.7d3a73f6-379f-42b9-847d-8aee355c2b01@github.com>

On Fri, 26 Apr 2024 18:21:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I am glad that this only focuses on the descriptor string as `MethodTypeDesc::displayDescriptor` is typically used for debugging and exception message and not performance-sensitive.

Yes, which is why I'd really like to desugar it: this is the method where I tripped on a bootstrap circularity when print-debugging an issue in the lambda code generator. It's no fun at all hitting bootstrapping issues when calling innocuous methods in `java.lang.*`

Obviously the performance of it is not important - I was just stringing it along for consistency.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18945#issuecomment-2080016093

From jjg at openjdk.org  Fri Apr 26 19:49:56 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 19:49:56 GMT
Subject: Integrated: 8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <jz5iSs8rS6B9ZP2l3HbT7UR9gdQiXvxyQFGqikRLN7U=.584799e9-55c0-4a22-b62f-e30406cfe8ea@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

This pull request has now been integrated.

Changeset: a920af23
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a920af233a11592af113f456f7608cb59dd1617e
Stats:     482 lines in 58 files changed: 385 ins; 3 del; 94 mod

8303689: javac -Xlint could/should report on "dangling" doc comments

Reviewed-by: vromero, ihse, prr

-------------

PR: https://git.openjdk.org/jdk/pull/18527

From naoto at openjdk.org  Fri Apr 26 19:56:47 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Apr 2024 19:56:47 GMT
Subject: RFR: 8331207: Misleading example in DateFormat#parse docs [v2]
In-Reply-To: <_8nDYe3AzKsukxSrsOay8BgseHB9gtdz4B9Jpd_58hI=.984e9fe6-250a-4af3-a355-26a257999517@github.com>
References: <PzYWWISxajrykTl0YTjEWeK0ZtpeMlB21RkfCvl_jX0=.628983e0-8e10-4400-8963-9b6e0b50bbac@github.com>
 <_8nDYe3AzKsukxSrsOay8BgseHB9gtdz4B9Jpd_58hI=.984e9fe6-250a-4af3-a355-26a257999517@github.com>
Message-ID: <yeYKmXNSVerUYcp-OWbpX_O8ZdCGaJN1hYTnXeK7qlM=.7e1d17a1-6886-4968-b97e-b4db5b7c5a9f@github.com>

On Fri, 26 Apr 2024 18:15:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Correct a misleading example in the DateFormat parse documentation. 
>> 
>> Common usage is to use a factory instance. The original example provided assumes a pattern provided by a COMPAT factory instance.
>> 
>> The pattern itself should be explicitly provided, since users may be using CLDR factory instances.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use COMPAT example, CLDR NBSP is problematic

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18983#pullrequestreview-2025774061

From acobbs at openjdk.org  Fri Apr 26 20:35:55 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 Apr 2024 20:35:55 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v9]
In-Reply-To: <yovztF-C7k6GrgjVpYKBkZ4XtjdomoKCeU4Kb1eC9Sg=.8b8afcbf-c740-47d6-8763-d1b7381a60e7@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
 <yovztF-C7k6GrgjVpYKBkZ4XtjdomoKCeU4Kb1eC9Sg=.8b8afcbf-c740-47d6-8763-d1b7381a60e7@github.com>
Message-ID: <CMXRwk-Gc5nbj3kxzdYE_88n-xVlIuAQX7aheM521Kk=.60acadac-71c1-4d74-89ee-ad335d5aae9c@github.com>

On Fri, 26 Apr 2024 17:43:40 GMT, Louis Bergelson <duke at openjdk.org> wrote:

> Is there any chance of backporting this to java 17 or 21? What's involved in doing that?

It's a straightforward process but I'm not sure I'm one to judge whether it would be appropriate.

@jaikiran and/or @LanceAndersen - any opnions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2080081476

From mchung at openjdk.org  Fri Apr 26 20:38:54 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 20:38:54 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <PDpAtIkoil5lTnCAu5h_jvUy79WmrJaQ9_M5JANk7D4=.47d60bc0-4813-4c1c-96ce-123f1112f55c@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
 <vClcU0-l_R6r9xTYr0I0wl4FnmZkF701Fw-0an6xgqc=.b33b666b-930f-44eb-bd69-92c74f22fa08@github.com>
 <PDpAtIkoil5lTnCAu5h_jvUy79WmrJaQ9_M5JANk7D4=.47d60bc0-4813-4c1c-96ce-123f1112f55c@github.com>
Message-ID: <znHc1C4JCD3D47lgD_2xAYCHuEIXO03CK7cVJd96Wj4=.1a9c9edf-26f8-46aa-acc1-967b5d5a59fc@github.com>

On Fri, 26 Apr 2024 18:41:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/sun/invoke/util/Wrapper.java line 384:
>> 
>>> 382: 
>>> 383:     /** A nominal descriptor of the primitive type */
>>> 384:     public ClassDesc primitiveClassDescriptor() { return primitiveTypeDesc; }
>> 
>> As this method is named as `primitiveClassDescriptor`, I expect this should either throw or return null for `OBJECT` and even `VOID` wrapper.   Or should be named "classDescriptor".
>
> While I agree it may seem non-sensical to define `CD_Object` for `Object`, there's precedent in that `Wrapper.primitiveType` is `Object.class` - so for consistency I wired it up the same way. For the usage patterns introduced with this patch we'll never call `primitiveClassDescriptor()` on `Wrapper.OBJECT`, though - and `Wrapper.forPrimitiveType` will throw an `IAE` if you try - so we can always revisit this. 
>  
> `void.class` is the primitive type for `Void.class`, allowed as a return type and recognized by `Wrapper.forPrimitiveType`. There are checks in for example `ConstantUtils.parseMethodDescriptor` which disallows `void.class` anywhere but as a return type.

I know it'll never call `primitiveClassDescriptor()` besides primitive types.   While `void.class.isPrimitive()` returns true, `void` is not a primitive type and called out explicitly in the spec.

My point is about the behavior does not match the method name.  It may be better to rename it to `classDescriptor` instead.  It's okay to clean up in your other performance fix (perhaps #18945).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18971#discussion_r1581507425

From liach at openjdk.org  Fri Apr 26 20:51:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 20:51:49 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v4]
In-Reply-To: <tz_5xaSN3AugzCJryL9yXlrmuo31I8BbVUYJn7wsN8k=.4a89290d-9c44-4562-a7fd-74452260279b@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <tz_5xaSN3AugzCJryL9yXlrmuo31I8BbVUYJn7wsN8k=.4a89290d-9c44-4562-a7fd-74452260279b@github.com>
Message-ID: <vnrrhCJkXJF5_PJTVRJ2JSFG0dHKxRz4WlDctGeaqgk=.f2b8d115-ba80-4c95-83b6-cb21a3a211c5@github.com>

On Fri, 26 Apr 2024 08:07:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use returnType field directly

test/micro/org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java line 1:

> 1: /*

You can update the copyright of this file if you don't mind.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18945#discussion_r1581519592

From lancea at openjdk.org  Fri Apr 26 20:51:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 26 Apr 2024 20:51:54 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v9]
In-Reply-To: <CMXRwk-Gc5nbj3kxzdYE_88n-xVlIuAQX7aheM521Kk=.60acadac-71c1-4d74-89ee-ad335d5aae9c@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>
 <yovztF-C7k6GrgjVpYKBkZ4XtjdomoKCeU4Kb1eC9Sg=.8b8afcbf-c740-47d6-8763-d1b7381a60e7@github.com>
 <CMXRwk-Gc5nbj3kxzdYE_88n-xVlIuAQX7aheM521Kk=.60acadac-71c1-4d74-89ee-ad335d5aae9c@github.com>
Message-ID: <4bNnMFEz4axKWCtXfh6W1d3eJ6JKABOWwReBWgnHzwM=.5073200f-21e4-4cb4-98b5-c2db7ec9e3e3@github.com>

On Fri, 26 Apr 2024 20:33:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > Is there any chance of backporting this to java 17 or 21? What's involved in doing that?
> 
> It's a straightforward process but I'm not sure I'm one to judge whether it would be appropriate.
> 
> @jaikiran and/or @LanceAndersen - any opnions?

I am not convinced this is a must have for a backport. Please see the[ OpenJDK developers guide regarding bacports.](https://openjdk.org/guide/#backporting).  Also note this would require a CSR for each backport

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2080100566

From vromero at openjdk.org  Fri Apr 26 20:57:16 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 20:57:16 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v14]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <ybEHRVJZ2IabGvAGvB6hc8NCl9nxLkpCpa9VuhYcLHk=.871f129c-993e-4d72-b73c-d0fc12a62d07@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  adding more tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/4c3d4e1e..fa995af6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=12-13

  Stats: 122 lines in 2 files changed: 122 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Fri Apr 26 21:15:20 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 21:15:20 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v15]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <vQND9nkOZbpRB8f9cTc4jaS49kdN7L7W0wmXn6vqIF8=.67ec00f2-f21c-4b51-80b7-13afe094fbc9@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  special case the new code for records only

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/fa995af6..cbc7956d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=13-14

  Stats: 144 lines in 2 files changed: 19 ins; 114 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From liach at openjdk.org  Fri Apr 26 21:30:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 21:30:59 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v15]
In-Reply-To: <vQND9nkOZbpRB8f9cTc4jaS49kdN7L7W0wmXn6vqIF8=.67ec00f2-f21c-4b51-80b7-13afe094fbc9@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <vQND9nkOZbpRB8f9cTc4jaS49kdN7L7W0wmXn6vqIF8=.67ec00f2-f21c-4b51-80b7-13afe094fbc9@github.com>
Message-ID: <_SMJ8Nd0geTggyyYv4LhzktpZDu_fsWztAHERJAtjHI=.765abddf-10a2-440b-ae03-d620651208f3@github.com>

On Fri, 26 Apr 2024 21:15:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   special case the new code for records only

src/java.base/share/classes/java/lang/reflect/Executable.java line 354:

> 352:                      */
> 353:                     int fromidx = genericParamTypes.length - 1;
> 354:                     for (int i = out.length - 1; i >= 0; i--) {

We don't really need this loop any more; can just do something like:

if (genericParamTypes.length == nonGenericParamTypes.length) {
    out = genericParamTypes;
} else {
    out = nonGenericParamTypes.clone();
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1581555623

From redestad at openjdk.org  Fri Apr 26 22:24:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 22:24:23 GMT
Subject: RFR: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor
 for primitive types [v3]
In-Reply-To: <znHc1C4JCD3D47lgD_2xAYCHuEIXO03CK7cVJd96Wj4=.1a9c9edf-26f8-46aa-acc1-967b5d5a59fc@github.com>
References: <_dJ1R-1Wxc3mZs8s7Ih6XgufDGHmxu2JkG9kJQ9bZB0=.ac814df1-5c4e-48c7-a491-5e12e00d5f75@github.com>
 <BZGh_6ggeiiDUcF8u4Zc7V2Vokezyy2H7lzSzuEITu0=.cab10e05-aaf6-42eb-98b4-cf8640c8813b@github.com>
 <vClcU0-l_R6r9xTYr0I0wl4FnmZkF701Fw-0an6xgqc=.b33b666b-930f-44eb-bd69-92c74f22fa08@github.com>
 <PDpAtIkoil5lTnCAu5h_jvUy79WmrJaQ9_M5JANk7D4=.47d60bc0-4813-4c1c-96ce-123f1112f55c@github.com>
 <znHc1C4JCD3D47lgD_2xAYCHuEIXO03CK7cVJd96Wj4=.1a9c9edf-26f8-46aa-acc1-967b5d5a59fc@github.com>
Message-ID: <BSFrAzR5p2-JZ5f8xPaRPqzj0PrRfWrhoq9wk43hm6U=.4a0137a1-9ce1-44a9-b198-8486945ccbe1@github.com>

On Fri, 26 Apr 2024 20:35:44 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> While I agree it may seem non-sensical to define `CD_Object` for `Object`, there's precedent in that `Wrapper.primitiveType` is `Object.class` - so for consistency I wired it up the same way. For the usage patterns introduced with this patch we'll never call `primitiveClassDescriptor()` on `Wrapper.OBJECT`, though - and `Wrapper.forPrimitiveType` will throw an `IAE` if you try - so we can always revisit this. 
>>  
>> `void.class` is the primitive type for `Void.class`, allowed as a return type and recognized by `Wrapper.forPrimitiveType`. There are checks in for example `ConstantUtils.parseMethodDescriptor` which disallows `void.class` anywhere but as a return type.
>
> I know it'll never call `primitiveClassDescriptor()` besides primitive types.   While `void.class.isPrimitive()` returns true, `void` is not a primitive type and called out explicitly in the spec.
> 
> My point is about the behavior does not match the method name.  It may be better to rename it to `classDescriptor` instead.  It's okay to clean up in your other performance fix (perhaps #18945).

Updated #18945, will try ignoring the pre-existing `Wrapper.primitiveType` inconsistencies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18971#discussion_r1581580674

From liach at openjdk.org  Fri Apr 26 22:27:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 22:27:21 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v3]
In-Reply-To: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
Message-ID: <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>

> Please review this patch that:
> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
> 2. Implemented `spliterator` to optimize for a single element.
> 
> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Add test to ensure reproducible iteration order
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
 - Use the improved form in forEach
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
 - Null checks should probably be in the beginning...
 - mark implicit null checks
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
 - Copyright year, revert changes for non-few element collections
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
 - ... and 6 more: https://git.openjdk.org/jdk/compare/a920af23...70583024

-------------

Changes: https://git.openjdk.org/jdk/pull/15834/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15834&range=02
  Stats: 126 lines in 3 files changed: 122 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15834.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15834/head:pull/15834

PR: https://git.openjdk.org/jdk/pull/15834

From liach at openjdk.org  Fri Apr 26 22:27:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 22:27:23 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <WJluiM0FQWMl1Qcd-vO1-1j19zPu7ZZqnzTwb5ylBEk=.7bd9f014-d4fc-451e-ad7c-8dab3969e5d2@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
 <WJluiM0FQWMl1Qcd-vO1-1j19zPu7ZZqnzTwb5ylBEk=.7bd9f014-d4fc-451e-ad7c-8dab3969e5d2@github.com>
Message-ID: <mSlPcUYk-K-xRecU1zHNYzBMZ3JpLSHpiPVUU5kTJs4=.8c9430e9-fa4d-4ffc-871d-37a55af33491@github.com>

On Tue, 23 Apr 2024 13:13:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Use the improved form in forEach
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>>  - Null checks should probably be in the beginning...
>>  - mark implicit null checks
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>>  - Copyright year, revert changes for non-few element collections
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>>  - Merge branch 'feature/imm-coll-stream' of https://github.com/liachmodded/jdk into feature/imm-coll-stream
>>  - Spliterator for 12, iterate/forEach benchmark
>>  - fix comments
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d5b95a0e...69bd0e9c
>
> Do we need additional tests or are these modifications already covered by the existing tests?

@minborg I have added a test as part of Collection mother-of-all-tests to ensure spliterator and forEach yields in the same order as iterator for unmodifiable/immutable collections. One thing of note is that somehow `==` for yields fail for some collections like `unmodifiableSequencedMap(linkedHashSet).sequencedKeySet()` so I have to use `Objects.equals` instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2080179982

From redestad at openjdk.org  Fri Apr 26 22:27:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 26 Apr 2024 22:27:43 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v5]
In-Reply-To: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
Message-ID: <HxkjF4HYRyIyIQ2NVsieNDIbwOAuA5rXD8P25NLHKiw=.63b98750-8a15-444b-bd9c-a297624e3a6c@github.com>

> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
> 
> Performance improves across the board in existing microbenchmarks:
> 
> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>   * = significant
> 
> 
> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
> 
> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>   * = significant
>   ```
>   
>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.

Claes Redestad 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:

 - Rename parameter, formatting
 - Rename Wrapper.primitiveClassDescriptor -> classDescriptor
 - Merge branch 'master' into methodtypedesc_descriptorString
 - Minor fixes
 - Use returnType field directly
 - Calculate length precisely
 - comma-separated
 - Optimize MethodTypeDescImpl::toString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18945/files
  - new: https://git.openjdk.org/jdk/pull/18945/files/6ff505f6..fff380df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18945&range=03-04

  Stats: 9169 lines in 1214 files changed: 1476 ins; 4863 del; 2830 mod
  Patch: https://git.openjdk.org/jdk/pull/18945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18945/head:pull/18945

PR: https://git.openjdk.org/jdk/pull/18945

From liach at openjdk.org  Fri Apr 26 22:27:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Apr 2024 22:27:44 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v5]
In-Reply-To: <HxkjF4HYRyIyIQ2NVsieNDIbwOAuA5rXD8P25NLHKiw=.63b98750-8a15-444b-bd9c-a297624e3a6c@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <HxkjF4HYRyIyIQ2NVsieNDIbwOAuA5rXD8P25NLHKiw=.63b98750-8a15-444b-bd9c-a297624e3a6c@github.com>
Message-ID: <CE5YeDULHfCqpy0JJrVdEb8bib0scJbmGrcH72DdYYM=.9d9988f9-aaff-4667-8407-5ea6a2958b2d@github.com>

On Fri, 26 Apr 2024 22:23:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad 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:
> 
>  - Rename parameter, formatting
>  - Rename Wrapper.primitiveClassDescriptor -> classDescriptor
>  - Merge branch 'master' into methodtypedesc_descriptorString
>  - Minor fixes
>  - Use returnType field directly
>  - Calculate length precisely
>  - comma-separated
>  - Optimize MethodTypeDescImpl::toString

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18945#pullrequestreview-2025936881

From vromero at openjdk.org  Fri Apr 26 23:02:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 23:02:17 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v16]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <47LUgJI5LQnJwTAuef3oYIz31FOtCTjqYFTP52Wi-AY=.b52f6f2b-d950-4a61-928e-3d37808c44d9@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  additional tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/cbc7956d..0abb4282

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=14-15

  Stats: 36 lines in 1 file changed: 32 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From mchung at openjdk.org  Fri Apr 26 23:16:09 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 23:16:09 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v5]
In-Reply-To: <HxkjF4HYRyIyIQ2NVsieNDIbwOAuA5rXD8P25NLHKiw=.63b98750-8a15-444b-bd9c-a297624e3a6c@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <HxkjF4HYRyIyIQ2NVsieNDIbwOAuA5rXD8P25NLHKiw=.63b98750-8a15-444b-bd9c-a297624e3a6c@github.com>
Message-ID: <TFoINlGbnfoMlP0W1f0j7Bn6klCjBHcnVAO-wT-7rtc=.815332e7-3d59-409b-8ea3-331c42098cf9@github.com>

On Fri, 26 Apr 2024 22:27:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad 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:
> 
>  - Rename parameter, formatting
>  - Rename Wrapper.primitiveClassDescriptor -> classDescriptor
>  - Merge branch 'master' into methodtypedesc_descriptorString
>  - Minor fixes
>  - Use returnType field directly
>  - Calculate length precisely
>  - comma-separated
>  - Optimize MethodTypeDescImpl::toString

Thanks for following up the feedback for 8331187.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18945#pullrequestreview-2025970705

From vromero at openjdk.org  Fri Apr 26 23:19:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 23:19:06 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v15]
In-Reply-To: <_SMJ8Nd0geTggyyYv4LhzktpZDu_fsWztAHERJAtjHI=.765abddf-10a2-440b-ae03-d620651208f3@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <vQND9nkOZbpRB8f9cTc4jaS49kdN7L7W0wmXn6vqIF8=.67ec00f2-f21c-4b51-80b7-13afe094fbc9@github.com>
 <_SMJ8Nd0geTggyyYv4LhzktpZDu_fsWztAHERJAtjHI=.765abddf-10a2-440b-ae03-d620651208f3@github.com>
Message-ID: <mg4E_GyLfaYnVwTsTpkIZOOyRRZceeSxSa6TtE67SEY=.fe8d3897-7281-41a1-ad7a-6d62a8bcf1c2@github.com>

On Fri, 26 Apr 2024 21:27:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   special case the new code for records only
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 354:
> 
>> 352:                      */
>> 353:                     int fromidx = genericParamTypes.length - 1;
>> 354:                     for (int i = out.length - 1; i >= 0; i--) {
> 
> We don't really need this loop any more; can just do something like:
> 
> if (genericParamTypes.length == nonGenericParamTypes.length) {
>     out = genericParamTypes;
> } else {
>     out = nonGenericParamTypes.clone();
> }

yup I like this, thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1581603973

From vromero at openjdk.org  Fri Apr 26 23:54:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 23:54:17 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v17]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <oMvlrJa4zDX0GQ9Yl6DgAJbBZjcPjNnK0Via091o0iM=.edf1a4e2-8764-4c2e-8743-346ce1152bd4@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  code refactoring

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/0abb4282..775599cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=15-16

  Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From liach at openjdk.org  Sat Apr 27 00:17:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 27 Apr 2024 00:17:06 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v17]
In-Reply-To: <oMvlrJa4zDX0GQ9Yl6DgAJbBZjcPjNnK0Via091o0iM=.edf1a4e2-8764-4c2e-8743-346ce1152bd4@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <oMvlrJa4zDX0GQ9Yl6DgAJbBZjcPjNnK0Via091o0iM=.edf1a4e2-8764-4c2e-8743-346ce1152bd4@github.com>
Message-ID: <fwjw2OjiKOWy3SdIjPvZggP9xpzb9FHhZTcsRN1KFOs=.d8e1d805-bddc-4116-a2b6-a2b975388433@github.com>

On Fri, 26 Apr 2024 23:54:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code refactoring

src/java.base/share/classes/java/lang/reflect/Executable.java line 348:

> 346:                 final Type[] out = new Type[nonGenericParamTypes.length];
> 347:                 final Parameter[] params = getParameters();
> 348:                 if (getDeclaringClass().isRecord() && this instanceof Constructor) {

Sorry for late notice but we can move the 2 variable allocation to the else block, to speed up the record constructor path.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1581636171

From duke at openjdk.org  Sat Apr 27 00:35:26 2024
From: duke at openjdk.org (Jin Kwon)
Date: Sat, 27 Apr 2024 00:35:26 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v4]
In-Reply-To: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
Message-ID: <82lc6dZj-dQ_dR5KB_LOvxaTm0a2tw9zOgaN7xZE300=.358cf7fb-0a73-40c2-bafa-63639bf6c737@github.com>

> Fix typos within the `DatabaseMetaData.java`.

Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:

  8330686: Fix typos in the DatabaseMetaData javadoc
  
  Reviewed-by: jpai, lancea, iris

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18860/files
  - new: https://git.openjdk.org/jdk/pull/18860/files/c8cf9728..94a38169

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18860&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18860&range=02-03

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18860/head:pull/18860

PR: https://git.openjdk.org/jdk/pull/18860

From jpai at openjdk.org  Sat Apr 27 01:14:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Apr 2024 01:14:12 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v4]
In-Reply-To: <82lc6dZj-dQ_dR5KB_LOvxaTm0a2tw9zOgaN7xZE300=.358cf7fb-0a73-40c2-bafa-63639bf6c737@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <82lc6dZj-dQ_dR5KB_LOvxaTm0a2tw9zOgaN7xZE300=.358cf7fb-0a73-40c2-bafa-63639bf6c737@github.com>
Message-ID: <H__BOJ0NkPZTcF_ri33dBQ3FfP635cOxYlqF2XCfWp4=.59a1f7be-c8c6-4ec0-b220-8a9dc9b6e861@github.com>

On Sat, 27 Apr 2024 00:35:26 GMT, Jin Kwon <duke at openjdk.org> wrote:

>> Fix typos within the `DatabaseMetaData.java`.
>
> Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8330686: Fix typos in the DatabaseMetaData javadoc
>   
>   Reviewed-by: jpai, lancea, iris

Marked as reviewed by jpai (Reviewer).

Hello Jin, once a PR is approved, unless there are additional review comments to address, it's a good idea not to update/change the PR.

In this case, it appears that you only updated the commit message to include the `Reviewed-By` line. Contributions to the JDK repo these days use bots which automatically add the `Reviewed-By` line when the PR is actually being integrated. We used to previously (before migrating to GitHub pull requests) expect the contributors to add that line themselves, but that's no longer the case.

I have reviewed this PR afresh and the change still looks good to me. I'll go ahead and sponsor this now.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18860#pullrequestreview-2026083414
PR Comment: https://git.openjdk.org/jdk/pull/18860#issuecomment-2080288362

From duke at openjdk.org  Sat Apr 27 01:14:12 2024
From: duke at openjdk.org (Jin Kwon)
Date: Sat, 27 Apr 2024 01:14:12 GMT
Subject: Integrated: 8330686: Fix typos in the DatabaseMetaData javadoc
In-Reply-To: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
Message-ID: <j6ktOefVDRqxTYxhdu7fPPsTikGbBrMa8CeTz_tpCmg=.a0c3d82e-3b6a-44b4-acad-2447f4c0d371@github.com>

On Fri, 19 Apr 2024 11:33:48 GMT, Jin Kwon <duke at openjdk.org> wrote:

> Fix typos within the `DatabaseMetaData.java`.

This pull request has now been integrated.

Changeset: aa2edd49
Author:    Jin Kwon <onacit at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa2edd491345cca1d8798848d71b151bc06c6c02
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8330686: Fix typos in the DatabaseMetaData javadoc

Reviewed-by: jpai, lancea, iris

-------------

PR: https://git.openjdk.org/jdk/pull/18860

From duke at openjdk.org  Sat Apr 27 01:42:15 2024
From: duke at openjdk.org (Jin Kwon)
Date: Sat, 27 Apr 2024 01:42:15 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v4]
In-Reply-To: <H__BOJ0NkPZTcF_ri33dBQ3FfP635cOxYlqF2XCfWp4=.59a1f7be-c8c6-4ec0-b220-8a9dc9b6e861@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <82lc6dZj-dQ_dR5KB_LOvxaTm0a2tw9zOgaN7xZE300=.358cf7fb-0a73-40c2-bafa-63639bf6c737@github.com>
 <H__BOJ0NkPZTcF_ri33dBQ3FfP635cOxYlqF2XCfWp4=.59a1f7be-c8c6-4ec0-b220-8a9dc9b6e861@github.com>
Message-ID: <rD7iMAQDyproeyRcF6EZ1-XO7wCz9GVKe_HqVQyywxI=.36eddc4c-dc4d-472c-9b4d-741ea53858b8@github.com>

On Sat, 27 Apr 2024 01:09:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8330686: Fix typos in the DatabaseMetaData javadoc
>>   
>>   Reviewed-by: jpai, lancea, iris
>
> Hello Jin, once a PR is approved, unless there are additional review comments to address, it's a good idea not to update/change the PR.
> 
> In this case, it appears that you only updated the commit message to include the `Reviewed-By` line. Contributions to the JDK repo these days use bots which automatically add the `Reviewed-By` line when the PR is actually being integrated. We used to previously (before migrating to GitHub pull requests) expect the contributors to add that line themselves, but that's no longer the case.
> 
> I have reviewed this PR afresh and the change still looks good to me. I'll go ahead and sponsor this now.

@jaikiran Is everything O.K. with this PR? Is it merged? Please help me. Thank you anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18860#issuecomment-2080307272

From jpai at openjdk.org  Sat Apr 27 01:48:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Apr 2024 01:48:09 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v4]
In-Reply-To: <82lc6dZj-dQ_dR5KB_LOvxaTm0a2tw9zOgaN7xZE300=.358cf7fb-0a73-40c2-bafa-63639bf6c737@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <82lc6dZj-dQ_dR5KB_LOvxaTm0a2tw9zOgaN7xZE300=.358cf7fb-0a73-40c2-bafa-63639bf6c737@github.com>
Message-ID: <ONGZJK8iUQtEWG5pO0ZjGye6ZW4Frkspe2jlV7oCfDo=.96447ae1-307b-4c46-af72-91fce2399f84@github.com>

On Sat, 27 Apr 2024 00:35:26 GMT, Jin Kwon <duke at openjdk.org> wrote:

>> Fix typos within the `DatabaseMetaData.java`.
>
> Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8330686: Fix typos in the DatabaseMetaData javadoc
>   
>   Reviewed-by: jpai, lancea, iris

Yes, the PR has been merged and the changes are now part of the JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18860#issuecomment-2080310010

From duke at openjdk.org  Sat Apr 27 02:13:14 2024
From: duke at openjdk.org (Jin Kwon)
Date: Sat, 27 Apr 2024 02:13:14 GMT
Subject: RFR: 8330686: Fix typos in the DatabaseMetaData javadoc [v4]
In-Reply-To: <ONGZJK8iUQtEWG5pO0ZjGye6ZW4Frkspe2jlV7oCfDo=.96447ae1-307b-4c46-af72-91fce2399f84@github.com>
References: <VohCnLRxYJlOVZRyijL4MwhuOY0Tg9S0kIow7UouVKk=.a2578f69-3915-43c8-84dc-14cfa1bfa762@github.com>
 <82lc6dZj-dQ_dR5KB_LOvxaTm0a2tw9zOgaN7xZE300=.358cf7fb-0a73-40c2-bafa-63639bf6c737@github.com>
 <ONGZJK8iUQtEWG5pO0ZjGye6ZW4Frkspe2jlV7oCfDo=.96447ae1-307b-4c46-af72-91fce2399f84@github.com>
Message-ID: <5fd31ZdkSSnfmQVVBcxZaba9tMJKqimLzH1RpMKsGHg=.56f6974d-8bf4-4387-9bd1-72a592ef5175@github.com>

On Sat, 27 Apr 2024 01:45:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jin Kwon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8330686: Fix typos in the DatabaseMetaData javadoc
>>   
>>   Reviewed-by: jpai, lancea, iris
>
> Yes, the PR has been merged and the changes are now part of the JDK.

@jaikiran I do love you. Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18860#issuecomment-2080320659

From duke at openjdk.org  Sat Apr 27 10:51:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 27 Apr 2024 10:51:10 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v18]
In-Reply-To: <Yw4kcTjZKxBKUDXIf0DFZLJ-ZA-axRJwUTv51jOnFic=.abb52ebf-e0a6-468d-aba5-11e123c172ed@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <Yw4kcTjZKxBKUDXIf0DFZLJ-ZA-axRJwUTv51jOnFic=.abb52ebf-e0a6-468d-aba5-11e123c172ed@github.com>
Message-ID: <zvjczviLhP8c0HYIlfd-3pFc_6i6wrmyU1Ii3W1vHGQ=.f069c247-8706-4893-a15c-a649adcc9ff7@github.com>

On Fri, 26 Apr 2024 05:48:03 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current BigDecimal(String) constructor calls String#toCharArray, which has a memory allocation.
>> 
>> 
>> public BigDecimal(String val) {
>>     this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>> 
>> 
>> When the length is greater than 18, create a char[]
>> 
>> 
>> boolean isCompact = (len <= MAX_COMPACT_DIGITS); // 18
>> if (!isCompact) {
>>     // ...
>> } else {
>>     char[] coeff = new char[len]; // allocate char[]
>>     // ...
>> }
>> 
>> 
>> This PR eliminates the two memory allocations mentioned above, resulting in an approximate 60% increase in performance..
>
> Shaojin Wen 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 22 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_dec_new
>  - Merge remote-tracking branch 'upstream/master' into optim_dec_new
>  - use while instead for
>  - Update src/java.base/share/classes/java/math/BigDecimal.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - bug fix for CharArraySequence#charAt
>  - bug fix for CharArraySequence
>  - fix benchmark
>  - one CharArraySequence
>  - restore comment
>  - easier to compare
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/26169c54...bb620ba3

In money-related scenarios, such as product prices, etc., BigDecimal needs to be used instead of float/double. I focus on optimizing the performance of BigDecimal's construction and toString scenarios.

Constructing BigDecimal usually includes two scenarios:
* new BigDecimal(char[], int, int), Many libraries, such as mysql drveri/fastjson/jackson and other commonly used libraries use this function to construct BigDecimal
* new BigDecimal(String), There are also many scenarios, such as data integration scenarios, scenarios where json is read from the message queue and then converted into target database row records, often using new BigDecimal(String)

I did a performance comparison test on Mac Book M1 Pro. The compared branches are:
* [baseline](https://github.com/wenshao/jdk/tree/upstream_master_0312) https://github.com/wenshao/jdk/tree/upstream_master_0312
* bb620ba  [Full](https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=17) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=16-17) ([bb620ba3](https://git.openjdk.org/jdk/pull/18177/files/bb620ba39a6f1ce17ff273bac54ebb709beb1667))


# 1. new BigDecimal(String) benchmark
Execute the following commands respectively 

make test TEST="micro:java.math.BigDecimals.testConstructorWithHugeString"
make test TEST="micro:java.math.BigDecimals.testConstructorWithLargeString"
make test TEST="micro:java.math.BigDecimals.testConstructorWithSmallString"
make test TEST="micro:java.math.BigDecimals.testConstructorWithString"


## benchmark result

-Benchmark                                      Mode  Cnt    Score   Error  Units #baseline
-BigDecimals.testConstructorWithHugeString      avgt   15  112.994 ? 2.342  ns/op
-BigDecimals.testConstructorWithLargeString     avgt   15  114.016 ? 2.529  ns/op
-BigDecimals.testConstructorWithSmallString     avgt   15   19.526 ? 0.078  ns/op
-BigDecimals.testConstructorWithString          avgt   15   68.058 ? 0.836  ns/op

+Benchmark                                      Mode  Cnt    Score    Error  Units #bb620ba
+BigDecimals.testConstructorWithHugeString      avgt   15   96.838 ?  8.743  ns/op +16.68%
+BigDecimals.testConstructorWithLargeString     avgt   15   20.904 ?  0.112  ns/op +445.42%
+BigDecimals.testConstructorWithSmallString     avgt   15   16.083 ?  0.042  ns/op +21.40%
+BigDecimals.testConstructorWithString          avgt   15   35.912 ?  0.350  ns/op +85.91%


It can be seen that there is a significant performance improvement in the new BigDecimal(String) scenario.

| case |  |
|-|-|
|BigDecimals.testConstructorWithHugeString |16.68% |
|BigDecimals.testConstructorWithLargeString |445.42% |
|BigDecimals.testConstructorWithSmallString |21.40% |
|BigDecimals.testConstructorWithString |85.91% |

# 2. new BigDecima(char[],int,int) benchmark

Execute the following commands respectively 

make test TEST="micro:java.math.BigDecimals.testConstructorWithHugeCharArray"
make test TEST="micro:java.math.BigDecimals.testConstructorWithLargeCharArray"
make test TEST="micro:java.math.BigDecimals.testConstructorWithSmallCharArray"
make test TEST="micro:java.math.BigDecimals.testConstructorWithCharArray"


## benchmark result

-Benchmark                                      Mode  Cnt    Score   Error  Units #baseline
-BigDecimals.testConstructorWithHugeCharArray   avgt   15   94.554 ? 4.262  ns/op
-BigDecimals.testConstructorWithLargeCharArray  avgt   15   94.669 ? 3.065  ns/op
-BigDecimals.testConstructorWithSmallCharArray  avgt   15   16.457 ? 0.081  ns/op
-BigDecimals.testConstructorWithCharArray       avgt   15   47.555 ? 0.562  ns/op

+Benchmark                                      Mode  Cnt    Score    Error  Units #bb620ba
+BigDecimals.testConstructorWithHugeCharArray   avgt   15  113.113 ?  1.924  ns/op -16.40%
+BigDecimals.testConstructorWithLargeCharArray  avgt   15   24.150 ?  0.098  ns/op +292.00%
+BigDecimals.testConstructorWithSmallCharArray  avgt   15   19.524 ?  0.044  ns/op -15.70%
+BigDecimals.testConstructorWithCharArray       avgt   15   52.178 ? 14.289  ns/op -8.86%


The current implementation has significant performance improvements in testConstructorWithLargeCharArray, but has performance degradation in the other four scenarios. The performance degradation of some of these scenarios is due to the need to avoid code duplication. If we don't care about code duplication, we can improve performance in all scenarios.

| case |  |
|-|-|
|BigDecimals.testConstructorWithHugeCharArray |-16.40% |
|BigDecimals.testConstructorWithLargeCharArray |+292.00% |
|BigDecimals.testConstructorWithSmallCharArray |-15.70% |
|BigDecimals.testConstructorWithCharArray |-8.86% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2080449446

From jpai at openjdk.org  Sat Apr 27 11:16:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Apr 2024 11:16:04 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v3]
In-Reply-To: <bRklCE0QPxh8YRlNu2h2YtGUUnEz31OKh9I1YTtdPto=.25f1a3b3-8a1f-4467-86dc-8145fd8fcf17@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <PIaR6T0MKovlJXXxEzbFCoeP_YTpk2r21a0iT9ZCh4s=.779da8bf-abcd-42d1-bf5c-8f410cd0e26d@github.com>
 <bRklCE0QPxh8YRlNu2h2YtGUUnEz31OKh9I1YTtdPto=.25f1a3b3-8a1f-4467-86dc-8145fd8fcf17@github.com>
Message-ID: <WaDXGEIy40CsMoTJiRf--Lq8IwCJV-pzr_eXDa4SyKM=.a00bc2be-a4e3-4428-9260-214bdcb31619@github.com>

On Fri, 26 Apr 2024 13:45:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> How useful is it to deploy with additional RandomGenerator implementations on the class path or module path?

It doesn't look like in its current form it's possible (without an `--add-exports`) to have additional `java.util.random.RandomGenerator` implementations in the class path (or module path). I tried some experiment today to introduce a trivial `java.util.random.RandomGenerator` implementation as follows:


package foo;

import java.util.Random;
import java.util.random.RandomGenerator;

public class DummyRandomGenerator implements RandomGenerator {

    private final Random random = new Random();

    @Override
    public long nextLong() {
        System.out.println("nextLong from " + this.getClass());
        return random.nextLong();
    }
}

Package this `DummyRandomGenerator` into a jar file and in that jar file include a `META-INF/services/java.util.RandomGenerator` which points to the `foo.DummyRandomGenerator` class. Then launch a main application with this jar in the classpath:


import java.util.random.RandomGeneratorFactory;

public class Main {
    public static void main(String[] args) {
        System.out.println("available RandomGenerator(s):");
        RandomGeneratorFactory.all().map(RandomGeneratorFactory::name).forEach(System.out::println);
    }
}

Running this `Main` application with that jar in the classpath doesn't list the `DummyRandomGenerator`. It appears that such application/library specific implementations of `java.util.random.RandomGenerator` are expected to be annotated to an annotation that belongs to the internals of the java.base module https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java#L391.

Changing the `DummyRandomGenerator` to have it annotated with:


@jdk.internal.util.random.RandomSupport.RandomGeneratorProperties(name="Dummy")
public class DummyRandomGenerator implements RandomGenerator {
...

and then compiling that application class with:


javac --add-exports java.base/jdk.internal.util.random=ALL-UNNAMED ...

and then re-packaging that jar with this class and rerunning the Main with that jar in the classpath will this time return the `DummyRandomGenerator` from a call to `RandomGeneratorFactory.all()`.

The API docs of `java.util.random.RandomGeneratorFactory` don't make a mention of the necessity of this internal `jdk.internal.util.random.RandomSupport.RandomGeneratorProperties` annotation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2080455552

From hgreule at openjdk.org  Sat Apr 27 11:52:06 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Sat, 27 Apr 2024 11:52:06 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v4]
In-Reply-To: <bgzgSyhfSw7ZJPUq36C5_khMuJXfqv_o55OWiu0VGBE=.c882a00c-a3a0-4fcb-994f-ed6a0f044456@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <bgzgSyhfSw7ZJPUq36C5_khMuJXfqv_o55OWiu0VGBE=.c882a00c-a3a0-4fcb-994f-ed6a0f044456@github.com>
Message-ID: <ASwgps2mqykXNveYGuBYm_xL9n5-WAGv8w3iK8JTQqI=.97192ca8-b34d-4498-b1c3-b0827a7248cd@github.com>

On Fri, 26 Apr 2024 15:24:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @uses javadoc tag for j.u.r.RandomGenerator in java.base.

Note that this also fixes a "bug" when calling `RandomGenerator.getDefault()` (or similar) from an unnamed module that does not have the application class loader as a(n indirect) parent. That previously resulted in the service loader only finding `Random`, `SecureRandom`, and `SplittableRandom`. As those are cached (https://github.com/openjdk/jdk/blob/fd84a28ba0aa82b2f48f247c3ec7e13acdcd6ff1/src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java#L137), even calls from somewhere else afterwards wouldn't find the correct implementation anymore. So I'm welcoming this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2080464407

From vklang at openjdk.org  Sat Apr 27 11:52:18 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 27 Apr 2024 11:52:18 GMT
Subject: RFR: 8278255: add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
Message-ID: <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>

> This is an attempt to be more clear about recommendations on Lock usage.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
  
  Co-authored-by: Pavel Rappo <32523691+pavelrappo at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18974/files
  - new: https://git.openjdk.org/jdk/pull/18974/files/74c937a1..e416c59a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18974&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18974&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18974/head:pull/18974

PR: https://git.openjdk.org/jdk/pull/18974

From vklang at openjdk.org  Sat Apr 27 11:55:09 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 27 Apr 2024 11:55:09 GMT
Subject: Integrated: 8296543: Update exception documentation for
 ExecutorService.invokeAll overriders as required
In-Reply-To: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
References: <mc3tVNVW9fm1G72Vy2W6SQBZSc5x3iVjNovfDEVb7rM=.f1b6e323-2d99-4a15-8fbd-149bb8185a41@github.com>
Message-ID: <Wm9tY3EtTS7fbl4TYQV7o_GogfLaekMyDG9EnVz1NZs=.23a434ba-e7f0-47a6-b058-75111bd4d60f@github.com>

On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR adds the exception documentation as per the ExecutorService API contract. I also took the liberty of adding @Override-annotations to be clear about intent.

This pull request has now been integrated.

Changeset: e3eb652c
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3eb652c251e8298c9df95d7ed2788f2cbb5f337
Stats:     31 lines in 1 file changed: 31 ins; 0 del; 0 mod

8296543: Update exception documentation for ExecutorService.invokeAll overriders as required

Reviewed-by: prappo, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/18966

From vklang at openjdk.org  Sat Apr 27 12:03:12 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 27 Apr 2024 12:03:12 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v28]
In-Reply-To: <b9F3NTIjnmwisjT9eVzz_gfD6Nkeu9mRJpAqFX1ZbYU=.64e9c467-56a7-47d0-baa6-e8c29408ea4a@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <b9F3NTIjnmwisjT9eVzz_gfD6Nkeu9mRJpAqFX1ZbYU=.64e9c467-56a7-47d0-baa6-e8c29408ea4a@github.com>
Message-ID: <HADrLqtHXFx_IDXhxlNOeX1PsVToOw5NVo6d9ZP9WiA=.d16db133-43d2-4f5e-bffe-2bf1e7648a24@github.com>

On Fri, 26 Apr 2024 17:59:39 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new section for finalizer memviz

src/java.base/share/classes/java/lang/ref/package-info.java line 137:

> 135:  * <a id="MemoryConsistency"></a>
> 136:  * <h2>Memory Consistency Properties</h2>
> 137:  * Certain interactions between references, references queues, and the garbage

Suggestion:

 * Certain interactions between references, reference queues, and the garbage

src/java.base/share/classes/java/lang/ref/package-info.java line 157:

> 155:  * <li>The dequeuing of a reference to a
> 156:  * {@linkplain Cleaner#register(Object object, Runnable action) registered}
> 157:  * object, by a Cleaner thread, <i>happens-before</i> that Cleaner thread runs

Are we committing to this? I.e. that there will always be a single Cleaner thread? (i.e. one could imagine a situation where you have one polling thread which executes the cleaning action on some other thread?)

src/java.base/share/classes/java/lang/ref/package-info.java line 176:

> 174:  * <li>Actions in a thread prior to calling
> 175:  * {@link Reference#reachabilityFence Reference.reachabilityFence(x)}
> 176:  * <i>happen-before</i> the finalizer for x is run by a finalizer thread.</li>

Suggestion:

 * <i>happen-before</i> the finalizer for {@code x} is run by a finalizer thread.</li>

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1581818740
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1581818931
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1581819080

From redestad at openjdk.org  Sat Apr 27 12:16:14 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 27 Apr 2024 12:16:14 GMT
Subject: RFR: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString [v5]
In-Reply-To: <HxkjF4HYRyIyIQ2NVsieNDIbwOAuA5rXD8P25NLHKiw=.63b98750-8a15-444b-bd9c-a297624e3a6c@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
 <HxkjF4HYRyIyIQ2NVsieNDIbwOAuA5rXD8P25NLHKiw=.63b98750-8a15-444b-bd9c-a297624e3a6c@github.com>
Message-ID: <AIHcDC19Fg2Xu45SdxW3qYPWoCc33eg25K-wJhl73Ks=.48cd2788-ca58-447a-9a62-d728a06fc520@github.com>

On Fri, 26 Apr 2024 22:27:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>> 
>> Performance improves across the board in existing microbenchmarks:
>> 
>> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
>> 
>> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
>> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
>> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>>   * = significant
>>   ```
>>   
>>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.
>
> Claes Redestad 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:
> 
>  - Rename parameter, formatting
>  - Rename Wrapper.primitiveClassDescriptor -> classDescriptor
>  - Merge branch 'master' into methodtypedesc_descriptorString
>  - Minor fixes
>  - Use returnType field directly
>  - Calculate length precisely
>  - comma-separated
>  - Optimize MethodTypeDescImpl::toString

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18945#issuecomment-2080505209

From redestad at openjdk.org  Sat Apr 27 12:16:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 27 Apr 2024 12:16:19 GMT
Subject: RFR: 8331134: Port SimpleStringBuilderStrategy to use ClassFile
 API [v10]
In-Reply-To: <yhrkajl4_8lFBx69sfOyLCI93e1gMxRJsO1SJ4X5DcI=.37117424-bccf-4a96-beec-c118cbc6fa2f@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
 <yhrkajl4_8lFBx69sfOyLCI93e1gMxRJsO1SJ4X5DcI=.37117424-bccf-4a96-beec-c118cbc6fa2f@github.com>
Message-ID: <85esoP3khukhDaRaLNYw0BVDCr4_VKRNSQR9_hqsI8g=.88256282-d3a9-4067-b30d-6355052c157e@github.com>

On Fri, 26 Apr 2024 14:57:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
>> 
>> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
>> 
>> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
>> 
>> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
>> 
>> Baseline strategy:
>> 13 args: 6.3M
>> 23 args: 18M
>> 123 args: 868M
>> 
>> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
>> 13 args: 2.11M
>> 23 args: 3.67M
>> 123 args: 4.75M
>> 
>> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
>> 
>> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Rebase after integration of #18953
>  - Nits, clean up constant, introduce missing constant MethodTypeDesc for toString
>  - Make Set.of(STRONG) a constant, fix compilation, minor code improvements
>  - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Minor SimpleStringBuilderStrategy::<clinit> overhead reduction
>  - Merge master, resolve conflicts due pr/18688
>  - Dump using the hidden class name
>  - Pre-size stringbuilders based on constant size and a small argument factor
>  - @liach feedback
>  - Bump threshold after experiments
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/5e2ced4b...f87fa1d7

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2080507738

From redestad at openjdk.org  Sat Apr 27 12:16:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 27 Apr 2024 12:16:20 GMT
Subject: Integrated: 8331134: Port SimpleStringBuilderStrategy to use ClassFile
 API
In-Reply-To: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
References: <_H0ByYexdVLtJMF9XPj5JObdtO1GN33sU_hC7tu6NPY=.f71b7306-70da-4006-b2ee-00c481fc3bc4@github.com>
Message-ID: <Cp2IBt2uV8zkPuDC6MqXZjZm6JOk5nSbhwzNLPuFEis=.61ec0023-0e76-4bde-af4f-a979181f1457@github.com>

On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch suggests a workaround to an issue with huge SCF MH expression trees taking excessive JIT compilation resources by reviving (part of) the simple bytecode-generating strategy that was originally available as an all-or-nothing strategy choice. 
> 
> Instead of reintroducing a binary strategy choice I propose a threshold parameter, controlled by `-Djava.lang.invoke.StringConcat.highArityThreshold=<val>`: For expressions below or at this threshold there's no change, for expressions with an arity above it we use the `StringBuilder`-chain bytecode generator. 
> 
> There are a few trade-offs at play here which influence the choice of threshold. The simple high arity strategy will for example not see any reuse of LambdaForms but strictly always generate a class per indy callsite, which means we might end up with a higher total number of classes generated and loaded in applications if we set this value too low. It may also produce worse performance on average. On the other hand there is the observed increase in C2 resource usage as expressions grow unwieldy. On the other other hand high arity expressions are likely rare to begin with, with less opportunities for sharing than the more common low-arity expressions. 
> 
> I turned the submitted test case into a few JMH benchmarks and did some experiments with `-XX:CompileCommand=MemStat,StringConcat::concat,print`:
> 
> Baseline strategy:
> 13 args: 6.3M
> 23 args: 18M
> 123 args: 868M
> 
> `-Djava.lang.invoke.StringConcat.highArityThreshold=0`:
> 13 args: 2.11M
> 23 args: 3.67M
> 123 args: 4.75M
> 
> For 123 args the memory overhead of the baseline strategy is 180x, but for 23 args we're down to a 5x memory overhead, and down to a 3x overhead for 13 args. Since the absolute overhead for 23 is borderline acceptable (+15Mb) I've conservatively chosen a threshold at arity 20. This keeps C2 resource pressure at a reasonable level (< 18M) while avoiding perturbing performance at the vast majority of call sites.
> 
> I was asked to use the new class file API for mainline. There's a version of this patch implemented using ASM in 7c52a9f which might be a reasonable basis for a backport.

This pull request has now been integrated.

Changeset: c3372c45
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3372c455542cef2aaf673d1f14be8759bb98e8d
Stats:     253 lines in 2 files changed: 80 ins; 142 del; 31 mod

8331134: Port SimpleStringBuilderStrategy to use ClassFile API

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/18690

From redestad at openjdk.org  Sat Apr 27 12:16:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 27 Apr 2024 12:16:15 GMT
Subject: Integrated: 8331114: Further improve performance of
 MethodTypeDesc::descriptorString
In-Reply-To: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
References: <_GwdXoYvSv1KgG4h2bEtHLJAlC2aVOnkirgpymQ67dQ=.f908903a-9d36-4499-9469-76c08b22cc24@github.com>
Message-ID: <T09ObjyyHr4A4RuCBax9Yutc9acKz4sGF_LsOGMWRpE=.f78f8351-eef3-4c07-9826-52f4a828288d@github.com>

On Thu, 25 Apr 2024 09:41:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When analyzing (startup) performance of the Classfile API I found this opportunity to further improve `MethodTypeDescImpl::descriptorString`.
> 
> Performance improves across the board in existing microbenchmarks:
> 
> Name                                                                 (descString) Cnt   Base   Error    Test   Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 55,179 ? 2,027  32,920 ? 1,189 ns/op   1,68x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 17,689 ? 1,871  11,060 ? 0,331 ns/op   1,60x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 86,627 ? 1,646  41,035 ? 0,636 ns/op   2,11x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 18,305 ? 1,974  13,110 ? 0,089 ns/op   1,40x (p = 0,000*)
>   * = significant
> 
> 
> The improvement is even more pronounced when running with `-Xint`, which is relevant for reducing startup overheads of early ClassFile API use:
> 
> Name                                                                 (descString) Cnt     Base      Error      Test     Error  Unit  Change
> MethodTypeDescFactories.descriptorString  (Ljava/lang/Object;Ljava/lang/String;)I   6 5122,061 ?   81,335  2626,481 ? 101,466 ns/op   1,95x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                                      ()V   6 3481,316 ?  258,904  1489,267 ?  15,506 ns/op   2,34x (p = 0,000*)
> MethodTypeDescFactories.descriptorString ([IJLjava/lang/String;Z)Ljava/util/List;   6 7741,081 ? 1628,244  3281,778 ?  41,892 ns/op   2,36x (p = 0,000*)
> MethodTypeDescFactories.descriptorString                    ()[Ljava/lang/String;   6 3677,803 ?   63,432  1495,291 ?   8,995 ns/op   2,46x (p = 0,000*)
>   * = significant
>   ```
>   
>  I also applied similar approach to `MethodTypeDesc::displayDescriptor`: while not performance sensitive I think these are so inter-related that it makes sense to implement them in a similar fashion.

This pull request has now been integrated.

Changeset: a078b5e6
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a078b5e6117d2a99386fecd349eb0e0c11b74953
Stats:     34 lines in 5 files changed: 19 ins; 1 del; 14 mod

8331114: Further improve performance of MethodTypeDesc::descriptorString

Reviewed-by: mchung, liach

-------------

PR: https://git.openjdk.org/jdk/pull/18945

From liach at openjdk.org  Sat Apr 27 12:22:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 27 Apr 2024 12:22:11 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v18]
In-Reply-To: <zvjczviLhP8c0HYIlfd-3pFc_6i6wrmyU1Ii3W1vHGQ=.f069c247-8706-4893-a15c-a649adcc9ff7@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <Yw4kcTjZKxBKUDXIf0DFZLJ-ZA-axRJwUTv51jOnFic=.abb52ebf-e0a6-468d-aba5-11e123c172ed@github.com>
 <zvjczviLhP8c0HYIlfd-3pFc_6i6wrmyU1Ii3W1vHGQ=.f069c247-8706-4893-a15c-a649adcc9ff7@github.com>
Message-ID: <D74xhFxP2nbNmIbAGjCIfOmtQLMDwVfcMYrEMuYNaaA=.ec88f114-8085-481a-8a16-cf47dfccc53e@github.com>

On Sat, 27 Apr 2024 10:48:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Shaojin Wen 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 22 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into optim_dec_new
>>  - Merge remote-tracking branch 'upstream/master' into optim_dec_new
>>  - use while instead for
>>  - Update src/java.base/share/classes/java/math/BigDecimal.java
>>    
>>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>>  - bug fix for CharArraySequence#charAt
>>  - bug fix for CharArraySequence
>>  - fix benchmark
>>  - one CharArraySequence
>>  - restore comment
>>  - easier to compare
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/47953a00...bb620ba3
>
> In money-related scenarios, such as product prices, etc., BigDecimal needs to be used instead of float/double. I focus on optimizing the performance of BigDecimal's construction and toString scenarios.
> 
> Constructing BigDecimal usually includes two scenarios:
> * new BigDecimal(char[], int, int), Many libraries, such as mysql drveri/fastjson/jackson and other commonly used libraries use this function to construct BigDecimal
> * new BigDecimal(String), There are also many scenarios, such as data integration scenarios, scenarios where json is read from the message queue and then converted into target database row records, often using new BigDecimal(String)
> 
> I did a performance comparison test on Mac Book M1 Pro. The compared branches are:
> * [baseline](https://github.com/wenshao/jdk/tree/upstream_master_0312) https://github.com/wenshao/jdk/tree/upstream_master_0312
> * bb620ba  [Full](https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=17) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=16-17) ([bb620ba3](https://git.openjdk.org/jdk/pull/18177/files/bb620ba39a6f1ce17ff273bac54ebb709beb1667))
> 
> 
> # 1. new BigDecimal(String) benchmark
> Execute the following commands respectively 
> 
> make test TEST="micro:java.math.BigDecimals.testConstructorWithHugeString"
> make test TEST="micro:java.math.BigDecimals.testConstructorWithLargeString"
> make test TEST="micro:java.math.BigDecimals.testConstructorWithSmallString"
> make test TEST="micro:java.math.BigDecimals.testConstructorWithString"
> 
> 
> ## benchmark result
> 
> -Benchmark                                      Mode  Cnt    Score   Error  Units #baseline
> -BigDecimals.testConstructorWithHugeString      avgt   15  112.994 ? 2.342  ns/op
> -BigDecimals.testConstructorWithLargeString     avgt   15  114.016 ? 2.529  ns/op
> -BigDecimals.testConstructorWithSmallString     avgt   15   19.526 ? 0.078  ns/op
> -BigDecimals.testConstructorWithString          avgt   15   68.058 ? 0.836  ns/op
> 
> +Benchmark                                      Mode  Cnt    Score    Error  Units #bb620ba
> +BigDecimals.testConstructorWithHugeString      avgt   15   96.838 ?  8.743  ns/op +16.68%
> +BigDecimals.testConstructorWithLargeString     avgt   15   20.904 ?  0.112  ns/op +445.42%
> +BigDecimals.testConstructorWithSmallString     avgt   15   16.083 ?  0.042  ns/op +21.40%
> +BigDecimals.testConstructorWithString          avgt   15   35.912 ?  0.350  ns/op +85.91%
> 
> 
> It can be seen that there is a significant performance improvement in the new BigDecimal(Str...

@wenshao I think @jddarcy means to share performance improvement in client applications, like in fastjson reading of bigdecimal from JSON, by "interesting workload the change improves".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2080520496

From duke at openjdk.org  Sun Apr 28 01:48:19 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 28 Apr 2024 01:48:19 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <mSlPcUYk-K-xRecU1zHNYzBMZ3JpLSHpiPVUU5kTJs4=.8c9430e9-fa4d-4ffc-871d-37a55af33491@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
 <WJluiM0FQWMl1Qcd-vO1-1j19zPu7ZZqnzTwb5ylBEk=.7bd9f014-d4fc-451e-ad7c-8dab3969e5d2@github.com>
 <mSlPcUYk-K-xRecU1zHNYzBMZ3JpLSHpiPVUU5kTJs4=.8c9430e9-fa4d-4ffc-871d-37a55af33491@github.com>
Message-ID: <OtTt4o4uXACriqIO-grZOVlq9JggpJt3rLa5mCNHukk=.f2a3f492-761a-47b3-b3aa-1cec8315f48f@github.com>

On Fri, 26 Apr 2024 22:11:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Do we need additional tests or are these modifications already covered by the existing tests?
>
> @minborg I have added a test as part of Collection mother-of-all-tests to ensure spliterator and forEach yields in the same order as iterator for unmodifiable/immutable collections. One thing of note is that somehow `==` for yields fail for some collections like `unmodifiableSequencedMap(linkedHashSet).sequencedKeySet()` so I have to use `Objects.equals` instead.

@liach
> One thing of note is that somehow `==` for yields fail for some collections like `unmodifiableSequencedMap(linkedHashSet)?.sequencedKeySet()` so I have to use `Objects.equals` instead.

Actually, it?d?be for?`unmodifiableMap(?)?.entrySet()` and?`Map?.of(?)?.entrySet()`, as?those?create a?new?`UnmodifiableEntry` and?`KeyValueHolder` on?iteration?respectively.

`unmodifiableSequencedMap(?)?.sequencedKeySet()` should?work with?`==`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2081284896

From aph at openjdk.org  Sun Apr 28 11:37:09 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sun, 28 Apr 2024 11:37:09 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v12]
In-Reply-To: <OkxoClDmm5mt0sjlXiJga9em7uXiUfeZi836lRzVtOI=.dfc347ea-1e93-45a6-9fba-bd16fa6d6328@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
 <OkxoClDmm5mt0sjlXiJga9em7uXiUfeZi836lRzVtOI=.dfc347ea-1e93-45a6-9fba-bd16fa6d6328@github.com>
Message-ID: <l4CHSj0WG-KjUSxuv7GStCV10SasB0OouIvbm6p1fbk=.5de7d5b9-0a06-406c-b5ca-e7ce6f2e5b22@github.com>

On Tue, 23 Apr 2024 09:46:08 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> HI,
>> Can you have a look at this patch adding some tests for Math.round instrinsics?
>> Thanks!
>> 
>> ### FYI:
>> During the development of RoundVF/RoundF, we faced the issues which were only spotted by running test exhaustively against 32/64 bits range of int/long.
>> It's helpful to add these exhaustive tests in jdk for future possible usage, rather than build it everytime when needed.
>> Of course, we need to put it in `manual` mode, so it's not run when `-automatic` jtreg option is specified which I guess is the mode CI used, please correct me if I'm assume incorrectly.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add vectorized and scalar version Float tests checking full 32 bits range

test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java line 99:

> 97:     System.out.println("Verification");
> 98:     int errn = 0;
> 99:     for (long l = Integer.MIN_VALUE; l <= Integer.MAX_VALUE; l+=ARRLEN) {

Can't you just do the obvious simple thing here?

test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java line 102:

> 100:       for (int i = 0; i < ARRLEN; i++) {
> 101:         input[i] = (int)(l+i);
> 102:       }

What is this array for? As far as i can tell it does nothing useful to batch the test results.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1582089522
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1582089157

From darcy at openjdk.org  Sun Apr 28 22:58:14 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 28 Apr 2024 22:58:14 GMT
Subject: Integrated: 8331108: Unused Math.abs call in
 java.lang.FdLibm.Expm1#compute
In-Reply-To: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
References: <8upxxGd66oIZXnjCFF_bw9Z3feMu8ztZWiDsNQ32WcQ=.8962995c-12c1-4d5c-828d-d5edbdfaa372@github.com>
Message-ID: <thzC5L2sIvBKPOvFlX9nn_s9BPx3zBvRVcp1djxfAPk=.d9e0fdfc-47b4-478c-9285-4ba72fb107d5@github.com>

On Thu, 25 Apr 2024 21:32:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Remove unnecessary setting of variable y, found by an IDE inspection noted in the bug report.

This pull request has now been integrated.

Changeset: 4e5c25ee
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e5c25ee43d4ec31ed5160fd93a2fd15e35182f8
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8331108: Unused Math.abs call in java.lang.FdLibm.Expm1#compute

Reviewed-by: naoto, bpb, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/18963

From jlahoda at openjdk.org  Mon Apr 29 06:31:20 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Apr 2024 06:31:20 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v12]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <urTZyal7RpzvG7Y54dTff33e6vN7XzSuTUVgNmN3U-I=.50546221-7ed3-4b42-9bd1-b6f6268593fe@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - Merge branch 'master' into wthexp
 - Post-merge fixes.
 - Merge branch 'master' into wthexp
 - Reflecting review feedback:
   - reverting unnecessary changes in TransPatterns
   - moving the patters/withers/Model test to a more appropriate place
 - Adding tests as suggested.
 - Reflecting review feedback:
   - pre-generating the JCVarDecls in Attr, to aid Flow
   - adding a note on how the desugared code looks like
 - JavaCompiler cleanup
 - Improving the javax.lang.model for component local variables, by darcy.
 - Reflecting review feedback.
 - Merge branch 'master' into wthexp
 - ... and 26 more: https://git.openjdk.org/jdk/compare/4e5c25ee...c97eb8e6

-------------

Changes: https://git.openjdk.org/jdk/pull/18509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=11
  Stats: 2023 lines in 51 files changed: 1965 ins; 19 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

PR: https://git.openjdk.org/jdk/pull/18509

From asotona at openjdk.org  Mon Apr 29 07:15:10 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 29 Apr 2024 07:15:10 GMT
Subject: Integrated: 8330684: ClassFile API runs into StackOverflowError while
 parsing certain class' bytes
In-Reply-To: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com>
Message-ID: <UrPTHw_ZO6qC19PSY_Mawe1V0UpXskAeGarCS1K_w6U=.c6d309ba-46f8-4c96-b84e-9089574001ba@github.com>

On Tue, 23 Apr 2024 07:39:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API dives into the nested constant pool entries without type restrictions, while parsing a class file. Validation of the entry is performed post-parsing. Specifically corrupted constant pool entry may cause infinite loop during parsing and throws SOE.
> This patch resolves the issue by providing specific implementations for the nested CP entries parsing, instead of sharing the common (post-checking) code.
> Added test simulates the situation on inner-looped method reference entry.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: fb63cbad
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb63cbadb419f1de91acae9fc66be258e1d3d214
Stats:     32 lines in 2 files changed: 23 ins; 0 del; 9 mod

8330684: ClassFile API runs into StackOverflowError while parsing certain class' bytes

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/18907

From redestad at openjdk.org  Mon Apr 29 08:15:27 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 29 Apr 2024 08:15:27 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
Message-ID: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>

I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.

-------------

Commit messages:
 - Missed null-check on changeReturnType
 - Reduce java.lang.constant initialization overhead

Changes: https://git.openjdk.org/jdk/pull/18991/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18991&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331264
  Stats: 72 lines in 6 files changed: 7 ins; 5 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/18991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18991/head:pull/18991

PR: https://git.openjdk.org/jdk/pull/18991

From asotona at openjdk.org  Mon Apr 29 08:37:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 29 Apr 2024 08:37:36 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v8]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <91ATYlVthOIBZsTCU1D9F7hZlf92v2nWhqc7qp-0maA=.c05f5c17-7e05-44db-b0ea-5522a6b3881b@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> 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 14 commits:

 - Merge branch 'master' into JDK-8294960-invoke
 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
 - applied suggested changes
 - Merge branch 'master' into JDK-8294960-invoke
 - Reversion of ClassBuilder changes
 - Merge branch 'master' into JDK-8294960-invoke
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - added missing comment
 - fixed InnerClassLambdaMetafactory for hidden caller classes
 - ... and 4 more: https://git.openjdk.org/jdk/compare/766d0b0f...d5cbbc69

-------------

Changes: https://git.openjdk.org/jdk/pull/17108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=07
  Stats: 2094 lines in 9 files changed: 421 ins; 838 del; 835 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From duke at openjdk.org  Mon Apr 29 09:16:27 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 29 Apr 2024 09:16:27 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
Message-ID: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>

This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.

Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
- for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
- for constructors, the release in which the constructor with the given VM descriptor was introduced
- for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited

Effective since value of an API element is computed as follows:
- if the given element has a `@since` tag in its javadoc, it is used
- in all other cases, return the effective since value of the enclosing element

The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.

Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far

The intial comment at the beginning of `SinceChecker.java` holds more information into the program.

I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

-------------

Commit messages:
 - trivial change - extra parentheses
 - General improvements:
 - Add more details to the initial comment
 - remove unnecessary class - jtreg comment is enough to run the test
 - renamed files to give them more unique filenames - add more to the comment at the beginning of the file
 - first `@since` checker test of the JDK. For `java.base`

Changes: https://git.openjdk.org/jdk/pull/18934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331051
  Stats: 869 lines in 3 files changed: 867 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From jjg at openjdk.org  Mon Apr 29 09:16:30 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Apr 2024 09:16:30 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <uxWVocHQyxO3dccmeJEjYShE3B49Kynf6O5FTfxmZsE=.b585b19a-1216-44ca-b475-99f0003352e5@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Various comments inline.  Overall, a great start.
Consider adding more explanatory comments for the bigger items, like classes and long/important methods. Imagine a future-person looking over your shoulder, asking what the more important items do or are for.

test/jdk/tools/sincechecker/SinceChecker.java line 49:

> 47: import java.util.regex.Matcher;
> 48: import java.util.regex.Pattern;
> 49: import java.util.stream.Collectors;

The imports are somewhat unordered.   I recommend the follooing order

* `java.*` imports first, 
* then `javax.*` imports
* then `com.sun.*` imports
* and finally the `jtreg` import.

And, alphabetically sorted in each group.

test/jdk/tools/sincechecker/SinceChecker.java line 52:

> 50: 
> 51: /*
> 52: The `@since` checker works as a two-step process:

Insert an initial sentence or paragraph, such as the following:


This checker checks the values of the `@since` tag found in the documentation comment for an element
against the release in which the element first appeared.

The source code containing the documentation comments is read from `src.zip` in the release of
JDK used to run the test.  The releases used to determine the expected value of `@since` tags
are taken from the historical data built into `javac`.

test/jdk/tools/sincechecker/SinceChecker.java line 79:

> 77: - When an element is still marked as preview, the `@since` should be the first JDK release where the element was added.
> 78: - If the element is no longer marked as preview, the `@since` should be the first JDK release where it was no longer preview.
> 79: 

Add a comment about need for special treatment of early preview features.

test/jdk/tools/sincechecker/SinceChecker.java line 87:

> 85: public class SinceChecker {
> 86:     private final Map<String, Set<String>> LEGACY_PREVIEW_METHODS = new HashMap<>();
> 87:     private final Map<String, IntroducedIn> classDictionary = new HashMap<>();

See comment lower down about `class IntroducedIn`

test/jdk/tools/sincechecker/SinceChecker.java line 116:

> 114:     }
> 115: 
> 116:     private void processModuleRecord(ModuleElement moduleElement, String releaseVersion, JavacTask ct) {

for this method, and similarly named methods, the use of `Record` seems confusing, if only because there do not seem to be any record classes being processed or analyzed.   Consider dropping `Record` or changing it to `Element`. Same for `analyzePackageRecord`, `analyzeClassRecord`.

Also, consider being consistent with `process` or analyze`.

test/jdk/tools/sincechecker/SinceChecker.java line 135:

> 133:     private void analyzeClassRecord(TypeElement te, String version, Types types, Elements elements) {
> 134:         Set<Modifier> classModifiers = te.getModifiers();
> 135:         if (!(classModifiers.contains(Modifier.PUBLIC) || classModifiers.contains(Modifier.PROTECTED))) {

Insert comment:

/// JDK documentation only contains public and protected declarations

which is 99% true. (The serialization page can contain `private` declarations...)

test/jdk/tools/sincechecker/SinceChecker.java line 140:

> 138:         persistElement(te.getEnclosingElement(), te, types, version);
> 139:         elements.getAllMembers(te).stream()
> 140:                 .filter(element -> element.getModifiers().contains(Modifier.PUBLIC) || element.getModifiers().contains(Modifier.PROTECTED))

Consider writing and using a predicate method:


boolean isDocumented(Element e) {
    var mods = e.getModifiers();
    return mods.contains(Modifier,.PUBLIC) || mods.contains(Modifier.PROTECTED);
}


You could then use that method in the obvious way for the class declaration(line 134) and in a lambda as follows:

    .filter(this::isDocumented)

test/jdk/tools/sincechecker/SinceChecker.java line 143:

> 141:                 .filter(element -> element.getKind().isField()
> 142:                         || element.getKind() == ElementKind.METHOD
> 143:                         || element.getKind() == ElementKind.CONSTRUCTOR)

Consider writing and using another predicate method, 

    boolean isMember(Element e) {
        var k = e.getKind();
        return k.isField() || switch (k) {
            case CONSTRUCTOR, METHOD -> true;
            default -> false;
        };
     }

test/jdk/tools/sincechecker/SinceChecker.java line 178:

> 176:     }
> 177: 
> 178:     private void testThisModule(String moduleName) throws Exception {

The word `this` is a bit distracting/unnecessary here.  It's enough to say `testModule(String moduleName)` although `checkModule(String moduleName)` would be even better

test/jdk/tools/sincechecker/SinceChecker.java line 190:

> 188:         if (!f.exists() && !f.isDirectory()) {
> 189:             throw new SkippedException("Skipping Test because src.zip wasn't found");
> 190:         }

For modern/new code I would recommend using `java.nio.file.Path` instead of `java.io.File`.

I see you actually have a `Path` in `srcZip`, so use `Files.exists(srcZip)` and `Files.isDirectory(srcZip)`

test/jdk/tools/sincechecker/SinceChecker.java line 214:

> 212:                     }
> 213:                     if (!wrongTagsList.isEmpty()) {
> 214:                         throw new Exception(wrongTagsList.toString());

This looks like it might be the exception to end the test, right, and the wrongTags could be long.
I'd suggest writing a heading to `System.err`, then`wrongTagsList.forEach(System.err::println);` and then throw the exception with a summary string, like `throw new Exception(wrongTagsList.size() + " problems found");

test/jdk/tools/sincechecker/SinceChecker.java line 223:

> 221:     private void processModuleCheck(ModuleElement moduleElement, JavacTask ct, Path packagePath, EffectiveSourceSinceHelper javadocHelper) {
> 222:         if (moduleElement == null) {
> 223:             wrongTagsList.add("Module element: was null because `elements.getModuleElement(moduleName)` returns null." +

This doesn't look like a "Wrong tag" so much as a general error message.

Consider this as a different paradigm -- instead of saving up strings in `wrongTagsList`, consider having a method to report (and count) error messages as you find them:


    private int errorCount;
    void error(String message) {
        System.err.println(message);
        errorCount++;
   }


then at the end of `testThisModule`, just check if `errorCount>0` to decide whether to throw the exception.

Note, in this model, you need not have a `\n` at the end of every string argument, the way you do for add strings added into `wrongTagsList`.

test/jdk/tools/sincechecker/SinceChecker.java line 274:

> 272:             try {
> 273:                 byte[] packageAsBytes = Files.readAllBytes(pkgInfo);
> 274:                 String packageContent = new String(packageAsBytes, StandardCharsets.UTF_8);

Easier to just use `Files.readString`

test/jdk/tools/sincechecker/SinceChecker.java line 309:

> 307:                 .map(TypeElement.class::cast)
> 308:                 .forEach(nestedClass -> analyzeClassCheck(nestedClass, currentjdkVersion, javadocHelper, types, elementUtils));
> 309:     }

more possible applications of those utility predicate methods I mentioned earlier.

test/jdk/tools/sincechecker/SinceChecker.java line 330:

> 328:                     mappedVersion.introducedStable;
> 329:         } catch (Exception e) {
> 330:             wrongTagsList.add("For element " + element + "mappedVersion" + mappedVersion + " is null" + e + "\n");

Put a space e or colon between `is null` and `e`

test/jdk/tools/sincechecker/SinceChecker.java line 358:

> 356:     private void checkEquals(String sinceVersion, String mappedVersion, String id) {
> 357:         if (sinceVersion == null || mappedVersion == null) {
> 358:             wrongTagsList.add("For " + id + " NULL value for either mapped or real `@since` . mapped version is="

Here and elsewhere, instead of `"For " + name + ....`  consider using the format `name + ":  " + ...` for the format of the messages

test/jdk/tools/sincechecker/SinceChecker.java line 375:

> 373:         if (mappedVersion.equals("9")) {
> 374:             message = "For " + elementSimpleName +
> 375:                     " Wrong `@since` version " + sinceVersion + " But the element exists before JDK 10\n";

lower case "but"

test/jdk/tools/sincechecker/SinceChecker.java line 421:

> 419:         public String introducedPreview;
> 420:         public String introducedStable;
> 421:     }

Suggest move this nearer the map at the top of the class -- either move this class up, or those members down.

test/jdk/tools/sincechecker/SinceChecker.java line 423:

> 421:     }
> 422: 
> 423:     //these were preview in before the introduction of the @PreviewFeature

Just curious: where do you find this information?

test/jdk/tools/sincechecker/SinceChecker.java line 543:

> 541:     }
> 542: 
> 543:     private final class EffectiveSourceSinceHelper implements AutoCloseable {

Consider putting a doc comment describing the purpose of this class. The name  hints at something useful, but is not specific enough by itself.

test/jdk/tools/sincechecker/SinceChecker.java line 559:

> 557:                     fm.close();
> 558:                 } catch (IOException closeEx) {
> 559:                 }

Consider using `ex.addSuppressed(closeEx);` instead of just dropping the exception

test/jdk/tools/sincechecker/SinceChecker.java line 716:

> 714:         }
> 715: 
> 716:         private static final class PatchModuleFileManager

provide a short doc comment describing the purpose/use of this class

test/jdk/tools/sincechecker/testjavabase/SinceChecker.java line 37:

> 35: 
> 36: public class SinceChecker {
> 37: }

You don't need this class, do you?
The comment should be enough to run the validator

-------------

PR Review: https://git.openjdk.org/jdk/pull/18934#pullrequestreview-2025970944
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578567066
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578573782
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578579654
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578592510
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578583705
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578584959
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578587585
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578588555
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578601911
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578593616
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578597558
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578600689
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578604639
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578605090
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578605648
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1581605988
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1581605289
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578592255
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1581606328
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1581603329
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1581605077
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1581604207
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578057928

From duke at openjdk.org  Mon Apr 29 09:16:30 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 29 Apr 2024 09:16:30 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <uxWVocHQyxO3dccmeJEjYShE3B49Kynf6O5FTfxmZsE=.b585b19a-1216-44ca-b475-99f0003352e5@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <uxWVocHQyxO3dccmeJEjYShE3B49Kynf6O5FTfxmZsE=.b585b19a-1216-44ca-b475-99f0003352e5@github.com>
Message-ID: <SxTdtJ6ewPVZYUwE3cmRarSE8vn97r63etse-BMmhAo=.60802a2c-8545-4f07-a0a0-deaeb4175772@github.com>

On Wed, 24 Apr 2024 21:59:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> test/jdk/tools/sincechecker/SinceChecker.java line 49:
> 
>> 47: import java.util.regex.Matcher;
>> 48: import java.util.regex.Pattern;
>> 49: import java.util.stream.Collectors;
> 
> The imports are somewhat unordered.   I recommend the follooing order
> 
> * `java.*` imports first, 
> * then `javax.*` imports
> * then `com.sun.*` imports
> * and finally the `jtreg` import.
> 
> And, alphabetically sorted in each group.

Thanks, fixed in 32edb4d811978f87bd2f850c214191e8fc7b8c88

> test/jdk/tools/sincechecker/SinceChecker.java line 52:
> 
>> 50: 
>> 51: /*
>> 52: The `@since` checker works as a two-step process:
> 
> Insert an initial sentence or paragraph, such as the following:
> 
> 
> This checker checks the values of the `@since` tag found in the documentation comment for an element
> against the release in which the element first appeared.
> 
> The source code containing the documentation comments is read from `src.zip` in the release of
> JDK used to run the test.  The releases used to determine the expected value of `@since` tags
> are taken from the historical data built into `javac`.

Added in  32edb4d811978f87bd2f850c214191e8fc7b8c88

> test/jdk/tools/sincechecker/SinceChecker.java line 79:
> 
>> 77: - When an element is still marked as preview, the `@since` should be the first JDK release where the element was added.
>> 78: - If the element is no longer marked as preview, the `@since` should be the first JDK release where it was no longer preview.
>> 79: 
> 
> Add a comment about need for special treatment of early preview features.

Thanks, added it

> test/jdk/tools/sincechecker/SinceChecker.java line 116:
> 
>> 114:     }
>> 115: 
>> 116:     private void processModuleRecord(ModuleElement moduleElement, String releaseVersion, JavacTask ct) {
> 
> for this method, and similarly named methods, the use of `Record` seems confusing, if only because there do not seem to be any record classes being processed or analyzed.   Consider dropping `Record` or changing it to `Element`. Same for `analyzePackageRecord`, `analyzeClassRecord`.
> 
> Also, consider being consistent with `process` or analyze`.

Fixed in 32edb4d811978f87bd2f850c214191e8fc7b8c88

> test/jdk/tools/sincechecker/SinceChecker.java line 140:
> 
>> 138:         persistElement(te.getEnclosingElement(), te, types, version);
>> 139:         elements.getAllMembers(te).stream()
>> 140:                 .filter(element -> element.getModifiers().contains(Modifier.PUBLIC) || element.getModifiers().contains(Modifier.PROTECTED))
> 
> Consider writing and using a predicate method:
> 
> 
> boolean isDocumented(Element e) {
>     var mods = e.getModifiers();
>     return mods.contains(Modifier,.PUBLIC) || mods.contains(Modifier.PROTECTED);
> }
> 
> 
> You could then use that method in the obvious way for the class declaration(line 134) and in a lambda as follows:
> 
>     .filter(this::isDocumented)

Added in 32edb4d811978f87bd2f850c214191e8fc7b8c88

> test/jdk/tools/sincechecker/SinceChecker.java line 143:
> 
>> 141:                 .filter(element -> element.getKind().isField()
>> 142:                         || element.getKind() == ElementKind.METHOD
>> 143:                         || element.getKind() == ElementKind.CONSTRUCTOR)
> 
> Consider writing and using another predicate method, 
> 
>     boolean isMember(Element e) {
>         var k = e.getKind();
>         return k.isField() || switch (k) {
>             case CONSTRUCTOR, METHOD -> true;
>             default -> false;
>         };
>      }

Added in 32edb4d811978f87bd2f850c214191e8fc7b8c88

> test/jdk/tools/sincechecker/SinceChecker.java line 178:
> 
>> 176:     }
>> 177: 
>> 178:     private void testThisModule(String moduleName) throws Exception {
> 
> The word `this` is a bit distracting/unnecessary here.  It's enough to say `testModule(String moduleName)` although `checkModule(String moduleName)` would be even better

Thanks, renamed it to `CheckModule`

> test/jdk/tools/sincechecker/SinceChecker.java line 190:
> 
>> 188:         if (!f.exists() && !f.isDirectory()) {
>> 189:             throw new SkippedException("Skipping Test because src.zip wasn't found");
>> 190:         }
> 
> For modern/new code I would recommend using `java.nio.file.Path` instead of `java.io.File`.
> 
> I see you actually have a `Path` in `srcZip`, so use `Files.exists(srcZip)` and `Files.isDirectory(srcZip)`

Fixed in 32edb4d811978f87bd2f850c214191e8fc7b8c88

> test/jdk/tools/sincechecker/SinceChecker.java line 214:
> 
>> 212:                     }
>> 213:                     if (!wrongTagsList.isEmpty()) {
>> 214:                         throw new Exception(wrongTagsList.toString());
> 
> This looks like it might be the exception to end the test, right, and the wrongTags could be long.
> I'd suggest writing a heading to `System.err`, then`wrongTagsList.forEach(System.err::println);` and then throw the exception with a summary string, like `throw new Exception(wrongTagsList.size() + " problems found");

Done. Added in 32edb4d811978f87bd2f850c214191e8fc7b8c88

> test/jdk/tools/sincechecker/SinceChecker.java line 223:
> 
>> 221:     private void processModuleCheck(ModuleElement moduleElement, JavacTask ct, Path packagePath, EffectiveSourceSinceHelper javadocHelper) {
>> 222:         if (moduleElement == null) {
>> 223:             wrongTagsList.add("Module element: was null because `elements.getModuleElement(moduleName)` returns null." +
> 
> This doesn't look like a "Wrong tag" so much as a general error message.
> 
> Consider this as a different paradigm -- instead of saving up strings in `wrongTagsList`, consider having a method to report (and count) error messages as you find them:
> 
> 
>     private int errorCount;
>     void error(String message) {
>         System.err.println(message);
>         errorCount++;
>    }
> 
> 
> then at the end of `testThisModule`, just check if `errorCount>0` to decide whether to throw the exception.
> 
> Note, in this model, you need not have a `\n` at the end of every string argument, the way you do for add strings added into `wrongTagsList`.

Changed it and removed '\n'

> test/jdk/tools/sincechecker/SinceChecker.java line 274:
> 
>> 272:             try {
>> 273:                 byte[] packageAsBytes = Files.readAllBytes(pkgInfo);
>> 274:                 String packageContent = new String(packageAsBytes, StandardCharsets.UTF_8);
> 
> Easier to just use `Files.readString`

Fixed it, thanks

> test/jdk/tools/sincechecker/SinceChecker.java line 358:
> 
>> 356:     private void checkEquals(String sinceVersion, String mappedVersion, String id) {
>> 357:         if (sinceVersion == null || mappedVersion == null) {
>> 358:             wrongTagsList.add("For " + id + " NULL value for either mapped or real `@since` . mapped version is="
> 
> Here and elsewhere, instead of `"For " + name + ....`  consider using the format `name + ":  " + ...` for the format of the messages

Fixed it.

> test/jdk/tools/sincechecker/SinceChecker.java line 421:
> 
>> 419:         public String introducedPreview;
>> 420:         public String introducedStable;
>> 421:     }
> 
> Suggest move this nearer the map at the top of the class -- either move this class up, or those members down.

Thanks, moved it up

> test/jdk/tools/sincechecker/SinceChecker.java line 543:
> 
>> 541:     }
>> 542: 
>> 543:     private final class EffectiveSourceSinceHelper implements AutoCloseable {
> 
> Consider putting a doc comment describing the purpose of this class. The name  hints at something useful, but is not specific enough by itself.

Added it, thanks

> test/jdk/tools/sincechecker/SinceChecker.java line 559:
> 
>> 557:                     fm.close();
>> 558:                 } catch (IOException closeEx) {
>> 559:                 }
> 
> Consider using `ex.addSuppressed(closeEx);` instead of just dropping the exception

Fixed in 32edb4d811978f87bd2f850c214191e8fc7b8c88

> test/jdk/tools/sincechecker/SinceChecker.java line 716:
> 
>> 714:         }
>> 715: 
>> 716:         private static final class PatchModuleFileManager
> 
> provide a short doc comment describing the purpose/use of this class

Added it, thanks

> test/jdk/tools/sincechecker/testjavabase/SinceChecker.java line 37:
> 
>> 35: 
>> 36: public class SinceChecker {
>> 37: }
> 
> You don't need this class, do you?
> The comment should be enough to run the validator

Thanks, didn't know that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582576708
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582576954
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582577120
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582577505
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582578042
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582578390
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582585880
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582579802
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582580425
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582580782
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582582577
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582583030
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582578684
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582581513
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582581661
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582581840
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1578128902

From asotona at openjdk.org  Mon Apr 29 11:04:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 29 Apr 2024 11:04:22 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v9]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <gsVcmi22sTwQcpWCv4gaq39YCexq1RVQ1M3KofxU2xk=.bce8ef80-8df0-4c77-95d7-611d1a1e239a@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Deferred initialization of attributes map by moving into a holder class
  
  Co-authored-by: Claes Redestad <redestad at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/d5cbbc69..803c804d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=07-08

  Stats: 10 lines in 1 file changed: 2 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From duke at openjdk.org  Mon Apr 29 11:34:07 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 29 Apr 2024 11:34:07 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <uxWVocHQyxO3dccmeJEjYShE3B49Kynf6O5FTfxmZsE=.b585b19a-1216-44ca-b475-99f0003352e5@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <uxWVocHQyxO3dccmeJEjYShE3B49Kynf6O5FTfxmZsE=.b585b19a-1216-44ca-b475-99f0003352e5@github.com>
Message-ID: <_7Mrae5rQivsrCMCNaFkhYaa57PJtD3uy6IN5tP0EDA=.7d8d0679-a88f-4442-af4d-1df39aa59976@github.com>

On Fri, 26 Apr 2024 23:24:19 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> test/jdk/tools/sincechecker/SinceChecker.java line 423:
> 
>> 421:     }
>> 422: 
>> 423:     //these were preview in before the introduction of the @PreviewFeature
> 
> Just curious: where do you find this information?

Used a script to get all the elements with `@Deprecated(forRemoval=true, since=...)`, `@jdk.internal.preview`, `{@preview Associated with ....` in their javadoc.
And then had to cross reference with a document that had all the ids

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1582899131

From mli at openjdk.org  Mon Apr 29 11:38:27 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 29 Apr 2024 11:38:27 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v13]
In-Reply-To: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
Message-ID: <yTfpBfWBMtjLm8BNvtocgxlBhgAKEVzpblP5OkyuTAM=.559b4718-ce15-4162-9f34-feda1d4a6398@github.com>

> HI,
> Can you have a look at this patch adding some tests for Math.round instrinsics?
> Thanks!
> 
> ### FYI:
> During the development of RoundVF/RoundF, we faced the issues which were only spotted by running test exhaustively against 32/64 bits range of int/long.
> It's helpful to add these exhaustive tests in jdk for future possible usage, rather than build it everytime when needed.
> Of course, we need to put it in `manual` mode, so it's not run when `-automatic` jtreg option is specified which I guess is the mode CI used, please correct me if I'm assume incorrectly.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  fix issues; modify vm options to make sure test the expected behaviors.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17753/files
  - new: https://git.openjdk.org/jdk/pull/17753/files/02d7600f..b5207436

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17753&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17753&range=11-12

  Stats: 12 lines in 2 files changed: 0 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17753/head:pull/17753

PR: https://git.openjdk.org/jdk/pull/17753

From mli at openjdk.org  Mon Apr 29 11:38:27 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 29 Apr 2024 11:38:27 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v12]
In-Reply-To: <l4CHSj0WG-KjUSxuv7GStCV10SasB0OouIvbm6p1fbk=.5de7d5b9-0a06-406c-b5ca-e7ce6f2e5b22@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
 <OkxoClDmm5mt0sjlXiJga9em7uXiUfeZi836lRzVtOI=.dfc347ea-1e93-45a6-9fba-bd16fa6d6328@github.com>
 <l4CHSj0WG-KjUSxuv7GStCV10SasB0OouIvbm6p1fbk=.5de7d5b9-0a06-406c-b5ca-e7ce6f2e5b22@github.com>
Message-ID: <cISsnY8u0iaZxnslp8XcLBWYsI_MYJeCIZF_zdVWJto=.8e744ca1-62ba-4143-9b5f-f5ee4a3e4fc1@github.com>

On Sun, 28 Apr 2024 11:34:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add vectorized and scalar version Float tests checking full 32 bits range
>
> test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java line 99:
> 
>> 97:     System.out.println("Verification");
>> 98:     int errn = 0;
>> 99:     for (long l = Integer.MIN_VALUE; l <= Integer.MAX_VALUE; l+=ARRLEN) {
> 
> Can't you just do the obvious simple thing here?

Not sure if I understand you correctly.
Do you mean just use a while loop? seems it will only test the scalar version in that way.

> test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java line 102:
> 
>> 100:       for (int i = 0; i < ARRLEN; i++) {
>> 101:         input[i] = (int)(l+i);
>> 102:       }
> 
> What is this array for? As far as i can tell it does nothing useful to batch the test results.

Sorry, it's bug.

Also fixed some other issues, e.g. in fact previously the newly added tests are not run, they still triggered TestRoundVectorFloatRandom.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1582907258
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1582907013

From jlahoda at openjdk.org  Mon Apr 29 11:49:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Apr 2024 11:49:30 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected
Message-ID: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>

Consider code like:

public class ConsoleTest {
    public static void main(String... args) {
        System.console().printf("Hello!");
    }
}


When run as:

$ java ConsoleTest.java >/dev/null


it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).

The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.

The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.

-------------

Commit messages:
 - Fixing test.
 - Attempting to stabilize the test.
 - Improving test to really test the redirect while stdin is connected to a terminal.
 - Fixing typo.
 - 8330998: System.console() writes to stderr when stdout is redirected

Changes: https://git.openjdk.org/jdk/pull/18996/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330998
  Stats: 212 lines in 3 files changed: 209 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18996/head:pull/18996

PR: https://git.openjdk.org/jdk/pull/18996

From jlahoda at openjdk.org  Mon Apr 29 12:05:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Apr 2024 12:05:18 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v17]
In-Reply-To: <oMvlrJa4zDX0GQ9Yl6DgAJbBZjcPjNnK0Via091o0iM=.edf1a4e2-8764-4c2e-8743-346ce1152bd4@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <oMvlrJa4zDX0GQ9Yl6DgAJbBZjcPjNnK0Via091o0iM=.edf1a4e2-8764-4c2e-8743-346ce1152bd4@github.com>
Message-ID: <XLpzsDRFGmdbjq-qPlrEKMTOpEufRyQXrh9ukxXl3HU=.fbae82a9-0ec0-439b-9cd5-2c0458e99070@github.com>

On Fri, 26 Apr 2024 23:54:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code refactoring

Makes sense to me. Moving the variable declarations to the else section may improve the code as suggest by @liach. Getting a review from somebody knowledgeable about the reflection might be good.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17070#pullrequestreview-2028320315

From redestad at openjdk.org  Mon Apr 29 12:14:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 29 Apr 2024 12:14:17 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v2]
In-Reply-To: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
Message-ID: <3DfNvrQirA4qYLtHVa64kXhT_Xn0MtVBh5g3fNFCMhE=.a3f866bd-17b7-4c11-9026-c83d1245cde9@github.com>

> I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Descriptors can't be empty, optimize isArray and isClassOrInterface with descriptorString().charAt(0) ==

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18991/files
  - new: https://git.openjdk.org/jdk/pull/18991/files/c27d5ff8..7e7386e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18991&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18991&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18991/head:pull/18991

PR: https://git.openjdk.org/jdk/pull/18991

From liach at openjdk.org  Mon Apr 29 12:21:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 29 Apr 2024 12:21:12 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v2]
In-Reply-To: <3DfNvrQirA4qYLtHVa64kXhT_Xn0MtVBh5g3fNFCMhE=.a3f866bd-17b7-4c11-9026-c83d1245cde9@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <3DfNvrQirA4qYLtHVa64kXhT_Xn0MtVBh5g3fNFCMhE=.a3f866bd-17b7-4c11-9026-c83d1245cde9@github.com>
Message-ID: <7zIJ8_2VdsPUEmUZV9W-OcoQN9kOPz2o2UmPTpn_PBo=.b1f795af-9f03-4012-bb86-19e1659ef744@github.com>

On Mon, 29 Apr 2024 12:14:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Descriptors can't be empty, optimize isArray and isClassOrInterface with descriptorString().charAt(0) ==

src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 74:

> 72: 
> 73:         for (ClassDesc cd : trustedArgTypes)
> 74:             if (cd.descriptorString().equals("V")) // implicit null check

Just curious, is `equals` faster than `charAt(0) ==` for single-char strings?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18991#discussion_r1582998433

From redestad at openjdk.org  Mon Apr 29 12:27:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 29 Apr 2024 12:27:17 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v2]
In-Reply-To: <7zIJ8_2VdsPUEmUZV9W-OcoQN9kOPz2o2UmPTpn_PBo=.b1f795af-9f03-4012-bb86-19e1659ef744@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <3DfNvrQirA4qYLtHVa64kXhT_Xn0MtVBh5g3fNFCMhE=.a3f866bd-17b7-4c11-9026-c83d1245cde9@github.com>
 <7zIJ8_2VdsPUEmUZV9W-OcoQN9kOPz2o2UmPTpn_PBo=.b1f795af-9f03-4012-bb86-19e1659ef744@github.com>
Message-ID: <tFhiydyheg_qT7U5sVeYLiSeUsp1jc4XMogsnxRegcc=.22423627-8e4d-4cdb-971f-4737d71ef8ba@github.com>

On Mon, 29 Apr 2024 12:18:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Descriptors can't be empty, optimize isArray and isClassOrInterface with descriptorString().charAt(0) ==
>
> src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 74:
> 
>> 72: 
>> 73:         for (ClassDesc cd : trustedArgTypes)
>> 74:             if (cd.descriptorString().equals("V")) // implicit null check
> 
> Just curious, is `equals` faster than `charAt(0) ==` for single-char strings?

I've not benchmarked this detail in JMH, only verified it does less work when interpreted. We could probably just drop `cd.isPrimitive() &&`, though, since a descriptor of length > 1 starting with `V` can't be created.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18991#discussion_r1583007082

From redestad at openjdk.org  Mon Apr 29 12:39:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 29 Apr 2024 12:39:17 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v3]
In-Reply-To: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
Message-ID: <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>

> I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Simplified void check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18991/files
  - new: https://git.openjdk.org/jdk/pull/18991/files/7e7386e1..40874ef1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18991&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18991&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18991/head:pull/18991

PR: https://git.openjdk.org/jdk/pull/18991

From liach at openjdk.org  Mon Apr 29 13:00:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 29 Apr 2024 13:00:06 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v3]
In-Reply-To: <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
Message-ID: <O4pSTCmtHQ27mZbShK6jaGyTAjGBZ6V93Dr6EN2hvxw=.04ee4e06-d954-4d33-8321-e00288c45a6c@github.com>

On Mon, 29 Apr 2024 12:39:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified void check

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18991#pullrequestreview-2028436359

From duke at openjdk.org  Mon Apr 29 13:26:08 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 29 Apr 2024 13:26:08 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <7-WZgG_hU3f6D54H_mjzaGKwyxs_R0a0zF_LVonbjOs=.6f2b3b1a-35bf-4151-80ae-d76c8b2925a4@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <vudrAiU0bDuHOJxeXOhPTr6cGZzajM_xwkCqmmizFsU=.ad583459-b9c3-4162-a8e1-d1771dc446a9@github.com>
 <7-WZgG_hU3f6D54H_mjzaGKwyxs_R0a0zF_LVonbjOs=.6f2b3b1a-35bf-4151-80ae-d76c8b2925a4@github.com>
Message-ID: <1juNagMTuuP9Jbqcxo6ejfR_dF22NzVvx7udxBv-A54=.faff46d2-9d7a-4cf3-a004-e3416772633e@github.com>

On Wed, 3 Apr 2024 07:13:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 1415:
>> 
>>> 1413:                                                      canonicalConstructorTypes,
>>> 1414:                                                      List.nil());
>>> 1415:         createNew.constructor = init;
>> 
>> Maybe?instead of?hardcoding the?constructor that?is?canonical at?compile?time (in?case new?components get?added), it?might be?better to?go?through some?sort of?`indy`?callsite?like (at?least when?not in?the?same compilation?unit):
>> 
>> DynamicCallSiteDesc[java.lang.runtime.RecordSupport::derivedConstructor(modified component names...):(T extends Record, Class<?>... /*?modified component types?*/)T]
>> 
>> 
>> with?the `derivedConstructor` bootstrap?method:
>> 
>> public static MethodHandle derivedConstructor(MethodHandles.Lookup lookup, String unused, MethodType type, String... modifiedComponents) throws ReflectiveOperationException {
>> 	requireNonNull(lookup);
>> 	requireNonNull(type);
>> 	// implicit null-check:
>> 	List<String> modifiedComponentNames = List.of(modifiedComponents);
>> 
>> 	Class<?> rtype = type.returnType();
>> 	if (
>> 		!rtype.isRecord()
>> 		|| type.parameterCount() != modifiedComponents.length + 1
>> 		|| type.parameterType(0) != rtype
>> 	) {
>> 		throw new IllegalArgumentException("...");
>> 	}
>> 
>> 	Set<String> remainingComponentNames = new HashSet(modifiedComponentNames);
>> 	if (remainingComponentNames.size() != modifiedComponentNames.size()) {
>> 		throw new IllegalArgumentException("Duplicate component names in modifiedComponents");
>> 	}
>> 
>> 	RecordComponent[] recordComponents = rtype.getRecordComponents();
>> 
>> 	var componentTypes = new Class<?>[recordComponents.length];
>> 	var filters = new MethodHandle[recordComponents.length];
>> 	var reorder = new int[recordComponents.length];
>> 
>> 	for (int i = 0, j = 1; i < recordComponents.length; i++) {
>> 		var component = recordComponents[i];
>> 		componentTypes[i] = component.getType();
>> 
>> 		var getter = lookup.findVirtual(rtype, component.getName(), MethodType.methodType(component.getType()));
>> 		if (modifiedComponentNames.contains(component.getName())) {
>> 			remainingComponentNames.remove(component.getName());
>> 			filters[i] = null;
>> 			reorder[i] = j++;
>> 		} else {
>> 			filters[i] = getter;
>> 			reorder[i] = 0;
>> 		}
>> 	}
>> 
>> 	if (!remainingComponentNames.isEmpty()) {
>> 		throw new IllegalArgumentException("Components " + remainingComponentNames + " are not present in the record " + rtype);...
>
> While this is very smart, I would prefer not to do that. JLS 13.4.27 talks about binary compatibility for record, and warns that adding or removing components may break record usages. So I don't think we need to provide too much support for adding or removing record components.
> 
> Overall, I believe the current code adheres to what the JLS draft says. If the author of the record wants to add or remove components, they can make it so that the existing compiled code still works (by adding constructor overloads and keeping the accessors for removed component). It is better, IMO, to keep the behavior predictable, and leave adjustments after record component modifications up to the record author, than to introduce some magic.

This?was once?again asked?about on?amber?dev:
- https://mail.openjdk.org/pipermail/amber-dev/2024-April/008748.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1583084422

From asotona at openjdk.org  Mon Apr 29 13:43:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 29 Apr 2024 13:43:24 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v10]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <ArskuPlDIf1OZ3dnm4WAntcvTcxd07uQX3iT2fKeFPM=.5a5317fb-c0bb-491e-af01-272b6ecb364b@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - Merge pull request #3 from cl4es/minor_init_improvements
   
   Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
 - Remove stray MRE_LF_interpretWithArguments
 - Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/803c804d..75d4a09f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=08-09

  Stats: 40 lines in 2 files changed: 2 ins; 13 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From pminborg at openjdk.org  Mon Apr 29 14:20:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 29 Apr 2024 14:20:04 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v3]
In-Reply-To: <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
Message-ID: <ENpnFYI0ATOcxk-F-Ay-eII2l8JIvANBBLAUfByiaPs=.4240119f-2a5a-4160-a8dc-b3fda707efee@github.com>

On Mon, 29 Apr 2024 12:39:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified void check

src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 178:

> 176: 
> 177:     private static final ClassDesc[] INDY_BOOTSTRAP_ARGS = {
> 178:             CD_MethodHandles_Lookup,

Can these fields be @Stable?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18991#discussion_r1583168392

From redestad at openjdk.org  Mon Apr 29 14:25:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 29 Apr 2024 14:25:06 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v3]
In-Reply-To: <ENpnFYI0ATOcxk-F-Ay-eII2l8JIvANBBLAUfByiaPs=.4240119f-2a5a-4160-a8dc-b3fda707efee@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
 <ENpnFYI0ATOcxk-F-Ay-eII2l8JIvANBBLAUfByiaPs=.4240119f-2a5a-4160-a8dc-b3fda707efee@github.com>
Message-ID: <zoBsyV05I6aeQw0azMc6ZauJFvC2BZU63mS8DMSgl_U=.6f5237c5-9eea-41bf-b6d4-b9e53a519ec8@github.com>

On Mon, 29 Apr 2024 14:16:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified void check
>
> src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 178:
> 
>> 176: 
>> 177:     private static final ClassDesc[] INDY_BOOTSTRAP_ARGS = {
>> 178:             CD_MethodHandles_Lookup,
> 
> Can these fields be @Stable?

I don't think it'd hurt, but I would be surprised if any of these would be hot enough to see a benefit from that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18991#discussion_r1583177539

From asotona at openjdk.org  Mon Apr 29 14:39:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 29 Apr 2024 14:39:22 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v11]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <AB21eqNtwvgaCstkAtrTEpXV5sHQejGdSD-a5cWpls0=.7ff2e768-cfb1-4c0b-b72c-7468967f4b0b@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #4 from cl4es/boxunbox_holder
   
   Only create box/unbox MethodRefEntries on request
 - Only create box/unbox MethodRefEntries on request

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/75d4a09f..1099de72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=09-10

  Stats: 42 lines in 1 file changed: 2 ins; 0 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From jkern at openjdk.org  Mon Apr 29 14:50:13 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 29 Apr 2024 14:50:13 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131
Message-ID: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>

Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :

 stdout: [];
 stderr: [Error: could not find libjava.so
Error: Could not find Java SE Runtime Environment.
]
 exitValue = 2

java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
at JliLaunchTest.main(JliLaunchTest.java:58)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
at java.base/java.lang.Thread.run(Thread.java:1575)

Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .

Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.

-------------

Commit messages:
 - JDK-8329653

Changes: https://git.openjdk.org/jdk/pull/19000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19000&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329653
  Stats: 56 lines in 3 files changed: 56 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19000/head:pull/19000

PR: https://git.openjdk.org/jdk/pull/19000

From jlahoda at openjdk.org  Mon Apr 29 14:56:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Apr 2024 14:56:23 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
Message-ID: <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>

> Consider code like:
> 
> public class ConsoleTest {
>     public static void main(String... args) {
>         System.console().printf("Hello!");
>     }
> }
> 
> 
> When run as:
> 
> $ java ConsoleTest.java >/dev/null
> 
> 
> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
> 
> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
> 
> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.

Jan Lahoda 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 JDK-8330998
 - Fixing test.
 - Attempting to stabilize the test.
 - Improving test to really test the redirect while stdin is connected to a terminal.
 - Fixing typo.
 - 8330998: System.console() writes to stderr when stdout is redirected

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18996/files
  - new: https://git.openjdk.org/jdk/pull/18996/files/9090e4c7..8a918e3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18996&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18996&range=00-01

  Stats: 22740 lines in 1516 files changed: 8365 ins; 10464 del; 3911 mod
  Patch: https://git.openjdk.org/jdk/pull/18996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18996/head:pull/18996

PR: https://git.openjdk.org/jdk/pull/18996

From liach at openjdk.org  Mon Apr 29 15:06:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 29 Apr 2024 15:06:05 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v3]
In-Reply-To: <zoBsyV05I6aeQw0azMc6ZauJFvC2BZU63mS8DMSgl_U=.6f5237c5-9eea-41bf-b6d4-b9e53a519ec8@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
 <ENpnFYI0ATOcxk-F-Ay-eII2l8JIvANBBLAUfByiaPs=.4240119f-2a5a-4160-a8dc-b3fda707efee@github.com>
 <zoBsyV05I6aeQw0azMc6ZauJFvC2BZU63mS8DMSgl_U=.6f5237c5-9eea-41bf-b6d4-b9e53a519ec8@github.com>
Message-ID: <tJl1z3fUsZOZtDl0lj4xCoxOToC1Du0nE1Nhgu3R-VQ=.e49e7365-3c7e-4938-8e7f-c3e5be607a0f@github.com>

On Mon, 29 Apr 2024 14:22:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 178:
>> 
>>> 176: 
>>> 177:     private static final ClassDesc[] INDY_BOOTSTRAP_ARGS = {
>>> 178:             CD_MethodHandles_Lookup,
>> 
>> Can these fields be @Stable?
>
> I don't think it'd hurt, but I would be surprised if any of these would be hot enough to see a benefit from that.

I don't think this really helps; the array elements are not used directly via field reference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18991#discussion_r1583240333

From alanb at openjdk.org  Mon Apr 29 16:00:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Apr 2024 16:00:05 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131
In-Reply-To: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
Message-ID: <ncCMr8yhkJNWyB5mz9I9TgvWk5rrGOpLmwFfFei7w_0=.d726adf0-6570-4c5a-bef4-9fafe23cf0b7@github.com>

On Mon, 29 Apr 2024 14:45:07 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
> 
>  stdout: [];
>  stderr: [Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
> ]
>  exitValue = 2
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
> at JliLaunchTest.main(JliLaunchTest.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
> 
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.

This looks like it's adding code to search LD_LIBRARY_PATH on Linux/macOS too, did you mean to do that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19000#issuecomment-2083102447

From darcy at openjdk.org  Mon Apr 29 16:51:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 29 Apr 2024 16:51:05 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <QoVK_Zx-c2T-UXZpiMc6a2opdh74yUxQkYfTNG_UIeU=.23cefb45-96b7-444e-abeb-7a935c029506@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

If not already planned, I recommend a much broader discussion/announcement of this test before it goes back. For example, a message to jdk-dev stating "The value of `@since` tags will be tested now by a tier $N test. This is how you run the test before a push. Here are rules for some tricky cases like introducing a covariant override." etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2083205402

From vromero at openjdk.org  Mon Apr 29 17:00:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 29 Apr 2024 17:00:26 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v18]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <S5OIWDa2NI0sn6Yz9W9RAdXkVn7GzGGb4UIOL87eUps=.eeb6c5e7-a79e-4987-bf2d-c006672c1141@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero 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 18 additional commits since the last revision:

 - Merge branch 'master' into JDK-8320575
 - code refactoring
 - additional tests
 - special case the new code for records only
 - adding more tests
 - Update test/jdk/java/lang/reflect/records/RecordReflectionTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - making the javadoc less general
 - Merge branch 'master' into JDK-8320575
 - adding comment to jcod file
 - adding a comment to the test
 - ... and 8 more: https://git.openjdk.org/jdk/compare/24a987e7...0237d72c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/775599cc..0237d72c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=16-17

  Stats: 24018 lines in 1560 files changed: 8871 ins; 10734 del; 4413 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Mon Apr 29 17:00:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 29 Apr 2024 17:00:26 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v17]
In-Reply-To: <fwjw2OjiKOWy3SdIjPvZggP9xpzb9FHhZTcsRN1KFOs=.d8e1d805-bddc-4116-a2b6-a2b975388433@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <oMvlrJa4zDX0GQ9Yl6DgAJbBZjcPjNnK0Via091o0iM=.edf1a4e2-8764-4c2e-8743-346ce1152bd4@github.com>
 <fwjw2OjiKOWy3SdIjPvZggP9xpzb9FHhZTcsRN1KFOs=.d8e1d805-bddc-4116-a2b6-a2b975388433@github.com>
Message-ID: <TQkNqEEjQTT2kVIv37j8AHEAM3I9gosdtL0YBn1jBqE=.0f81685c-e287-465d-9665-c422726cc9aa@github.com>

On Sat, 27 Apr 2024 00:14:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code refactoring
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 348:
> 
>> 346:                 final Type[] out = new Type[nonGenericParamTypes.length];
>> 347:                 final Parameter[] params = getParameters();
>> 348:                 if (getDeclaringClass().isRecord() && this instanceof Constructor) {
> 
> Sorry for late notice but we can move the 2 variable allocation to the else block, to speed up the record constructor path.

yep true, will do

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1583416245

From duke at openjdk.org  Mon Apr 29 17:12:16 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 29 Apr 2024 17:12:16 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v4]
In-Reply-To: <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
Message-ID: <7xReXBRnWqualihyWkuZ4cp2Wnq9YwZb0eHJUAKCdGU=.59605e73-d601-418f-9dd5-d5a6656c7a75@github.com>

On Thu, 18 Apr 2024 05:54:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>> 
>> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
>> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

This doesn?t fix the case where the lambda is created from an instance method, e.g.:


import java.util.function.Supplier;

public class HiddenLambda implements HiddenTest {
	public String test() {
		Supplier<String> s = this::toString;
		return s.get();
	}

	public String toString() {
		return getClass().getName();
	}
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18810#issuecomment-2083240740

From asotona at openjdk.org  Mon Apr 29 17:20:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 29 Apr 2024 17:20:09 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v4]
In-Reply-To: <7xReXBRnWqualihyWkuZ4cp2Wnq9YwZb0eHJUAKCdGU=.59605e73-d601-418f-9dd5-d5a6656c7a75@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
 <7xReXBRnWqualihyWkuZ4cp2Wnq9YwZb0eHJUAKCdGU=.59605e73-d601-418f-9dd5-d5a6656c7a75@github.com>
Message-ID: <kaMHwea9YBn303X48eej_mW1Ixf8ttttHtK2HqPKjfo=.d6f02fdd-5d6a-4beb-a93f-9e450b405428@github.com>

On Mon, 29 Apr 2024 17:09:24 GMT, ExE Boss <duke at openjdk.org> wrote:

> This doesn?t fix the case where the lambda is created from an instance method, e.g.:
> 

Yes, unfortunately the fix is limited to invokeStatic (see the comments above).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18810#issuecomment-2083253380

From liach at openjdk.org  Mon Apr 29 17:23:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 29 Apr 2024 17:23:13 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v4]
In-Reply-To: <7xReXBRnWqualihyWkuZ4cp2Wnq9YwZb0eHJUAKCdGU=.59605e73-d601-418f-9dd5-d5a6656c7a75@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
 <7xReXBRnWqualihyWkuZ4cp2Wnq9YwZb0eHJUAKCdGU=.59605e73-d601-418f-9dd5-d5a6656c7a75@github.com>
Message-ID: <rkX6OowT0_dBZfoBniB59YN23PMyGvOkhiEnyK4pc_w=.0e55a4c1-fee3-4d9f-9f5a-8734df9bc22b@github.com>

On Mon, 29 Apr 2024 17:09:24 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>>   
>>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>
> This doesn?t fix the case where the lambda is created from an instance method, e.g.:
> 
> 
> import java.util.function.Supplier;
> 
> public class HiddenLambda implements HiddenTest {
> 	public String test() {
> 		Supplier<String> s = this::toString;
> 		return s.get();
> 	}
> 
> 	public String toString() {
> 		return getClass().getName();
> 	}
> }

@ExE-Boss This patch intentionally does not support the said case. Reason being that an instance method will require a hidden class receiver, yet this receiver cannot be represented as part of a method type from the constant pool; so even if you grab the MH from condy, you still cannot `invokeExact` in bytecode, but have to perform an `asType` conversion first (or just use plain `invoke`)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18810#issuecomment-2083259410

From mchung at openjdk.org  Mon Apr 29 17:48:07 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 29 Apr 2024 17:48:07 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v3]
In-Reply-To: <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
Message-ID: <D2mzG35oPKs9HheE9MfVSmfXNQ-EsNQkJYSnLBkZSPI=.24b66026-a66d-4c50-95d3-d35dad7579d0@github.com>

On Mon, 29 Apr 2024 12:39:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified void check

The changes look good to me but I wonder if the non-zero length check before calling `arraycopy` really needed?  That seems to add some noise to the code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18991#pullrequestreview-2029162828

From darcy at openjdk.org  Mon Apr 29 17:49:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 29 Apr 2024 17:49:13 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.5a6217f6-86e2-4eba-ac48-647b19052cda@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
 <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.5a6217f6-86e2-4eba-ac48-647b19052cda@github.com>
Message-ID: <i6esXfmg7Qx3-KZZgjmszE9ZFHd5-qmZeCZW-YAlef8=.fae9238b-100f-43ca-9cf2-9c1f9ea851a0@github.com>

On Tue, 23 Apr 2024 07:03:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are further updates to this test in the pipeline (new deprecated flags in 23) so you will need to keep updating to reflect that.

Thanks @dholmes-ora ; acknowledged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1583479535

From bpb at openjdk.org  Mon Apr 29 17:57:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 29 Apr 2024 17:57:12 GMT
Subject: Integrated: 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins
 carrier
In-Reply-To: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
References: <veTN9NSobeknV1T4e2aiXbOG3cHpoJBemifm1XnWkNs=.4acafad4-88ff-473b-9aea-29efcfaa8a94@github.com>
Message-ID: <7RAC0VwZ0k1nOFdFrETMSlQM2gexwl7Y7wx8MQFicms=.25e385f0-33d0-4481-9842-c77dbd9966de@github.com>

On Mon, 22 Apr 2024 19:07:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Prevent blocking due to a carrier thread not being released when `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.

This pull request has now been integrated.

Changeset: 819f3d6f
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/819f3d6fc70ff6fe54ac5f9033c17c3dd4326aa5
Stats:     142 lines in 2 files changed: 139 ins; 0 del; 3 mod

8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/18901

From mchung at openjdk.org  Mon Apr 29 18:07:12 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 29 Apr 2024 18:07:12 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v4]
In-Reply-To: <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
Message-ID: <rRYG5radsy5yBjSjlp8OWvBc5bcCqTRxHJ1cype7SMI=.1eb30d58-652a-434a-be92-90f358ec3d33@github.com>

On Thu, 18 Apr 2024 05:54:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>> 
>> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
>> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

`this::toString` references the hidden class by name [1] which fails to be resolved.   The code needs to ensure that hidden class's name is not referenced for example by casting to a supertype whose is a normal class:


        HiddenTest o = this;
        Supplier<String> s = o::toString;


[1] https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/Class.html#hiddenClasses

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18810#issuecomment-2083336824

From liach at openjdk.org  Mon Apr 29 18:07:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 29 Apr 2024 18:07:12 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v4]
In-Reply-To: <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
Message-ID: <A3kA3YNsSyf6lRSsVjxXcbpX8SC_29LUozXdB-nYUiY=.e6d9578d-996b-46f8-a30e-7f1aa19e0688@github.com>

On Thu, 18 Apr 2024 05:54:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>> 
>> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
>> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

The code snippet probably doesn't work here assuming `HiddenTest` is the Hidden class itself, you might have meant `Object o = this;`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18810#issuecomment-2083342710

From mchung at openjdk.org  Mon Apr 29 18:12:10 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 29 Apr 2024 18:12:10 GMT
Subject: RFR: 8330467: NoClassDefFoundError when lambda is in a hidden
 class [v4]
In-Reply-To: <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
References: <xk51mi5W7dY-JldOtH_X8oj9LUke9eg7lv0knjWdSbQ=.ae8304bf-274c-4921-b977-99a8b90a700a@github.com>
 <ibdhW-YUIEh373FMzDAAiY-v8KSD-Ki3Gnr8al6qoAE=.bbf53b0a-2f3f-4745-bea9-5f874a050b4c@github.com>
Message-ID: <BDGL94e_BbPQm7zvXHRaVW2To_2UaCjwUFBW6Vop6LA=.0dc4ce76-ce07-44a8-a7f7-70a53715a005@github.com>

On Thu, 18 Apr 2024 05:54:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Current implementation of `LambdaMetafactory` does not allow to use lambdas in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>> 
>> This patch includes lambda implementation in a hidden class under the special handling of `useImplMethodHandle`.
>> The patch also fixes `j/l/i/defineHiddenClass/BasicTest::testLambda` to correctly cover this test case.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

HiddenTest is not a hidden class in this test.  So it should be fine.   The bottom line is to ensure that the type reference is not a hidden class.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18810#issuecomment-2083352956

From naoto at openjdk.org  Mon Apr 29 18:44:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 18:44:09 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
Message-ID: <AgPIsLMYyLc6_iCfo4b-tiVW6MMEsPxhfQeGgH4ocxM=.81a948e8-e20a-496a-8054-b0fa5e7da998@github.com>

On Mon, 29 Apr 2024 14:56:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class ConsoleTest {
>>     public static void main(String... args) {
>>         System.console().printf("Hello!");
>>     }
>> }
>> 
>> 
>> When run as:
>> 
>> $ java ConsoleTest.java >/dev/null
>> 
>> 
>> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
>> 
>> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
>> 
>> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.
>
> Jan Lahoda 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 JDK-8330998
>  - Fixing test.
>  - Attempting to stabilize the test.
>  - Improving test to really test the redirect while stdin is connected to a terminal.
>  - Fixing typo.
>  - 8330998: System.console() writes to stderr when stdout is redirected

Looks good to me. Left some minor suggestions.
BTW, should we file an issue at the `JLine` project, not to redirect to stderr, or suggest a new config (sorry if it has already been taken care of)?

test/jdk/jdk/internal/jline/RedirectedStdOut.java line 29:

> 27:  * @summary Verify that even if the stdout is redirected java.io.Console will
> 28:  *          use it for writing.
> 29:  * @run main RedirectedStdOut runRedirectAllTest

`@modules jdk.internal.le` is needed, as the test relies on it.

test/jdk/jdk/internal/jline/RedirectedStdOut.java line 59:

> 57:     void runRedirectAllTest() throws Exception {
> 58:         String testJDK = System.getProperty("test.jdk");
> 59:         Path javaLauncher = Path.of(testJDK, "bin", "java");

Could utilize `ProcessTools` test library to start the test jdk process (applies to the other location as well)

-------------

PR Review: https://git.openjdk.org/jdk/pull/18996#pullrequestreview-2029297831
PR Review Comment: https://git.openjdk.org/jdk/pull/18996#discussion_r1583564260
PR Review Comment: https://git.openjdk.org/jdk/pull/18996#discussion_r1583565422

From vromero at openjdk.org  Mon Apr 29 18:55:24 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 29 Apr 2024 18:55:24 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v19]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <TTQWn-Mw-IZSJL2FPJ9jq5gVGdjEA7RLfe5FRf2jn2k=.8611bc23-3663-4e7a-a298-502d103f97ee@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  minor refactoring

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/0237d72c..234f78d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=17-18

  Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From redestad at openjdk.org  Mon Apr 29 19:01:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 29 Apr 2024 19:01:05 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v3]
In-Reply-To: <D2mzG35oPKs9HheE9MfVSmfXNQ-EsNQkJYSnLBkZSPI=.24b66026-a66d-4c50-95d3-d35dad7579d0@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
 <D2mzG35oPKs9HheE9MfVSmfXNQ-EsNQkJYSnLBkZSPI=.24b66026-a66d-4c50-95d3-d35dad7579d0@github.com>
Message-ID: <6iTlK-TkLfSvdFK6Jy9anwG7NHyAUkEU4yryqHbhpDU=.698d5a71-b3ea-47ea-b021-e8b39e41d4f9@github.com>

On Mon, 29 Apr 2024 17:45:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The changes look good to me but I wonder if the non-zero length check before calling `arraycopy` really needed? That seems to add some noise to the code.

I recall benchmarking similar code in `MethodType` extensively, and found that it had a small but significant impact, especially when adding or dropping parameters at the end or beginning of an argument list (which is the most common case). Adhoc JMH:


    @Benchmark
    public MethodTypeDesc dropFirstParameter() {
        return desc.dropParameterTypes(0, 1);
    }

Name                                                                   (descString) Cnt   Base   Error    Test   Error  Unit  Change
MethodTypeDescFactories.dropFirstParameter  (Ljava/lang/Object;Ljava/lang/String;)I   6 20,382 ? 0,635  16,116 ? 0,737 ns/op   1,26x (p = 0,000*)
MethodTypeDescFactories.dropFirstParameter ([IJLjava/lang/String;Z)Ljava/util/List;   6 26,875 ? 0,652  19,863 ? 0,749 ns/op   1,35x (p = 0,000*)
MethodTypeDescFactories.dropFirstParameter                                 (..IIJ)V   6 29,774 ? 0,983  20,747 ? 1,181 ns/op   1,44x (p = 0,000*)
MethodTypeDescFactories.dropFirstParameter                 (.....................).   6 33,224 ? 0,939  30,350 ? 1,739 ns/op   1,09x (p = 0,000*)
  * = significant

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18991#issuecomment-2083446959

From naoto at openjdk.org  Mon Apr 29 19:45:30 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 19:45:30 GMT
Subject: RFR: 8331202: Support for Duration until another Instant
Message-ID: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>

A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:

https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html

A CSR has also been drafted.

-------------

Commit messages:
 - Prefer until over between
 - nonnull
 - Internal suggestions, added a test
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/19007/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19007&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331202
  Stats: 62 lines in 2 files changed: 59 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19007.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19007/head:pull/19007

PR: https://git.openjdk.org/jdk/pull/19007

From duke at openjdk.org  Mon Apr 29 19:55:07 2024
From: duke at openjdk.org (Bernd)
Date: Mon, 29 Apr 2024 19:55:07 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
Message-ID: <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>

On Mon, 29 Apr 2024 14:56:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class ConsoleTest {
>>     public static void main(String... args) {
>>         System.console().printf("Hello!");
>>     }
>> }
>> 
>> 
>> When run as:
>> 
>> $ java ConsoleTest.java >/dev/null
>> 
>> 
>> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
>> 
>> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
>> 
>> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.
>
> Jan Lahoda 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 JDK-8330998
>  - Fixing test.
>  - Attempting to stabilize the test.
>  - Improving test to really test the redirect while stdin is connected to a terminal.
>  - Fixing typo.
>  - 8330998: System.console() writes to stderr when stdout is redirected

I think it's a feature when System.console() actually writes to the tty if stdout is redirected. After all it's not System.out. Of course the question is if it should write to stderr or /dev/tty like mechanism..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2083542510

From tprinzing at openjdk.org  Mon Apr 29 19:57:32 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 29 Apr 2024 19:57:32 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v9]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <3XIRqaNWkthCK1SsNZup_b-nFBkLR98tKGOEcJm60KM=.10f00ced-6145-4337-b1a5-c26a7fd9c707@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

Tim Prinzing 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 'refs/heads/master' into JDK-8329138
 - remove unecessary blank line
 - IntelliJ trying to help
 - undo fix being handled in JDK-8329330.
 - test file local to test
 - fix windows build issue
 - requested changes
 - Add support for AsynchronousFileChannel.force().
 - javadoc fixup
 - remove mirrors from JDKEvents
 - ... and 1 more: https://git.openjdk.org/jdk/compare/819f3d6f...743b92a6

-------------

Changes: https://git.openjdk.org/jdk/pull/18542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=08
  Stats: 279 lines in 12 files changed: 238 ins; 27 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542

From tprinzing at openjdk.org  Mon Apr 29 20:01:38 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 29 Apr 2024 20:01:38 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v10]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <oVKR1hsexF2OE1bdPcMncpczH3_E7mHK0MiWBaCuJn8=.f64c8069-eee9-48ea-a807-6fe21d68d0c0@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  fix mistake in merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/743b92a6..8bc34431

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

PR: https://git.openjdk.org/jdk/pull/18542

From darcy at openjdk.org  Mon Apr 29 20:20:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 29 Apr 2024 20:20:06 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v19]
In-Reply-To: <TTQWn-Mw-IZSJL2FPJ9jq5gVGdjEA7RLfe5FRf2jn2k=.8611bc23-3663-4e7a-a298-502d103f97ee@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <TTQWn-Mw-IZSJL2FPJ9jq5gVGdjEA7RLfe5FRf2jn2k=.8611bc23-3663-4e7a-a298-502d103f97ee@github.com>
Message-ID: <2sdYjjzSsRyImFY55rHCeqOPehPJk3md9nC445_W7q0=.d8c8dd2d-b001-4cad-a7f9-fe877260ba07@github.com>

On Mon, 29 Apr 2024 18:55:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring

test/jdk/java/lang/reflect/records/R10.jcod line 1:

> 1: class R10 {

Please add some comments in the jcod file saying what it does/why it is being used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1583694445

From acobbs at openjdk.org  Mon Apr 29 20:24:06 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 29 Apr 2024 20:24:06 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
 <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>
Message-ID: <2nHfM1COmrjxJc8ZBGcUXhznnI9V2EW6JGh_aLiqSPY=.0794fe56-a40c-47f7-abca-a6bd44de68a5@github.com>

On Mon, 29 Apr 2024 19:52:17 GMT, Bernd <duke at openjdk.org> wrote:

> Of course the question is if it should write to stderr or /dev/tty like mechanism..

I was wondering the same thing. My understanding of the definition of "console" is a bidirectional byte channel with a keyboard & screen on the other end. It has no concept of stdout vs. stderr. It just has a display (or in the old days, a printer).

The function of a "shell" is to intermediate between one or more executing programs and the console. It figures out how & when to actually display on the console any stuff written to stdout and/or stderr by one of the programs it has launched.

A program can also access its console (if any) directly by opening /dev/tty or whatever, thereby bypassing the shell.

So I would think writing to something called "System.console()" from Java (which is a program) would have nothing to do with Java's stderr or stdout, except for a possible downstream interleaving with what the shell may also be writing to the console at the same time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2083593864

From darcy at openjdk.org  Mon Apr 29 20:26:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 29 Apr 2024 20:26:07 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v19]
In-Reply-To: <TTQWn-Mw-IZSJL2FPJ9jq5gVGdjEA7RLfe5FRf2jn2k=.8611bc23-3663-4e7a-a298-502d103f97ee@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <TTQWn-Mw-IZSJL2FPJ9jq5gVGdjEA7RLfe5FRf2jn2k=.8611bc23-3663-4e7a-a298-502d103f97ee@github.com>
Message-ID: <96AxrwZP9TFxSV06va3Dx6ecuv2Tg_vZE0_Dljsbz38=.a957c426-7a9b-405a-a6ba-0ebad12b7980@github.com>

On Mon, 29 Apr 2024 18:55:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring

src/java.base/share/classes/java/lang/reflect/Executable.java line 286:

> 284:      * declared parameter in addition to explicitly declared ones.
> 285:      * Also note that compact constructors of a record class may have
> 286:      * implicitly ({@linkplain java.compiler/javax.lang.model.util.Elements.Origin#MANDATED mandated}) declared parameters.

I think a better version of this edit is

`{@linkplain java.compiler/javax.lang.model.util.Elements.Origin#MANDATED implicitly declared}`

src/java.base/share/classes/java/lang/reflect/Executable.java line 287:

> 285:      * Also note that compact constructors of a record class may have
> 286:      * implicitly ({@linkplain java.compiler/javax.lang.model.util.Elements.Origin#MANDATED mandated}) declared parameters.
> 287:      * Finally note that as a <a href="{@docRoot}/java.base/java/lang/reflect/package-summary.html#LanguageJvmModel">modeling

I believe syntax like

`{@link java.lang.reflect##LanguageJvmModel modeling artifact}`

can be used instead of the href link.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1583699306
PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1583702180

From bchristi at openjdk.org  Mon Apr 29 20:47:13 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 29 Apr 2024 20:47:13 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v28]
In-Reply-To: <HADrLqtHXFx_IDXhxlNOeX1PsVToOw5NVo6d9ZP9WiA=.d16db133-43d2-4f5e-bffe-2bf1e7648a24@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <b9F3NTIjnmwisjT9eVzz_gfD6Nkeu9mRJpAqFX1ZbYU=.64e9c467-56a7-47d0-baa6-e8c29408ea4a@github.com>
 <HADrLqtHXFx_IDXhxlNOeX1PsVToOw5NVo6d9ZP9WiA=.d16db133-43d2-4f5e-bffe-2bf1e7648a24@github.com>
Message-ID: <zyajOq6aXml3EhjIBO17xAjlsZ1g0x2BayW67hxWAck=.2f6c56ae-34f2-4c7a-9ea7-53d24abda530@github.com>

On Sat, 27 Apr 2024 11:57:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   new section for finalizer memviz
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 137:
> 
>> 135:  * <a id="MemoryConsistency"></a>
>> 136:  * <h2>Memory Consistency Properties</h2>
>> 137:  * Certain interactions between references, references queues, and the garbage
> 
> Suggestion:
> 
>  * Certain interactions between references, reference queues, and the garbage

Yes, thank you

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1583736191

From bchristi at openjdk.org  Mon Apr 29 20:57:09 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 29 Apr 2024 20:57:09 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v28]
In-Reply-To: <HADrLqtHXFx_IDXhxlNOeX1PsVToOw5NVo6d9ZP9WiA=.d16db133-43d2-4f5e-bffe-2bf1e7648a24@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <b9F3NTIjnmwisjT9eVzz_gfD6Nkeu9mRJpAqFX1ZbYU=.64e9c467-56a7-47d0-baa6-e8c29408ea4a@github.com>
 <HADrLqtHXFx_IDXhxlNOeX1PsVToOw5NVo6d9ZP9WiA=.d16db133-43d2-4f5e-bffe-2bf1e7648a24@github.com>
Message-ID: <-UxEARTB6jmjtbraAdYE3dNpURToaL9xK_Izau6LTlA=.a9b901a4-9bca-4e0c-bb9b-22a54d889979@github.com>

On Sat, 27 Apr 2024 11:58:52 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   new section for finalizer memviz
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 157:
> 
>> 155:  * <li>The dequeuing of a reference to a
>> 156:  * {@linkplain Cleaner#register(Object object, Runnable action) registered}
>> 157:  * object, by a Cleaner thread, <i>happens-before</i> that Cleaner thread runs
> 
> Are we committing to this? I.e. that there will always be a single Cleaner thread? (i.e. one could imagine a situation where you have one polling thread which executes the cleaning action on some other thread?)

I'll revert this back to "_the_ Cleaner thread".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1583750541

From bchristi at openjdk.org  Mon Apr 29 21:17:24 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 29 Apr 2024 21:17:24 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v29]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <88uucCyrO2W6frWuhxgcWtRcffZChQ8zvGO5H7OOCEU=.ffbf7203-1cde-4232-960c-84bd5d95cfe0@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  small grammar fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/5f90b5d8..a41e6fc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=27-28

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From naoto at openjdk.org  Mon Apr 29 21:32:16 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 21:32:16 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v2]
In-Reply-To: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
Message-ID: <-C9SWhi0aljukKJtfv80rmE3JLj0JzmyjYwMvVqy6Bk=.7d9d0798-3c14-4e92-88e0-67f93172886e@github.com>

> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
> 
> A CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Test with Duration.between()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19007/files
  - new: https://git.openjdk.org/jdk/pull/19007/files/ff599c4f..df2c1157

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19007&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19007&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19007.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19007/head:pull/19007

PR: https://git.openjdk.org/jdk/pull/19007

From tprinzing at openjdk.org  Mon Apr 29 21:33:24 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 29 Apr 2024 21:33:24 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v9]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <IS6zbEDQPUEB5-z-2hyoFpD_SgPVGlpmgP31PQ23R24=.e9422ae5-8819-4307-be2e-46d3a91e2dfb@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - fix merge
 - Merge branch 'refs/heads/master' into JDK-8310994
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
 - more annotation fixup
 - cleanup of annotations
 - remove selector spin event attempt and associated test.
 - update copyright dates
 - Merge branch 'master' into JDK-8310994
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java
 - comment fixup
 - add select timeout field to the event
 - Change event generation:
   
   - selectNow is filtered out
   - select that times out is always sent
   - select without timeout uses duration test
 - ... and 11 more: https://git.openjdk.org/jdk/compare/819f3d6f...dd43f4fa

-------------

Changes: https://git.openjdk.org/jdk/pull/16710/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=08
  Stats: 277 lines in 9 files changed: 273 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710

PR: https://git.openjdk.org/jdk/pull/16710

From joehw at openjdk.org  Mon Apr 29 21:41:04 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 29 Apr 2024 21:41:04 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v2]
In-Reply-To: <-C9SWhi0aljukKJtfv80rmE3JLj0JzmyjYwMvVqy6Bk=.7d9d0798-3c14-4e92-88e0-67f93172886e@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
 <-C9SWhi0aljukKJtfv80rmE3JLj0JzmyjYwMvVqy6Bk=.7d9d0798-3c14-4e92-88e0-67f93172886e@github.com>
Message-ID: <NuTScytgzkZCSeJAw_P4Oegp7LCi440-DYEfC-mB6VQ=.b2118e95-40af-4d1b-9c85-d1a6666d602e@github.com>

On Mon, 29 Apr 2024 21:32:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>> 
>> A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test with Duration.between()

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19007#pullrequestreview-2029696826

From tprinzing at openjdk.org  Mon Apr 29 21:56:10 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 29 Apr 2024 21:56:10 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <_5zaiminpkaaX8Bwx4BhcULhyii-W0zCUswNab-aQVg=.19a2551a-b69c-4238-9aab-cffc3d9e9751@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
 <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
 <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>
 <_5zaiminpkaaX8Bwx4BhcULhyii-W0zCUswNab-aQVg=.19a2551a-b69c-4238-9aab-cffc3d9e9751@github.com>
Message-ID: <TpIMJnCm76IYCVYaWfjm33Oj4lcUp2TmDs7ZVQF1Jog=.737e20ee-289f-4c9c-bdec-d7d9fd186f95@github.com>

On Thu, 11 Apr 2024 16:39:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I think it's okay for now. If there is another phase of this work to help diagnose spinning issues then it will need to re-visited. I'm very concerned about the possible changes for that second phase, but this first phase of instrumentation is not disruptive.
>
> OK. I am a little concerned about how often this event will be fired when using the HttpClient - given that it's enabled by default. Idle connections sitting in the pool will fire it at least once per connection every 1500ms. That may not be too bad.

Should I set the default to be fairly high (like maybe 1600ms)?  I think to be useful people will have to set the threshold to something that fits their needs anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1583825215

From joehw at openjdk.org  Mon Apr 29 22:03:07 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 29 Apr 2024 22:03:07 GMT
Subject: RFR: 8330276: Console methods with explicit Locale
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <Hyaq1CQEQBbRoll_4UnYO4TG0QZ14iy8sOWtucRpDXw=.cc582334-48e2-4dde-b130-6952e8cf4f7c@github.com>

On Tue, 23 Apr 2024 20:35:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

src/java.base/share/classes/java/io/Console.java line 193:

> 191:      * {@code locale}.
> 192:      *
> 193:      * @param  locale locale used for formatting

Specify the behavior when locale is null?

src/java.base/share/classes/java/io/Console.java line 202:

> 200:      *         string.  If there are more arguments than format specifiers, the
> 201:      *         extra arguments are ignored.  The number of arguments is
> 202:      *         variable and may be zero.  The maximum number of arguments is

readLine and readPassword don't have this statement (The number of arguments is variable and may be zero). Is this statement helpful for those methods as well?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1583826762
PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1583828717

From darcy at openjdk.org  Mon Apr 29 22:50:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 29 Apr 2024 22:50:26 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v3]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <VINxNLNLhQ2xaEHji5EqHYA1MxLKYpjqnaSzlp7Cklw=.a2b04dfa-65f2-4421-9852-cf7b5faf9cbb@github.com>

> Get JDK 24 underway.

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 seven additional commits since the last revision:

 - Update deprecated options test.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Correct release date as observed in review feedback.
 - Improve javadoc of class file update.
 - JDK-8330182: Start of release updates for JDK 24
   JDK-8330183: Add SourceVersion.RELEASE_24
   JDK-8330184: Add source 24 and target 24 to javac

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18787/files
  - new: https://git.openjdk.org/jdk/pull/18787/files/dc488f21..47100a28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=01-02

  Stats: 69237 lines in 1984 files changed: 31363 ins; 31713 del; 6161 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From naoto at openjdk.org  Mon Apr 29 23:22:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 23:22:21 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressed review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/f3f879ea..7884cfe3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=00-01

  Stats: 59 lines in 2 files changed: 43 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

PR: https://git.openjdk.org/jdk/pull/18923

From naoto at openjdk.org  Mon Apr 29 23:22:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 23:22:21 GMT
Subject: RFR: 8330276: Console methods with explicit Locale
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <z29kSvrHkMxIcvuVn1oAno8jbaYgNKrZn3YD1pGsiU4=.002368f8-3e6d-424e-9a6c-66093e53b664@github.com>

On Tue, 23 Apr 2024 20:35:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Thanks, Joe. Addressed your points (and updated the test case accordingly)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18923#issuecomment-2083846171

From naoto at openjdk.org  Mon Apr 29 23:22:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Apr 2024 23:22:21 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <Hyaq1CQEQBbRoll_4UnYO4TG0QZ14iy8sOWtucRpDXw=.cc582334-48e2-4dde-b130-6952e8cf4f7c@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <Hyaq1CQEQBbRoll_4UnYO4TG0QZ14iy8sOWtucRpDXw=.cc582334-48e2-4dde-b130-6952e8cf4f7c@github.com>
Message-ID: <ZEI5YcUW4cDIO8n2JSsN29Hb3i0KuojmubOtZfAp7Z0=.51ab0d1d-e17c-4e7e-8b8e-32207ec2980a@github.com>

On Mon, 29 Apr 2024 21:54:55 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> src/java.base/share/classes/java/io/Console.java line 193:
> 
>> 191:      * {@code locale}.
>> 192:      *
>> 193:      * @param  locale locale used for formatting
> 
> Specify the behavior when locale is null?

Good point. Brought the same wording from `String.format`

> src/java.base/share/classes/java/io/Console.java line 202:
> 
>> 200:      *         string.  If there are more arguments than format specifiers, the
>> 201:      *         extra arguments are ignored.  The number of arguments is
>> 202:      *         variable and may be zero.  The maximum number of arguments is
> 
> readLine and readPassword don't have this statement (The number of arguments is variable and may be zero). Is this statement helpful for those methods as well?

Modified each description for `args` consistently.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1583891641
PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1583892038

From mchung at openjdk.org  Tue Apr 30 00:14:04 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 30 Apr 2024 00:14:04 GMT
Subject: RFR: 8331264: Reduce java.lang.constant initialization overhead
 [v3]
In-Reply-To: <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
 <M1OSzW5YZ9QHidQPhcTCzqTz_ZjeEiKAJx4mnRDnC3w=.040b2f11-3cc5-4b98-92a0-c92f36bca810@github.com>
Message-ID: <VpdKw8CkkwAP-vtcOnOpGdUFgi_Wcb1SUnwXBTDn5rg=.3b5ce885-219f-428a-bbbc-b5343ba21764@github.com>

On Mon, 29 Apr 2024 12:39:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified void check

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18991#pullrequestreview-2029946427

From tprinzing at openjdk.org  Tue Apr 30 00:34:07 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 30 Apr 2024 00:34:07 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v10]
In-Reply-To: <oVKR1hsexF2OE1bdPcMncpczH3_E7mHK0MiWBaCuJn8=.f64c8069-eee9-48ea-a807-6fe21d68d0c0@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <oVKR1hsexF2OE1bdPcMncpczH3_E7mHK0MiWBaCuJn8=.f64c8069-eee9-48ea-a807-6fe21d68d0c0@github.com>
Message-ID: <-tjL8Ax2C7Hr_DMe1tmNGBMAO8sjZxugPaFw3csRsQQ=.638b72e5-d88b-4a77-9e12-7cd93d3e6ea5@github.com>

On Mon, 29 Apr 2024 20:01:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix mistake in merge

I went ahead and ran teir1 through teir3 tests on everything after the merge.  Everything passes so this is ready for integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2083946114

From joehw at openjdk.org  Tue Apr 30 02:00:05 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 30 Apr 2024 02:00:05 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
Message-ID: <6Nbii0WAObqlOoZUOLRmt6fujcqMO3OXbuBgMuUPX9Y=.2b690e57-d92b-449a-9ea9-a5637034ba9c@github.com>

On Mon, 29 Apr 2024 23:22:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Thanks for the update. Changes look good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18923#pullrequestreview-2030033024

From iris at openjdk.org  Tue Apr 30 06:25:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 30 Apr 2024 06:25:08 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v3]
In-Reply-To: <VINxNLNLhQ2xaEHji5EqHYA1MxLKYpjqnaSzlp7Cklw=.a2b04dfa-65f2-4421-9852-cf7b5faf9cbb@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <VINxNLNLhQ2xaEHji5EqHYA1MxLKYpjqnaSzlp7Cklw=.a2b04dfa-65f2-4421-9852-cf7b5faf9cbb@github.com>
Message-ID: <xGZzLsZ7Je6HKGkeGvkIQBcF71OB4-oWlmAmF4DzpJI=.e1129607-d7da-4aea-a8de-b348ece53267@github.com>

On Mon, 29 Apr 2024 22:50:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> 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 seven additional commits since the last revision:
> 
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8330188
>  - Merge branch 'master' into JDK-8330188
>  - Merge branch 'master' into JDK-8330188
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.
>  - JDK-8330182: Start of release updates for JDK 24
>    JDK-8330183: Add SourceVersion.RELEASE_24
>    JDK-8330184: Add source 24 and target 24 to javac

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2030298396

From scolebourne at openjdk.org  Tue Apr 30 06:43:04 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Tue, 30 Apr 2024 06:43:04 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v2]
In-Reply-To: <-C9SWhi0aljukKJtfv80rmE3JLj0JzmyjYwMvVqy6Bk=.7d9d0798-3c14-4e92-88e0-67f93172886e@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
 <-C9SWhi0aljukKJtfv80rmE3JLj0JzmyjYwMvVqy6Bk=.7d9d0798-3c14-4e92-88e0-67f93172886e@github.com>
Message-ID: <dJ823yXDc5WB6ruwLC1giH-kOW6Qaby1Hf-iKkAaw5g=.75cb60d8-afd9-4280-967c-1fa3ad63ff19@github.com>

On Mon, 29 Apr 2024 21:32:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>> 
>> A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test with Duration.between()

Marked as reviewed by scolebourne (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19007#pullrequestreview-2030326257

From jkratochvil at openjdk.org  Tue Apr 30 07:04:13 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 30 Apr 2024 07:04:13 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
Message-ID: <3fIwsx3mIcsYdCkzQg41iKthcjfcf3fLXSdzgrBLoIo=.1f549df9-83d5-4fab-bbd2-0e0fcdb41daf@github.com>

On Sun, 10 Mar 2024 14:40:09 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Fix whitespace
>  - Merge branch 'master' into master-cgroup
>    
>    Conflicts:
>    	test/hotspot/gtest/os/linux/test_cgroupSubsystem_linux.cpp
>  - Fix gtest
>  - Update the Java part
>  - Fix cgroup1 backward compatibility message
>  - Merge remote-tracking branch 'centos79/master-cgroup' into master-cgroup
>  - Disable cgroup.subtree_control testcase on cgroup1
>  - Fix gtest
>  - Merge branch 'master' into master-cgroup
>  - Merge remote-tracking branch 'f38crac/master-cgroup' into master-cgroup
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/243cb098...39c90162

- Will the patch be accepted only for memory or it has to support also CPU?
- Should I code it on top of OpenJDK trunk or on top of https://github.com/jerboaa/jdk/commit/92aaa6fd7e3ff8b64de064fecfcd725a157cb5bb ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2084523889

From redestad at openjdk.org  Tue Apr 30 08:30:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 30 Apr 2024 08:30:10 GMT
Subject: Integrated: 8331264: Reduce java.lang.constant initialization overhead
In-Reply-To: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
References: <LSv9YitoGDQau5D3O_BXfhVz2sP-hhnzxmN1mn-uguE=.810bd58e-eeb5-48a6-8c8d-bf05f2696629@github.com>
Message-ID: <ewll63xFNUk2SeSjIR_LDUDR0XSW2Ga9AV-vf0MPdug=.cbd2e01d-1fa0-45b9-8e53-d2f4b87d49aa@github.com>

On Mon, 29 Apr 2024 08:11:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'm looking at ways at reducing/eliminating startup overheads the classfile API in preparation of #17108, and have pushed a series of enhancements to that effect already. This PR is a collection of minor improvements which add up to a 1.5% reduction in retired instructions - or a 5% reduction in executed bytecode - on a simple lambda startup test.

This pull request has now been integrated.

Changeset: 0630bb02
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0630bb02eb760081ddd612ccb1b12d57d43aab5e
Stats:     74 lines in 7 files changed: 7 ins; 5 del; 62 mod

8331264: Reduce java.lang.constant initialization overhead

Reviewed-by: liach, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/18991

From jkern at openjdk.org  Tue Apr 30 08:37:04 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 30 Apr 2024 08:37:04 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131
In-Reply-To: <ncCMr8yhkJNWyB5mz9I9TgvWk5rrGOpLmwFfFei7w_0=.d726adf0-6570-4c5a-bef4-9fafe23cf0b7@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
 <ncCMr8yhkJNWyB5mz9I9TgvWk5rrGOpLmwFfFei7w_0=.d726adf0-6570-4c5a-bef4-9fafe23cf0b7@github.com>
Message-ID: <wC9UopH4Xbcy_BY0IaKyFxXdmFSp6W3uy_ySHd9xhVU=.3be74d39-f3ce-4114-82b0-d20be57a86b4@github.com>

On Mon, 29 Apr 2024 15:57:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks like it's adding code to search LD_LIBRARY_PATH on Linux/macOS too, did you mean to do that?

Hi Alan, this first commit of the PR is just a question if Linux/macOS want to participate in this 3rd method. For them it's just a fallback; for AIX it's necessary. If they decide not to participate I just suggest to `#ifdef AIX` the added code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19000#issuecomment-2084712623

From rgiulietti at openjdk.org  Tue Apr 30 08:44:32 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 30 Apr 2024 08:44:32 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v4]
In-Reply-To: <ktZDmC-1cjJNkiYuIvbPzNWNSoffSbGAVtTFYLhBCbI=.9e41dd82-3dd7-4bfd-943c-35b1fae10a47@github.com>
References: <ktZDmC-1cjJNkiYuIvbPzNWNSoffSbGAVtTFYLhBCbI=.9e41dd82-3dd7-4bfd-943c-35b1fae10a47@github.com>
Message-ID: <dBIjji1datjdEFJqOoMhrAn6uytM5P1NtegTelf2H_o=.4839e626-0dbf-46c7-b6b6-ce1a1a005383@github.com>

> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings.

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:

 - Merge branch 'master' into 8316662
 - Merge branch 'master' into 8316662
 - Uppercase JLA.
 - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15861/files
  - new: https://git.openjdk.org/jdk/pull/15861/files/87e09f38..4308b78f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15861&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15861&range=02-03

  Stats: 1500684 lines in 12654 files changed: 338946 ins; 714685 del; 447053 mod
  Patch: https://git.openjdk.org/jdk/pull/15861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15861/head:pull/15861

PR: https://git.openjdk.org/jdk/pull/15861

From vklang at openjdk.org  Tue Apr 30 09:18:20 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 30 Apr 2024 09:18:20 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
Message-ID: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>

This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

-------------

Commit messages:
 - Updating PreviewFeature.STREAM_GATHERERS to 473 - Second Preview

Changes: https://git.openjdk.org/jdk/pull/19003/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19003&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331346
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19003/head:pull/19003

PR: https://git.openjdk.org/jdk/pull/19003

From pminborg at openjdk.org  Tue Apr 30 09:18:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 30 Apr 2024 09:18:20 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
In-Reply-To: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
Message-ID: <rFwAA-MilLCBnSM2whLeZdAwyOj-hgMVfZoSvPoMUwQ=.1a643efe-a95c-49e8-a9dd-2afb72318ab3@github.com>

On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

LGTM

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19003#pullrequestreview-2030731354

From vklang at openjdk.org  Tue Apr 30 09:18:20 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 30 Apr 2024 09:18:20 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
In-Reply-To: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
Message-ID: <_nPuZMQuVPI-E4ElYwUU2-VFmamgXDGtNl0t5_XB46w=.8883686e-4e38-48b5-840a-1ceb01d39d69@github.com>

On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

@AlanBateman Let me know if I should create a new JBS issue for this change, or if it is fine to target the JEP JBS issue. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19003#issuecomment-2083196525

From alanb at openjdk.org  Tue Apr 30 09:18:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Apr 2024 09:18:20 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
In-Reply-To: <_nPuZMQuVPI-E4ElYwUU2-VFmamgXDGtNl0t5_XB46w=.8883686e-4e38-48b5-840a-1ceb01d39d69@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
 <_nPuZMQuVPI-E4ElYwUU2-VFmamgXDGtNl0t5_XB46w=.8883686e-4e38-48b5-840a-1ceb01d39d69@github.com>
Message-ID: <C0Lb3-7I3vjbzbb2865vXN5u7zSHJ6gayxiOWYmqrI8=.3e273759-70ee-480c-9790-a57b4e0a4c18@github.com>

On Mon, 29 Apr 2024 16:42:59 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> @AlanBateman Let me know if I should create a new JBS issue for this change, or if it is fine to target the JEP JBS issue. ?

The bot has spotted this already (see "Integration Blocker" in the updated description). You'll need to create a separate JBS issue for the implementation change and link it in JBS to the JEP.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19003#issuecomment-2083249877

From alanb at openjdk.org  Tue Apr 30 09:56:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Apr 2024 09:56:05 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
In-Reply-To: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
Message-ID: <qc-YN1B0j6wZuR_SZz8afTrJf8wpQyvwcXHai8aocFU=.de7d4a76-b282-44c1-a61c-c7986ed4e314@github.com>

On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19003#pullrequestreview-2030820148

From jpai at openjdk.org  Tue Apr 30 09:59:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Apr 2024 09:59:25 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test virtual
 threads
Message-ID: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>

Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?

When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.

`test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.

`test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.

I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.

-------------

Commit messages:
 - 8308033: The jcmd thread dump related tests should test virtual threads

Changes: https://git.openjdk.org/jdk/pull/19016/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308033
  Stats: 51 lines in 3 files changed: 42 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19016/head:pull/19016

PR: https://git.openjdk.org/jdk/pull/19016

From rgiulietti at openjdk.org  Tue Apr 30 10:21:49 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 30 Apr 2024 10:21:49 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v5]
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <gvKhmWgKxHoB7cl9uQvGUWB5yKhqJS5NkSTHd9lPLf0=.5575df1c-8298-4682-ba3f-fc5594dc8ea2@github.com>

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18932/files
  - new: https://git.openjdk.org/jdk/pull/18932/files/d502b245..59c86b43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18932&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18932/head:pull/18932

PR: https://git.openjdk.org/jdk/pull/18932

From asotona at openjdk.org  Tue Apr 30 11:56:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 11:56:20 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot of
 static initializations
Message-ID: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>

Hi,
During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.

I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
 
Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.

Thank you,
Adam

-------------

Commit messages:
 - added impl comment
 - removed list of predefined attributes
 - move mappers implementations to AbstractAttributeMapper
 - 8331291: java.lang.classfile.Attributes class performs a lot of static initializations

Changes: https://git.openjdk.org/jdk/pull/19006/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331291
  Stats: 2029 lines in 47 files changed: 904 ins; 619 del; 506 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

PR: https://git.openjdk.org/jdk/pull/19006

From liach at openjdk.org  Tue Apr 30 11:56:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Apr 2024 11:56:20 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <YUvFFllRTrJ-mTbS64o2QbfG2grk7mhTHmaHaqfsURE=.41d41022-1831-4354-8ad4-c7588146e211@github.com>

On Mon, 29 Apr 2024 18:48:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Nice changes! Remarks
1. The `INSTANCE` fields should be declared `final`, still safe for lazy initialization.
2. Not from this patch, but the `AttributeStability stability()` overrides can be moved to `AbstractAttributeMapper`, stored in a field, to decrease source code size.
3. `AbstractAttributeMapper` might become sealed now that its implementations are no longer anonymous, might move it to be a private nested class of `Attributes` to omit the long list of permits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2083832111

From asotona at openjdk.org  Tue Apr 30 11:56:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 11:56:20 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations
In-Reply-To: <YUvFFllRTrJ-mTbS64o2QbfG2grk7mhTHmaHaqfsURE=.41d41022-1831-4354-8ad4-c7588146e211@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <YUvFFllRTrJ-mTbS64o2QbfG2grk7mhTHmaHaqfsURE=.41d41022-1831-4354-8ad4-c7588146e211@github.com>
Message-ID: <9NS-fjr36lj9hA4htcRwnIEeN3qZHTXSOAWBeyBdAs4=.d2b88f96-f9f6-4f66-887c-1bfcd709e7d9@github.com>

On Mon, 29 Apr 2024 23:04:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Nice changes! Remarks
> 
> 1. The `INSTANCE` fields should be declared `final`, still safe for lazy initialization.
> 2. Not from this patch, but the `AttributeStability stability()` overrides can be moved to `AbstractAttributeMapper`, stored in a field, to decrease source code size.
> 3. `AbstractAttributeMapper` might become sealed now that its implementations are no longer anonymous, might move it to be a private nested class of `Attributes` to omit the long list of permits.

Yes, that is part of the plan for today :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2084446739

From liach at openjdk.org  Tue Apr 30 12:12:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Apr 2024 12:12:06 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>

On Mon, 29 Apr 2024 18:48:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Also the `final` modifier addition should be included in the CSR, as it changes the access modifiers even if it has no real impact.

src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 996:

> 994:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
> 995:         // critical bootstrap path, so no lambdas nor method handles here
> 996:         return switch (name.hashCode()) {

I think we can safely switch over strings, as they are compiled to hashCode switch like what you explicitly have right now. Isn't that the case?

test/jdk/jdk/classfile/AttributesTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @summary Testing Attributes API.

Can add a line `@bug 8331291`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2085160221
PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584686905
PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584687500

From magnus.ihse.bursie at oracle.com  Tue Apr 30 12:16:14 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 30 Apr 2024 14:16:14 +0200
Subject: Usage of iconv()
In-Reply-To: <91874482-df68-4e76-99e9-4fb90ef2c7a7@oracle.com>
References: <20240423121114.EE241662C87@dd33810.kasserver.com>
 <e9f7107a-4f9c-4511-9270-9bb08f7bca87@oracle.com>
 <91874482-df68-4e76-99e9-4fb90ef2c7a7@oracle.com>
Message-ID: <77bc954e-e0bb-40f3-a602-cb58cb7f74a3@oracle.com>

On 2024-04-25 20:30, Philip Race wrote:

>
>
> On 4/24/24 4:24 AM, Magnus Ihse Bursie wrote:
>> That is a good question. libiconv is used only on macOS and AIX, for 
>> a few libraries, as you say. I just tried removing -liconv from the 
>> macOS dependencies and recompiled, just to see what would happen. 
>> There were three instances for macOS: libsplashscreen, libjdwp and 
>> libinstrument.
>>
>>
>>
>> libsplashscreen uses it in splashscreen_sys.m, where it is used to 
>> convert the jar file name.
>
> This is called from the launcher, in java.base/share/native/libjli/java.c
>
>
>>
>> libjdwp uses it in utf_util.c, where it is used to convert file name 
>> and command lines, iiuc.
>>
>> It is likely that we have similar (but better) ways to convert 
>> charsets elsewhere in our libraries that can be used instead of 
>> libiconv. I guess these are not the only two places where a filename 
>> must be converted from the platform charset to UTF8.
>
> So whatever replacement there might be, it needs to be something that 
> is available very early in the life of the VM, in fact before there is 
> a VM running.

Agreed. But it seems to be that this is something that needs to be 
handled by libjli, to properly deal with paths and command lines. I'm 
wondering if the places which to *not* use iconv (or similar) is 
actually incorrect.

/Magnus

>
> -phil.

From asotona at openjdk.org  Tue Apr 30 12:23:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 12:23:36 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v2]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <RozF-tbZQwbV2ffLbQZAlDJes7X0G0H9gw6GXpQq7e8=.e4e4ea57-3d5b-4acc-bbd4-a6ba80c78231@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added bug number

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/b7b35c5d..27238368

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

PR: https://git.openjdk.org/jdk/pull/19006

From asotona at openjdk.org  Tue Apr 30 12:23:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 12:23:36 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations
In-Reply-To: <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
Message-ID: <phaIEfkEGahvGXohPOJ98GEG7fGYWJ3XSQN5hLb1pL8=.c731ff13-d1ff-4729-a3ae-d55f7fe7b3cc@github.com>

On Tue, 30 Apr 2024 12:09:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also the `final` modifier addition should be included in the CSR, as it changes the access modifiers even if it has no real impact.

The class already had only private constructor, so there was no way to extend it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2085173489

From asotona at openjdk.org  Tue Apr 30 12:23:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 12:23:37 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v2]
In-Reply-To: <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
Message-ID: <Mx9FkDxCrMsQ-zmdTCN1e6Vx615GyUYstAjNMBHdUOM=.35238e6f-fb15-4525-9ca1-b9c153fc60ce@github.com>

On Tue, 30 Apr 2024 12:05:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added bug number
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 996:
> 
>> 994:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
>> 995:         // critical bootstrap path, so no lambdas nor method handles here
>> 996:         return switch (name.hashCode()) {
> 
> I think we can safely switch over strings, as they are compiled to hashCode switch like what you explicitly have right now. Isn't that the case?

Freshly parsed Utf8Entries conversion to String is expensive and unnecessary. We should be very careful when to ask for the conversion as it significantly affects some benchmarks.

> test/jdk/jdk/classfile/AttributesTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @summary Testing Attributes API.
> 
> Can add a line `@bug 8331291`

Added, thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584696556
PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584707230

From sgehwolf at openjdk.org  Tue Apr 30 12:25:08 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Apr 2024 12:25:08 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <3fIwsx3mIcsYdCkzQg41iKthcjfcf3fLXSdzgrBLoIo=.1f549df9-83d5-4fab-bbd2-0e0fcdb41daf@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
 <3fIwsx3mIcsYdCkzQg41iKthcjfcf3fLXSdzgrBLoIo=.1f549df9-83d5-4fab-bbd2-0e0fcdb41daf@github.com>
Message-ID: <2W4Bc218kau9Zye2krPEDbPpGdgRbqh7YDhy9MTxtug=.310c8fa3-1a19-4521-a1a0-17ee4c404a83@github.com>

On Tue, 30 Apr 2024 07:01:16 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> * Will the patch be accepted only for memory or it has to support also CPU?

It should be fine for memory only for a start, but we should allow for on-boarding of other controllers as well.

> * Should I code it on top of OpenJDK trunk or on top of [jerboaa at 92aaa6f](https://github.com/jerboaa/jdk/commit/92aaa6fd7e3ff8b64de064fecfcd725a157cb5bb) ?

Since this patch solves a similar problem than https://bugs.openjdk.java.net/browse/JDK-8217338 did at the time when only cg v1 was supported I'd feel more comfortable in paying the technical debt and recode it so that cg v1 and cg v2 behaves the same or at least similar. That should make the code cleaner, easier to test and maintain in the long run. So I'm thinking on top of the refactoring. I'll try to prioritize those work items accordingly. Does that sound OK?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2085186173

From liach at openjdk.org  Tue Apr 30 12:31:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Apr 2024 12:31:05 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v2]
In-Reply-To: <Mx9FkDxCrMsQ-zmdTCN1e6Vx615GyUYstAjNMBHdUOM=.35238e6f-fb15-4525-9ca1-b9c153fc60ce@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
 <Mx9FkDxCrMsQ-zmdTCN1e6Vx615GyUYstAjNMBHdUOM=.35238e6f-fb15-4525-9ca1-b9c153fc60ce@github.com>
Message-ID: <qBd5LxYBcH_0mlhLjMYtXNGVePP4rW_6Z38YOpTi9kc=.ce79ce1d-ffcf-4338-b7b5-51f589ae13b1@github.com>

On Tue, 30 Apr 2024 12:13:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 996:
>> 
>>> 994:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
>>> 995:         // critical bootstrap path, so no lambdas nor method handles here
>>> 996:         return switch (name.hashCode()) {
>> 
>> I think we can safely switch over strings, as they are compiled to hashCode switch like what you explicitly have right now. Isn't that the case?
>
> Freshly parsed Utf8Entries conversion to String is expensive and unnecessary. We should be very careful when to ask for the conversion as it significantly affects some benchmarks.

You are right, I forgot these are Utf8Entry instead of Strings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584719802

From liach at openjdk.org  Tue Apr 30 12:41:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Apr 2024 12:41:06 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v2]
In-Reply-To: <RozF-tbZQwbV2ffLbQZAlDJes7X0G0H9gw6GXpQq7e8=.e4e4ea57-3d5b-4acc-bbd4-a6ba80c78231@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <RozF-tbZQwbV2ffLbQZAlDJes7X0G0H9gw6GXpQq7e8=.e4e4ea57-3d5b-4acc-bbd4-a6ba80c78231@github.com>
Message-ID: <R5LZbb1mB39zC1ILcTk2HBRsPw_EMaB0AXya4c-uv6s=.40fde4a6-92df-41d3-8529-3eed90e41e53@github.com>

On Tue, 30 Apr 2024 12:23:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi,
>> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
>> 
>> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>>  
>> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added bug number

Yeah, it has no real usage impact but such changes do require CSRs, like https://bugs.openjdk.org/browse/JDK-8305158 for a `final` on `Arrays` class, so you should include the `final` modifier change in your CSR's specdiff.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2085221255

From vklang at openjdk.org  Tue Apr 30 12:41:06 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 30 Apr 2024 12:41:06 GMT
Subject: RFR: 8278255: add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
Message-ID: <x0vxRrQhxbysPCXRTZup2QQ8bRZhR7dlSkV_8NYmEMk=.824578bb-b18f-48eb-9259-87ba00c45b49@github.com>

On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>   
>   Co-authored-by: Pavel Rappo <32523691+pavelrappo at users.noreply.github.com>

@pavelrappo Wdyt?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2085221026

From jkratochvil at openjdk.org  Tue Apr 30 12:52:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 30 Apr 2024 12:52:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
Message-ID: <DPA8Ri1-CoE_DEHlDAUshHlTKc20oVXMKtyLoHkgpkA=.b422b924-8edb-4bf5-bef6-20aaa3a605d3@github.com>

On Sun, 10 Mar 2024 14:40:09 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Fix whitespace
>  - Merge branch 'master' into master-cgroup
>    
>    Conflicts:
>    	test/hotspot/gtest/os/linux/test_cgroupSubsystem_linux.cpp
>  - Fix gtest
>  - Update the Java part
>  - Fix cgroup1 backward compatibility message
>  - Merge remote-tracking branch 'centos79/master-cgroup' into master-cgroup
>  - Disable cgroup.subtree_control testcase on cgroup1
>  - Fix gtest
>  - Merge branch 'master' into master-cgroup
>  - Merge remote-tracking branch 'f38crac/master-cgroup' into master-cgroup
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/243cb098...39c90162

Should I rebase it on top of the commit https://github.com/jerboaa/jdk/commit/92aaa6fd7e3ff8b64de064fecfcd725a157cb5bb or wait until you finish it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2085243290

From prappo at openjdk.org  Tue Apr 30 12:54:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 30 Apr 2024 12:54:04 GMT
Subject: RFR: 8278255: add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <x0vxRrQhxbysPCXRTZup2QQ8bRZhR7dlSkV_8NYmEMk=.824578bb-b18f-48eb-9259-87ba00c45b49@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
 <x0vxRrQhxbysPCXRTZup2QQ8bRZhR7dlSkV_8NYmEMk=.824578bb-b18f-48eb-9259-87ba00c45b49@github.com>
Message-ID: <8FiXkdnD7pZLj9gs5LBi7hmgCDUaI4FJOb7QlBoaWgo=.88423561-c7f4-4081-a2c0-c8988d56f7ce@github.com>

On Tue, 30 Apr 2024 12:38:02 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> @pavelrappo Wdyt?

I like it, but maybe native speakers who also write clearly could double check that change from _which_ to _that_? In no particular order: @DougLea, @AlanBateman, @stuart-marks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2085246810

From sgehwolf at openjdk.org  Tue Apr 30 13:23:09 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Apr 2024 13:23:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
Message-ID: <Pxlgl5zKFpS9FAPQcxgBbX-d7aIf13BcJosfG6Q2etU=.57e8c57e-3c4f-44e8-99ae-69b04c66a8bf@github.com>

On Sun, 10 Mar 2024 14:40:09 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Fix whitespace
>  - Merge branch 'master' into master-cgroup
>    
>    Conflicts:
>    	test/hotspot/gtest/os/linux/test_cgroupSubsystem_linux.cpp
>  - Fix gtest
>  - Update the Java part
>  - Fix cgroup1 backward compatibility message
>  - Merge remote-tracking branch 'centos79/master-cgroup' into master-cgroup
>  - Disable cgroup.subtree_control testcase on cgroup1
>  - Fix gtest
>  - Merge branch 'master' into master-cgroup
>  - Merge remote-tracking branch 'f38crac/master-cgroup' into master-cgroup
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/243cb098...39c90162

> Should I rebase it on top of the commit [jerboaa at 92aaa6f](https://github.com/jerboaa/jdk/commit/92aaa6fd7e3ff8b64de064fecfcd725a157cb5bb) or wait until you finish it?

Up to you. I'll keep you posted once the PRs are out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2085319806

From asotona at openjdk.org  Tue Apr 30 13:26:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 13:26:19 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v3]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <cQIT_b1jhjjlqszpj-IVZ4N1cSHsZ1yFmnSeivK5hxw=.e0063e4e-91ef-4edd-9f11-e7c4ae7b823f@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  changed order in allowed modules attributes check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/27238368..f0d9174e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=01-02

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

PR: https://git.openjdk.org/jdk/pull/19006

From jlahoda at openjdk.org  Tue Apr 30 14:04:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 30 Apr 2024 14:04:05 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <2nHfM1COmrjxJc8ZBGcUXhznnI9V2EW6JGh_aLiqSPY=.0794fe56-a40c-47f7-abca-a6bd44de68a5@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
 <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>
 <2nHfM1COmrjxJc8ZBGcUXhznnI9V2EW6JGh_aLiqSPY=.0794fe56-a40c-47f7-abca-a6bd44de68a5@github.com>
Message-ID: <xeHAVcoY67xg4AwDsabR6n33WwZ27aK-Pi39_mWL-jo=.158a6875-94d3-46fb-b8b7-49472f61a08d@github.com>

On Mon, 29 Apr 2024 20:21:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > Of course the question is if it should write to stderr or /dev/tty like mechanism..
> 
> I was wondering the same thing. My understanding of the definition of "console" is a bidirectional byte channel with a keyboard & screen on the other end. It has no concept of stdout vs. stderr. It just has a display (or in the old days, a printer).
> 
> The function of a "shell" is to intermediate between one or more executing programs and the console. It figures out how & when to actually display on the console any stuff written to stdout and/or stderr by one of the programs it has launched.
> 
> A program can also access its console (if any) directly by opening /dev/tty or whatever, thereby bypassing the shell.
> 
> So I would think writing to something called "System.console()" from Java (which is a program) would have nothing to do with Java's stderr or stdout, except for a possible downstream interleaving with what the shell may also be writing to the console at the same time.

I tried a few programs, like `mc`, `top` and `htop`. When I redirect the stdout for them, they still write into it (and there's obviously nothing on the terminal, and there are escape sequences in the target file of the redirect). The only program I know from the top of my head that (AFAIK) bypasses stdin/stdout and reaches directly to the controlling terminal is `ssh` when reading passwords (for quite obvious very special reasons).

I.e. not trying to be too smart about output, and simply using stdout as other programs do seems consistent, and most useful - the output can then be used in pipes, etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2085419986

From prappo at openjdk.org  Tue Apr 30 14:43:26 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 30 Apr 2024 14:43:26 GMT
Subject: RFR: 8331427: Rename confusingly named ArraysSupport.signedHashCode
Message-ID: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>

Please review this trivial method rename. While this issue was originally spotted in [another PR], it makes sense to address it separately. Test results are pending; not that I expect failures, but still.

[another PR]: https://github.com/openjdk/jdk/pull/14831#issuecomment-1655477396

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/19023/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19023&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331427
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19023/head:pull/19023

PR: https://git.openjdk.org/jdk/pull/19023

From acobbs at openjdk.org  Tue Apr 30 14:56:04 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 30 Apr 2024 14:56:04 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <xeHAVcoY67xg4AwDsabR6n33WwZ27aK-Pi39_mWL-jo=.158a6875-94d3-46fb-b8b7-49472f61a08d@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
 <w3lK-X2fkby_FgDkw7rf9IkbTHBYBxS4FAF6ew32fTM=.65404153-1b0c-4464-8771-c9dd91a83245@github.com>
 <2nHfM1COmrjxJc8ZBGcUXhznnI9V2EW6JGh_aLiqSPY=.0794fe56-a40c-47f7-abca-a6bd44de68a5@github.com>
 <xeHAVcoY67xg4AwDsabR6n33WwZ27aK-Pi39_mWL-jo=.158a6875-94d3-46fb-b8b7-49472f61a08d@github.com>
Message-ID: <y8sfYX4NzjvsKtgosTxwJByWwjjf20ftFxIxCkRy2GM=.230fcdd7-677d-43d2-96c6-e0e9759d827f@github.com>

On Tue, 30 Apr 2024 14:01:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I.e. not trying to be too smart about output, and simply using stdout as other programs do seems consistent, and most useful - the output can then be used in pipes, etc.

Totally reasonable. But the ssh example is telling - suppose for example someone wanted to implement something like ssh in Java. Would that person expect to be able to do what ssh does (accepting non-echoed passwords) by using `System.console()` ?

In other words, what exactly is `System.console()` supposed to represent? Maybe that question pinpoints the source of the ambiguity here. Of course, it will differ by O/S which adds to the challenge.

These questions are probably beyond the scope of this PR but you've got me curious :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2085559962

From jlahoda at openjdk.org  Tue Apr 30 15:02:21 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 30 Apr 2024 15:02:21 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v3]
In-Reply-To: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
Message-ID: <bJ99HAH1H96JfGviZb0bcGd5sKqTd0Pe06mgRxcG4Cc=.f1e8001f-1302-4385-be67-7686609ffa61@github.com>

> Consider code like:
> 
> public class ConsoleTest {
>     public static void main(String... args) {
>         System.console().printf("Hello!");
>     }
> }
> 
> 
> When run as:
> 
> $ java ConsoleTest.java >/dev/null
> 
> 
> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
> 
> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
> 
> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adjusting test, as suggested.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18996/files
  - new: https://git.openjdk.org/jdk/pull/18996/files/8a918e3f..76599ac9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18996&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18996&range=01-02

  Stats: 57 lines in 1 file changed: 6 ins; 35 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18996/head:pull/18996

PR: https://git.openjdk.org/jdk/pull/18996

From vklang at openjdk.org  Tue Apr 30 15:14:10 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 30 Apr 2024 15:14:10 GMT
Subject: Integrated: 8331346: Update PreviewFeature of STREAM_GATHERERS to
 JEP-473
In-Reply-To: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
Message-ID: <O5weTFB1plrm852t0BaOtJvqs-MYXd9zS_pTcnL-cVU=.767cbc5e-2b21-46a4-b2fb-1d3ebc786bcb@github.com>

On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

This pull request has now been integrated.

Changeset: 2cc8eccb
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cc8eccb360848f3ddf3259f1d943552f86234b9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473

Reviewed-by: pminborg, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19003

From asotona at openjdk.org  Tue Apr 30 15:37:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 15:37:15 GMT
Subject: RFR: 8331320: ClassFile API OutOfMemoryError with certain class files
Message-ID: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>

Class files with specifically corrupted tableswitch or lookupswitch instructions in the bytecode cause OutOfMemoryError while parsing with Class-File API.
This patch performs additional checks to avoid OOME and adds relevant tests.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - 8331320: ClassFile API OutOfMemoryError with certain class files

Changes: https://git.openjdk.org/jdk/pull/19024/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19024&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331320
  Stats: 60 lines in 2 files changed: 59 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19024/head:pull/19024

PR: https://git.openjdk.org/jdk/pull/19024

From tprinzing at openjdk.org  Tue Apr 30 15:42:15 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 30 Apr 2024 15:42:15 GMT
Subject: Integrated: 8329138: Convert JFR FileForceEvent to static mirror event
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <HasaqnpphS9XAn2WFGK11MNvLJeA9i2q51z19WCj1ds=.dbbe5e5d-ee14-4845-a58c-5849ec11bbee@github.com>

On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

This pull request has now been integrated.

Changeset: f4caac8d
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4caac8dea1c95234743712386cb28a1ecb11197
Stats:     280 lines in 12 files changed: 238 ins; 28 del; 14 mod

8329138: Convert JFR FileForceEvent to static mirror event

Reviewed-by: alanb, egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/18542

From alanb at openjdk.org  Tue Apr 30 16:00:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Apr 2024 16:00:07 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <TpIMJnCm76IYCVYaWfjm33Oj4lcUp2TmDs7ZVQF1Jog=.737e20ee-289f-4c9c-bdec-d7d9fd186f95@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
 <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
 <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>
 <_5zaiminpkaaX8Bwx4BhcULhyii-W0zCUswNab-aQVg=.19a2551a-b69c-4238-9aab-cffc3d9e9751@github.com>
 <TpIMJnCm76IYCVYaWfjm33Oj4lcUp2TmDs7ZVQF1Jog=.737e20ee-289f-4c9c-bdec-d7d9fd186f95@github.com>
Message-ID: <NgmecIALcnWDgow3gT1_aNsmNiQUmWUoxIpeNdxhQRY=.27919331-b39c-403d-8d17-0cde3b5d8e49@github.com>

On Mon, 29 Apr 2024 21:53:02 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Should I set the default to be fairly high (like maybe 1600ms)? I think to be useful people will have to set the threshold to something that fits their needs anyway.

I wonder about the usefulness of this event if the default threshold is so high. My guess is that it's rare to change the default threshold. To your question then I suppose this comes back to how this event might be used. Maybe it's worth writing down a few possible usages and that might help to inform if the threshold should be 20ms or something else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1585104188

From jlu at openjdk.org  Tue Apr 30 16:53:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 30 Apr 2024 16:53:10 GMT
Subject: Integrated: 8331207: Misleading example in DateFormat#parse docs
In-Reply-To: <PzYWWISxajrykTl0YTjEWeK0ZtpeMlB21RkfCvl_jX0=.628983e0-8e10-4400-8963-9b6e0b50bbac@github.com>
References: <PzYWWISxajrykTl0YTjEWeK0ZtpeMlB21RkfCvl_jX0=.628983e0-8e10-4400-8963-9b6e0b50bbac@github.com>
Message-ID: <eELBpstgUiR1ho8JGQ7Kitcf6O_GK-wKSgAPd_CN_VM=.19f5c735-7ca8-4434-8012-43257046939e@github.com>

On Fri, 26 Apr 2024 17:47:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Correct a misleading example in the DateFormat parse documentation. 
> 
> Common usage is to use a factory instance. The original example provided assumes a pattern provided by a COMPAT factory instance.
> 
> The pattern itself should be explicitly provided, since users may be using CLDR factory instances.

This pull request has now been integrated.

Changeset: a863ef5d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a863ef5d74e9001a143af4638422348ee946c939
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8331207: Misleading example in DateFormat#parse docs

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18983

From psandoz at openjdk.org  Tue Apr 30 18:20:54 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 30 Apr 2024 18:20:54 GMT
Subject: RFR: 8331320: ClassFile API OutOfMemoryError with certain class
 files
In-Reply-To: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>
References: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>
Message-ID: <4TYCNDjryMTitN8tYklgk875gEWN8d-JrA-i5hLLW_A=.bdb5aa44-2a56-43fc-ae64-9737c54b6472@github.com>

On Tue, 30 Apr 2024 15:31:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class files with specifically corrupted tableswitch or lookupswitch instructions in the bytecode cause OutOfMemoryError while parsing with Class-File API.
> This patch performs additional checks to avoid OOME and adds relevant tests.
> 
> Please review.
> 
> Thank you,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 320:

> 318:             int low = code.classReader.readInt(ap + 4);
> 319:             int high = code.classReader.readInt(ap + 8);
> 320:             if (high < low || high - low > code.codeLength >> 2) {

May be its also an opportunity to reduce duplication e.g., replace line 316 with a call to `afterPadding()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19024#discussion_r1585300727

From dl at openjdk.org  Tue Apr 30 19:44:52 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 30 Apr 2024 19:44:52 GMT
Subject: RFR: 8278255: Add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
Message-ID: <FbeaxqsS5SF9koVG-pHExVNRoWir-4kmJgu6VaOEt1g=.3ff0eff0-a80d-44b3-b955-63fcf3693912@github.com>

On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>   
>   Co-authored-by: Pavel Rappo <32523691+pavelrappo at users.noreply.github.com>

The grammar rules prefer "that" because it is a restrictive clause, even though "which" might sound better.  See for example: https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2086883300

From duke at openjdk.org  Tue Apr 30 22:03:59 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Tue, 30 Apr 2024 22:03:59 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 <NC3E6wpsavqRXUqdgNHh3y26lFSIPXoA0yi
 KcV_2CyI=.391c9553-458a-417f-b86d-2c88dacf7df1@github.com>
 <Kc8tP6_hlFmF_NqcwSHEX6NF9atmoeglRsRFTrLaA5A=.bacb4a7d-26cb-4fdc-8f7b-f883587cd58c@github.com>
 <xrA2rqmjQ-gHGaZ23SQIYZCgda6sHslW2oHIqQxyM2Y=.f4ae4438-78b0-4eb1-b4aa-ed461c31ef1f@github.com>
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
 <hSP68W3vGCfGCOlUCf84DDw0qzt9Z7d-56LKLALocYo=.6c507f84-037d-449f-b4f6-f8c9771e6409@github.com>
 <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@github.com>
 <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>
 <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
 <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>
 <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>
Message-ID: <z094CbYeWxVsMZ8s2_54mVC8fD_p67gSGyJxeiTZuVE=.78b39116-a5ad-4f03-ac15-7e3a09dc180e@github.com>

On Sun, 21 Apr 2024 04:37:45 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Could you please run the new benchmarking?
>> To save time and don't patch JDK several times, I've created JavaBenchmarkHarness
>> class which is under package java.util and compares several versions of DPQS.
>> Also I prepared several versions of current sorting source from JDK to detect what is going wrong.
>> 
>> What you need is to compile and run JavaBenchmarkHarness once:
>> 
>> javac --patch-module java.base=. -d classes *.java
>> java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness
>> 
>> Find the sources there:
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java  
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_ins.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_mrg.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_piv.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01_prt.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r29p.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r29p5.java
>> 
>> Thank you,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> Please see the data below:
> 
> Thanks,
> Vamsi
> 
> 
> 
> name | builder | size | mode | count | score
> -- | -- | -- | -- | -- | --
> b01 | RANDOM | 600 | avg | 325677 | 6.862
> b01 | RANDOM | 3000 | avg | 52041 | 82.233
> b01 | RANDOM | 90000 | avg | 1217 | 4456.51
> b01 | RANDOM | 400000 | avg | 242 | 22923.28
> b01 | RANDOM | 1000000 | avg | 90 | 60598.84
> b01 | REPEATED | 600 | avg | 651354 | 1.933
> b01 | REPEATED | 3000 | avg | 104083 | 13.753
> b01 | REPEATED | 90000 | avg | 2435 | 723.039
> b01 | REPEATED | 400000 | avg | 484 | 3084.416
> b01 | REPEATED | 1000000 | avg | 180 | 8234.428
> b01 | STAGGER | 600 | avg | 1954062 | 1.005
> b01 | STAGGER | 3000 | avg | 312251 | 4.945
> b01 | STAGGER | 90000 | avg | 7305 | 133.126
> b01 | STAGGER | 400000 | avg | 1453 | 592.144
> b01 | STAGGER | 1000000 | avg | 542 | 1493.876
> b01 | SHUFFLE | 600 | avg | 325677 | 5.12
> b01 | SHUFFLE | 3000 | avg | 52041 | 29.252
> b01 | SHUFFLE | 90000 | avg | 1217 | 1396.664
> b01 | SHUFFLE | 400000 | avg | 242 | 5743.489
> b01 | SHUFFLE | 1000000 | avg | 90 | 15490.81
> b01_ins | RANDOM | 600 | avg | 325677 | 7.594
> b01_ins | RANDOM | 3000 | avg | 52041 | 78.631
> b01_ins | RANDOM | 90000 | avg | 1217 | 4312.511
> b01_ins | RANDOM | 400000 | avg | 242 | 22108.18
> b01_ins | RANDOM | 1000000 | avg | 90 | 58467.16
> b01_ins | REPEATED | 600 | avg | 651354 | 1.569
> b01_ins | REPEATED | 3000 | avg | 104083 | 11.313
> b01_ins | REPEATED | 90000 | avg | 2435 | 720.838
> b01_ins | REPEATED | 400000 | avg | 484 | 3003.673
> b01_ins | REPEATED | 1000000 | avg | 180 | 8144.944
> b01_ins | STAGGER | 600 | avg | 1954062 | 0.98
> b01_ins | STAGGER | 3000 | avg | 312251 | 4.948
> b01_ins | STAGGER | 90000 | avg | 7305 | 132.909
> b01_ins | STAGGER | 400000 | avg | 1453 | 592.572
> b01_ins | STAGGER | 1000000 | avg | 542 | 1492.627
> b01_ins | SHUFFLE | 600 | avg | 325677 | 4.092
> b01_ins | SHUFFLE | 3000 | avg | 52041 | 27.138
> b01_ins | SHUFFLE | 90000 | avg | 1217 | 1304.326
> b01_ins | SHUFFLE | 400000 | avg | 242 | 5465.745
> b01_ins | SHUFFLE | 1000000 | avg | 90 | 14585.08
> b01_mrg | RANDOM | 600 | avg | 325677 | 7.139
> b01_mrg | RANDOM | 3000 | avg | 52041 | 81.01
> b01_mrg | RANDOM | 90000 | avg | 1217 | 4266.084
> b01_mrg | RANDOM | 400000 | avg | 242 | 21937.77
> b01_mrg | RANDOM | 1000000 | avg | 90 | 58177.72
> b01_mrg | REPEATED | 600 | avg | 651354 | 1.36
> b01_mrg | REPEATED | 3000 | avg | 104083 | 9.013
> b01_mrg | REPEATED | 90000 | avg | 2435 | 737.684
> b01_mrg | REPEATED | 400000 | avg | 484 | 3152.447
> b01_mrg | REPEATED | 1000000 | avg |...

Hello Vamsi (@vamsi-parasa),

Could you please run the new benchmarking to detect the best case
for Radix sort and parallel sorting?

What you need is to compile and run JavaBenchmarkHarness:

javac --patch-module java.base=. -d classes *.java
java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness

Find the sources there:

https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_a.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_11.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_12.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_13.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_14.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_21.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_23.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java

Thank you,
Vladimir

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2087504178

From imediava at gmail.com  Wed Apr 24 14:51:52 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Wed, 24 Apr 2024 16:51:52 +0200
Subject: Looking for a sponsor to help with my first contribution
Message-ID: <CA+wBRWAzJSU_GTogz7f_PBu+PPrhaZahuHJiy3jkeegPnq7y2A@mail.gmail.com>

Hello,

For my first contribution to OpenJDK, I've started looking into
JDK-8313674, an issue that falls into core-libs. According to the OpenJDK
Developers? Guide I'd need a sponsor to help me through the contribution
process, would anyone be available to help me ?

Thanks in advance

??igo Mediavilla Saiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240424/c61b17a9/attachment.htm>

From imediava at gmail.com  Thu Apr 25 04:23:32 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Thu, 25 Apr 2024 06:23:32 +0200
Subject: Need for a sponsor for JDK-8313674
Message-ID: <CA+wBRWAESfCOEB0=Oj7gr=PtVBd3qgvSxFEfNocbFg4TNKhSAw@mail.gmail.com>

Hello,

For my first contribution to OpenJDK, I've started looking into
JDK-8313674, an issue that falls into core-libs. According to the OpenJDK
Developers? Guide I'd need a sponsor to help me through the contribution
process, would anyone be available to help me ?

Thanks in advance

??igo Mediavilla Saiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240425/85d1b554/attachment.htm>