From duke at openjdk.org  Fri Mar  1 00:04:57 2024
From: duke at openjdk.org (duke)
Date: Fri, 1 Mar 2024 00:04:57 GMT
Subject: Withdrawn: 6356745: (coll) Add PriorityQueue(Collection, Comparator)
In-Reply-To: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
References: <zAcGyJ33ZP0osNg-HMJp4UCtOXYzdqi969ugDhJ7954=.c5f8e2de-cfe8-4224-a98e-70f49da9a7a3@github.com>
Message-ID: <wHAR9NOHuEd8B5KDKXI2M0gF6B2eA1vT_oriHiVnwrs=.8ca333c6-8d85-41a7-bc2c-c0e1ad47fc86@github.com>

On Mon, 11 Dec 2023 01:28:29 GMT, Valeh Hajiyev <duke at openjdk.org> wrote:

> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times).  This is resulting in an overall time complexity of `O(nlogn)`. 
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(customComparator);
> pq.addAll(existingCollection);
> 
> 
> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`.  If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later  `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time.
> 
> 
> PriorityQueue<String> pq = new PriorityQueue<>(existingCollection, customComparator);

This pull request has been closed without being integrated.

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

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

From jlu at openjdk.org  Fri Mar  1 01:05:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Mar 2024 01:05:14 GMT
Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for
 invalid patterns [v6]
In-Reply-To: <S0h5X3J918JmJvvNLa3VVAo_p0JZGgqD6PemhQ_W_pc=.49ebe3b9-5f80-4523-9a31-deed19cde778@github.com>
References: <S0h5X3J918JmJvvNLa3VVAo_p0JZGgqD6PemhQ_W_pc=.49ebe3b9-5f80-4523-9a31-deed19cde778@github.com>
Message-ID: <MKdVlFyU_07-a02drAMj08IKnUfVgmSTIa5xmPQUbAA=.f9e92e83-2319-47f3-9531-7a2dcb0d1350@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
> 
> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
> 
> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
> 
> 
> // no limit -> throws an expected IllegalArgumentException
> var a = new ChoiceFormat("#foo");
> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
> b.format(2); // returns 'bar'
> // no relation or limit -> discards the incorrect portion, 'foo' and continues
> var c = new ChoiceFormat("foo");
> c.format(1); // throws AIOOBE

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

  wording: punctuation and use 'constructor'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17856/files
  - new: https://git.openjdk.org/jdk/pull/17856/files/8e5bbe05..aa1071e2

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

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

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

From vpetko at openjdk.org  Fri Mar  1 03:18:13 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 1 Mar 2024 03:18:13 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <YIvK3rTRYMZuxuhA1Mj07GiifDzMJqe1zt-iIdKJEZw=.6759466b-17fc-4a7f-a073-9dd0e24bc8b9@github.com>
References: <YIvK3rTRYMZuxuhA1Mj07GiifDzMJqe1zt-iIdKJEZw=.6759466b-17fc-4a7f-a073-9dd0e24bc8b9@github.com>
Message-ID: <5ZQv4MgJ-phpMHe3hBVedyK9Zatgn-E9n0vmjVaAWI0=.73a26163-2434-4ebf-9ee0-b7a97dd54bcc@github.com>

On Fri, 1 Mar 2024 01:50:46 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This MR fixes segsegv in jspawnhelper when it is called without args. 
> This scenario happens when a long running Java process is not restarted during upgrade. 
> 
> It updates test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java to check that jspawnhelper exits with code 1:
> 
> After test update:
> 
> $ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
> ...
> Running jspawnhelper without args
> STDERR:
> java.lang.Exception: Parent process exited with 12
>         at JspawnhelperProtocol.simulateJspawnhelperWithoutArgs(JspawnhelperProtocol.java:126)
>         at JspawnhelperProtocol.main(JspawnhelperProtocol.java:267)
>         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)
> ...
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>>>                                                       1     0     1     0 <<
> ==============================
> TEST FAILURE
> 
> After jspawnhelper change the test passes:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> The user will see the following output in the logs:
> 
> An earlier version of Java is trying to call jspawnhelper.
> Please restart Java process.
> Exception in thread "main" java.io.IOException: Cannot run program "ls": error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
>         at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
>         at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
>         at Test.main(Test.java:3)
> Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
>         at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
>         at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
>         at java.base/java.lang.ProcessIm...

Manual test:


public class Test {
    public static void main(String[] args) throws Throwable {
        Process p = new ProcessBuilder("ls", "-alrt", "/tmp").start();
        p.waitFor();
    }
}

Running older java with a new jspawnhelper will result in the following output:

java --version
openjdk 17.0.9-internal 2023-10-17
OpenJDK Runtime Environment (build 17.0.9-internal+0-adhoc.vladimirp.jdk17u)
OpenJDK 64-Bit Server VM (build 17.0.9-internal+0-adhoc.vladimirp.jdk17u, mixed mode)

$ ./java -cp . Test
An earlier version of Java is trying to call jspawnhelper.
Please restart Java process.
Exception in thread "main" java.io.IOException: Cannot run program "ls": error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
        at Test.main(Test.java:3)
Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
        at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
        at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
        at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:244)
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)

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

PR Comment: https://git.openjdk.org/jdk/pull/18074#issuecomment-1972308222

From vpetko at openjdk.org  Fri Mar  1 03:18:12 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 1 Mar 2024 03:18:12 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
Message-ID: <YIvK3rTRYMZuxuhA1Mj07GiifDzMJqe1zt-iIdKJEZw=.6759466b-17fc-4a7f-a073-9dd0e24bc8b9@github.com>

This MR fixes segsegv in jspawnhelper when it is called without args. 
This scenario happens when a long running Java process is not restarted during upgrade. 

It updates test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java to check that jspawnhelper exits with code 1:

After test update:

$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
...
Running jspawnhelper without args
STDERR:
java.lang.Exception: Parent process exited with 12
        at JspawnhelperProtocol.simulateJspawnhelperWithoutArgs(JspawnhelperProtocol.java:126)
        at JspawnhelperProtocol.main(JspawnhelperProtocol.java:267)
        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)
...
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>>                                                       1     0     1     0 <<
==============================
TEST FAILURE

After jspawnhelper change the test passes:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
                                                         1     1     0     0   
==============================
TEST SUCCESS


The user will see the following output in the logs:

An earlier version of Java is trying to call jspawnhelper.
Please restart Java process.
Exception in thread "main" java.io.IOException: Cannot run program "ls": error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
        at Test.main(Test.java:3)
Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
        at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
        at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
        at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:244)
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)

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

Commit messages:
 - update copyright year
 - handle no-args call in jspawnhelper
 - update JspawnhelperProtocol.java to test jspawnhelper call without args

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

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

From dholmes at openjdk.org  Fri Mar  1 06:32:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 1 Mar 2024 06:32:51 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries
In-Reply-To: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
Message-ID: <Eq24XtDRZm8WMIbGI9-U7aphH-MWJIihgvVXVFUkHEE=.eb8c0d69-7cc2-488c-97ea-1e8895ccd746@github.com>

On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
> 
> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
> 
> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
> 
> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".

test/jdk/tools/launcher/RunpathTest.java line 27:

> 25:  * @test
> 26:  * @bug 7190813 8022719
> 27:  * @summary Check for extended RPATHs on Linux

Pre-existing but really the restriction to Linux should be via `@requires` not a runtime test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1508535229

From alanb at openjdk.org  Fri Mar  1 07:39:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Mar 2024 07:39:51 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <YIvK3rTRYMZuxuhA1Mj07GiifDzMJqe1zt-iIdKJEZw=.6759466b-17fc-4a7f-a073-9dd0e24bc8b9@github.com>
References: <YIvK3rTRYMZuxuhA1Mj07GiifDzMJqe1zt-iIdKJEZw=.6759466b-17fc-4a7f-a073-9dd0e24bc8b9@github.com>
Message-ID: <8ZFH2fi-ZkCdcaM-3wzSvvQGqlucidg6ZIXzyEuarJ8=.21c53722-75b4-4627-a4b3-847d94636951@github.com>

On Fri, 1 Mar 2024 01:50:46 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This MR fixes segsegv in jspawnhelper when it is called without args. 
> This scenario happens when a long running Java process is not restarted during upgrade. 
> 
> It updates test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java to check that jspawnhelper exits with code 1:
> 
> After test update:
> 
> $ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
> ...
> Running jspawnhelper without args
> STDERR:
> java.lang.Exception: Parent process exited with 12
>         at JspawnhelperProtocol.simulateJspawnhelperWithoutArgs(JspawnhelperProtocol.java:126)
>         at JspawnhelperProtocol.main(JspawnhelperProtocol.java:267)
>         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)
> ...
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>>>                                                       1     0     1     0 <<
> ==============================
> TEST FAILURE
> 
> After jspawnhelper change the test passes:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> The user will see the following output in the logs:
> 
> An earlier version of Java is trying to call jspawnhelper.
> Please restart Java process.
> Exception in thread "main" java.io.IOException: Cannot run program "ls": error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
>         at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
>         at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
>         at Test.main(Test.java:3)
> Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
>         at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
>         at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
>         at java.base/java.lang.ProcessIm...

Would it be possible to expand a bit on what is going on here? Are you saying that in the course of upgrading a JDK that you somehow get into a state where jspawnhelper has been replaced with a version from a newer JDK? Is the real issue here that the upgrade didn't shutdown the application and/or something copied over an existing installation during the upgrade?

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

PR Comment: https://git.openjdk.org/jdk/pull/18074#issuecomment-1972674199

From vpetko at openjdk.org  Fri Mar  1 08:02:48 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 1 Mar 2024 08:02:48 GMT
Subject: Withdrawn: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <YIvK3rTRYMZuxuhA1Mj07GiifDzMJqe1zt-iIdKJEZw=.6759466b-17fc-4a7f-a073-9dd0e24bc8b9@github.com>
References: <YIvK3rTRYMZuxuhA1Mj07GiifDzMJqe1zt-iIdKJEZw=.6759466b-17fc-4a7f-a073-9dd0e24bc8b9@github.com>
Message-ID: <SdfvtkqNRtK1zn8VeVOxVN_fXG64cpbQVfXPWYSPA9E=.e9ed996a-505e-4313-a633-a737cbeadce6@github.com>

On Fri, 1 Mar 2024 01:50:46 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This MR fixes segsegv in jspawnhelper when it is called without args. 
> This scenario happens when a long running Java process is not restarted during upgrade. 
> 
> It updates test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java to check that jspawnhelper exits with code 1:
> 
> After test update:
> 
> $ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
> ...
> Running jspawnhelper without args
> STDERR:
> java.lang.Exception: Parent process exited with 12
>         at JspawnhelperProtocol.simulateJspawnhelperWithoutArgs(JspawnhelperProtocol.java:126)
>         at JspawnhelperProtocol.main(JspawnhelperProtocol.java:267)
>         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)
> ...
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>>>                                                       1     0     1     0 <<
> ==============================
> TEST FAILURE
> 
> After jspawnhelper change the test passes:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> The user will see the following output in the logs:
> 
> An earlier version of Java is trying to call jspawnhelper.
> Please restart Java process.
> Exception in thread "main" java.io.IOException: Cannot run program "ls": error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
>         at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
>         at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
>         at Test.main(Test.java:3)
> Caused by: java.io.IOException: error=0, Failed to exec spawn helper: pid: 2168121, exit value: 1
>         at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
>         at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
>         at java.base/java.lang.ProcessIm...

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Fri Mar  1 08:07:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 1 Mar 2024 08:07:52 GMT
Subject: RFR: 8326591: New test JmodExcludedFiles.java fails on Windows
 when --with-external-symbols-in-bundles=public is used
In-Reply-To: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com>
References: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com>
Message-ID: <eeukNc_xy0MLHFZ7MM7-SJeFhJADCkLUV5XwVIRJ58s=.cb1869a0-fbe7-487f-b8d4-d7bc4e29cec3@github.com>

On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The new test JmodExcludedFiles.java checks that no debug symbol files are contained in the jmod files. It does not take into account that with configure option --with-external-symbols-in-bundles=public we want to have stripped pdb files, also in jmods, to get native callstacks with line number.
> 
> This modifies the test and checks if equivalent *stripped.pdb files exist when .pdb files are encountered inside jmods. In that case one can assume that --with-external-symbols-in-bundles=public was chosen as configure option.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17990#pullrequestreview-1910541971

From clanger at openjdk.org  Fri Mar  1 10:44:14 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 1 Mar 2024 10:44:14 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v7]
In-Reply-To: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
Message-ID: <r__SpoJaRXPAH-aJNSrMxetk4OkTGCILvAcDVRRxSxo=.53101fde-2aaa-4368-ba56-89167be8ad53@github.com>

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

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

 - Indentation
 - Merge branch 'master' into JDK-8325579
 - Review feedback
 - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
 - Merge branch 'master' into JDK-8325579
 - Typo
 - Merge branch 'master' into JDK-8325579
 - Rename test and refine comment
 - Enhance test
 - JDK-8325579

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17797/files
  - new: https://git.openjdk.org/jdk/pull/17797/files/ec6579d2..97299970

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

  Stats: 17321 lines in 1249 files changed: 9833 ins; 3144 del; 4344 mod
  Patch: https://git.openjdk.org/jdk/pull/17797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17797/head:pull/17797

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

From lancea at openjdk.org  Fri Mar  1 11:47:45 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 1 Mar 2024 11:47:45 GMT
Subject: RFR: 8326915: NPE when a validating parser is restricted
In-Reply-To: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
References: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
Message-ID: <EfwKix7_eNRTUL0oo9wQApfdQ5LF2HkrpkJDSyx7Aps=.39e56581-4f67-468d-8610-2a559f26bc45@github.com>

On Thu, 29 Feb 2024 21:00:09 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a NPE when a validating parser is restricted by the JDKCatalog resolve property. Also slightly improved the error msg with the catalog name.
> 
> Test: new test added
>          existing test CatalogSupport5 would fail without the Null check on ErrorReporter. It's a separate issue not covered by this fix.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18071#pullrequestreview-1910945957

From mdonovan at openjdk.org  Fri Mar  1 12:25:47 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 1 Mar 2024 12:25:47 GMT
Subject: Integrated: 8319648: java/lang/SecurityManager tests ignore vm flags
In-Reply-To: <8QF-ychCHq3eRcsTlZqFqP68z2NApgazCTWyaDaP2iY=.e261430a-7cff-425a-ba7d-26b7f44fd0bc@github.com>
References: <8QF-ychCHq3eRcsTlZqFqP68z2NApgazCTWyaDaP2iY=.e261430a-7cff-425a-ba7d-26b7f44fd0bc@github.com>
Message-ID: <35Wa6Y9xS7-JCipGz3Dl2fb56SU2rtclwfExHrigfik=.c4c55d4b-95eb-4f39-907a-d07d7bc79241@github.com>

On Thu, 15 Feb 2024 17:06:25 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder methods to pass VM options to child processes.

This pull request has now been integrated.

Changeset: 437cf354
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/437cf354e2d1f7df79fa32265ccf86a0e84257b5
Stats:     9 lines in 2 files changed: 1 ins; 3 del; 5 mod

8319648: java/lang/SecurityManager tests ignore vm flags

Reviewed-by: mullan

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

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

From mbaesken at openjdk.org  Fri Mar  1 12:48:46 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 1 Mar 2024 12:48:46 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3]
In-Reply-To: <dfVSb3btAYBD76FUI6qLae7Ow08TqyrnLTirf04lt3Y=.ef572cec-2377-440d-aac1-91bbde6a31d0@github.com>
References: <c5aISQVkHj2YxC5I6658UL_ET8z6eQbycgI-vmWCsuY=.083d3ae2-c536-421d-9483-c943871d74e2@github.com>
 <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
 <dfVSb3btAYBD76FUI6qLae7Ow08TqyrnLTirf04lt3Y=.ef572cec-2377-440d-aac1-91bbde6a31d0@github.com>
Message-ID: <5ggdUMnCI1WG_mJ2wnyG1SwfYH-oZzMrYGEWtjyFCXc=.b08545c4-de75-4b34-a0de-82edc29a97ef@github.com>

On Mon, 26 Feb 2024 06:57:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello David, the updated text that I proposed to Matthias, of the form "expected: ... but was: ..." was borrowed from what junit5

Unfortunately we get now error messages like this 

java.lang.RuntimeException: VM output should contain exactly one rtm locking statistics entry for method compiler.testlibrary.rtm.XAbortProvoker::forceAbort expected: 0 but was: 1

It should be ... expected: 1 but was: 0 ; the assertEquals has this interface `assertEquals(Object lhs, Object rhs, String msg)`  so we have a left hand (lhs) and a right hand side (rhs) of a comparison but was is expected and what is what we got is not defined  .

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

PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1973131407

From erikj at openjdk.org  Fri Mar  1 13:58:08 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Mar 2024 13:58:08 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v2]
In-Reply-To: <Eq24XtDRZm8WMIbGI9-U7aphH-MWJIihgvVXVFUkHEE=.eb8c0d69-7cc2-488c-97ea-1e8895ccd746@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <Eq24XtDRZm8WMIbGI9-U7aphH-MWJIihgvVXVFUkHEE=.eb8c0d69-7cc2-488c-97ea-1e8895ccd746@github.com>
Message-ID: <cvpZOfMJ48JpCclzAOzCJ-tCWTBjMJap__3j4-k4pLw=.884f5938-7286-4849-a42c-0f55cbb20693@github.com>

On Fri, 1 Mar 2024 06:30:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use @requires in test
>
> test/jdk/tools/launcher/RunpathTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 7190813 8022719
>> 27:  * @summary Check for extended RPATHs on Linux
> 
> Pre-existing but really the restriction to Linux should be via `@requires` not a runtime test.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1509047068

From erikj at openjdk.org  Fri Mar  1 13:58:08 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Mar 2024 13:58:08 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v2]
In-Reply-To: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
Message-ID: <XDxNanHeNzR08co4WxsSrG31-FkPN15RBWpgE4kE9fU=.506115fc-247b-4838-add6-d4fcfdabbcde@github.com>

> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
> 
> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
> 
> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
> 
> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".

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

  Use @requires in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18050/files
  - new: https://git.openjdk.org/jdk/pull/18050/files/749a95f9..592281f2

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

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

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

From rgiulietti at openjdk.org  Fri Mar  1 14:36:52 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 1 Mar 2024 14:36:52 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v8]
In-Reply-To: <lLQUfUOGoOwH8IuW8WmEdhvhOAEYVgTFWXZLWDLyFVE=.75975414-1a07-4421-8ea2-4ac333e72dc6@github.com>
References: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
 <lLQUfUOGoOwH8IuW8WmEdhvhOAEYVgTFWXZLWDLyFVE=.75975414-1a07-4421-8ea2-4ac333e72dc6@github.com>
Message-ID: <PDoESB3SQ7_JQ3XdSxVvEdDylEjoePWKk4_U3zC-SyY=.66a43729-cd8d-43a0-ab35-946fd8253185@github.com>

On Wed, 28 Feb 2024 06:08:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A new paper
>> 
>>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>> 
>> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback, adjust worst-case bounds.

Tests.java L:111 should read

     * @param d floating-point number whose exponent is to be extracted

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

PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1973309784

From mli at openjdk.org  Fri Mar  1 15:01:00 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 1 Mar 2024 15:01:00 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <PtAhe54HuLaDb9Rafryn3EFaN_HdZpDNQ4VT1WwQtAs=.4afaccf5-f1b6-4a60-b292-f10372ace4fb@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

Just a quick update, I've rebased the code, and will continue the work soon.

I've looked through the previous discussion, seems there is no blocking issues, if I misunderstood or miss some information, please feel free to let me know, also if you have any further comment. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1973345855

From ihse at openjdk.org  Fri Mar  1 15:12:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Mar 2024 15:12:59 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <A-67wzy3_Jpj9tsxMMbMArjhDKjxhs19o6cYlJxMB7o=.2324e91d-b5c9-407a-a33c-f3b6bf959422@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

Iirc, your assessment is right; the code should be ready for integration; I just don't know about the state of testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1973364027

From rgiulietti at openjdk.org  Fri Mar  1 16:38:57 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 1 Mar 2024 16:38:57 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v8]
In-Reply-To: <lLQUfUOGoOwH8IuW8WmEdhvhOAEYVgTFWXZLWDLyFVE=.75975414-1a07-4421-8ea2-4ac333e72dc6@github.com>
References: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
 <lLQUfUOGoOwH8IuW8WmEdhvhOAEYVgTFWXZLWDLyFVE=.75975414-1a07-4421-8ea2-4ac333e72dc6@github.com>
Message-ID: <QH1vwE6rzfhTOoXUnFh2ghsNaswbaKRFk9aW_AOxZ_0=.57130b15-1051-43cf-ad8b-fb1eab9f98e1@github.com>

On Wed, 28 Feb 2024 06:08:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A new paper
>> 
>>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>> 
>> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback, adjust worst-case bounds.

test/jdk/java/lang/Math/WorstCaseTests.java line 35:

> 33: 
> 34: /**
> 35:  * This test containst two distinct kinds of worst-case inputs:

Suggestion:

 * This test contains two distinct kinds of worst-case inputs:

test/jdk/java/lang/Math/WorstCaseTests.java line 39:

> 37:  * 1) Exact numerical results that are nearly half-way between
> 38:  * representable numbers or very close to a representable
> 39:  * number. (Half-way caess are hardest for round to nearest even;

Suggestion:

 * number. (Half-way cases are hardest for round to nearest even;

test/jdk/java/lang/Math/WorstCaseTests.java line 43:

> 41:  * roundings.)
> 42:  *
> 43:  * 2) Worst-case errors as observed emprically across different

Suggestion:

 * 2) Worst-case errors as observed empirically across different

test/jdk/java/lang/Math/WorstCaseTests.java line 46:

> 44:  * implementations that are not correctly rounded.
> 45:  *
> 46:  * For the first categpory, the "Table Maker's Dilemma" results from

Suggestion:

 * For the first category, the "Table Maker's Dilemma" results from

test/jdk/java/lang/Math/WorstCaseTests.java line 48:

> 46:  * For the first categpory, the "Table Maker's Dilemma" results from
> 47:  * Jean-Michel Muller and Vincent Lef&egrave;vre, are used.
> 48:  * See http://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original

Suggestion:

 * See https://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original

test/jdk/java/lang/Math/WorstCaseTests.java line 50:

> 48:  * See http://perso.ens-lyon.fr/jean-michel.muller/TMD.html for original
> 49:  * test vectors from 2000 and see
> 50:  * http://perso.ens-lyon.fr/jean-michel.muller/TMDworstcases.pdf with

Suggestion:

 * https://perso.ens-lyon.fr/jean-michel.muller/TMDworstcases.pdf with

test/jdk/java/lang/Math/WorstCaseTests.java line 245:

> 243:             {-0x1.842d8ec8f752fp+21,    -0x1.6ce864edeaffdp-1},
> 244:             {-0x1.07e4c92b5349dp+4,     +0x1.6a096375ffb23p-1},
> 245:             // {-0x1.13a5ccd87c9bbp+1008,  -0x1.27b3964185d8dp-1}, // check -- need +/-

High-precision computations confirm `-0x1.27b3964185d8dp-1`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1509239002
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1509239088
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1509239189
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1509239253
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1509239477
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1509239558
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1509239711

From naoto at openjdk.org  Fri Mar  1 17:05:43 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Mar 2024 17:05:43 GMT
Subject: RFR: 8326915: NPE when a validating parser is restricted
In-Reply-To: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
References: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
Message-ID: <hbcWVkUM5Uk7oKYDBRAxH2ElIbWAehpsyNXn04gaXa4=.982065ce-0c9f-4ba1-971a-d6f5c65c4fb0@github.com>

On Thu, 29 Feb 2024 21:00:09 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a NPE when a validating parser is restricted by the JDKCatalog resolve property. Also slightly improved the error msg with the catalog name.
> 
> Test: new test added
>          existing test CatalogSupport5 would fail without the Null check on ErrorReporter. It's a separate issue not covered by this fix.

LGTM

src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java line 402:

> 400:         int i = input.lastIndexOf('/');
> 401:         if (i > 0) {
> 402:             return input.substring(i+1, input.length());

Nit: the second argument is not needed.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18071#pullrequestreview-1910127344
PR Review Comment: https://git.openjdk.org/jdk/pull/18071#discussion_r1508361029

From darcy at openjdk.org  Fri Mar  1 18:01:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 1 Mar 2024 18:01:11 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v9]
In-Reply-To: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
References: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
Message-ID: <n0DkZXE9xWi9_E6ndT8uzpfN0JcX2QD3fT6mafa3nWg=.1c58f24a-1e77-429c-9610-59590b507abe@github.com>

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

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 18 additional commits since the last revision:

 - Respond to review feedback and fix typos.
 - Merge branch 'master' into JDK-8316708
 - Respond to review feedback, adjust worst-case bounds.
 - Appease jcheck.
 - Update atan2 and hypot tests.
 - Expand fingerprinting to more StrictMath tests.
 - Fix missing minus sign.
 - Checkpoint.
 - Checkpoint StrictMath test for trig, inverse trig, and hyperbolic trig fingerprint values.
 - Add cos test cases.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/fd67967c...e705e10a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15879/files
  - new: https://git.openjdk.org/jdk/pull/15879/files/98c8e69f..e705e10a

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

  Stats: 6391 lines in 800 files changed: 3300 ins; 1492 del; 1599 mod
  Patch: https://git.openjdk.org/jdk/pull/15879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15879/head:pull/15879

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

From joehw at openjdk.org  Fri Mar  1 18:02:24 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 1 Mar 2024 18:02:24 GMT
Subject: RFR: 8326915: NPE when a validating parser is restricted [v2]
In-Reply-To: <hbcWVkUM5Uk7oKYDBRAxH2ElIbWAehpsyNXn04gaXa4=.982065ce-0c9f-4ba1-971a-d6f5c65c4fb0@github.com>
References: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
 <hbcWVkUM5Uk7oKYDBRAxH2ElIbWAehpsyNXn04gaXa4=.982065ce-0c9f-4ba1-971a-d6f5c65c4fb0@github.com>
Message-ID: <RuCKNW1PMThoO3FQfF7MNMlim4dJJsp-KVefZI-N_Qc=.19c5ae5d-10c8-41ea-ba68-722b8213cbff@github.com>

On Fri, 1 Mar 2024 00:53:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   input.substring second argument not needed; proper test method name
>
> src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java line 402:
> 
>> 400:         int i = input.lastIndexOf('/');
>> 401:         if (i > 0) {
>> 402:             return input.substring(i+1, input.length());
> 
> Nit: the second argument is not needed.

Thanks. Fixed. Also replaced the test's method name with a proper name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18071#discussion_r1509351975

From joehw at openjdk.org  Fri Mar  1 18:02:24 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 1 Mar 2024 18:02:24 GMT
Subject: RFR: 8326915: NPE when a validating parser is restricted [v2]
In-Reply-To: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
References: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
Message-ID: <jEBPvSD71ig3MAOGmvbiDWuF4GGbXp4TaCvJea8s1HU=.11df3351-71e5-42d0-817c-bff58a68d5ed@github.com>

> Fix a NPE when a validating parser is restricted by the JDKCatalog resolve property. Also slightly improved the error msg with the catalog name.
> 
> Test: new test added
>          existing test CatalogSupport5 would fail without the Null check on ErrorReporter. It's a separate issue not covered by this fix.

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

  input.substring second argument not needed; proper test method name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18071/files
  - new: https://git.openjdk.org/jdk/pull/18071/files/6efb3c22..d847cf5d

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

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

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

From rgiulietti at openjdk.org  Fri Mar  1 18:06:54 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 1 Mar 2024 18:06:54 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v9]
In-Reply-To: <n0DkZXE9xWi9_E6ndT8uzpfN0JcX2QD3fT6mafa3nWg=.1c58f24a-1e77-429c-9610-59590b507abe@github.com>
References: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
 <n0DkZXE9xWi9_E6ndT8uzpfN0JcX2QD3fT6mafa3nWg=.1c58f24a-1e77-429c-9610-59590b507abe@github.com>
Message-ID: <snN7eQUPuAA7__2XJMcv5C9tzOsx8m-DLC-vv2-0QR0=.c6bfe14c-8be2-4830-8fca-4893956f2a3d@github.com>

On Fri, 1 Mar 2024 18:01:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A new paper
>> 
>>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>> 
>> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.
>
> 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 18 additional commits since the last revision:
> 
>  - Respond to review feedback and fix typos.
>  - Merge branch 'master' into JDK-8316708
>  - Respond to review feedback, adjust worst-case bounds.
>  - Appease jcheck.
>  - Update atan2 and hypot tests.
>  - Expand fingerprinting to more StrictMath tests.
>  - Fix missing minus sign.
>  - Checkpoint.
>  - Checkpoint StrictMath test for trig, inverse trig, and hyperbolic trig fingerprint values.
>  - Add cos test cases.
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/673a11b1...e705e10a

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15879#pullrequestreview-1911741566

From lancea at openjdk.org  Fri Mar  1 18:17:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 1 Mar 2024 18:17:54 GMT
Subject: RFR: 8326915: NPE when a validating parser is restricted [v2]
In-Reply-To: <jEBPvSD71ig3MAOGmvbiDWuF4GGbXp4TaCvJea8s1HU=.11df3351-71e5-42d0-817c-bff58a68d5ed@github.com>
References: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
 <jEBPvSD71ig3MAOGmvbiDWuF4GGbXp4TaCvJea8s1HU=.11df3351-71e5-42d0-817c-bff58a68d5ed@github.com>
Message-ID: <PEYSgAdSKl8iT1NFYyWtscHdyCv8sU7yltOT0SoXhiE=.2fa39883-54c0-437e-af7e-75bd76c46a8a@github.com>

On Fri, 1 Mar 2024 18:02:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix a NPE when a validating parser is restricted by the JDKCatalog resolve property. Also slightly improved the error msg with the catalog name.
>> 
>> Test: new test added
>>          existing test CatalogSupport5 would fail without the Null check on ErrorReporter. It's a separate issue not covered by this fix.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   input.substring second argument not needed; proper test method name

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18071#pullrequestreview-1911761210

From ihse at openjdk.org  Fri Mar  1 18:44:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Mar 2024 18:44:53 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v2]
In-Reply-To: <XDxNanHeNzR08co4WxsSrG31-FkPN15RBWpgE4kE9fU=.506115fc-247b-4838-add6-d4fcfdabbcde@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <XDxNanHeNzR08co4WxsSrG31-FkPN15RBWpgE4kE9fU=.506115fc-247b-4838-add6-d4fcfdabbcde@github.com>
Message-ID: <ixxUVLwbwifBGt31RXZKL35okjERMGBwXGQMWGjFBPI=.10109b7c-b70e-4bb4-9788-a2876017e8ca@github.com>

On Fri, 1 Mar 2024 13:58:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
>> 
>> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
>> 
>> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
>> 
>> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use @requires in test

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18050#pullrequestreview-1911804757

From naoto at openjdk.org  Fri Mar  1 18:55:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Mar 2024 18:55:21 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v10]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <dnSrOIX0FJCxNVB_9S8lj9x4mMvAEd4BBc4pVt1s-Vw=.caf7a418-2238-48b8-aef0-c5cf70b0cee1@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

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

  Removed the gc test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/7c1ca90e..84f5f692

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

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

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

From darcy at openjdk.org  Fri Mar  1 19:33:50 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 1 Mar 2024 19:33:50 GMT
Subject: Integrated: JDK-8316708: Augment WorstCaseTests with more cases
In-Reply-To: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
References: <aYFHc-tqZuKV3cSom8J_HcLXC0oejl0ntLhQEvEt0dg=.d849594a-74e2-4e02-9c24-a1f1e98b8d7a@github.com>
Message-ID: <0KfaMt09QLkpp4ft0aM__zkdrMiFs0Zxz_e2GTRlkIo=.f803e5f8-1301-4c7e-beb3-66b63b520122@github.com>

On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

This pull request has now been integrated.

Changeset: 7f02f07f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f02f07f754c942735ba15d70858cd1661a658c0
Stats:     307 lines in 13 files changed: 275 ins; 0 del; 32 mod

8316708: Augment WorstCaseTests with more cases

Reviewed-by: rgiulietti

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

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

From naoto at openjdk.org  Fri Mar  1 21:32:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Mar 2024 21:32:29 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v11]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <eUCMcXPPY9mk5ttu2aLB_KX6W35EuB5hQkeg4BTiF3A=.05bfb1c9-057d-424a-aadb-5f7f324da8aa@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

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

  copyright year revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/84f5f692..41150e12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=09-10

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

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

From rriggs at openjdk.org  Fri Mar  1 21:32:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Mar 2024 21:32:29 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v11]
In-Reply-To: <eUCMcXPPY9mk5ttu2aLB_KX6W35EuB5hQkeg4BTiF3A=.05bfb1c9-057d-424a-aadb-5f7f324da8aa@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <eUCMcXPPY9mk5ttu2aLB_KX6W35EuB5hQkeg4BTiF3A=.05bfb1c9-057d-424a-aadb-5f7f324da8aa@github.com>
Message-ID: <6BjJBX0Aw_PoVS-TuUlaaQxtdj2CELy2w9q_eSu8v94=.de3fe830-b0a6-4c48-a28a-0239bb3a0a05@github.com>

On Fri, 1 Mar 2024 21:29:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year revert

Much simpler and looks good.  Thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1912051206

From bchristi at openjdk.org  Fri Mar  1 22:58:11 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 1 Mar 2024 22:58:11 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v11]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <gIQYW6Ym1TSFG7-w2Np-4xJ9aSqQHWiEuY69yxJf0aE=.ac28001e-9250-437f-a694-d02c66d1c6be@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:

  Tiny clarification to 'strongly reachable' definition; add link to Reference class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/adb1fbe3..855b13a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=09-10

  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 jlu at openjdk.org  Sat Mar  2 00:39:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 2 Mar 2024 00:39:19 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string
Message-ID: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>

Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.

The cause is that the maximum fraction digits is initialized to `Integer.MAX_VALUE` which causes StringBuilder to eventually throw OOME when internally doubling capacity too many times when toPattern is invoked. CSR covers potential behavioral compatibility changes.

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

Commit messages:
 - minor additions
 - init

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

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

From iklam at openjdk.org  Sat Mar  2 01:22:16 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Mar 2024 01:22:16 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and CDS.java
Message-ID: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>

A few clean ups:

1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.

2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.

3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.

4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.

5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.

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

Commit messages:
 - 8327138: Clean up status management in cdsConfig.hpp and CDS.java

Changes: https://git.openjdk.org/jdk/pull/18095/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18095&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327138
  Stats: 191 lines in 19 files changed: 43 ins; 53 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18095/head:pull/18095

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

From joehw at openjdk.org  Sat Mar  2 04:48:59 2024
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 2 Mar 2024 04:48:59 GMT
Subject: Integrated: 8326915: NPE when a validating parser is restricted
In-Reply-To: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
References: <YVg5orR-3JuqY20bnmdcr5YieGJHVY7NvOTJuZ9CTLM=.1ceb8bcd-8e3c-4f04-ade3-f292ca9bffae@github.com>
Message-ID: <lYmeQA_h20jXXxEnvN9ozjat_5OmCHYIgIArrvcAeLw=.b1e9fa7c-83bb-4fde-87a4-b8eaf5e3c86b@github.com>

On Thu, 29 Feb 2024 21:00:09 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a NPE when a validating parser is restricted by the JDKCatalog resolve property. Also slightly improved the error msg with the catalog name.
> 
> Test: new test added
>          existing test CatalogSupport5 would fail without the Null check on ErrorReporter. It's a separate issue not covered by this fix.

This pull request has now been integrated.

Changeset: a3d51d20
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3d51d2027c18e88703022d1c65a3048b9f2967e
Stats:     116 lines in 5 files changed: 101 ins; 0 del; 15 mod

8326915: NPE when a validating parser is restricted

Reviewed-by: lancea, naoto

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

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

From rgiulietti at openjdk.org  Sat Mar  2 14:28:42 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 2 Mar 2024 14:28:42 GMT
Subject: RFR: 8326718: Test java/util/Formatter/Padding.java should timeout
 on large inputs before fix in JDK-8299677 [v2]
In-Reply-To: <kLxU3DOdW6K7xh94umCx03Emvc682CU6H337aAPTRPM=.3181ec15-fe16-4462-a9cc-686c238638dc@github.com>
References: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
 <kLxU3DOdW6K7xh94umCx03Emvc682CU6H337aAPTRPM=.3181ec15-fe16-4462-a9cc-686c238638dc@github.com>
Message-ID: <d2H-p0REtceYAfDjiaHKBY9FsXJcwSGuaBMfhm6yk0U=.6c8526ff-7bae-43ab-a381-00ce44973931@github.com>

On Wed, 28 Feb 2024 00:00:01 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after.
>> 
>> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updates

test/jdk/java/util/Formatter/Padding.java line 44:

> 42: 
> 43:     private static final String tenMillionZeros = "0".repeat(10000000);
> 44:     private static final String tenMillionBlanks = " ".repeat(10000000);

Just a nit to help readability
Suggestion:

    private static final String tenMillionZeros = "0".repeat(10_000_000);
    private static final String tenMillionBlanks = " ".repeat(10_000_000);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1509251657

From jbhateja at openjdk.org  Sat Mar  2 16:22:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 2 Mar 2024 16:22:22 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v17]
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: <Q5Ey7huf8Xm7afWnC5v2lj6Fbo-4ZfLsLHfM_CjBO1U=.005180ad-b3e5-43af-8d1c-510a0bf4ac2e@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 incrementally with one additional commit since the last revision:

  Review resolutions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16354/files
  - new: https://git.openjdk.org/jdk/pull/16354/files/b971fbb7..0b270d2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=15-16

  Stats: 25 lines in 4 files changed: 10 ins; 9 del; 6 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 eirbjo at openjdk.org  Sat Mar  2 18:51:16 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 2 Mar 2024 18:51:16 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v12]
In-Reply-To: <T1cRMdy0pbReTAlAxPs_IaydJYSgtZpBhlQW2Wkb5fI=.bdef4ba3-93d4-493b-95c7-78c791b949a1@github.com>
References: <T1cRMdy0pbReTAlAxPs_IaydJYSgtZpBhlQW2Wkb5fI=.bdef4ba3-93d4-493b-95c7-78c791b949a1@github.com>
Message-ID: <gS1-42kPZ4_NmtLfGkyDYm-ubE5OFOWgT-xoAWPqNLk=.1326d04e-98fe-405c-aef9-637b6d6b6c92@github.com>

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is greater than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Make the new specification text an @implSpec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17919/files
  - new: https://git.openjdk.org/jdk/pull/17919/files/b51ff1dc..6ccf2ce8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=10-11

  Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17919/head:pull/17919

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

From gli at openjdk.org  Sun Mar  3 05:02:51 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 3 Mar 2024 05:02:51 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <opssWK17CH7cXcdSq6M7Qxjux4xlIlNcujGIgH-wZkU=.9d26b388-a23d-477c-b185-1dc85f3e3a23@github.com>

On Sat, 2 Mar 2024 00:34:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs.

It seems a bug in `toPattern` or `StringBuilder`? May be better to investigate more about it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18094#issuecomment-1975023075

From ihse at openjdk.org  Sun Mar  3 15:30:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 3 Mar 2024 15:30:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <eGE-Yo2mIy9CsBP7uNYcaR0IvQKqejcJW0eq8e2xQ08=.1c3808bd-bca4-4fe4-8bd2-ed752296968e@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

For the record, there is a series of comment posted as Github commit comments. See https://github.com/openjdk/jdk/commit/ac3ce2aa156332fc4e6f33018ff669657ab4b797#commitcomment-139295772.

According to the comments, this PR breaks building hsdis with ccache.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975197285

From ihse at openjdk.org  Sun Mar  3 15:34:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 3 Mar 2024 15:34:54 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <537eZ4LFh0sfwSpT_HSyXOy5UZQo2H1B8WcxSjI9Ovs=.9d34407c-c8f0-4460-84f7-edc2891c78de@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

@claudionieder

> One last comment. I just discovered, that if I remove the --enable-ccache from the configure command, then it works also with this commit. Hopefully this helps for fixing the issue.

So what you really saying is that this breaks when compiling capstone hsdis on macOS/aarch64 when you have ccache enabled?

It seems more reasonable that this could be a ccache error than a hsdis-with-capstone error. Can you build any normal JDK targets with ccache?

(Also, why are you using ccache? It is highly unclear if that really adds any performance improvements)

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975198444

From alanb at openjdk.org  Sun Mar  3 18:46:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Mar 2024 18:46:44 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v12]
In-Reply-To: <gS1-42kPZ4_NmtLfGkyDYm-ubE5OFOWgT-xoAWPqNLk=.1326d04e-98fe-405c-aef9-637b6d6b6c92@github.com>
References: <T1cRMdy0pbReTAlAxPs_IaydJYSgtZpBhlQW2Wkb5fI=.bdef4ba3-93d4-493b-95c7-78c791b949a1@github.com>
 <gS1-42kPZ4_NmtLfGkyDYm-ubE5OFOWgT-xoAWPqNLk=.1326d04e-98fe-405c-aef9-637b6d6b6c92@github.com>
Message-ID: <Dk1p1Kb5Io_K6o5tXegGG05609VHQBsuwxlqVFoKg3s=.9f67c823-3468-4ba6-b165-5ec141c50e75@github.com>

On Sat, 2 Mar 2024 18:51:16 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
>> 
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> * `Deflater.getTotalOut()`
>> 
>> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
>> 
>> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
>> 
>> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is greater than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the new specification text an @implSpec

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17919#pullrequestreview-1913060830

From liach at openjdk.org  Sun Mar  3 21:26:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 3 Mar 2024 21:26:59 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: <9nVN9Gnq1fNi7QHlSMjSbq9i61uq-K6sLs0XzX3SAOk=.5eda6975-73c0-47a6-b4b0-8cb00fa8f1f9@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

src/java.base/share/classes/java/util/AbstractMap.java line 314:

> 312:      * {@code contains} method delegates to this map's
> 313:      * {@code containsKey} method.
> 314:      *

Extra blank line

src/java.base/share/classes/java/util/AbstractMap.java line 336:

> 334:      * method and the {@code contains} method delegates to this map's
> 335:      * {@code containsValue} method.
> 336:      *

Extra blank line

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1510400633
PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1510400802

From dholmes at openjdk.org  Sun Mar  3 22:14:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 3 Mar 2024 22:14:56 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v2]
In-Reply-To: <XDxNanHeNzR08co4WxsSrG31-FkPN15RBWpgE4kE9fU=.506115fc-247b-4838-add6-d4fcfdabbcde@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <XDxNanHeNzR08co4WxsSrG31-FkPN15RBWpgE4kE9fU=.506115fc-247b-4838-add6-d4fcfdabbcde@github.com>
Message-ID: <oI0kIalG-thRuh5ae1cKg55lXFYgBKWxG3S0R7Uu1cg=.6624cabd-35fb-4a2c-be0a-b6b23c39987e@github.com>

On Fri, 1 Mar 2024 13:58:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
>> 
>> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
>> 
>> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
>> 
>> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use @requires in test

I find it somewhat odd that we seem to be add odds with the general programming community when it comes to this behaviour. Giving precedence to `LD_LIBRARY_PATH` is the new behaviour, enabled via `--enable-new-dtags`; and at some point this was made the default behaviour so it must be considered generally desirable. But we have now decided we do not want this behaviour so we have to explicitly disable it via `--disable-new-dtags`.

make/autoconf/flags-cflags.m4 line 40:

> 38:     # Default works for linux, might work on other platforms as well.
> 39:     SHARED_LIBRARY_FLAGS='-shared'
> 40:     SET_EXECUTABLE_ORIGIN='-Wl,-rpath,\$$ORIGIN[$]1 -Wl,--disable-new-dtags'

The reason we use `--disable-new-dtags` needs to be documented somewhere.

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

PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1975375484
PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1510411289

From duke at openjdk.org  Sun Mar  3 23:30:51 2024
From: duke at openjdk.org (Claudio Nieder)
Date: Sun, 3 Mar 2024 23:30:51 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <wHcG1NUm5We4Qw1UF-yogB7brRcE3NhdH8TzPBomDgw=.a07db378-a32b-4071-93ac-374d5240e0d0@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

Indeed hsdis or no hsdis does not matter at all. --enable-ccache is broken with this commit in any case. I executed the much simplified script below, which builds once using this commit and once the parent commit. Seems, that with hsdis enabled HSDIS was just the first thing that needed to be compiled. Now it is failing when "Creating support/modules_libs/java.base/server/libjvm.dylib".

Regarding why I use ccache: I frankly didn't time it to see if there is an advantage. I just read in doc/building.md (lines 1517 ff) "The JDK build supports building with ccache when using gcc or clang. Using ccache can radically speed up compilation of native code if you often rebuild the same sources." so I included it in my personal script to build OpenJDK. But I can easily live without using ccache and personally wouldn't mind if OpenJDK stops supporting ccache. 

Below the content of `build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch.cmdline` for this commit ac3ce2aa where you can see the main issue, that the command `/opt/homebrew/bin/ccache /usr/bin/clang` is missing in front of the first compiler option -D__STDC_FORMAT_MACROS. Additionally some environment variables are missing/different.


cd /tmp/ac3ce2aa/jdk && CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=pch_defines -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -pipe -fno-rtti -fno-exceptions -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer -flimit-debug-info -mno-omit-leaf-frame-pointer -mstack-alignment=16 -std=c++14 -DMAC_OS_X_VERSION_MIN_REQUIRED=110000 -mmacosx-version-min=11.00.00 -DLIBC=default -D_ALLBSD_SOURCE -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE -Wall -Wextra -Wformat=2 -Wpointer-arith -Wsign-compare -Wreorder -Wunused-function -Wundef -Wunused-value -Woverloaded-virtual -fPIC -DVM_LITTLE_ENDIAN -D_LP64=1 -arch arm64 -DASSERT -DCHECK_UNHANDLED_OOPS -DTARGET_ARCH_aarch64 -DINCLUDE_SUFFIX_OS=_bsd -DINCLUDE_SUFFIX_CPU=_aarch64 -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc -DAARCH64 -DHOTSPOT_LIB_ARCH='"aarch64"' -DCOMPILER1 -DCOMPILER2 -DDTRACE_ENABLED -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc/adfiles -Isrc/hotspot/share -Isrc/hotspo
 t/os/bsd -Isrc/hotspot/os/posix -Isrc/hotspot/cpu/aarch64 -Isrc/hotspot/os_cpu/bsd_aarch64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc -Isrc/hotspot/share/precompiled -Isrc/hotspot/share/include -Isrc/hotspot/os/posix/include -Ibuild/macosx-aarch64-server-fastdebug/support/modules_include/java.base -Ibuild/macosx-aarch64-server-fastdebug/support/modules_include/java.base/darwin -Isrc/java.base/share/native/libjimage -arch arm64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc/adfiles -Isrc/hotspot/share -Isrc/hotspot/os/bsd -Isrc/hotspot/os/posix -Isrc/hotspot/cpu/aarch64 -Isrc/hotspot/os_cpu/bsd_aarch64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc -g -gdwarf-4 -gdwarf-aranges -Wno-unknown-warning-option -Wno-unused-parameter -Wno-unused -Wno-sometimes-uninitialized -Wno-missing-braces -Wno-delete-non-abstract-non-virtual-dtor -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -isysroot /Applic
 ations/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk -iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/Library/Frameworks -O3 -x c++-header -c -MMD -MF build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch.d.tmp src/hotspot/share/precompiled/precompiled.hpp -o build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch


and here the content of `build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch.cmdline` for the parent commit bceaed6d


cd /tmp/bceaed6d/jdk && CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=pch_defines,time_macros CCACHE_BASEDIR=/tmp/bceaed6d/jdk/ /opt/homebrew/bin/ccache /usr/bin/clang -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -pipe -fno-rtti -fno-exceptions -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer -flimit-debug-info -mno-omit-leaf-frame-pointer -mstack-alignment=16 -std=c++14 -DMAC_OS_X_VERSION_MIN_REQUIRED=110000 -mmacosx-version-min=11.00.00 -DLIBC=default -D_ALLBSD_SOURCE -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE -Wall -Wextra -Wformat=2 -Wpointer-arith -Wsign-compare -Wreorder -Wunused-function -Wundef -Wunused-value -Woverloaded-virtual -fPIC -DVM_LITTLE_ENDIAN -D_LP64=1 -arch arm64 -DASSERT -DCHECK_UNHANDLED_OOPS -DTARGET_ARCH_aarch64 -DINCLUDE_SUFFIX_OS=_bsd -DINCLUDE_SUFFIX_CPU=_aarch64 -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc -DAARCH64 -DHOTSPOT_LIB_ARCH='"aarch64"' -DCOMPILER1 -DCOMPILER2 -DDTRACE_ENABLED -Ibuild/macosx-aarch64-s
 erver-fastdebug/hotspot/variant-server/gensrc/adfiles -Isrc/hotspot/share -Isrc/hotspot/os/bsd -Isrc/hotspot/os/posix -Isrc/hotspot/cpu/aarch64 -Isrc/hotspot/os_cpu/bsd_aarch64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc -Isrc/hotspot/share/precompiled -Isrc/hotspot/share/include -Isrc/hotspot/os/posix/include -Ibuild/macosx-aarch64-server-fastdebug/support/modules_include/java.base -Ibuild/macosx-aarch64-server-fastdebug/support/modules_include/java.base/darwin -Isrc/java.base/share/native/libjimage -arch arm64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc/adfiles -Isrc/hotspot/share -Isrc/hotspot/os/bsd -Isrc/hotspot/os/posix -Isrc/hotspot/cpu/aarch64 -Isrc/hotspot/os_cpu/bsd_aarch64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc -g -gdwarf-4 -gdwarf-aranges -Wno-unknown-warning-option -Wno-unused-parameter -Wno-unused -Wno-sometimes-uninitialized -Wno-missing-braces -Wno-delete-non-abstract-non-virtual-dtor 
 -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk -iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/Library/Frameworks -O3 -x c++-header -c -MMD -MF build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch.d.tmp src/hotspot/share/precompiled/precompiled.hpp -o build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch


Script used to test


#!/bin/bash

export LANG=en_US
export LC_ALL=en_US

suspectedCommit=ac3ce2aa
preceedingCommit=bceaed6d

function build() {
 bash ./configure --enable-ccache --disable-warnings-as-errors --with-debug-level=fastdebug
 make clean
 make images
}

cd /tmp
rm -rf $preceedingCommit
mkdir $preceedingCommit
cd $preceedingCommit
git clone "https://github.com/openjdk/jdk.git"
cd jdk
git checkout $preceedingCommit
build

cd /tmp
rm -rf $suspectedCommit
mkdir $suspectedCommit
cd $suspectedCommit
git clone "https://github.com/openjdk/jdk.git"
cd jdk
git checkout $suspectedCommit
build

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975396416

From duke at openjdk.org  Mon Mar  4 00:02:48 2024
From: duke at openjdk.org (Claudio Nieder)
Date: Mon, 4 Mar 2024 00:02:48 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <VVosEvM3nkqv_7fvXj3bkwuqGz5GQq6t-GadFdtX1D4=.d3f7ccf0-9fa3-469d-a504-f1f0dcdc8a81@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

As a side note, I now did time the effect of ccache using the below script. This is the result without ccache


real	3m42.896s
user	20m49.584s
sys	2m56.578s


this is the result with --enable-ccache

real	4m56.290s
user	26m16.230s
sys	5m50.993s


Thus at least on my MacBook Pro M1 using ccache slows down the compilation!

Script

#!/bin/bash

export LANG=en_US
export LC_ALL=en_US

preceedingCommit=bceaed6d

d1=noCCache
d2=ccache

cd /tmp
rm -rf $d1
mkdir $d1
cd $d1
git clone "https://github.com/openjdk/jdk.git"
cd jdk
git checkout $preceedingCommit
bash ./configure --disable-warnings-as-errors --with-debug-level=fastdebug \
  --enable-hsdis-bundling --with-hsdis=capstone
make clean
time make images 2>&1 | tee /tmp/$d1/time.txt

cd /tmp
rm -rf $d2
mkdir $d2
cd $d2
git clone "https://github.com/openjdk/jdk.git"
cd jdk
git checkout $preceedingCommit
bash ./configure --disable-warnings-as-errors --with-debug-level=fastdebug \
  --enable-ccache --enable-hsdis-bundling --with-hsdis=capstone
make clean
time make images 2>&1 | tee /tmp/$d2/time.txt

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975406744

From lancea at openjdk.org  Mon Mar  4 00:49:55 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 4 Mar 2024 00:49:55 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v12]
In-Reply-To: <gS1-42kPZ4_NmtLfGkyDYm-ubE5OFOWgT-xoAWPqNLk=.1326d04e-98fe-405c-aef9-637b6d6b6c92@github.com>
References: <T1cRMdy0pbReTAlAxPs_IaydJYSgtZpBhlQW2Wkb5fI=.bdef4ba3-93d4-493b-95c7-78c791b949a1@github.com>
 <gS1-42kPZ4_NmtLfGkyDYm-ubE5OFOWgT-xoAWPqNLk=.1326d04e-98fe-405c-aef9-637b6d6b6c92@github.com>
Message-ID: <H5M3tRy8GI9EGsGTEbOFB5mRS4dvwq6hZRvcJehjmCE=.981233eb-5eb6-4222-9ee1-1eb85d070050@github.com>

On Sat, 2 Mar 2024 18:51:16 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
>> 
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> * `Deflater.getTotalOut()`
>> 
>> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
>> 
>> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
>> 
>> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is greater than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the new specification text an @implSpec

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17919#pullrequestreview-1913187374

From davidalayachew at gmail.com  Mon Mar  4 03:00:36 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 3 Mar 2024 22:00:36 -0500
Subject: Any plans to make resource leaks easier to detect?
Message-ID: <CAA9v-_PxpOGkq1gAo3CdQyZNYq=DwCrRjL7ugjgQn39NiZNAmQ@mail.gmail.com>

Hello Amber Dev Team and Core Libs Dev Team,

I am making my own implementation of java.util.stream.Stream that reads
data from the internet lazily. It's basically
java.nio.file.Files.lines(...), but the file is on the internet instead.
Here is a StackOverflow post I made that basically gave birth to idea. Just
for context. [1]

I used composition -- I held my resource and the stream inside of my
container data type. However, I also had this container data type implement
java.util.stream.Stream too. This way, the end user can use this object
exactly like a Stream.

In my implementation, I delegated all method calls to the underlying
stream. But, for each terminal operation, I would wrap the delegated calls
with try-with-resources for my resources, to prevent resource leak upon
exception.

Now, I know that this is taking an uphill path to a solution. We could
easily tell the user that they have to close the resources themself. Or we
could let the user provide their own resources and thus, leave the
responsibility on their plate. Or we could use the escape-hatch provided by
stream lol, and tell the user to use try-with-resources on my custom
stream. As you all intended us to do, I'm sure.

I know the reason might seem poorly justified (StackOverflow told me as
much -- [1]), but I did this so that none of the users of my stream would
have to concern themselves doing try-with-resources. Try-with-resources is
an excellent utility, but I have no way to know if I left a resource
unclosed because there are no compiler warnings or errors if I do so.

Are there any plans to make it easier to detect potential resource leaks?
Ideally with a compiler warning or error?

Thank you for your time and help!
David Alayachew

[1] = https://stackoverflow.com/questions/77959436
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240303/cb9f3227/attachment.htm>

From davidalayachew at gmail.com  Mon Mar  4 03:02:47 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 3 Mar 2024 22:02:47 -0500
Subject: Any plans to make resource leaks easier to detect?
In-Reply-To: <CAA9v-_PxpOGkq1gAo3CdQyZNYq=DwCrRjL7ugjgQn39NiZNAmQ@mail.gmail.com>
References: <CAA9v-_PxpOGkq1gAo3CdQyZNYq=DwCrRjL7ugjgQn39NiZNAmQ@mail.gmail.com>
Message-ID: <CAA9v-_NYVX4XXdsW6fBe5VhgR8EuYgsthN5uBua48B6Rz+WekQ@mail.gmail.com>

And as a side note, I did some pretty in-depth research on the topic, and
stumbled on this post on the lambda mailing list during Java 8's creation.
I am adding it, as it seems to be considering many of the same concerns I
have now.

https://mail.openjdk.org/pipermail/lambda-libs-spec-experts/2013-August/002195.html

On Sun, Mar 3, 2024 at 10:00?PM David Alayachew <davidalayachew at gmail.com>
wrote:

>
> Hello Amber Dev Team and Core Libs Dev Team,
>
> I am making my own implementation of java.util.stream.Stream that reads
> data from the internet lazily. It's basically
> java.nio.file.Files.lines(...), but the file is on the internet instead.
> Here is a StackOverflow post I made that basically gave birth to idea. Just
> for context. [1]
>
> I used composition -- I held my resource and the stream inside of my
> container data type. However, I also had this container data type implement
> java.util.stream.Stream too. This way, the end user can use this object
> exactly like a Stream.
>
> In my implementation, I delegated all method calls to the underlying
> stream. But, for each terminal operation, I would wrap the delegated calls
> with try-with-resources for my resources, to prevent resource leak upon
> exception.
>
> Now, I know that this is taking an uphill path to a solution. We could
> easily tell the user that they have to close the resources themself. Or we
> could let the user provide their own resources and thus, leave the
> responsibility on their plate. Or we could use the escape-hatch provided by
> stream lol, and tell the user to use try-with-resources on my custom
> stream. As you all intended us to do, I'm sure.
>
> I know the reason might seem poorly justified (StackOverflow told me as
> much -- [1]), but I did this so that none of the users of my stream would
> have to concern themselves doing try-with-resources. Try-with-resources is
> an excellent utility, but I have no way to know if I left a resource
> unclosed because there are no compiler warnings or errors if I do so.
>
> Are there any plans to make it easier to detect potential resource leaks?
> Ideally with a compiler warning or error?
>
> Thank you for your time and help!
> David Alayachew
>
> [1] = https://stackoverflow.com/questions/77959436
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240303/6f9c47b6/attachment-0001.htm>

From javalists at cbfiddle.com  Mon Mar  4 03:09:27 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 3 Mar 2024 19:09:27 -0800
Subject: jpackage requests permission via a dialog
Message-ID: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>

I tried using jpackage on macOS to create a DMG (which I have not done before) and was surprised when a system dialog was displayed requesting permission for Terminal to control Finder.

I found this issue described in JDK-8231855, which was closed without explanation as ?not an issue?.

It seems to me that having a command line build tool try to interact with a user via a dialog is inappropriate, even if it happens only once per system.

I?m not sure why this dialog is shown, as it appears that all of the actions are performed by running the hdiutil program.

It does seem odd, however, that jpackage mounts the DMG to modify its contents. Shouldn?t the contents be set up before creating the DMG?

Is mounting the image the source of the dialog?

Is there some reason this cannot be fixed?


From jwaters at openjdk.org  Mon Mar  4 06:44:56 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Mar 2024 06:44:56 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

I'd find it quite sad if we stopped supporting ccache just because it broke after this commit, I know for a fact that quite a few JDK developers do use it (myself included). Regarding the issue itself, I wonder if it's the SetupToolchain changes that has caused this. ccache is collapsed into CC and CXX to my knowledge, which would explain why the ccache cc or ccache c++ command is missing from the command line (substitute cc and c++ for the respective compiler drivers)

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975838054

From epeter at openjdk.org  Mon Mar  4 08:13:00 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 4 Mar 2024 08:13:00 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v17]
In-Reply-To: <Q5Ey7huf8Xm7afWnC5v2lj6Fbo-4ZfLsLHfM_CjBO1U=.005180ad-b3e5-43af-8d1c-510a0bf4ac2e@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Q5Ey7huf8Xm7afWnC5v2lj6Fbo-4ZfLsLHfM_CjBO1U=.005180ad-b3e5-43af-8d1c-510a0bf4ac2e@github.com>
Message-ID: <cVdKB65RXzXeLhNbpB7Wa-rPFNEzyVjWMST0Jns5-uA=.61d998f9-89d5-48c5-8d57-b84204d0adab@github.com>

On Sat, 2 Mar 2024 16:22:22 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
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review resolutions.

@jatin-bhateja thanks for all the work, this is a really nice feature!
And thanks for baring with all the comments ?

Testing up to commit 14 looks good.

@PaulSandoz thanks for looking at the Vector API java code!

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1913610983

From asotona at openjdk.org  Mon Mar  4 09:18:53 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Mar 2024 09:18:53 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v7]
In-Reply-To: <DuX77trlbQpBH1gc7PJaaEM9E3LBW2yIhEtbPQIILVs=.d0788697-b2ec-4a90-ae7f-5d7299cd255b@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <DuX77trlbQpBH1gc7PJaaEM9E3LBW2yIhEtbPQIILVs=.d0788697-b2ec-4a90-ae7f-5d7299cd255b@github.com>
Message-ID: <6uqGYnM098mmJ4E9kutl9-Q6FUUE523x_6JTVkTjmfc=.29dace57-4b3a-4233-a8da-b4091e59e14b@github.com>

On Mon, 15 Jan 2024 12:01:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API performance related improvements have been separated from #17121 into this PR.
>> 
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
>> 
>> 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/jdk/internal/classfile/impl/StackMapDecoder.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Please review.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/17306#issuecomment-1976089621

From eirbjo at openjdk.org  Mon Mar  4 10:05:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 4 Mar 2024 10:05:03 GMT
Subject: RFR: 8327208: Remove unused method java.util.jar.Manifest.make72Safe
Message-ID: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>

Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.

This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.

Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.

This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

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

Commit messages:
 - Update copyright years
 - Remove the internal, unused method Manifest.make72Safe. Update tests to not reference this legacy method.

Changes: https://git.openjdk.org/jdk/pull/18104/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327208
  Stats: 33 lines in 3 files changed: 2 ins; 21 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18104/head:pull/18104

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

From redestad at openjdk.org  Mon Mar  4 11:06:54 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 4 Mar 2024 11:06:54 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v7]
In-Reply-To: <DuX77trlbQpBH1gc7PJaaEM9E3LBW2yIhEtbPQIILVs=.d0788697-b2ec-4a90-ae7f-5d7299cd255b@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <DuX77trlbQpBH1gc7PJaaEM9E3LBW2yIhEtbPQIILVs=.d0788697-b2ec-4a90-ae7f-5d7299cd255b@github.com>
Message-ID: <GWIukojllABysfdD5mpUD1vY8QqpeyzgWR1jjsEtFWw=.affbda91-0cfe-4349-acbd-225adca26d22@github.com>

On Mon, 15 Jan 2024 12:01:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API performance related improvements have been separated from #17121 into this PR.
>> 
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
>> 
>> 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/jdk/internal/classfile/impl/StackMapDecoder.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Improvement looks good, but the microbenchmark needs to sink new instances into a blackhole to make sure we measure the right thing.

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 36:

> 34: import java.lang.classfile.constantpool.MemberRefEntry;
> 35: import static java.lang.classfile.ClassFile.*;
> 36: import java.lang.constant.MethodTypeDesc;

Imports are strangely out-of-order and imports in the classfile package look haphazard. Is there some system to it that I don't see? I don't know if we have an applicable style guide to lean on, but alphabetically sorted and static imports split out at the end seem like the convention in the OpenJDK sources.

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 103:

> 101:         this.methodDesc = methodDesc;
> 102:         this.cp = cp;
> 103:         targets = new ArrayDeque<>();

Seeing `ArrayDeque` being put to good use always makes me happy.

test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools.java line 108:

> 106:     @Benchmark
> 107:     public void benchmarkStackMapsGenerator() {
> 108:         for (var d : data) new StackMapGenerator(

When we return something from a benchmark JMH makes sure to sink that something into a blackhole to avoid JIT assuming the result is unused and eliminating it, wholly or in parts. When it's impractical to return a single thing that captures all the computation in the benchmark it's good practice to let a `org.openjdk.jmh.infra.Blackhole` consume effects to attain the same effect:

    public void benchmarkStackMapsGenerator(Blackhole bh) {
        for (var d : data) bh.consume(new StackMapGenerator(

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

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17306#pullrequestreview-1913911634
PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1510912679
PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1510921619
PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1510933717

From ihse at openjdk.org  Mon Mar  4 11:30:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Mar 2024 11:30:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
Message-ID: <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>

On Mon, 4 Mar 2024 06:42:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I wonder if it's the SetupToolchain changes that has caused this. ccache is collapsed into CC and CXX to my knowledge

Yeah, it must have been. Would you like to take a look at it? Otherwise I'll file a bug and fix it. Breaking ccache was an unintended regression, so it needs to be fixed. If we want to drop ccache support it needs to be done explicitly and separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976368808

From jwaters at openjdk.org  Mon Mar  4 11:48:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Mar 2024 11:48:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
 <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
Message-ID: <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>

On Mon, 4 Mar 2024 11:28:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > I wonder if it's the SetupToolchain changes that has caused this. ccache is collapsed into CC and CXX to my knowledge
> 
> Yeah, it must have been. Would you like to take a look at it? Otherwise I'll file a bug and fix it. Breaking ccache was an unintended regression, so it needs to be fixed. If we want to drop ccache support it needs to be done explicitly and separately.

No problem! I do hope that dropping ccache support isn't something that's planned though :(

> Additionally some environment variables are missing/different.

Could I trouble you to mention what exactly was different?

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976398726

From asotona at openjdk.org  Mon Mar  4 12:00:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Mar 2024 12:00:18 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v8]
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <v9C-GhUQrN4NcVDqZvOhOxH9Ty1aIOpIZy8vnDOXbj8=.f85585db-d547-4679-8993-004781b801a9@github.com>

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> 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 24 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8323184-performance-fixes
 - applied suggested changes
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - updated copyright year
 - reverted custom method slots counting in StackCounter
 - improved and extended GenerateStackMaps benchmarks and renamed to CodeAttributeTools
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - applied suggested changes
 - applied suggested changes
 - improved StackMapDescoder::initFrameLocals performance
 - ... and 14 more: https://git.openjdk.org/jdk/compare/45f0a396...747fce8e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17306/files
  - new: https://git.openjdk.org/jdk/pull/17306/files/5a04ec59..747fce8e

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

  Stats: 122960 lines in 3981 files changed: 64082 ins; 30411 del; 28467 mod
  Patch: https://git.openjdk.org/jdk/pull/17306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17306/head:pull/17306

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

From asotona at openjdk.org  Mon Mar  4 12:00:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Mar 2024 12:00:18 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v7]
In-Reply-To: <GWIukojllABysfdD5mpUD1vY8QqpeyzgWR1jjsEtFWw=.affbda91-0cfe-4349-acbd-225adca26d22@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <DuX77trlbQpBH1gc7PJaaEM9E3LBW2yIhEtbPQIILVs=.d0788697-b2ec-4a90-ae7f-5d7299cd255b@github.com>
 <GWIukojllABysfdD5mpUD1vY8QqpeyzgWR1jjsEtFWw=.affbda91-0cfe-4349-acbd-225adca26d22@github.com>
Message-ID: <W_9f-0U1uLDQWdukFKCPi6b3JS9ZLJBP8NzRe5nbdGo=.b1bef3df-7c32-49fe-8485-ec66b5782a94@github.com>

On Mon, 4 Mar 2024 10:08:27 GMT, Claes Redestad <redestad 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/jdk/internal/classfile/impl/StackMapDecoder.java
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 36:
> 
>> 34: import java.lang.classfile.constantpool.MemberRefEntry;
>> 35: import static java.lang.classfile.ClassFile.*;
>> 36: import java.lang.constant.MethodTypeDesc;
> 
> Imports are strangely out-of-order and imports in the classfile package look haphazard. Is there some system to it that I don't see? I don't know if we have an applicable style guide to lean on, but alphabetically sorted and static imports split out at the end seem like the convention in the OpenJDK sources.

Fixed, thanks.

> test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools.java line 108:
> 
>> 106:     @Benchmark
>> 107:     public void benchmarkStackMapsGenerator() {
>> 108:         for (var d : data) new StackMapGenerator(
> 
> When we return something from a benchmark JMH makes sure to sink that something into a blackhole to avoid JIT assuming the result is unused and eliminating it, wholly or in parts. When it's impractical to return a single thing that captures all the computation in the benchmark it's good practice to let a `org.openjdk.jmh.infra.Blackhole` consume effects to attain the same effect:
> 
>     public void benchmarkStackMapsGenerator(Blackhole bh) {
>         for (var d : data) bh.consume(new StackMapGenerator(

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1511040395
PR Review Comment: https://git.openjdk.org/jdk/pull/17306#discussion_r1511042556

From redestad at openjdk.org  Mon Mar  4 12:27:56 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 4 Mar 2024 12:27:56 GMT
Subject: RFR: 8323183: ClassFile API performance improvements [v8]
In-Reply-To: <v9C-GhUQrN4NcVDqZvOhOxH9Ty1aIOpIZy8vnDOXbj8=.f85585db-d547-4679-8993-004781b801a9@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
 <v9C-GhUQrN4NcVDqZvOhOxH9Ty1aIOpIZy8vnDOXbj8=.f85585db-d547-4679-8993-004781b801a9@github.com>
Message-ID: <BjchmhGwaF9b4QPBb6UYETaChKPVB5kw38Rk5GizLxo=.941f7376-6082-4f53-9d85-88010acab47f@github.com>

On Mon, 4 Mar 2024 12:00:18 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API performance related improvements have been separated from #17121 into this PR.
>> 
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
>> 
>> Please review.
>> 
>> Thanks,
>> 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 24 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8323184-performance-fixes
>  - applied suggested changes
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - updated copyright year
>  - reverted custom method slots counting in StackCounter
>  - improved and extended GenerateStackMaps benchmarks and renamed to CodeAttributeTools
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - applied suggested changes
>  - applied suggested changes
>  - improved StackMapDescoder::initFrameLocals performance
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/d128c9e7...747fce8e

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17306#pullrequestreview-1914189294

From duke at openjdk.org  Mon Mar  4 13:00:54 2024
From: duke at openjdk.org (Claudio Nieder)
Date: Mon, 4 Mar 2024 13:00:54 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
 <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
 <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
Message-ID: <Eux5XyKqCklnUrXp8aGIOqapxVKbIbHoRuXwMbPBYnA=.fc99209e-8e2f-4abf-8bab-eb137b920d61@github.com>

On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Could I trouble you to mention what exactly was different?

No trouble at all. 

`CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is where I checked out OpenJDK)

`CCACHE_SLOPPINESS` has the value `pch_defines,time_macros` with the working parent commit but just `pch_defines` with this commit. I.e. `CCACHE_SLOPPINESS=pch_defines,time_macros` vs `CCACHE_SLOPPINESS=pch_defines`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976528283

From jwaters at openjdk.org  Mon Mar  4 13:04:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Mar 2024 13:04:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <Eux5XyKqCklnUrXp8aGIOqapxVKbIbHoRuXwMbPBYnA=.fc99209e-8e2f-4abf-8bab-eb137b920d61@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
 <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
 <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
 <Eux5XyKqCklnUrXp8aGIOqapxVKbIbHoRuXwMbPBYnA=.fc99209e-8e2f-4abf-8bab-eb137b920d61@github.com>
Message-ID: <d16NqTj0wxfYX4lHoWKGG0hKkCFjeWV7mdXfkwzET2A=.835286f5-6ed1-48c1-972e-6ec3c6baeaac@github.com>

On Mon, 4 Mar 2024 12:58:28 GMT, Claudio Nieder <duke at openjdk.org> wrote:

> > Could I trouble you to mention what exactly was different?
> 
> No trouble at all.
> 
> `CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is where I checked out OpenJDK)
> 
> `CCACHE_SLOPPINESS` has the value `pch_defines,time_macros` with the working parent commit but just `pch_defines` with this commit. I.e. `CCACHE_SLOPPINESS=pch_defines,time_macros` vs `CCACHE_SLOPPINESS=pch_defines`.

Thanks! Seems curious to me, off the top of my head I can't seem to discern why these would change, perhaps it's time for a little investigating

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976534197

From jlahoda at openjdk.org  Mon Mar  4 13:56:12 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Mar 2024 13:56:12 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled
Message-ID: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>

Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.

This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

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

Commit messages:
 - Explicitly listing the modules that should get native access.
 - Native access modules-1

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

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

From redestad at openjdk.org  Mon Mar  4 13:59:59 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 4 Mar 2024 13:59:59 GMT
Subject: RFR: 8327225: Revert DataInputStream.readUTF to static final
Message-ID: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>

[JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally removed `final` from the `static final DataInputStream.readUTF` method. This has a minor compatibility impact (allows hiding the method in a subclass, while before that would throw an exception at compile time) and since it was not the intent of the prior change to alter any behavioral semantics here I want to revert that change.

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

Commit messages:
 - 8327225: Revert DataInputStream.readUTF to static final

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

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

From mcimadamore at openjdk.org  Mon Mar  4 14:14:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 4 Mar 2024 14:14:43 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <qFF0WMBrjUKykQUct5LCzfkye5jUQbTGInkefWzsWQw=.07a21123-f748-4000-8f17-da2a860b6702@github.com>

On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

Looks good.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 273:

> 271: 
> 272:     /**
> 273:      * Updates module named name in layer layer to allow access to restricted methods.

Suggestion:

     * Updates module named {@code name} in layer {@code layer} to allow access to restricted methods.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 806:

> 804:     /**
> 805:      * Process the --enable-native-access option to grant access to restricted methods to selected modules.
> 806:      * Also add Enable native access from JDK modules.

I don't think this extra comment is needed.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1914419463
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1511226929
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1511223692

From erikj at openjdk.org  Mon Mar  4 14:20:52 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 4 Mar 2024 14:20:52 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <jXtp1UbhG1JNxBdlENDq_XdxvRooGN0c4i5pADXz6a4=.4921f077-c5be-4898-867b-8e9129dd6b68@github.com>

On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1914434715

From erikj at openjdk.org  Mon Mar  4 14:49:52 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 4 Mar 2024 14:49:52 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v2]
In-Reply-To: <oI0kIalG-thRuh5ae1cKg55lXFYgBKWxG3S0R7Uu1cg=.6624cabd-35fb-4a2c-be0a-b6b23c39987e@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <XDxNanHeNzR08co4WxsSrG31-FkPN15RBWpgE4kE9fU=.506115fc-247b-4838-add6-d4fcfdabbcde@github.com>
 <oI0kIalG-thRuh5ae1cKg55lXFYgBKWxG3S0R7Uu1cg=.6624cabd-35fb-4a2c-be0a-b6b23c39987e@github.com>
Message-ID: <f1-BflXOXVTkPQKvKb9zELfBQ-LGPCKZrjcyNG0oEmo=.cfaef399-d793-4c04-b041-e296e9845e67@github.com>

On Sun, 3 Mar 2024 22:09:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I find it somewhat odd that we seem to be add odds with the general programming community when it comes to this behaviour. Giving precedence to `LD_LIBRARY_PATH` is the new behaviour, enabled via `--enable-new-dtags`; and at some point this was made the default behaviour so it must be considered generally desirable. But we have now decided we do not want this behaviour so we have to explicitly disable it via `--disable-new-dtags`.

Your point here is the reason it took me this long to come to the realization that my proposal here is correct for a product like the JDK. I have been dealing with these rpaths several time over the years and have been confused over the significance of the two kinds, but figured that since RUNPATH is the new variant and the general move is towards that, we should just stick to that too. However, as I allude to in the bug description, we aren't really fitting the usecases the default is aiming to solve.

If you are building a single library for distribution, or to install in your local Linux distribution, then letting the user have the option to customize the dynamic loader with LD_LIBRARY_PATH by default seems reasonable. I can see why Linux distributions prefer having LD_LIBRARY_PATH available to override rpaths as well. They want to promote applications that are well integrated with the system and using the system versions of all dependency libraries instead of bundling their own competing versions. 

However, what we are building is more of a self contained application. When users jlink an application, it becomes even more obvious. RPATH allows us to completely self contain the dependencies between our _internal_ native libraries. Any external dependency that the JDK has (glibc etc) we still link to from the system the same way as before. Looking for discussions about RPATH and RUNPATH online, this is basically the conclusion I find.

A better solution would perhaps have been to name our internal libraries better, using a namespace that would make name clashes with other external libraries less likely (e.g. libjavanet.so instead of libnet.so). If we had done that, then this issue would probably not have been worth raising.

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

PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1976750074

From erikj at openjdk.org  Mon Mar  4 15:00:07 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 4 Mar 2024 15:00:07 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v3]
In-Reply-To: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
Message-ID: <hOf1qlagwSxuLF5Sx41PA-xx6ZK3KO1eJb6qn_8RN70=.0bda76ce-1d17-456d-93bc-e0a4a3ae4a16@github.com>

> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
> 
> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
> 
> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
> 
> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".

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

  Add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18050/files
  - new: https://git.openjdk.org/jdk/pull/18050/files/592281f2..faafef8a

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

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

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

From ihse at openjdk.org  Mon Mar  4 15:00:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Mar 2024 15:00:07 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v2]
In-Reply-To: <oI0kIalG-thRuh5ae1cKg55lXFYgBKWxG3S0R7Uu1cg=.6624cabd-35fb-4a2c-be0a-b6b23c39987e@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <XDxNanHeNzR08co4WxsSrG31-FkPN15RBWpgE4kE9fU=.506115fc-247b-4838-add6-d4fcfdabbcde@github.com>
 <oI0kIalG-thRuh5ae1cKg55lXFYgBKWxG3S0R7Uu1cg=.6624cabd-35fb-4a2c-be0a-b6b23c39987e@github.com>
Message-ID: <229POn9CgME8neEYBaEfFNwBowY5RsCJXGBOGZGyRB8=.10cb48a7-7254-4458-8ffc-1f6026a0a195@github.com>

On Sun, 3 Mar 2024 22:12:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use @requires in test
>
> make/autoconf/flags-cflags.m4 line 40:
> 
>> 38:     # Default works for linux, might work on other platforms as well.
>> 39:     SHARED_LIBRARY_FLAGS='-shared'
>> 40:     SET_EXECUTABLE_ORIGIN='-Wl,-rpath,\$$ORIGIN[$]1 -Wl,--disable-new-dtags'
> 
> The reason we use `--disable-new-dtags` needs to be documented somewhere.

I agree. A short description and a reference to this bug number would be nice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1511290973

From erikj at openjdk.org  Mon Mar  4 15:00:07 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 4 Mar 2024 15:00:07 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v2]
In-Reply-To: <229POn9CgME8neEYBaEfFNwBowY5RsCJXGBOGZGyRB8=.10cb48a7-7254-4458-8ffc-1f6026a0a195@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <XDxNanHeNzR08co4WxsSrG31-FkPN15RBWpgE4kE9fU=.506115fc-247b-4838-add6-d4fcfdabbcde@github.com>
 <oI0kIalG-thRuh5ae1cKg55lXFYgBKWxG3S0R7Uu1cg=.6624cabd-35fb-4a2c-be0a-b6b23c39987e@github.com>
 <229POn9CgME8neEYBaEfFNwBowY5RsCJXGBOGZGyRB8=.10cb48a7-7254-4458-8ffc-1f6026a0a195@github.com>
Message-ID: <Tv1eoiwgLOcwPKZ-waBGB1oVejkpfdalVz7XW0xNrPk=.eee67e95-977f-4b9b-86d9-8e713705760d@github.com>

On Mon, 4 Mar 2024 14:53:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 40:
>> 
>>> 38:     # Default works for linux, might work on other platforms as well.
>>> 39:     SHARED_LIBRARY_FLAGS='-shared'
>>> 40:     SET_EXECUTABLE_ORIGIN='-Wl,-rpath,\$$ORIGIN[$]1 -Wl,--disable-new-dtags'
>> 
>> The reason we use `--disable-new-dtags` needs to be documented somewhere.
>
> I agree. A short description and a reference to this bug number would be nice.

Added comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18050#discussion_r1511291650

From ihse at openjdk.org  Mon Mar  4 15:00:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Mar 2024 15:00:07 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v3]
In-Reply-To: <hOf1qlagwSxuLF5Sx41PA-xx6ZK3KO1eJb6qn_8RN70=.0bda76ce-1d17-456d-93bc-e0a4a3ae4a16@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <hOf1qlagwSxuLF5Sx41PA-xx6ZK3KO1eJb6qn_8RN70=.0bda76ce-1d17-456d-93bc-e0a4a3ae4a16@github.com>
Message-ID: <9nCyTRpsMelbQU8gunv4D_jQzvqgrPQC9Hflkexlh3s=.94340550-a149-467f-9273-783fcee32991@github.com>

On Mon, 4 Mar 2024 14:57:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
>> 
>> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
>> 
>> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
>> 
>> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18050#pullrequestreview-1914533756

From ihse at openjdk.org  Mon Mar  4 15:01:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Mar 2024 15:01:58 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
 <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
 <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
Message-ID: <eiywV-5D-ligXgz8loKKDINf1BpFgJl9X7dKMSfAuu0=.4ad1ab6e-2dd8-43d4-bc52-ee0e16cd7fda@github.com>

On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>  I do hope that dropping ccache support isn't something that's planned though :(

Not really. The benefit of dropping it is quite small, and there might be use cases where it helps.

But I think we should perhaps be more explicit in the documentation that it is not obvious that it helps performance, and encourage testing before enabling it. And perhaps even print a warning in configure if you enable it that you need to check that it helps.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976777022

From aefimov at openjdk.org  Mon Mar  4 15:05:58 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 4 Mar 2024 15:05:58 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: <rxsscNAo3wJCLQ-Zr3HSAN2PdTNdwMe9fIOiYNUzrSg=.9cde53d2-43f0-4b35-93d2-52e7f0820683@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <Gfc5nSHywS0SkSv33Bgu9htQapPQgbH1SAXmjtU6UIA=.82fe269b-3a6a-40cb-b77d-c878b4d12210@github.com>
 <rNceCTggSqL-bJVTTj4X4HEzVsmanlKNIhrbrPCf-g0=.395f0162-d5d9-4840-98dd-199def542269@github.com>
 <RaKJiTLW6li4_S5-HsffyRqDNOwd-vFCkLH8b0_dD1k=.4bff88c5-04f4-498d-af4d-14c437bb369a@github.com>
 <QZU5goh25uLufkMD76XbPw1yrRDok-cl995sUZ602pI=.536873ab-d1bb-457e-88a9-d180f3720f8b@github.com>
 <ysYpm97ehjB1vmPga-F6V81vmdDwbQ_s-67oNUKbmrQ=.601fadce-df07-4a25-8559-819025c1a7ce@github.com>
 <rxsscNAo3wJCLQ-Zr3HSAN2PdTNdwMe9fIOiYNUzrSg=.9cde53d2-43f0-4b35-93d2-52e7f0820683@github.com>
Message-ID: <36-uLVrsexBrgtOwUkfGEY9DYq7kVtZG58b_bQoBe0s=.49a0d4b1-e141-4863-bc9f-80a8bd7b8196@github.com>

On Fri, 23 Feb 2024 15:30:09 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> Thanks for exploring the possibility of improving tracebility of test invocations to reported bugs.
> 
> >

I've given this test change a second thought, maybe you can try to separate the test into two separate test classes? One possibility to avoid duplicating code and have a separate test for each bug is to introduce a base test class that will contain the common functionality for [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) and [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1976785208

From mullan at openjdk.org  Mon Mar  4 15:18:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:18:59 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:

> 67:         }
> 68:         private void setPrincipal() {
> 69:             Subject subject = Subject.current();

Why change this to `Subject.current()` if you are requiring the SM to be allowed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511332276

From asotona at openjdk.org  Mon Mar  4 15:29:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Mar 2024 15:29:01 GMT
Subject: Integrated: 8323183: ClassFile API performance improvements
In-Reply-To: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
References: <CFQIj73f50AHv1VOiTRdCF7mRRgL8qGacznzOSsE304=.2febafda-8a54-447d-ab32-0ce26b9578d2@github.com>
Message-ID: <hI5k9XOVVpPEodkNKh-2fx0ESROWll3lUBgjKFFvrX8=.dc3e09c1-eb3a-492c-be12-8b689bb988fd@github.com>

On Mon, 8 Jan 2024 13:38:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API performance related improvements have been separated from #17121 into this PR.
> 
> These improvements are important to minimize performance regression of
> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes #17121
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 0583f735
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0583f7357480c0500daa82f490b2fcc05f2fb65a
Stats:     304 lines in 5 files changed: 147 ins; 139 del; 18 mod

8323183: ClassFile API performance improvements

Reviewed-by: redestad

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

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

From mullan at openjdk.org  Mon Mar  4 15:30:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:30:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:

> 307:         final Subject s;
> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
> 309:             s = Subject.current();

We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511351340

From rriggs at openjdk.org  Mon Mar  4 15:32:52 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Mar 2024 15:32:52 GMT
Subject: RFR: 8327225: Revert DataInputStream.readUTF to static final
In-Reply-To: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
References: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
Message-ID: <uUeSAtPQOe-wE2TawgMh_NpODeRxJnYIXGxNZXE6rRg=.08670eb2-9955-469e-b95e-798095a4d076@github.com>

On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally removed `final` from the `static final DataInputStream.readUTF` method. This has a minor compatibility impact (allows hiding the method in a subclass, while before that would throw an exception at compile time) and since it was not the intent of the prior change to alter any behavioral semantics here I want to revert that change.

Good catch; it would have been caught by the signature tests but later.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18107#pullrequestreview-1914625661

From mullan at openjdk.org  Mon Mar  4 15:35:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:35:48 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <2ScdK8KcKlERkLJo7THfkI6UloVwIfWKn-sWF7ZzJsg=.5634f7e1-a6c2-4b19-9829-2fb1129a65c9@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

test/jdk/javax/security/auth/Subject/doAs/NestedActions.java line 283:

> 281:     static void readFile(String filename) {
> 282:         System.out.println("ReadFromFileAction: try to read " + filename);
> 283:         Subject subject = Subject.current();

Couldn't we have just left these calling `Subject.getSubject` for now since these tests run with an SM enabled?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511358336

From asotona at openjdk.org  Mon Mar  4 15:37:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Mar 2024 15:37:20 GMT
Subject: RFR: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes [v12]
In-Reply-To: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
Message-ID: <EO6Vcq51EbjH9-yRFXGNFO_aox55jBNf06WaRYFFEhg=.35e5bf05-5c95-4522-8888-3eb90ef49899@github.com>

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
> 
> This patch converts it to use Classfile API.
> 
> It is continuation of https://github.com/openjdk/jdk/pull/10991
> 
> 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 21 commits:

 - Merge branch 'master' into JDK-8294961-proxy
 - Update src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - initialization of template entries by index
 - Apply suggestions from code review
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - applied suggested changes
 - Revert "StackCounter performance boost"
   
   This reverts commit 0dc63d4edf40fd9458fbfa0c7661d57ed0022981.
 - Revert "SplitConstantPool performance fix"
   
   This reverts commit b7a60ae944983224e3b4c097576c496351394fe0.
 - Revert "applied the recommended changes"
   
   This reverts commit 7d0da2c0190c27f8e2cf89557e31f5d16ab4950e.
 - Revert "minor StackCounter fix"
   
   This reverts commit 41e879348c8f2ea70b25119e65527b81281c33ac.
 - Revert "Update src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java"
   
   This reverts commit c8f1d304358e19872450cd29449d82675f9bbe3e.
 - ... and 11 more: https://git.openjdk.org/jdk/compare/0583f735...40f99d1c

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

Changes: https://git.openjdk.org/jdk/pull/17121/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17121&range=11
  Stats: 543 lines in 2 files changed: 129 ins; 189 del; 225 mod
  Patch: https://git.openjdk.org/jdk/pull/17121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17121/head:pull/17121

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

From rriggs at openjdk.org  Mon Mar  4 16:06:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Mar 2024 16:06:53 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <ycyUibb8e5NBVff0ftU7WeAhlreWrW0qLIXJu9zbv1E=.d4694e1a-fded-4dfc-a57c-8632590aa8ab@github.com>

On Sat, 2 Mar 2024 00:34:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

src/java.base/share/classes/java/text/DecimalFormat.java line 3717:

> 3715:             // As maxFracDigits are fully displayed unlike maxIntDigits
> 3716:             // Prevent OOME by setting to a much more reasonable value.
> 3717:             setMaximumFractionDigits(DOUBLE_FRACTION_DIGITS);

Setting a reasonable default makes sense.  
In other control paths, the max fraction digits come from the inputs or are explicitly set.

It might be a reasonable related change to use StringBuilder.repeat() instead of a loop at LIne 3312-3319, where the pattern char(s) are being appended to the result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1511404338

From mullan at openjdk.org  Mon Mar  4 16:22:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 16:22:51 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

src/java.base/share/classes/javax/security/auth/Subject.java line 112:

> 110:  *
> 111:  * <p><b><a id="sm-allowed">These methods behave differently depending on
> 112:  * whether a security manager is allowed or disallowed</a></b>:

Suggest linking "a security manager is allowed or disallowed" to `SecurityManager.html#set-security-manager`.

src/java.base/share/classes/javax/security/auth/Subject.java line 120:

> 118:  * {@code getSubject(AccessControlContext)} method.
> 119: *  <li>If a security manager is not allowed, which means it
> 120:  * {@linkplain System#setSecurityManager is not set and not allowed to be set

I think `SecurityManager.html#set-security-manager` is a better (more informative) link. Also, not sure why it is linked here but not in the "If a security manager is allowed" paragraph. If you link it in the first sentence ("These methods behave differently ...) then you probably only need one link and don't need this link.

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 27:

> 25:  * @test
> 26:  * @bug 8296244
> 27:  * @enablePreview

Can you add a comment as to why `enablePreview` is needed? (Assume it is for `StructuredTaskScope`.)

test/jdk/javax/security/auth/Subject/Compat.java line 34:

> 32: /*
> 33:  * @test
> 34:  * @run main/othervm -Djava.security.manager=allow Compat

Missing `@summary` and `@bug`.

test/jdk/javax/security/auth/Subject/UnsupportedSV.java line 59:

> 57: 
> 58:         // TODO: Still has no way to reject the following code.
> 59:         // Here, AccessController::getContext returns a plan ACC without

typo: s/plan/plain/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511419716
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511424024
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511380094
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511393254
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511366395

From psandoz at openjdk.org  Mon Mar  4 16:24:59 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 4 Mar 2024 16:24:59 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v17]
In-Reply-To: <Q5Ey7huf8Xm7afWnC5v2lj6Fbo-4ZfLsLHfM_CjBO1U=.005180ad-b3e5-43af-8d1c-510a0bf4ac2e@github.com>
References: <bFMGfbhJS6iecd1-od-Irw1400eZAD7MVMYFZyIXLRc=.e78b0dc8-1942-44d5-ba03-23519d717767@github.com>
 <Q5Ey7huf8Xm7afWnC5v2lj6Fbo-4ZfLsLHfM_CjBO1U=.005180ad-b3e5-43af-8d1c-510a0bf4ac2e@github.com>
Message-ID: <iWsU5eECr9sBK3NxHxWkSIuYj-Gtn7h_XnPyIJbN4h0=.1c78cb87-9758-473a-8765-4ec0144ccb30@github.com>

On Sat, 2 Mar 2024 16:22:22 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
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review resolutions.

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1914752388

From clanger at openjdk.org  Mon Mar  4 16:35:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 4 Mar 2024 16:35:56 GMT
Subject: Integrated: 8326591: New test JmodExcludedFiles.java fails on Windows
 when --with-external-symbols-in-bundles=public is used
In-Reply-To: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com>
References: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com>
Message-ID: <CLq1EtS6ZnoRo8pHiNyjIxKkpN6puaav8OVZ7ORbEiw=.b7c88248-6927-4120-885a-2cb10cb62aee@github.com>

On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The new test JmodExcludedFiles.java checks that no debug symbol files are contained in the jmod files. It does not take into account that with configure option --with-external-symbols-in-bundles=public we want to have stripped pdb files, also in jmods, to get native callstacks with line number.
> 
> This modifies the test and checks if equivalent *stripped.pdb files exist when .pdb files are encountered inside jmods. In that case one can assume that --with-external-symbols-in-bundles=public was chosen as configure option.

This pull request has now been integrated.

Changeset: 43c6f0b5
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43c6f0b5880899b797fab2f851bd35be1c342439
Stats:     48 lines in 1 file changed: 30 ins; 5 del; 13 mod

8326591: New test JmodExcludedFiles.java fails on Windows when --with-external-symbols-in-bundles=public is used

Reviewed-by: mbaesken

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

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

From clanger at openjdk.org  Mon Mar  4 16:35:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 4 Mar 2024 16:35:56 GMT
Subject: RFR: 8326591: New test JmodExcludedFiles.java fails on Windows
 when --with-external-symbols-in-bundles=public is used
In-Reply-To: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com>
References: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com>
Message-ID: <XVvQfcylXAjZfThI4OzW7s9FzBnZxwEiLOU2dAhW-Xc=.79ed94dc-6d5b-4d12-8f7a-83350cb02401@github.com>

On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The new test JmodExcludedFiles.java checks that no debug symbol files are contained in the jmod files. It does not take into account that with configure option --with-external-symbols-in-bundles=public we want to have stripped pdb files, also in jmods, to get native callstacks with line number.
> 
> This modifies the test and checks if equivalent *stripped.pdb files exist when .pdb files are encountered inside jmods. In that case one can assume that --with-external-symbols-in-bundles=public was chosen as configure option.

Thanks for the review, Matthias.

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

PR Comment: https://git.openjdk.org/jdk/pull/17990#issuecomment-1976989827

From duke at openjdk.org  Mon Mar  4 16:36:57 2024
From: duke at openjdk.org (Claudio Nieder)
Date: Mon, 4 Mar 2024 16:36:57 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <vBRE5ItRzRSFWymd8ajaSQHPOX4Lhc_8LFN-nGfcJ0Q=.81ab56fb-41c6-426d-846e-09fab6258f8b@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

One little side note, I tried now also on a Linux x86 system and saw the same issue, so it is not limited to macOS or aarch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976999445

From bpb at openjdk.org  Mon Mar  4 17:04:52 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Mar 2024 17:04:52 GMT
Subject: RFR: 8327225: Revert DataInputStream.readUTF to static final
In-Reply-To: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
References: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
Message-ID: <Ob8nglQKa-9JQsKZPOmzNmWRJ7GcHrH1_NRjrJPtxgA=.f9762e04-9718-4e51-a930-7985a822baaf@github.com>

On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally removed `final` from the `static final DataInputStream.readUTF` method. This has a minor compatibility impact (allows hiding the method in a subclass, while before that would throw an exception at compile time) and since it was not the intent of the prior change to alter any behavioral semantics here I want to revert that change.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18107#pullrequestreview-1914844449

From alanb at openjdk.org  Mon Mar  4 17:30:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Mar 2024 17:30:43 GMT
Subject: RFR: 8327225: Revert DataInputStream.readUTF to static final
In-Reply-To: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
References: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
Message-ID: <yvKrQf2-Wz8IxHrI798CTuFjj67QHfymYTf4OO4jElE=.5af94a37-1338-4034-8229-1301bd2caa7d@github.com>

On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally removed `final` from the `static final DataInputStream.readUTF` method. This has a minor compatibility impact (allows hiding the method in a subclass, while before that would throw an exception at compile time) and since it was not the intent of the prior change to alter any behavioral semantics here I want to revert that change.

It's a bit unusual to have the final modifier on static methods, looks like it goes back to JDK 1.1 at least, not clear if it was intentional.

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

PR Comment: https://git.openjdk.org/jdk/pull/18107#issuecomment-1977103579

From simeon.danailov.andreev at gmail.com  Mon Mar  4 12:23:19 2024
From: simeon.danailov.andreev at gmail.com (S A)
Date: Mon, 4 Mar 2024 14:23:19 +0200
Subject: Class loader leaked when ForkJoinPool is used in loaded class, with
 Java 19+
Message-ID: <CACcnpz0uu6_Qeq2an_7J6fA4WB=MW1vS6_eJaJVd4rPANzB2Qg@mail.gmail.com>

Hi all,

after moving our application to Java 21 (up from Java 17), we noticed a
class loader leak. A memory snapshot points to a ProtectionDomain object
held by a ForkJoinWorkerThread, the protection domain holds the class
loader and prevents GC.

To reproduce outside of our application, we use this snippet:

import java.lang.ref.WeakReference;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.nio.file.Paths;
public class TestClassloaderLeak {
    public static void main(String[] args) throws Exception {
        WeakReference<Object> wr = load();
        gc();
        System.out.println("wr=" + wr.get());
    }
    private static void gc() {
        System.gc();
        System.runFinalization();
    }
    private static WeakReference<Object> load() throws Exception {
        URLClassLoader cl = new URLClassLoader(new URL[] { url() },
TestClassloaderLeak.class.getClassLoader());
        WeakReference<Object> wr = new WeakReference<>(cl);
        Class<?> ca = cl.loadClass("A");
        ca.getConstructor(String.class).newInstance("A");
        cl.close();
        return wr;
    }
    private static URL url() throws MalformedURLException {
        return Paths.get("/data/tmp/testleak/lib/").toUri().toURL();
    }
}

import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.ForkJoinTask;
public class A {
    public final String s;
    public A(String s) {
        this.s = s;
        ForkJoinTask<?> task = ForkJoinPool.commonPool().submit(() -> {
System.out.println("A constructor"); });
        try {
            task.get();
        } catch (Exception e) {
            e.printStackTrace(System.out);
        }
    }
}

Place the compiled A.class at the hard-coded location
"/data/tmp/testleak/lib/", then run the main method with JVM flags
"-Xlog:class+unload". Observe that no class is unloaded, which is not the
case if the main() code runs twice, or if the snippet is executed e.g. with
Java 17.

It seems each time ForkJoinPool creates a new ForkJoinWorkerThread from a
loaded class, it is no longer possible to GC the class loader of the class
using ForkJoinPool.

The leak occurs after this commit, with Java 19+:

https://github.com/openjdk/jdk19u/commit/00e6c63cd12e3f92d0c1d007aab4f74915616ffb

Essentially, our application loads and runs user code. The user changes
their code, runs their code again - we use a new class loader to run the
changed code in the same JVM. We unload the previous class loader, to free
up memory and to avoid problems with hot swapping code (an old version of a
loaded class can cause an error when trying to hot swap the latest loaded
version of that class). So the leaked class loader is giving us trouble.

What possible workarounds can we use to avoid this problem?

Best regards and thanks,
Simeon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240304/c8430156/attachment.htm>

From duke at openjdk.org  Mon Mar  4 17:57:53 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 4 Mar 2024 17:57:53 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <qAg9sBkhBX3Tz-u_j8AcEtfnaW5WifKDfFN168_uyTo=.ad5198d5-03f3-4f09-8af7-f89a1157bb75@github.com>

On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

src/java.base/share/classes/java/lang/ModuleLayer.java line 885:

> 883: 
> 884:     /**
> 885:      * Returns the module with the given name in this later only.

Suggestion:

     * Returns the module with the given name in this layer only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1511542904

From naoto at openjdk.org  Mon Mar  4 18:44:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Mar 2024 18:44:00 GMT
Subject: Integrated: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <DNuZkLuJKs8zHctNbprC3qzanXQOGofv1F3MpG4GuKI=.f60e36c3-5457-4fad-bace-95e7bb2a2f38@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

This pull request has now been integrated.

Changeset: f615ac4b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f615ac4bdf94750390d18aa954d41f72eb4ef4d2
Stats:     437 lines in 4 files changed: 43 ins; 267 del; 127 mod

8309622: Re-examine the cache mechanism in BaseLocale

Reviewed-by: dfuchs, rriggs

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

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

From naoto at openjdk.org  Mon Mar  4 19:07:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Mar 2024 19:07:44 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v6]
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <T8EvrAU2TaEKGwnqcAv1q3TsREiAFSoblLo-NPRvRBo=.2a7aaa81-da1c-477b-b612-b1cafee8e9d0@github.com>

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

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

 - Merge branch 'master' into JDK-8174269-COMPAT-Removal
 - Addressing review comments
 - Update test/jdk/java/text/Format/DateFormat/Bug6683975.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Remove `GensrcLocaleData.gmk`
 - Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - cleanup
 - BreakIteratorProvider available locales fix
 - clean-up
 - test fixes
 - makeZoneData.pl fix
 - ... and 34 more: https://git.openjdk.org/jdk/compare/fe877cfd...b771e303

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17991/files
  - new: https://git.openjdk.org/jdk/pull/17991/files/d5953788..b771e303

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

  Stats: 19239 lines in 1290 files changed: 10762 ins; 3853 del; 4624 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

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

From vpetko at openjdk.org  Mon Mar  4 19:45:49 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 4 Mar 2024 19:45:49 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <8ZFH2fi-ZkCdcaM-3wzSvvQGqlucidg6ZIXzyEuarJ8=.21c53722-75b4-4627-a4b3-847d94636951@github.com>
References: <YIvK3rTRYMZuxuhA1Mj07GiifDzMJqe1zt-iIdKJEZw=.6759466b-17fc-4a7f-a073-9dd0e24bc8b9@github.com>
 <8ZFH2fi-ZkCdcaM-3wzSvvQGqlucidg6ZIXzyEuarJ8=.21c53722-75b4-4627-a4b3-847d94636951@github.com>
Message-ID: <M-jZ8d4IFksCt_cnJgj4o7xag2Y1HIg1Ewoc-wndfjY=.fcd679fb-fd92-44b7-8853-8e195448074d@github.com>

On Fri, 1 Mar 2024 07:37:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to expand a bit on what is going on here? Are you saying that in the course of upgrading a JDK that you somehow get into a state where jspawnhelper has been replaced with a version from a newer JDK? Is the real issue here that the upgrade didn't shutdown the application and/or something copied over an existing installation during the upgrade?

It appears that answer is yes (in Debian and Ubuntu) if the machine is running unattended-upgrades service and openjdk is not blacklisted from upgrades. 
I believe we should blacklist openjdk packages by default to avoid this situation.

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

PR Comment: https://git.openjdk.org/jdk/pull/18074#issuecomment-1977331977

From weijun at openjdk.org  Mon Mar  4 19:54:45 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 19:54:45 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
Message-ID: <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>

On Mon, 4 Mar 2024 15:28:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:
> 
>> 307:         final Subject s;
>> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>> 309:             s = Subject.current();
> 
> We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.

I was not exactly sure if we will support this functionality. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511716084

From mullan at openjdk.org  Mon Mar  4 19:59:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 19:59:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
Message-ID: <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>

On Mon, 4 Mar 2024 19:51:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:
>> 
>>> 307:         final Subject s;
>>> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>>> 309:             s = Subject.current();
>> 
>> We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.
>
> I was not exactly sure if we will support this functionality. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.

I think we need @kevinjwalls or @dfuch to help advise on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511721920

From lancea at openjdk.org  Mon Mar  4 20:16:51 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 4 Mar 2024 20:16:51 GMT
Subject: RFR: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <LJLqwhot1za0zlfVK9C4Z6R40Ltr3biGjl17zNB1UII=.ed3dc386-a010-4d88-a5c9-570240cbefb6@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18104#pullrequestreview-1915256398

From iris at openjdk.org  Mon Mar  4 20:26:43 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 4 Mar 2024 20:26:43 GMT
Subject: RFR: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <84pJEELHzfdC6V0_t5n1IQlpmTD7BXoNWqun2tb5xtk=.a1b24c6b-17a2-47ac-9cd8-8b12dca077a3@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18104#pullrequestreview-1915271908

From weijun at openjdk.org  Mon Mar  4 20:33:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:33:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
Message-ID: <e65Omm5EaxnZ_Q4ymvpwK0kafK6AWDhLAJDUqPzhEvc=.a8badc5d-0ce1-4302-94bc-f03e9920326d@github.com>

On Mon, 4 Mar 2024 15:15:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:
> 
>> 67:         }
>> 68:         private void setPrincipal() {
>> 69:             Subject subject = Subject.current();
> 
> Why change this to `Subject.current()` if you are requiring the SM to be allowed?

When SM is allowed, `Subject.current()` is equivalent to `Subject.getSubject(AccessController.getContext())`. I can revert the change.

> test/jdk/javax/security/auth/Subject/UnsupportedSV.java line 59:
> 
>> 57: 
>> 58:         // TODO: Still has no way to reject the following code.
>> 59:         // Here, AccessController::getContext returns a plan ACC without
> 
> typo: s/plan/plain/

Yes.

> test/jdk/javax/security/auth/Subject/doAs/NestedActions.java line 283:
> 
>> 281:     static void readFile(String filename) {
>> 282:         System.out.println("ReadFromFileAction: try to read " + filename);
>> 283:         Subject subject = Subject.current();
> 
> Couldn't we have just left these calling `Subject.getSubject` for now since these tests run with an SM enabled?

Yes, we can.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511755373
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511756265
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511755860

From weijun at openjdk.org  Mon Mar  4 20:39:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:39:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
Message-ID: <AWOnbHXGoCGZKp0Ecva-eQU-Yf9hn6mdPmp1qVThatU=.dfb9494c-31fb-410b-bab5-d27e314144eb@github.com>

On Mon, 4 Mar 2024 15:47:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8296244
>> 27:  * @enablePreview
> 
> Can you add a comment as to why `enablePreview` is needed? (Assume it is for `StructuredTaskScope`.)

OK.

> test/jdk/javax/security/auth/Subject/Compat.java line 34:
> 
>> 32: /*
>> 33:  * @test
>> 34:  * @run main/othervm -Djava.security.manager=allow Compat
> 
> Missing `@summary` and `@bug`.

Will Add.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511760021
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511761591

From weijun at openjdk.org  Mon Mar  4 20:49:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:49:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
Message-ID: <xQbhbPkhHusDyyQ8zlwv0Xr3CZvYyP5aKVWOR4llj4s=.9bcccc3f-b7c7-4b59-b7b9-b8bd2427af9e@github.com>

On Mon, 4 Mar 2024 16:17:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 120:
> 
>> 118:  * {@code getSubject(AccessControlContext)} method.
>> 119: *  <li>If a security manager is not allowed, which means it
>> 120:  * {@linkplain System#setSecurityManager is not set and not allowed to be set
> 
> I think `SecurityManager.html#set-security-manager` is a better (more informative) link. Also, not sure why it is linked here but not in the "If a security manager is allowed" paragraph. If you link it in the first sentence ("These methods behave differently ...) then you probably only need one link and don't need this link.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511771517

From alexey.semenyuk at oracle.com  Mon Mar  4 21:23:39 2024
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 4 Mar 2024 16:23:39 -0500
Subject: jpackage requests permission via a dialog
In-Reply-To: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
Message-ID: <cce0c954-d27d-47d4-baba-9985032cdc12@oracle.com>



On 3/3/2024 10:09 PM, Alan Snyder wrote:
> I tried using jpackage on macOS to create a DMG (which I have not done before) and was surprised when a system dialog was displayed requesting permission for Terminal to control Finder.
>
> I found this issue described in JDK-8231855, which was closed without explanation as ?not an issue?.
There is a comment in the CR with the explanation and suggested workaround.
>
> It seems to me that having a command line build tool try to interact with a user via a dialog is inappropriate, even if it happens only once per system.
>
> I?m not sure why this dialog is shown, as it appears that all of the actions are performed by running the hdiutil program.
>
> It does seem odd, however, that jpackage mounts the DMG to modify its contents. Shouldn?t the contents be set up before creating the DMG?
>
> Is mounting the image the source of the dialog?
>
> Is there some reason this cannot be fixed?
Alexander, could you please help with the above questions?

- Alexey
>


From duke at openjdk.org  Mon Mar  4 21:24:00 2024
From: duke at openjdk.org (Elif Aslan)
Date: Mon, 4 Mar 2024 21:24:00 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
Message-ID: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>

This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.

Existing tests passes since it does not check behavior without args.
After test update the test fails without 

   if (argc != 2) {
        shutItDown();
    }

code block

> Test results: failed: 1
> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> Error: Some tests failed or other problems occurred.
> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>  
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
> >>                                                       1     0     1     0 <<
> ==============================
> TEST FAILURE



after added the code block back 

   if (argc != 2) {
        shutItDown();
    }


updated test passes


lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
        -Xmx768m \\
        -XX:MaxRAMPercentage=1.04167 \\
        -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
        -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
        -ea \\
        -esa \\
        -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
        com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/java/lang/ProcessBuilder/JspawnhelperProtocol.d/main.0.jta
result: Passed. Execution successful
 
 
test result: Passed. Execution successful

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

Commit messages:
 - Add Robust arg check
 - Remove usage text and add test
 - 8325567:jspawnhelper without args fails with segfault

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

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

From alexander.matveev at oracle.com  Mon Mar  4 21:27:49 2024
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 4 Mar 2024 21:27:49 +0000
Subject: jpackage requests permission via a dialog
In-Reply-To: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
Message-ID: <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>

Hi Alan,

See below.

From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Alan Snyder <javalists at cbfiddle.com>
Date: Sunday, March 3, 2024 at 7:09?PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: jpackage requests permission via a dialog
I tried using jpackage on macOS to create a DMG (which I have not done before) and was surprised when a system dialog was displayed requesting permission for Terminal to control Finder.

I found this issue described in JDK-8231855, which was closed without explanation as ?not an issue?.
From JDK-8231855: ?Looks like this dialog is part of macOS Catalina Data Protection features. I did not found if it possible not to trigger this prompt. Also, this prompt is shown only once and subsequent jpackage runs will not show any prompts. As workaround in case when jpackage will be part of automated build system which needs to be run without user intervention it is recommended to run jpackage first on this system and confirm any prompts.?.

It seems to me that having a command line build tool try to interact with a user via a dialog is inappropriate, even if it happens only once per system.
So far, I did not figure out other solution for this problem.

I?m not sure why this dialog is shown, as it appears that all of the actions are performed by running the hdiutil program.
This dialog is shown when we running osascript (https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/DMGsetup.scpt) to post process DMG file. This script will setup DMG background and re-arrange icons, so it look nice.

It does seem odd, however, that jpackage mounts the DMG to modify its contents. Shouldn?t the contents be set up before creating the DMG?
We need to mount it to run osascript I mentioned above.

Is mounting the image the source of the dialog?
No, dialog is shown after we mount it from osascript which is run right after DMG is mounted.

Is there some reason this cannot be fixed?
So far I did not found any substitution to our osascript to setup background image and re-arrange icons. I do not think that Apple provides any other ways to do it.
Thanks,
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240304/33961c5f/attachment.htm>

From duke at openjdk.org  Mon Mar  4 21:42:52 2024
From: duke at openjdk.org (Raju Gupta)
Date: Mon, 4 Mar 2024 21:42:52 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <zYA3R0Eg2eU70YtWCregenTvT8UQkjbHHOB03W7vWjM=.ed96e265-7688-4f95-897f-52481c88ea49@github.com>

On Sat, 2 Mar 2024 00:34:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

Would declaring an object for the input and then invoking the two methods on the same object rather than creating two objects be considered an alternative?

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

Marked as reviewed by rajucomp at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/18094#pullrequestreview-1915406613

From eastigeevich at openjdk.org  Mon Mar  4 21:51:52 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 4 Mar 2024 21:51:52 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <5jpwcWcDgS0LeOBCe2Bm99FnPOY3TjTsX2WDYTwToGw=.16bcfa8f-e600-4107-bdc9-9e7572c413c1@github.com>

On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.
> 
> Existing tests passes since it does not check behavior without args.
> After test update the test fails without 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> code block
> 
>> Test results: failed: 1
>> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
>> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>> Error: Some tests failed or other problems occurred.
>> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
>> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>  
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>> >>                                                       1     0     1     0 <<
>> ==============================
>> TEST FAILURE
> 
> 
> 
> after added the code block back 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> 
> updated test passes
> 
> 
> lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
>         -Xmx768m \\
>         -XX:MaxRAMPercentage=1.04167 \\
>         -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
>         -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
>         -ea \\
>         -esa \\
>         -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
>         com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/java/lang/ProcessBuilder/JspawnhelperPr...

lgtm

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

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18112#pullrequestreview-1915420153

From weijun at openjdk.org  Mon Mar  4 21:54:13 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 21:54:13 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v4]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <9_c9PpQBHzo6FdR5aaSQ_qCCwrd2yGr1CNsGdj6HDjk=.84620353-2d09-4599-8a05-b3b2f08ab855@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

  revert some test changes, spec change for subject

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/8f270d09..e57f7250

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

  Stats: 44 lines in 6 files changed: 18 ins; 3 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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

From mik3hall at gmail.com  Mon Mar  4 22:07:00 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 4 Mar 2024 16:07:00 -0600
Subject: jpackage requests permission via a dialog
In-Reply-To: <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
Message-ID: <4D92BAE9-8D01-4357-A23F-99FC4E744547@gmail.com>

If I remember what I read correctly it was Apple?s intention that some services require explicit user authorization. 
So, the dialog. 
You could probably hdiutil yourself but the AppleScript does have benefits. Such as a background image, the drag to Application Folder option, layout appearance with multiple files.  I think there was some provision for customization as well. 
From what I remember. 




From rriggs at openjdk.org  Mon Mar  4 23:26:42 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Mar 2024 23:26:42 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <ZngLnS1_EaaokU2p0qbYq7CDGWEnKwOJPvRUHGKwJOc=.7d260bd7-cd26-4f11-9e8e-4c5f33ae6602@github.com>

On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.
> 
> Existing tests passes since it does not check behavior without args.
> After test update the test fails without 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> code block
> 
>> Test results: failed: 1
>> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
>> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>> Error: Some tests failed or other problems occurred.
>> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
>> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>  
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>> >>                                                       1     0     1     0 <<
>> ==============================
>> TEST FAILURE
> 
> 
> 
> after added the code block back 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> 
> updated test passes
> 
> 
> lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
>         -Xmx768m \\
>         -XX:MaxRAMPercentage=1.04167 \\
>         -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
>         -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
>         -ea \\
>         -esa \\
>         -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
>         com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/java/lang/ProcessBuilder/JspawnhelperPr...

Changes requested by rriggs (Reviewer).

Need more time to review.

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 111:

> 109:         if (p.exitValue() != 1)
> 110:             System.exit(ERROR + 2);
> 111:         System.exit(0);

Its bad form to System.exit from not at the top level. Is that necessary.

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

PR Review: https://git.openjdk.org/jdk/pull/18112#pullrequestreview-1915545846
PR Comment: https://git.openjdk.org/jdk/pull/18112#issuecomment-1977643226
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1511921441

From erikj at openjdk.org  Mon Mar  4 23:44:14 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 4 Mar 2024 23:44:14 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v4]
In-Reply-To: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
Message-ID: <UF3mP44thXI-j_zj8_m4or5scjDJbS62vhYUqB8uJKo=.6f7ffb5f-a476-44e5-8ff1-99fff5e1d753@github.com>

> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
> 
> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
> 
> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
> 
> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".

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

  bug ref

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18050/files
  - new: https://git.openjdk.org/jdk/pull/18050/files/faafef8a..8639eee5

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

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

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

From javalists at cbfiddle.com  Mon Mar  4 23:50:40 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 4 Mar 2024 15:50:40 -0800
Subject: jpackage requests permission via a dialog
In-Reply-To: <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
Message-ID: <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>

Thank you for the explanation.

It was not obvious to me that the configuration of the DMG appearance actually means configuring the .DS_Store file in the DMG.

  Alan

> On Mar 4, 2024, at 1:27?PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Alan,
>  
> See below.
>  
> From: core-libs-dev <core-libs-dev-retn at openjdk.org <mailto:core-libs-dev-retn at openjdk.org>> on behalf of Alan Snyder <javalists at cbfiddle.com <mailto:javalists at cbfiddle.com>>
> Date: Sunday, March 3, 2024 at 7:09?PM
> 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: jpackage requests permission via a dialog
> 
> I tried using jpackage on macOS to create a DMG (which I have not done before) and was surprised when a system dialog was displayed requesting permission for Terminal to control Finder.
> 
> I found this issue described in JDK-8231855, which was closed without explanation as ?not an issue?.
> 
> From JDK-8231855: ?Looks like this dialog is part of macOS Catalina Data Protection features. I did not found if it possible not to trigger this prompt. Also, this prompt is shown only once and subsequent jpackage runs will not show any prompts. As workaround in case when jpackage will be part of automated build system which needs to be run without user intervention it is recommended to run jpackage first on this system and confirm any prompts.?.
> 
> It seems to me that having a command line build tool try to interact with a user via a dialog is inappropriate, even if it happens only once per system.
> 
> So far, I did not figure out other solution for this problem.
> 
> I?m not sure why this dialog is shown, as it appears that all of the actions are performed by running the hdiutil program.
> 
> This dialog is shown when we running osascript (https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/DMGsetup.scpt) to post process DMG file. This script will setup DMG background and re-arrange icons, so it look nice.
> 
> It does seem odd, however, that jpackage mounts the DMG to modify its contents. Shouldn?t the contents be set up before creating the DMG?
> 
> We need to mount it to run osascript I mentioned above.
> 
> Is mounting the image the source of the dialog?
> 
> No, dialog is shown after we mount it from osascript which is run right after DMG is mounted.
> 
> Is there some reason this cannot be fixed?
> 
> So far I did not found any substitution to our osascript to setup background image and re-arrange icons. I do not think that Apple provides any other ways to do it.
> 
> Thanks,
> 
> Alexander
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240304/d4b90c15/attachment.htm>

From vpetko at openjdk.org  Mon Mar  4 23:57:52 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 4 Mar 2024 23:57:52 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <ZngLnS1_EaaokU2p0qbYq7CDGWEnKwOJPvRUHGKwJOc=.7d260bd7-cd26-4f11-9e8e-4c5f33ae6602@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <ZngLnS1_EaaokU2p0qbYq7CDGWEnKwOJPvRUHGKwJOc=.7d260bd7-cd26-4f11-9e8e-4c5f33ae6602@github.com>
Message-ID: <bM0-VQtvEoxf1CIkTSu4uLYCz3au_ICdlwwaoEhMUR4=.2ff7ac91-74b0-44b3-b38a-52fd964eb4f6@github.com>

On Mon, 4 Mar 2024 23:23:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.
>> 
>> Existing tests passes since it does not check behavior without args.
>> After test update the test fails without 
>> 
>>    if (argc != 2) {
>>         shutItDown();
>>     }
>> 
>> code block
>> 
>>> Test results: failed: 1
>>> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
>>> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>> Error: Some tests failed or other problems occurred.
>>> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
>>> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>>  
>>> ==============================
>>> Test summary
>>> ==============================
>>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>>> >>                                                       1     0     1     0 <<
>>> ==============================
>>> TEST FAILURE
>> 
>> 
>> 
>> after added the code block back 
>> 
>>    if (argc != 2) {
>>         shutItDown();
>>     }
>> 
>> 
>> updated test passes
>> 
>> 
>> lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
>>         -Xmx768m \\
>>         -XX:MaxRAMPercentage=1.04167 \\
>>         -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
>>         -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
>>         -ea \\
>>         -esa \\
>>         -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
>>         com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang...
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 111:
> 
>> 109:         if (p.exitValue() != 1)
>> 110:             System.exit(ERROR + 2);
>> 111:         System.exit(0);
> 
> Its bad form to System.exit from not at the top level. Is that necessary.

This is in line with other tests in this file , e.g. see `parentCode()`. 

I agree that code would be cleaner if the test is refactored to return error code from the test methods and system.exit() in the main instead, but this might be a separate pr done before or after this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1511953089

From jlu at openjdk.org  Tue Mar  5 00:32:47 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 00:32:47 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string [v2]
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

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 five additional commits since the last revision:

 - cleanup/typo
 - Merge branch 'master' into JDK-8326908-emptyPattern-OOME
 - implement feedback + improve pattern related tests
 - minor additions
 - init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18094/files
  - new: https://git.openjdk.org/jdk/pull/18094/files/fc8a7ce4..7ca56500

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

  Stats: 5885 lines in 919 files changed: 2483 ins; 1248 del; 2154 mod
  Patch: https://git.openjdk.org/jdk/pull/18094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18094/head:pull/18094

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

From jlu at openjdk.org  Tue Mar  5 00:32:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 00:32:48 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string [v2]
In-Reply-To: <ycyUibb8e5NBVff0ftU7WeAhlreWrW0qLIXJu9zbv1E=.d4694e1a-fded-4dfc-a57c-8632590aa8ab@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <ycyUibb8e5NBVff0ftU7WeAhlreWrW0qLIXJu9zbv1E=.d4694e1a-fded-4dfc-a57c-8632590aa8ab@github.com>
Message-ID: <Ltk6S6M2A9oKxGf3dHZUO-SD2LhbcnZm0EcwYVsICmo=.44ba2165-8738-42c4-9b92-3e5dd9edf462@github.com>

On Mon, 4 Mar 2024 16:03:55 GMT, Roger Riggs <rriggs 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 five additional commits since the last revision:
>> 
>>  - cleanup/typo
>>  - Merge branch 'master' into JDK-8326908-emptyPattern-OOME
>>  - implement feedback + improve pattern related tests
>>  - minor additions
>>  - init
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 3717:
> 
>> 3715:             // As maxFracDigits are fully displayed unlike maxIntDigits
>> 3716:             // Prevent OOME by setting to a much more reasonable value.
>> 3717:             setMaximumFractionDigits(DOUBLE_FRACTION_DIGITS);
> 
> Setting a reasonable default makes sense.  
> In other control paths, the max fraction digits come from the inputs or are explicitly set.
> 
> It might be a reasonable related change to use StringBuilder.repeat() instead of a loop at LIne 3312-3319, where the pattern char(s) are being appended to the result.

Thanks for taking a look. Updated the loop with `repeat` as you suggested, and decided to refactor the rest of the method while I was at it.

Additionally, I added some more tests, as it seems that there is a lack of pattern tests for DecimalFormat in general.

> In other control paths, the max fraction digits come from the inputs or are explicitly set.

Right, while `Integer.MAX_VALUE` can still be set by other control paths (and thus an OOME if toPattern() is invoked), this is something explicitly done by the user, and thus we decided we would still allow the behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1511966791

From jlu at openjdk.org  Tue Mar  5 00:32:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 00:32:48 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string
In-Reply-To: <opssWK17CH7cXcdSq6M7Qxjux4xlIlNcujGIgH-wZkU=.9d26b388-a23d-477c-b185-1dc85f3e3a23@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <opssWK17CH7cXcdSq6M7Qxjux4xlIlNcujGIgH-wZkU=.9d26b388-a23d-477c-b185-1dc85f3e3a23@github.com>
Message-ID: <3hQuEgs2G2EaqOYtju-thoLE36yjHCkj_fgYSEPBB24=.819fbdde-471c-49f5-822a-3c49cc7f4d50@github.com>

On Sun, 3 Mar 2024 05:00:36 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
>> 
>> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.
>
>> When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs.
> 
> It seems a bug in `toPattern` or `StringBuilder`? May be better to investigate more about it.

Hi @lgxbslgx,

For clarification, this is entirely a bug with DecimalFormat, not StringBuilder. An empty String pattern DecimalFormat sets the maximum fraction digits to `Integer.MAX_VALUE`. When toPattern() is invoked, the local StringBuilder will append until an OOME is thrown by the StringBuilder as there is not enough memory, when internally, the buffer is doubled for a value too large. But such an OOME would occur for any large enough value, so the issue lies with DecimalFormat.

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

PR Comment: https://git.openjdk.org/jdk/pull/18094#issuecomment-1977712428

From naoto at openjdk.org  Tue Mar  5 00:57:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 00:57:08 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing all
 bad cases
Message-ID: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>

Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.

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

Commit messages:
 - initial commit

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

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

From darcy at openjdk.org  Tue Mar  5 02:29:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 5 Mar 2024 02:29:53 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases
In-Reply-To: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
Message-ID: <zNZ94G6-xn7khYjIiFR8aUqe0U--6WXYbXvzq-Mo1VM=.17b01fd2-ed96-4caf-826c-819ccecb7a5a@github.com>

On Tue, 5 Mar 2024 00:51:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.

Looks fine; thanks for sending out the fix.

test/jdk/java/lang/Double/ParseDouble.java line 559:

> 557:     private static void testParsing(String [] input,
> 558:                                     boolean exceptionalInput) {
> 559:         for(int i = 0; i < input.length; i++) {

As you're updating the file, I think changing the loop to an enhanced for loop would be an improvement.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18113#pullrequestreview-1915727056
PR Review Comment: https://git.openjdk.org/jdk/pull/18113#discussion_r1512050441

From mik3hall at gmail.com  Tue Mar  5 03:44:25 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 4 Mar 2024 21:44:25 -0600
Subject: jpackage requests permission via a dialog
In-Reply-To: <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
Message-ID: <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>

I?m not following what the .DS_Store file has to do with anything, other than being a Mac feature that?s occasionally a nuisance when the files end up in zip?s or elsewhere where you don?t want them. 

I?m also not sure if that was my explanation or Alexander?s you?re talking about. Using the osascript to run the dmg gives the dmg a look more like other distributed macOS applications. 

If that doesn?t matter to you then you could use jpackage to create a standalone app image and hdiutil a dmg for it. Opening it will show the files, period. Or use Disk Utility to create a dmg would also work. I?ve done that sometimes. Then you don?t have to remember the hdiutil command line usage. 

> On Mar 4, 2024, at 5:50?PM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> Thank you for the explanation.
> 
> It was not obvious to me that the configuration of the DMG appearance actually means configuring the .DS_Store file in the DMG.
> 
>   Alan
> 


From alexander.matveev at oracle.com  Tue Mar  5 03:57:14 2024
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 5 Mar 2024 03:57:14 +0000
Subject: [External] : Re: jpackage requests permission via a dialog
In-Reply-To: <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
 <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
Message-ID: <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>

Hi Michael,

.DS_Store file contains information about icon position and other visual information on how to display folder. Once osascript configures DMG, Finder will store these setting in .DS_Store file. If it gets deleted from DMG, DMG will look like osascript was never run. So, Alan is right with ?the configuration of the DMG appearance actually means configuring the .DS_Store file in the DMG?.

Thanks,
Alexander

From: Michael Hall <mik3hall at gmail.com>
Date: Monday, March 4, 2024 at 7:44?PM
To: Alan Snyder <fishgarage at cbfiddle.com>
Cc: Alexander Matveev <alexander.matveev at oracle.com>, core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: jpackage requests permission via a dialog
I?m not following what the .DS_Store file has to do with anything, other than being a Mac feature that?s occasionally a nuisance when the files end up in zip?s or elsewhere where you don?t want them.

I?m also not sure if that was my explanation or Alexander?s you?re talking about. Using the osascript to run the dmg gives the dmg a look more like other distributed macOS applications.

If that doesn?t matter to you then you could use jpackage to create a standalone app image and hdiutil a dmg for it. Opening it will show the files, period. Or use Disk Utility to create a dmg would also work. I?ve done that sometimes. Then you don?t have to remember the hdiutil command line usage.

> On Mar 4, 2024, at 5:50?PM, Alan Snyder <javalists at cbfiddle.com> wrote:
>
> Thank you for the explanation.
>
> It was not obvious to me that the configuration of the DMG appearance actually means configuring the .DS_Store file in the DMG.
>
>   Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/57f61812/attachment-0001.htm>

From jpai at openjdk.org  Tue Mar  5 04:28:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 04:28:44 GMT
Subject: RFR: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <fRItNcOqp860rtjDFnxsG6OGTGZRNOgx9jE97dcrH08=.1caf787d-467b-4aa3-8087-1d1ec765b227@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

Hello Eirik, the removal of this internal unused package private method and the updated comments in the tests look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18104#pullrequestreview-1915846886

From joehw at openjdk.org  Tue Mar  5 06:52:54 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 5 Mar 2024 06:52:54 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v6]
In-Reply-To: <T8EvrAU2TaEKGwnqcAv1q3TsREiAFSoblLo-NPRvRBo=.2a7aaa81-da1c-477b-b612-b1cafee8e9d0@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <T8EvrAU2TaEKGwnqcAv1q3TsREiAFSoblLo-NPRvRBo=.2a7aaa81-da1c-477b-b612-b1cafee8e9d0@github.com>
Message-ID: <BTe8l5vnvQEU9F1G-g8IeYmEP_GMUHpBK1nqnnrG4Kg=.fcb7149f-f6a0-4773-a182-2f26d7774d8a@github.com>

On Mon, 4 Mar 2024 19:07:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8174269-COMPAT-Removal
>  - Addressing review comments
>  - Update test/jdk/java/text/Format/DateFormat/Bug6683975.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Remove `GensrcLocaleData.gmk`
>  - Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - cleanup
>  - BreakIteratorProvider available locales fix
>  - clean-up
>  - test fixes
>  - makeZoneData.pl fix
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/9da59104...b771e303

LGTM. This is a lot of work. Looking through the files alone takes hours. Kudos to the great work!

I kind of like some of the date formats in COMPACT to be honest :-)

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1320:

> 1318:      * "US<NBSP>dst" -> "D"
> 1319:      *
> 1320:      * `tzdbLinks` retains `Link`s of time zones. if the value

nit, "if the value" seems to be an unfinished sentence.

src/java.base/share/classes/sun/util/locale/provider/BaseLocaleDataMetaInfo.java line 31:

> 29:  * It is used to avoid loading non-existent localized resources so that
> 30:  * jar files won't be opened unnecessary to look up them.
> 31:  */

nit: move the class description to right above the class? "unnecessary" -> "unnecessarily"

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17991#pullrequestreview-1915980264
PR Comment: https://git.openjdk.org/jdk/pull/17991#issuecomment-1978071713
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1512206671
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1512207766

From dholmes at openjdk.org  Tue Mar  5 07:18:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Mar 2024 07:18:47 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v4]
In-Reply-To: <UF3mP44thXI-j_zj8_m4or5scjDJbS62vhYUqB8uJKo=.6f7ffb5f-a476-44e5-8ff1-99fff5e1d753@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <UF3mP44thXI-j_zj8_m4or5scjDJbS62vhYUqB8uJKo=.6f7ffb5f-a476-44e5-8ff1-99fff5e1d753@github.com>
Message-ID: <2E3wi6IUpcYa0hPInwu1QuQyvEe8YWZWTnXJDwc-dSQ=.670c3032-aa88-48d9-9c0c-5b04a27eab8b@github.com>

On Mon, 4 Mar 2024 23:44:14 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
>> 
>> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
>> 
>> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
>> 
>> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug ref

Thanks for the further explanation and adding the comment.

LGTM.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18050#pullrequestreview-1916027301

From mik3hall at gmail.com  Tue Mar  5 03:44:25 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 4 Mar 2024 21:44:25 -0600
Subject: jpackage requests permission via a dialog
In-Reply-To: <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
Message-ID: <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>

I?m not following what the .DS_Store file has to do with anything, other than being a Mac feature that?s occasionally a nuisance when the files end up in zip?s or elsewhere where you don?t want them. 

I?m also not sure if that was my explanation or Alexander?s you?re talking about. Using the osascript to run the dmg gives the dmg a look more like other distributed macOS applications. 

If that doesn?t matter to you then you could use jpackage to create a standalone app image and hdiutil a dmg for it. Opening it will show the files, period. Or use Disk Utility to create a dmg would also work. I?ve done that sometimes. Then you don?t have to remember the hdiutil command line usage. 

> On Mar 4, 2024, at 5:50?PM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> Thank you for the explanation.
> 
> It was not obvious to me that the configuration of the DMG appearance actually means configuring the .DS_Store file in the DMG.
> 
>   Alan
> 


From mik3hall at gmail.com  Tue Mar  5 08:28:04 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 5 Mar 2024 02:28:04 -0600
Subject: [External] : Re: jpackage requests permission via a dialog
In-Reply-To: <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
 <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
 <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>
Message-ID: <98870774-91FA-4631-8E79-32C748D93400@gmail.com>

Hello Alexander,

I had forgotten or didn?t know that. I didn?t see it mentioned anywhere in this list thread previously. But there is generally no reason to delete this file. Unless you don?t want it included in a zip or a GitHub project. The icon placement for multiple files with jpackage ?mac-dmg-content is determined by the AppleScript. You might remember I had a related bug report. I provided a workaround with slight changes to the code invoking the AppleScript and the AppleScript. You came up with your own fix. I was impressed you did it by just changing the AppleScript but I slightly preferred the placement of my change. Again, if I remember right. 

Mike

> On Mar 4, 2024, at 9:57?PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
>  
> .DS_Store file contains information about icon position and other visual information on how to display folder. Once osascript configures DMG, Finder will store these setting in .DS_Store file. If it gets deleted from DMG, DMG will look like osascript was never run. So, Alan is right with ?the configuration of the DMG appearance actually means configuring the .DS_Store file in the DMG?.
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/a6c10356/attachment.htm>

From eirbjo at openjdk.org  Tue Mar  5 08:41:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 5 Mar 2024 08:41:55 GMT
Subject: RFR: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <nl4Rjy6FqsKKJBBUCdZngbYTx2_o91uYFlnfT7ACwV8=.ea7cd02f-5c2d-4e99-a7a9-4d70c7fb6c34@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

Thanks for reviewing, Lance, Iris & Jai!

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

PR Comment: https://git.openjdk.org/jdk/pull/18104#issuecomment-1978224550

From eirbjo at openjdk.org  Tue Mar  5 08:41:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 5 Mar 2024 08:41:55 GMT
Subject: Integrated: 8327208: Remove unused method
 java.util.jar.Manifest.make72Safe
In-Reply-To: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
References: <i_vb9ms8fGo6PoaKjY8mf1AyAKjVsSagE-YGiqPdHqI=.a612143f-b78b-4ac9-8498-dd2a26b69f32@github.com>
Message-ID: <XvEZAWuRwR5yf90CW3PvhzdK_-ZEyXnZcQZodosZGgw=.489c378f-0b53-424a-8c19-84049cdd0a20@github.com>

On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`.
> 
> This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use. It should rather be removed.
> 
> Some tests reference the `make72Safe` methods in comment, or implement the legacy versions of the same logic to simulate pre JDK 11 line break behavior of `Manifest.write`. These comments and method names are adjusted to not reference the now removed method.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119819.html

This pull request has now been integrated.

Changeset: e9adceba
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9adcebaf242843fe2004b01747b5a930b62b291
Stats:     33 lines in 3 files changed: 2 ins; 21 del; 10 mod

8327208: Remove unused method java.util.jar.Manifest.make72Safe

Reviewed-by: lancea, iris, jpai

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

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

From aturbanov at openjdk.org  Tue Mar  5 09:09:47 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 5 Mar 2024 09:09:47 GMT
Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized'
 unnecessarily
In-Reply-To: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>
References: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>
Message-ID: <GyKhWBlfh8GoyH00L1udsYoM-DaSQGNYFWMoVAxKv_M=.5893e9cb-6caf-4d55-8a12-25030a88f988@github.com>

On Tue, 16 Jan 2024 10:19:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 methods in `java.util.TimeZone` which are `public static` and marked as `synchronized`:
> 1. getTimeZone(String)
> 2. getAvailableIDs(int)
> 3. getAvailableIDs()
> 
> This means it is a bottle neck for the whole VM.
> I've checked the implementation and concluded that `synchronized` is unnecessary.

keep open. Waiting for review

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

PR Comment: https://git.openjdk.org/jdk/pull/17441#issuecomment-1978273804

From shade at openjdk.org  Tue Mar  5 10:41:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 5 Mar 2024 10:41:54 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <Wh7mlhwLnhoh9J1ajGDFA9OBC2D39OlPpMLlWP4G08M=.1eb79fb0-240e-4c6a-9188-46bcc4cdb54b@github.com>

On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.
> 
> Existing tests passes since it does not check behavior without args.
> After test update the test fails without 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> code block
> 
>> Test results: failed: 1
>> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
>> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>> Error: Some tests failed or other problems occurred.
>> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
>> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>  
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>> >>                                                       1     0     1     0 <<
>> ==============================
>> TEST FAILURE
> 
> 
> 
> after added the code block back 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> 
> updated test passes
> 
> 
> lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
>         -Xmx768m \\
>         -XX:MaxRAMPercentage=1.04167 \\
>         -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
>         -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
>         -ea \\
>         -esa \\
>         -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
>         com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/java/lang/ProcessBuilder/JspawnhelperPr...

The change in jspawnhelper looks good.

I think it would be simpler to have a separate `jdk/java/lang/ProcessBuilder/JspawnhelperMisuse.java` test that simply invokes the `jspawnhelper` and verifies the proper message is printed. It would be more straightforward than trying to fit the _protocol_ test? Plus, we can test 0, 1, 3, 4 args, not only 0 args in that test, and we can also test 2 args with bad format.

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

PR Review: https://git.openjdk.org/jdk/pull/18112#pullrequestreview-1916529453

From kevinw at openjdk.org  Tue Mar  5 11:39:48 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 11:39:48 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
Message-ID: <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>

On Mon, 4 Mar 2024 19:57:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I was not exactly sure if we will support this functionality when there is no SM. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.
>
> I think we need @kevinjwalls or @dfuch to help advise on this.

Right, this does not depend on the SM.   All we need to do is get the Subject.
This method implements the basic monitor (readonly) and control (readwrite) access.
accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1512676642

From gli at openjdk.org  Tue Mar  5 11:56:45 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 5 Mar 2024 11:56:45 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string
In-Reply-To: <3hQuEgs2G2EaqOYtju-thoLE36yjHCkj_fgYSEPBB24=.819fbdde-471c-49f5-822a-3c49cc7f4d50@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <opssWK17CH7cXcdSq6M7Qxjux4xlIlNcujGIgH-wZkU=.9d26b388-a23d-477c-b185-1dc85f3e3a23@github.com>
 <3hQuEgs2G2EaqOYtju-thoLE36yjHCkj_fgYSEPBB24=.819fbdde-471c-49f5-822a-3c49cc7f4d50@github.com>
Message-ID: <FgItzEBaBwqeuTcueenqJHMyPOUTBTn3SZfNM1XWr_c=.aa28b7e9-4d35-4d2e-b8f5-3e490311cfcd@github.com>

On Tue, 5 Mar 2024 00:15:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> For clarification, this is entirely a bug with DecimalFormat, not StringBuilder. An empty String pattern DecimalFormat sets the maximum fraction digits to Integer.MAX_VALUE. When toPattern() is invoked, the local StringBuilder will append until an OOME is thrown by the StringBuilder as there is not enough memory, when internally, the buffer is doubled for a value too large. But such an OOME would occur for any large enough value, so the issue lies with DecimalFormat.

Got it. Thanks for your explanation.

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

PR Comment: https://git.openjdk.org/jdk/pull/18094#issuecomment-1978591032

From gli at openjdk.org  Tue Mar  5 12:27:45 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 5 Mar 2024 12:27:45 GMT
Subject: RFR: 8327225: Revert DataInputStream.readUTF to static final
In-Reply-To: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
References: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
Message-ID: <9yqdt15AhzgmCRf4J3uJ9AjfrKJgoPSNbpbiDkX1Bhw=.60967263-ed2c-46c3-a0ba-a38e3c52fbba@github.com>

On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally removed `final` from the `static final DataInputStream.readUTF` method. This has a minor compatibility impact (allows hiding the method in a subclass, while before that would throw an exception at compile time) and since it was not the intent of the prior change to alter any behavioral semantics here I want to revert that change.

> It's a bit unusual to have the final modifier on static methods

I searched the `public static final` and `public final static` in the code base. Currently, some methods, if not many, also use the `public final static`.

I would be OK with this patch.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18107#pullrequestreview-1916756792

From jlahoda at openjdk.org  Tue Mar  5 12:44:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Mar 2024 12:44:10 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

Jan Lahoda 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>
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18106/files
  - new: https://git.openjdk.org/jdk/pull/18106/files/924e1aa0..6127044d

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

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

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

From jlahoda at openjdk.org  Tue Mar  5 12:44:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Mar 2024 12:44:10 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <XHuh25R9QzUR6dEzXvV1dN_29eVRempkb1qPsDQvTrk=.86e9f3f0-a94d-45db-a5fc-00d6db0c6f84@github.com>

On Tue, 5 Mar 2024 12:41:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda 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>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 806:

> 804:     /**
> 805:      * Process the --enable-native-access option to grant access to restricted methods to selected modules.
> 806:      * Also add Enable native access from JDK modules.

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512761636

From redestad at openjdk.org  Tue Mar  5 13:33:49 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 5 Mar 2024 13:33:49 GMT
Subject: RFR: 8327225: Revert DataInputStream.readUTF to static final
In-Reply-To: <yvKrQf2-Wz8IxHrI798CTuFjj67QHfymYTf4OO4jElE=.5af94a37-1338-4034-8229-1301bd2caa7d@github.com>
References: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
 <yvKrQf2-Wz8IxHrI798CTuFjj67QHfymYTf4OO4jElE=.5af94a37-1338-4034-8229-1301bd2caa7d@github.com>
Message-ID: <5P9dxRUjxdPixuGh3TevFgGszkBI2riyRi69hUVUatc=.1842e099-d458-4fa4-b24f-a5f26d95b0d8@github.com>

On Mon, 4 Mar 2024 17:27:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's a bit unusual to have the final modifier on static methods, looks like it goes back to JDK 1.1 at least, not clear if it was intentional.

Right, I was asked by JCK folks to either file a CSR to have the change recorded, or revert. Since the behavior change was not intended and was not a key part of [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) I prefer reverting. If anyone wants to get rid of this and other more or less superfluous `final`s that should be done in a separate, deliberate RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/18107#issuecomment-1978780028

From redestad at openjdk.org  Tue Mar  5 13:33:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 5 Mar 2024 13:33:50 GMT
Subject: Integrated: 8327225: Revert DataInputStream.readUTF to static final
In-Reply-To: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
References: <GZPEChso4g7oD6Owx4fQiRcxPQsfvJyA9JN7Rj1U0Mw=.c0c9dc66-c495-4d61-9d0c-c18b4b9894e2@github.com>
Message-ID: <UIzbxIBXGFE4qsIUNc5uq9F-V59byWyRf61mZA4lmmw=.28a47fc0-9ec0-4928-b3a4-50f887c3a671@github.com>

On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally removed `final` from the `static final DataInputStream.readUTF` method. This has a minor compatibility impact (allows hiding the method in a subclass, while before that would throw an exception at compile time) and since it was not the intent of the prior change to alter any behavioral semantics here I want to revert that change.

This pull request has now been integrated.

Changeset: c653e67c
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c653e67c0f6ce7a023a5ea079d8872b1eeb8eba7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8327225: Revert DataInputStream.readUTF to static final

Reviewed-by: rriggs, bpb, gli

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

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

From jvernee at openjdk.org  Tue Mar  5 13:34:50 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 5 Mar 2024 13:34:50 GMT
Subject: Integrated: 8326172: Dubious claim on long[]/double[] alignment in
 MemorySegment javadoc
In-Reply-To: <VvyLXZG3TwhT7r32xiSDM_i9H72cepoYdBKmcVlz8fc=.3a7caa8c-e662-49c3-b1ae-b3e50b1aea06@github.com>
References: <VvyLXZG3TwhT7r32xiSDM_i9H72cepoYdBKmcVlz8fc=.3a7caa8c-e662-49c3-b1ae-b3e50b1aea06@github.com>
Message-ID: <43o41rrSOz-jot0JSMlm0nKjAfZsp38JF_ZT67V33ZI=.4b4f75e2-e487-4cf7-8d9f-ec4aba6c10b3@github.com>

On Mon, 26 Feb 2024 13:24:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, regardless of the underlying platform. This means that atomic access modes work on memory segments wrapping `long[]` or `double[]`, as they already do when using `MethodHandless::arrayAccessVarHandle`.
> 
> After discussion, we came to the conclusion that it is reasonable for the JDK to require the elements of a `long[]` and `double[]` to be 8 byte aligned. It is ultimately up to the JDK to set these requirements, which are for the VM to implement.
> 
> I was seeing a stack overflow when running test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've lowered the recursion to 50 (which is still more than enough I think).
> 
> Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86 Linux (uses fallback linker)

This pull request has now been integrated.

Changeset: 2372aba6
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2372aba6a21c569d4d724396e59b9fd1bec90682
Stats:     67 lines in 10 files changed: 18 ins; 23 del; 26 mod

8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc

Reviewed-by: mcimadamore

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

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

From jpai at openjdk.org  Tue Mar  5 13:51:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 13:51:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>

On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda 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>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

make/conf/module-loader-map.conf line 95:

> 93:     #
> 94: 
> 95: NATIVE_ACCESS_MODULES= \

Hello Jan, does this make configuration allow for something like:


NATIVE_ACCESS_MODULES= ${BOOT_MODULES} \
${PLATFORM_MODULES} \
foo.bar.additional.module

(please ignore any syntax issues in that snippet)

to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512845758

From jpai at openjdk.org  Tue Mar  5 14:04:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 14:04:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <CQCdfDP6785EDomU2zdtqsi6DpyHYpnHo20Sucs7xPc=.58038e72-419c-40a5-a378-a7bd6b766809@github.com>

On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda 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>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Some of the files updated in this PR need a copyright year update.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 817:

> 815:                 JLA.addEnableNativeAccessToAllUnnamed();
> 816:             } else if (!JLA.addEnableNativeAccess(layer, name) && shouldWarn) {
> 817:                 warnUnknownModule(ENABLE_NATIVE_ACCESS, name);

Should we instead warn irrespective of whether or not it's user configured native access module name or a module name configured in JDK's build configuration? Or are the build misconfiguration in the `NATIVE_ACCESS_MODULES` expected to be caught much earlier in some other place?

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

PR Comment: https://git.openjdk.org/jdk/pull/18106#issuecomment-1978836356
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512869279

From alanb at openjdk.org  Tue Mar  5 14:04:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Mar 2024 14:04:48 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
Message-ID: <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>

On Tue, 5 Mar 2024 13:42:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?

The list to be be granted native access is a subset, it shouldn't be granted all modules mapped to the boot or platform class loaders.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512873855

From jpai at openjdk.org  Tue Mar  5 14:16:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 14:16:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
 <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
Message-ID: <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>

On Tue, 5 Mar 2024 14:01:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> make/conf/module-loader-map.conf line 95:
>> 
>>> 93:     #
>>> 94: 
>>> 95: NATIVE_ACCESS_MODULES= \
>> 
>> Hello Jan, does this make configuration allow for something like:
>> 
>> 
>> NATIVE_ACCESS_MODULES= ${BOOT_MODULES} \
>> ${PLATFORM_MODULES} \
>> foo.bar.additional.module
>> 
>> (please ignore any syntax issues in that snippet)
>> 
>> to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?
>
>> to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?
> 
> The list to be be granted native access is a subset, it shouldn't be granted all modules mapped to the boot or platform class loaders.

I see. I then misunderstood a part of the PR description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512894628

From gli at openjdk.org  Tue Mar  5 14:20:46 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 5 Mar 2024 14:20:46 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases
In-Reply-To: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
Message-ID: <rLLIk7IGKpmZe9mb30ntmvJMil8VLgUhXbbHP3WZ8g0=.15081e1a-1327-4ca8-b214-47b161effd1c@github.com>

On Tue, 5 Mar 2024 00:51:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.

Looks good.

Only a trivial suggestion.

test/jdk/java/lang/Double/ParseDouble.java line 564:

> 562:                 check(input[i]);
> 563:             }
> 564:             catch (NumberFormatException e) {

The `catch` clause doesn't need to stay in a new line.

test/jdk/java/lang/Float/ParseFloat.java line 284:

> 282:                 check(input[i]);
> 283:             }
> 284:             catch (NumberFormatException e) {

The `catch` clause doesn't need to stay in a new line.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18113#pullrequestreview-1917117778
PR Review Comment: https://git.openjdk.org/jdk/pull/18113#discussion_r1512898093
PR Review Comment: https://git.openjdk.org/jdk/pull/18113#discussion_r1512899151

From erikj at openjdk.org  Tue Mar  5 14:21:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 5 Mar 2024 14:21:46 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v4]
In-Reply-To: <2E3wi6IUpcYa0hPInwu1QuQyvEe8YWZWTnXJDwc-dSQ=.670c3032-aa88-48d9-9c0c-5b04a27eab8b@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <UF3mP44thXI-j_zj8_m4or5scjDJbS62vhYUqB8uJKo=.6f7ffb5f-a476-44e5-8ff1-99fff5e1d753@github.com>
 <2E3wi6IUpcYa0hPInwu1QuQyvEe8YWZWTnXJDwc-dSQ=.670c3032-aa88-48d9-9c0c-5b04a27eab8b@github.com>
Message-ID: <ToHTphWoxPgLOENkn9ZDyzSMn5UFc4dn_rojw0Wn798=.e1abf667-53e7-4199-ab73-e2869a120454@github.com>

On Tue, 5 Mar 2024 07:16:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Thanks for the further explanation and adding the comment.
> 
> LGTM.

Thanks! Does the release note also looks ok? I understand it needs to be reviewed together with the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1978879864

From ihse at openjdk.org  Tue Mar  5 14:25:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Mar 2024 14:25:47 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v4]
In-Reply-To: <UF3mP44thXI-j_zj8_m4or5scjDJbS62vhYUqB8uJKo=.6f7ffb5f-a476-44e5-8ff1-99fff5e1d753@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <UF3mP44thXI-j_zj8_m4or5scjDJbS62vhYUqB8uJKo=.6f7ffb5f-a476-44e5-8ff1-99fff5e1d753@github.com>
Message-ID: <jJQVTFG3mUk8yJxI7R7_jcH2egQE6wld62KzQ6NIynM=.506627e3-5346-43a4-ab33-1bf1672d2d11@github.com>

On Mon, 4 Mar 2024 23:44:14 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
>> 
>> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
>> 
>> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
>> 
>> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug ref

Yes, the release note looks good. Is there any process to formally review release notes?

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

PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1978888625

From weijun at openjdk.org  Tue Mar  5 14:46:47 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:46:47 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
Message-ID: <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>

On Tue, 5 Mar 2024 11:36:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I think we need @kevinjwalls or @dfuch to help advise on this.
>
> Right, this does not depend on the SM.   All we need to do is get the Subject.
> This method implements the basic monitor (readonly) and control (readwrite) access.
> accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.

Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1512951092

From weijun at openjdk.org  Tue Mar  5 14:58:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:58:25 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v5]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <5fLmCMsDfb6akv1964_z9y8a4ccxmXaLJVjNiU5Khvs=.69025b5e-374e-4ae2-9db8-d27580a10345@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

 - Merge branch 'master' into 8296244
 - revert some test changes, spec change for subject
 - fix MBeanServerFileAccessController, more test in SM
 - JMX needs SM
 - Resolve Alan's comments
 - remove exe bits
 - remove x bit
 - the patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/e57f7250..2b55b171

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

  Stats: 97308 lines in 3235 files changed: 46912 ins; 26097 del; 24299 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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

From duke at openjdk.org  Tue Mar  5 15:23:55 2024
From: duke at openjdk.org (duke)
Date: Tue, 5 Mar 2024 15:23:55 GMT
Subject: Withdrawn: 8318971: Better Error Handling for Jar Tool Processing of
 "@File"
In-Reply-To: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
References: <tRdwONiBvfMq3k-WnIjNFZMGqJiKnd9IZ-KNizuRAIk=.16306664-5830-44cc-b275-185701a31228@github.com>
Message-ID: <A63WndReCmpkGOTBWs8loxuzKP6fKcp_7_HZwMjPFLw=.c790b145-a2c5-42cd-ad1a-b616621a4de0@github.com>

On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace <duke at openjdk.org> wrote:

> Hi all,
> 
> Please review this fix for jar tool not producing an archive if there is a missing file supplied.
> The current behaviour will recognise missing files as an error but continue processing,
> creating a temporary archive and then deleting it without moving to the current directory.
> The fix is to return false when a missing file is supplied and exit immediately without continuing with any wasted processing.
> 
> Thanks,
> Ryan.

This pull request has been closed without being integrated.

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

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

From jlahoda at openjdk.org  Tue Mar  5 16:15:46 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Mar 2024 16:15:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
 <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
 <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>
Message-ID: <qUywPUBxrFPqmBQt0CmeoIjDdY__AaxZ1RnqbqpKtxs=.19abd551-8a3b-40e0-a148-0701fbce0405@github.com>

On Tue, 5 Mar 2024 14:14:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> to make the intention clear as well as reduce the chances of missing some boot or platform module in this NATIVE_ACCESS_MODULES?
>> 
>> The list to be be granted native access is a subset, it shouldn't be granted all modules mapped to the boot or platform class loaders.
>
> I see. I then misunderstood a part of the PR description.

I believe we could technically reuse the list for boot/platform modules. But, the intent here is to provide more control over the modules with native access, not only being able to add to the list, but also remove from the list. So, to me, it seemed better to have an explicit list, from/to which we can remove/add modules easily.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513107379

From javalists at cbfiddle.com  Tue Mar  5 16:50:34 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 5 Mar 2024 08:50:34 -0800
Subject: [External] : Re: jpackage requests permission via a dialog
In-Reply-To: <98870774-91FA-4631-8E79-32C748D93400@gmail.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
 <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
 <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>
 <98870774-91FA-4631-8E79-32C748D93400@gmail.com>
Message-ID: <BFEE7025-C914-42D2-88C2-7BB28E649B59@cbfiddle.com>

I?m wondering whether some developers might prefer to arrange the DMG layout by hand.

That would require jpackage to use a .DS_Store file provided by the developer and not running the script.

The issue is whether a .DS_Store file created using a previous DMG would work in a new DMG.

The documentation for install4j suggests that there is a way.

[https://www.ej-technologies.com/resources/install4j/help/doc/concepts/dmgStyling.html]



> On Mar 5, 2024, at 12:28?AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Hello Alexander,
> 
> I had forgotten or didn?t know that. I didn?t see it mentioned anywhere in this list thread previously. But there is generally no reason to delete this file. Unless you don?t want it included in a zip or a GitHub project. The icon placement for multiple files with jpackage ?mac-dmg-content is determined by the AppleScript. You might remember I had a related bug report. I provided a workaround with slight changes to the code invoking the AppleScript and the AppleScript. You came up with your own fix. I was impressed you did it by just changing the AppleScript but I slightly preferred the placement of my change. Again, if I remember right. 
> 
> Mike
> 
>> On Mar 4, 2024, at 9:57?PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>> 
>> Hi Michael,
>>  
>> .DS_Store file contains information about icon position and other visual information on how to display folder. Once osascript configures DMG, Finder will store these setting in .DS_Store file. If it gets deleted from DMG, DMG will look like osascript was never run. So, Alan is right with ?the configuration of the DMG appearance actually means configuring the .DS_Store file in the DMG?.
>>  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/ce70f864/attachment.htm>

From kevinw at openjdk.org  Tue Mar  5 16:51:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 16:51:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
Message-ID: <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>

On Tue, 5 Mar 2024 14:44:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Right, this does not depend on the SM.   All we need to do is get the Subject.
>> This method implements the basic monitor (readonly) and control (readwrite) access.
>> accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.
>
> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.

Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

(That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
https://github.com/openjdk/jdk/pull/18025 )

makeClient in RMIJRMPServerImpl creates RMIConnectionImpl

..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513164360

From naoto at openjdk.org  Tue Mar  5 17:26:11 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 17:26:11 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases [v2]
In-Reply-To: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
Message-ID: <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>

> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.

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

  Reflects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18113/files
  - new: https://git.openjdk.org/jdk/pull/18113/files/4c80fe5c..c67ecc32

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

  Stats: 16 lines in 2 files changed: 0 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/18113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18113/head:pull/18113

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

From naoto at openjdk.org  Tue Mar  5 17:26:11 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 17:26:11 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases
In-Reply-To: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
Message-ID: <07ZZA1SNRKTlj2mqMHWhlRdo7ye-6VRCd63Q0jTtLec=.fedac518-3a94-4ec0-a9b4-9d3b505f1ff4@github.com>

On Tue, 5 Mar 2024 00:51:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.

Thanks for the reviews. Updated as suggested

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

PR Comment: https://git.openjdk.org/jdk/pull/18113#issuecomment-1979271823

From joehw at openjdk.org  Tue Mar  5 17:45:46 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 5 Mar 2024 17:45:46 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases [v2]
In-Reply-To: <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
 <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
Message-ID: <YoUJCLislM2E2LTjFA7PLX3o_iaNC0X6aVRf1fDRN5w=.1fba8730-7a6d-498f-b0e0-3cbc61e6dfc8@github.com>

On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18113#pullrequestreview-1917711954

From naoto at openjdk.org  Tue Mar  5 17:50:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 17:50:09 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v7]
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <fzGtSyEbpU0QGOK-minXRamVv9EWt5L_qLYuAPcThF0=.65bc53ce-4cf0-4d5a-96f5-9a2980fddda9@github.com>

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

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

  Reflects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17991/files
  - new: https://git.openjdk.org/jdk/pull/17991/files/b771e303..78a5130e

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

  Stats: 13 lines in 3 files changed: 5 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

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

From naoto at openjdk.org  Tue Mar  5 17:50:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 17:50:14 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v6]
In-Reply-To: <BTe8l5vnvQEU9F1G-g8IeYmEP_GMUHpBK1nqnnrG4Kg=.fcb7149f-f6a0-4773-a182-2f26d7774d8a@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <T8EvrAU2TaEKGwnqcAv1q3TsREiAFSoblLo-NPRvRBo=.2a7aaa81-da1c-477b-b612-b1cafee8e9d0@github.com>
 <BTe8l5vnvQEU9F1G-g8IeYmEP_GMUHpBK1nqnnrG4Kg=.fcb7149f-f6a0-4773-a182-2f26d7774d8a@github.com>
Message-ID: <XM_GpXkUjbHcbxlbDPL-lrI4oO3s3ZT4npxsZTwyMfs=.ac9e9fb6-f665-423a-9b29-ce3a382b7140@github.com>

On Tue, 5 Mar 2024 06:44:52 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8174269-COMPAT-Removal
>>  - Addressing review comments
>>  - Update test/jdk/java/text/Format/DateFormat/Bug6683975.java
>>    
>>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>>  - Remove `GensrcLocaleData.gmk`
>>  - Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - cleanup
>>  - BreakIteratorProvider available locales fix
>>  - clean-up
>>  - test fixes
>>  - makeZoneData.pl fix
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/7faf5495...b771e303
>
> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1320:
> 
>> 1318:      * "US<NBSP>dst" -> "D"
>> 1319:      *
>> 1320:      * `tzdbLinks` retains `Link`s of time zones. if the value
> 
> nit, "if the value" seems to be an unfinished sentence.

Thanks. Not only the sentence, the description itself was unfinished. Corrected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1513248212

From rriggs at openjdk.org  Tue Mar  5 17:58:45 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Mar 2024 17:58:45 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <ylVfkXxoZYKiwHQEjUr3VqquY4yZukOSmAhLkwx5m7c=.c7eeee37-e34b-44c8-8865-f38a92071ee3@github.com>

On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.
> 
> Existing tests passes since it does not check behavior without args.
> After test update the test fails without 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> code block
> 
>> Test results: failed: 1
>> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
>> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>> Error: Some tests failed or other problems occurred.
>> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
>> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>  
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>> >>                                                       1     0     1     0 <<
>> ==============================
>> TEST FAILURE
> 
> 
> 
> after added the code block back 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> 
> updated test passes
> 
> 
> lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
>         -Xmx768m \\
>         -XX:MaxRAMPercentage=1.04167 \\
>         -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
>         -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
>         -ea \\
>         -esa \\
>         -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
>         com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/java/lang/ProcessBuilder/JspawnhelperPr...

I'm curious why this test is requires `vm.debug`?  That means it generally won't get run on release builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/18112#issuecomment-1979329508

From rriggs at openjdk.org  Tue Mar  5 17:58:46 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Mar 2024 17:58:46 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <bM0-VQtvEoxf1CIkTSu4uLYCz3au_ICdlwwaoEhMUR4=.2ff7ac91-74b0-44b3-b38a-52fd964eb4f6@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <ZngLnS1_EaaokU2p0qbYq7CDGWEnKwOJPvRUHGKwJOc=.7d260bd7-cd26-4f11-9e8e-4c5f33ae6602@github.com>
 <bM0-VQtvEoxf1CIkTSu4uLYCz3au_ICdlwwaoEhMUR4=.2ff7ac91-74b0-44b3-b38a-52fd964eb4f6@github.com>
Message-ID: <IjXc1aLiNtOeleYRbL5I44qHe29j6lvDJEnm4V2i9aM=.c2373229-7466-43b7-a0ae-aa9282066ffb@github.com>

On Mon, 4 Mar 2024 23:54:38 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 111:
>> 
>>> 109:         if (p.exitValue() != 1)
>>> 110:             System.exit(ERROR + 2);
>>> 111:         System.exit(0);
>> 
>> Its bad form to System.exit from not at the top level. Is that necessary.
>
> This is in line with other tests in this file , e.g. see `parentCode()`. 
> 
> I agree that code would be cleaner if the test is refactored to return error code from the test methods and system.exit() in the main instead, but this might be a separate pr done before or after this one, e.g. something like [1].
> 
> [1] https://github.com/vpa1977/jdk/commit/7cbbaf498da8b71476e61e1c0f3fa7882c7aa7b6

ok, the same pattern is used consistently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1513262005

From eirbjo at gmail.com  Tue Mar  5 18:22:42 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 5 Mar 2024 19:22:42 +0100
Subject: RFD: Can we remove the deprecated internal Unsafe *Object* methods?
Message-ID: <CA+pBWhsGVnQPv3NsHzDwYYsMPahK5JM7HQyKo0KnOsAyzvm=1w@mail.gmail.com>

Hi,

Now that the JDK  repo is the single source of truth for
java.util.concurrent [1], I'm wondering if time has come to remove the
deprecated *Object* methods introduced in JDK-8213043 [2]

These alias methods were introduced because jsr166 used them, but there no
longer seems to be any use within the OpenJDK (verified by removing them
and running java.util.concurrent tests).

Hearing no objections I'll prepare a PR to remove these 19 deprecated, for
removal methods.

Eirik.

[1]
https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119047.html
[2] https://bugs.openjdk.org/browse/JDK-8213043
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/76e3a789/attachment.htm>

From joehw at openjdk.org  Tue Mar  5 18:42:48 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 5 Mar 2024 18:42:48 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v7]
In-Reply-To: <fzGtSyEbpU0QGOK-minXRamVv9EWt5L_qLYuAPcThF0=.65bc53ce-4cf0-4d5a-96f5-9a2980fddda9@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <fzGtSyEbpU0QGOK-minXRamVv9EWt5L_qLYuAPcThF0=.65bc53ce-4cf0-4d5a-96f5-9a2980fddda9@github.com>
Message-ID: <7C49Hs0D7ZXRz5sn63NdYDO4Hh3VSQpukJoFj0M7CTQ=.011b6a93-ec7b-4475-8950-4d85f39641a1@github.com>

On Tue, 5 Mar 2024 17:50:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17991#pullrequestreview-1917852026

From jlu at openjdk.org  Tue Mar  5 18:44:45 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 18:44:45 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases [v2]
In-Reply-To: <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
 <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
Message-ID: <rF3WtY990_0YoE2pjijCJuYifLD2tPHO7KYbGFOOnHQ=.d410f063-e801-4672-82f6-7c0e6ecfc3b7@github.com>

On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18113#pullrequestreview-1917856118

From bpb at openjdk.org  Tue Mar  5 18:49:46 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Mar 2024 18:49:46 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases [v2]
In-Reply-To: <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
 <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
Message-ID: <74xZTdc5EcELMhru9BjJVWT8YskHZiZB51-KRXfBRtQ=.02fab645-a932-4edd-be1b-990746b51939@github.com>

On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18113#pullrequestreview-1917870069

From lancea at openjdk.org  Tue Mar  5 18:52:45 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 5 Mar 2024 18:52:45 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases [v2]
In-Reply-To: <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
 <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
Message-ID: <RenCcpu1mGiWr9QL7G45eHyB4kIxSqQwV8t5sWpYb_c=.95ff0e5d-7480-4f11-8c79-8b9d7a0e6db5@github.com>

On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18113#pullrequestreview-1917875583

From alanb at openjdk.org  Tue Mar  5 18:58:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Mar 2024 18:58:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>

On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda 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>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

I assume you'll bump the copyright header on all files before integrating.

make/conf/module-loader-map.conf line 139:

> 137:     jdk.unsupported \
> 138:     jdk.xml.dom \
> 139:     jdk.zipfs \

We should create a JBS issue to prune this.

src/java.base/share/classes/java/lang/ModuleLayer.java line 896:

> 894:         return nameToModule.get(name);
> 895:     }
> 896: 

What would you think about replacing this with addEnableNativeAccess(String name) so it can be called by JLA. addEnableNativeAccess. The reason is that the JLA methods are usually just calls to some non-public method but the changes mean mean there is "core" in the JLA method that is not easy to find.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 812:

> 810:     }
> 811: 
> 812:     private static void addEnableNativeAccess(ModuleLayer layer, Set<String> moduleNames, boolean shouldWarn) {

The private methods in this class have a short comment to summarise what they do.

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

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1917862955
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513331594
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513345563
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513347180

From vpetko at openjdk.org  Tue Mar  5 19:16:46 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 5 Mar 2024 19:16:46 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <ylVfkXxoZYKiwHQEjUr3VqquY4yZukOSmAhLkwx5m7c=.c7eeee37-e34b-44c8-8865-f38a92071ee3@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <ylVfkXxoZYKiwHQEjUr3VqquY4yZukOSmAhLkwx5m7c=.c7eeee37-e34b-44c8-8865-f38a92071ee3@github.com>
Message-ID: <ugwjAdZN86dYo6LXhSnBqb7Cxqdt_El45R9Xtppvkj8=.03636f83-0ab6-4f0e-a515-ebf321e6fbd2@github.com>

On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I'm curious why this test is requires `vm.debug`? That means it generally won't get run on release builds.

This is due to the tests of the crash scenarios that are guarded with #ifdef DEBUG in jspawnhelper. 

Moving the test in the separate file is a great suggestion so that misuse case is added to the release test suite.

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

PR Comment: https://git.openjdk.org/jdk/pull/18112#issuecomment-1979466109

From naoto at openjdk.org  Tue Mar  5 19:26:47 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 19:26:47 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string [v2]
In-Reply-To: <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>
Message-ID: <c2AryhpH3YNSYzCF7XBwoDw8yicqKlfyqd9OzOSYGi8=.827f0d55-fc2d-42e1-a68c-abd71394f03a@github.com>

On Tue, 5 Mar 2024 00:32:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
>> 
>> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.
>
> 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 five additional commits since the last revision:
> 
>  - cleanup/typo
>  - Merge branch 'master' into JDK-8326908-emptyPattern-OOME
>  - implement feedback + improve pattern related tests
>  - minor additions
>  - init

src/java.base/share/classes/java/text/DecimalFormat.java line 3367:

> 3365:             }
> 3366:         }
> 3367:         return false;

can simply be a single return statement.

test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 60:

> 58:         dFmt.setMinimumFractionDigits(minFrac);
> 59: 
> 60:         String[] patterns = dFmt.toPattern().split("\\.");

Instead of assuming/hardcoding the decimal separator, `DecimalFormatSymbols.getInstance(Locale.US).getDecimalSeparator()` may be better.

test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 110:

> 108:     // 8326908: Verify that an empty pattern DecimalFormat does not throw an
> 109:     // OutOfMemoryError when toPattern() is invoked. Behavioral change of
> 110:     // MAXIMUM_INTEGER_DIGITS replaced with DOUBLE_FRACTION_DIGITS for empty

Should we explicitly check `new DecimalFormat("").getMaximumFractionDigits() == DOUBLE_FRACTION_DIGITS`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513356393
PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513364152
PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513378668

From naoto at openjdk.org  Tue Mar  5 19:34:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 19:34:54 GMT
Subject: Integrated: 8174269: Remove COMPAT locale data provider from JDK
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <vOXZQwyVBubfdf7g8HPAAfNdF_-x-jHlPFtsTkSUPcM=.0b74ef70-2017-42ae-9b89-6dd22dfc1fb2@github.com>

On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 809995b5
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/809995b526ea79e4fd9fd4f911bcce811f77eb89
Stats:     67953 lines in 568 files changed: 483 ins; 66704 del; 766 mod

8174269: Remove COMPAT locale data provider from JDK

Reviewed-by: ihse, joehw

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

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

From weijun at openjdk.org  Tue Mar  5 19:56:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 19:56:58 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

  revert changes to MBeanServerFileAccessController.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/2b55b171..80810b54

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

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

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

From weijun at openjdk.org  Tue Mar  5 19:56:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 19:56:58 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
 <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
Message-ID: <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>

On Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.
>
> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
> 
> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
> https://github.com/openjdk/jdk/pull/18025 )
> 
> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
> 
> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.

I?ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.

Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513410552

From jlaskey at openjdk.org  Tue Mar  5 20:23:56 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 5 Mar 2024 20:23:56 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v4]
In-Reply-To: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
References: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
Message-ID: <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>

> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.

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

  Fix ReferencedKeySet::add

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17732/files
  - new: https://git.openjdk.org/jdk/pull/17732/files/51cf3e4a..72859919

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

  Stats: 30 lines in 3 files changed: 26 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17732/head:pull/17732

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

From jlaskey at openjdk.org  Tue Mar  5 20:23:57 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 5 Mar 2024 20:23:57 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v3]
In-Reply-To: <IZrxi0fSEmrXH8BUMldmhVooaVHsWMKDrfaUwr5mFg8=.f57f20b7-fa5a-432c-a816-4b9144d7cd5d@github.com>
References: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
 <ZqKpfNhproMcHldi_ork6Fk55sOf23IY4Mp9twvKd3g=.02e05d68-5be9-48a7-936e-c5b6e652f693@github.com>
 <IZrxi0fSEmrXH8BUMldmhVooaVHsWMKDrfaUwr5mFg8=.f57f20b7-fa5a-432c-a816-4b9144d7cd5d@github.com>
Message-ID: <fj_o67Tk0LIN5eGbJXKNeNnhShK7nKVPm85Mjg1Q1hw=.e3883117-0899-415f-8485-294b4f4c2d8c@github.com>

On Sun, 11 Feb 2024 17:41:14 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update ReferencedKeyTest.java
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 151:
> 
>> 149:     @Override
>> 150:     public boolean add(T e) {
>> 151:         return intern(e) == e;
> 
> https://github.com/openjdk/jdk/pull/14684#discussion_r1485634936
>> While `intern(e)?==?e` is?(mostly)?sufficient, it?will?return a?false?positive when?`add(e)` is?called and?`e` is?already?present in?the?map, the?correctest?implementation would?be some?internal?API in?`ReferencedKeyMap` for?implementing?`ReferencedKeySet::add`.

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17732#discussion_r1513458157

From erikj at openjdk.org  Tue Mar  5 20:33:50 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 5 Mar 2024 20:33:50 GMT
Subject: Integrated: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries
In-Reply-To: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
Message-ID: <kgiPJBtxPoUIp-siwxIhUWfholD8nP7blWsz55ZuTpE=.23f86b1a-7a88-455b-8292-6dd51c80b2ac@github.com>

On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.
> 
> There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.
> 
> The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.
> 
> I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".

This pull request has now been integrated.

Changeset: 721bfee5
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/721bfee53af5bc2e2d67eebc7b82f09a642d5309
Stats:     22 lines in 2 files changed: 8 ins; 3 del; 11 mod

8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries

Reviewed-by: ihse, dholmes

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

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

From vpetko at openjdk.org  Tue Mar  5 20:37:46 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 5 Mar 2024 20:37:46 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <Wh7mlhwLnhoh9J1ajGDFA9OBC2D39OlPpMLlWP4G08M=.1eb79fb0-240e-4c6a-9188-46bcc4cdb54b@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <Wh7mlhwLnhoh9J1ajGDFA9OBC2D39OlPpMLlWP4G08M=.1eb79fb0-240e-4c6a-9188-46bcc4cdb54b@github.com>
Message-ID: <SQzEN8LebbOLvzKUKF5Om3ZZtu1QSdclvpE3q33znNE=.8572807b-1156-44db-b98a-eabc52867c9f@github.com>

On Tue, 5 Mar 2024 10:39:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The change in jspawnhelper looks good.
> 
> I think it would be simpler to have a separate `jdk/java/lang/ProcessBuilder/JspawnhelperMisuse.java` test that simply invokes the `jspawnhelper` and verifies the proper message is printed. It would be more straightforward than trying to fit the _protocol_ test? Plus, we can test 0, 1, 3, 4 args, not only 0 args in that test, and we can also test 2 args with bad format.

Yes, this makes the test cleaner[1]. 
Also it seems that there is another issue with process streams handling: the test started to pass only after I've flushed stdout in jspawnhelper [2].

[1] https://github.com/vpa1977/jdk/commit/ac7b5c13eaaa177058c3940cf5c817f4c729ef56
[2] https://github.com/vpa1977/jdk/commit/5f398d5344f4f525cee0e92029528a70fd8e2479

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

PR Comment: https://git.openjdk.org/jdk/pull/18112#issuecomment-1979592133

From ccheung at openjdk.org  Tue Mar  5 20:43:45 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 5 Mar 2024 20:43:45 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java
In-Reply-To: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
Message-ID: <Dn6fbSLGyLZXogBi7TSJ-6UUm65AjtVOiWvLBHLkQ0M=.9de5619f-5d44-4f6d-a675-cf83eeb48354@github.com>

On Sat, 2 Mar 2024 01:18:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> A few clean ups:
> 
> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
> 
> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
> 
> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
> 
> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
> 
> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.

Looks good. Just one nit below.
I assume that it has gone through some testing?

src/hotspot/share/cds/cdsConfig.hpp line 94:

> 92:   static bool   is_dumping_full_module_graph()               { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
> 93:   static void   stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
> 94:   static bool     is_using_full_module_graph()                NOT_CDS_JAVA_HEAP_RETURN_(false);

Please align this with line #90.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18095#pullrequestreview-1918091197
PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1513475007

From liach at openjdk.org  Tue Mar  5 20:51:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Mar 2024 20:51:47 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v4]
In-Reply-To: <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
References: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
 <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
Message-ID: <st1igwVo9inwcWPoWoP_k9ZyPGyOcvB8grjwx77qv0U=.30ee92c5-70af-403b-a1e1-fdf558322b9f@github.com>

On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ReferencedKeySet::add

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/17732#pullrequestreview-1918108342

From jlu at openjdk.org  Tue Mar  5 21:27:09 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 21:27:09 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string [v3]
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <8YD325UqNtT5sDADtJBwWalIvH2VPqcXeCZcF17igyw=.f429c7da-fcd9-4661-ba58-fec5e1b3b519@github.com>

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

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

  reflect review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18094/files
  - new: https://git.openjdk.org/jdk/pull/18094/files/7ca56500..7ee87fc2

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

  Stats: 20 lines in 2 files changed: 8 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18094/head:pull/18094

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

From jlu at openjdk.org  Tue Mar  5 21:27:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 21:27:11 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string [v2]
In-Reply-To: <c2AryhpH3YNSYzCF7XBwoDw8yicqKlfyqd9OzOSYGi8=.827f0d55-fc2d-42e1-a68c-abd71394f03a@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>
 <c2AryhpH3YNSYzCF7XBwoDw8yicqKlfyqd9OzOSYGi8=.827f0d55-fc2d-42e1-a68c-abd71394f03a@github.com>
Message-ID: <VLbpgbwApZG30uaGComVDznk1UBO2oBP8f9WLIPiE4g=.54cc3c91-fb93-4329-bc1e-fe0486df1810@github.com>

On Tue, 5 Mar 2024 19:10:19 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 five additional commits since the last revision:
>> 
>>  - cleanup/typo
>>  - Merge branch 'master' into JDK-8326908-emptyPattern-OOME
>>  - implement feedback + improve pattern related tests
>>  - minor additions
>>  - init
>
> test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 60:
> 
>> 58:         dFmt.setMinimumFractionDigits(minFrac);
>> 59: 
>> 60:         String[] patterns = dFmt.toPattern().split("\\.");
> 
> Instead of assuming/hardcoding the decimal separator, `DecimalFormatSymbols.getInstance(Locale.US).getDecimalSeparator()` may be better.

Actually, since `toPattern()` is non-localized, it will always use "." as specified by DecimalFormat.

I removed the misleading comment `// Use a US dFmt, which uses '.' as the decimal separator` that indicated we needed to use a DecimalFormatSymbols where "." was the decimal separator. Can just simply use a DecimalFormat returned by the default constructor.

> test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 110:
> 
>> 108:     // 8326908: Verify that an empty pattern DecimalFormat does not throw an
>> 109:     // OutOfMemoryError when toPattern() is invoked. Behavioral change of
>> 110:     // MAXIMUM_INTEGER_DIGITS replaced with DOUBLE_FRACTION_DIGITS for empty
> 
> Should we explicitly check `new DecimalFormat("").getMaximumFractionDigits() == DOUBLE_FRACTION_DIGITS`?

Thanks for the review, added an explicit check

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513517348
PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513517336

From jlu at openjdk.org  Tue Mar  5 21:41:00 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 21:41:00 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string [v4]
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <ZCLWqqwlkQs7AknGn-Uux6ql1dsQ84SCqo8OAB-mIxo=.a6beba47-957d-4800-bce0-21008dc04594@github.com>

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

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

  locale no longer needed, remove unusued imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18094/files
  - new: https://git.openjdk.org/jdk/pull/18094/files/7ee87fc2..e9e86da7

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

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

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

From naoto at openjdk.org  Tue Mar  5 21:41:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 21:41:00 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string [v3]
In-Reply-To: <8YD325UqNtT5sDADtJBwWalIvH2VPqcXeCZcF17igyw=.f429c7da-fcd9-4661-ba58-fec5e1b3b519@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <8YD325UqNtT5sDADtJBwWalIvH2VPqcXeCZcF17igyw=.f429c7da-fcd9-4661-ba58-fec5e1b3b519@github.com>
Message-ID: <nIuki7as8gNR5RFJNLbxe8-1equa0E87H2RTSi5kC8U=.c0a6007a-59e8-4a79-93a3-084e4301327a@github.com>

On Tue, 5 Mar 2024 21:27:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
>> 
>> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18094#pullrequestreview-1918175848

From naoto at openjdk.org  Tue Mar  5 21:41:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 21:41:00 GMT
Subject: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError
 when pattern is empty string [v2]
In-Reply-To: <VLbpgbwApZG30uaGComVDznk1UBO2oBP8f9WLIPiE4g=.54cc3c91-fb93-4329-bc1e-fe0486df1810@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>
 <c2AryhpH3YNSYzCF7XBwoDw8yicqKlfyqd9OzOSYGi8=.827f0d55-fc2d-42e1-a68c-abd71394f03a@github.com>
 <VLbpgbwApZG30uaGComVDznk1UBO2oBP8f9WLIPiE4g=.54cc3c91-fb93-4329-bc1e-fe0486df1810@github.com>
Message-ID: <crRbTXX92VunbgijX8whMkOOlh2l6cxSIlgBYnjKU50=.071a7221-e405-474a-8751-3bf964d1bcea@github.com>

On Tue, 5 Mar 2024 21:23:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 60:
>> 
>>> 58:         dFmt.setMinimumFractionDigits(minFrac);
>>> 59: 
>>> 60:         String[] patterns = dFmt.toPattern().split("\\.");
>> 
>> Instead of assuming/hardcoding the decimal separator, `DecimalFormatSymbols.getInstance(Locale.US).getDecimalSeparator()` may be better.
>
> Actually, since `toPattern()` is non-localized, it will always use "." as specified by DecimalFormat.
> 
> I removed the misleading comment `// Use a US dFmt, which uses '.' as the decimal separator` that indicated we needed to use a DecimalFormatSymbols where "." was the decimal separator. Can just simply use a DecimalFormat returned by the default constructor.

Oh right. Yes, so we should not use the US locale for this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513526760

From rriggs at openjdk.org  Tue Mar  5 21:42:46 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Mar 2024 21:42:46 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v4]
In-Reply-To: <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
References: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
 <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
Message-ID: <jzpx3kgAQw4YFNluoq0UnqzhrAJ9OI7tf70XtN52uwA=.ad3dcd44-0c95-42ff-a958-076fd3986615@github.com>

On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ReferencedKeySet::add

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17732#pullrequestreview-1918184517

From alexander.matveev at oracle.com  Tue Mar  5 21:46:33 2024
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 5 Mar 2024 21:46:33 +0000
Subject: [External] : Re: jpackage requests permission via a dialog
In-Reply-To: <BFEE7025-C914-42D2-88C2-7BB28E649B59@cbfiddle.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
 <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
 <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>
 <98870774-91FA-4631-8E79-32C748D93400@gmail.com>
 <BFEE7025-C914-42D2-88C2-7BB28E649B59@cbfiddle.com>
Message-ID: <PH7PR10MB7055E4D14775B38FBD5D1A6A99222@PH7PR10MB7055.namprd10.prod.outlook.com>

Hi Alan,

jpackage does not use .DS_Store file directly. Script tells ?Finder? application to arrange DMG layout and once script is finished ?Finder? will create .DS_Store file to store layout.
If user wants to modify it, them generated DMG needs to be converted to writable, mounted, layout modified by hand or any other ways like script, unmount and make DMG read only.

DMG might have additional content specified by jpackage users, so I do not know how we could re-use .DS_Store in such cases, since we do not know what content DMG might have.

Thanks,
Alexander

From: Alan Snyder <javalists at cbfiddle.com>
Date: Tuesday, March 5, 2024 at 8:50?AM
To: Michael Hall <mik3hall at gmail.com>
Cc: Alexander Matveev <alexander.matveev at oracle.com>, core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: jpackage requests permission via a dialog
I?m wondering whether some developers might prefer to arrange the DMG layout by hand.

That would require jpackage to use a .DS_Store file provided by the developer and not running the script.

The issue is whether a .DS_Store file created using a previous DMG would work in a new DMG.

The documentation for install4j suggests that there is a way.

[https://www.ej-technologies.com/resources/install4j/help/doc/concepts/dmgStyling.html<https://urldefense.com/v3/__https:/www.ej-technologies.com/resources/install4j/help/doc/concepts/dmgStyling.html__;!!ACWV5N9M2RV99hQ!JI59aSFm4DwVoosoosGu5U5p_6GD8_bhXqh9tplhX6GJ_6Z7GiQ9IV3JuHHOn_an62KkkoC22UPLytOMOANY58u4rV4$>]




On Mar 5, 2024, at 12:28?AM, Michael Hall <mik3hall at gmail.com> wrote:

Hello Alexander,

I had forgotten or didn?t know that. I didn?t see it mentioned anywhere in this list thread previously. But there is generally no reason to delete this file. Unless you don?t want it included in a zip or a GitHub project. The icon placement for multiple files with jpackage ?mac-dmg-content is determined by the AppleScript. You might remember I had a related bug report. I provided a workaround with slight changes to the code invoking the AppleScript and the AppleScript. You came up with your own fix. I was impressed you did it by just changing the AppleScript but I slightly preferred the placement of my change. Again, if I remember right.

Mike


On Mar 4, 2024, at 9:57?PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:

Hi Michael,

.DS_Store file contains information about icon position and other visual information on how to display folder. Once osascript configures DMG, Finder will store these setting in .DS_Store file. If it gets deleted from DMG, DMG will look like osascript was never run. So, Alan is right with ?the configuration of the DMG appearance actually means configuring the .DS_Store file in the DMG?.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/b22ccb39/attachment-0001.htm>

From jlu at openjdk.org  Tue Mar  5 22:40:51 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 22:40:51 GMT
Subject: Integrated: JDK-6801704: ChoiceFormat::applyPattern inconsistency for
 invalid patterns
In-Reply-To: <S0h5X3J918JmJvvNLa3VVAo_p0JZGgqD6PemhQ_W_pc=.49ebe3b9-5f80-4523-9a31-deed19cde778@github.com>
References: <S0h5X3J918JmJvvNLa3VVAo_p0JZGgqD6PemhQ_W_pc=.49ebe3b9-5f80-4523-9a31-deed19cde778@github.com>
Message-ID: <ySLrxpNMgno7Pjy-dbWQVuCHf5Y9giMgIuZDXJ5ylOg=.f98bcccc-2ef5-4725-8eb0-6955eec7f81f@github.com>

On Wed, 14 Feb 2024 22:29:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
> 
> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
> 
> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
> 
> 
> // no limit -> throws an expected IllegalArgumentException
> var a = new ChoiceFormat("#foo");
> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
> b.format(2); // returns 'bar'
> // no relation or limit -> discards the incorrect portion, 'foo' and continues
> var c = new ChoiceFormat("foo");
> c.format(1); // throws AIOOBE

This pull request has now been integrated.

Changeset: b665fe3a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b665fe3ac10f4e85b91737228780b1d50ae81514
Stats:     21 lines in 1 file changed: 13 ins; 0 del; 8 mod

6801704: ChoiceFormat::applyPattern inconsistency for invalid patterns

Reviewed-by: naoto

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

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

From mchung at openjdk.org  Tue Mar  5 22:46:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 5 Mar 2024 22:46:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
Message-ID: <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>

On Tue, 5 Mar 2024 18:43:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda 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>
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> make/conf/module-loader-map.conf line 139:
> 
>> 137:     jdk.unsupported \
>> 138:     jdk.xml.dom \
>> 139:     jdk.zipfs \
> 
> We should create a JBS issue to prune this.

Many of these modules do not need native access in the current implementation.   Should this list be trimmed to list the ones that need native access in the current implementation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513588480

From mandy.chung at oracle.com  Tue Mar  5 22:57:01 2024
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 5 Mar 2024 14:57:01 -0800
Subject: RFD: Can we remove the deprecated internal Unsafe *Object*
 methods?
In-Reply-To: <CA+pBWhsGVnQPv3NsHzDwYYsMPahK5JM7HQyKo0KnOsAyzvm=1w@mail.gmail.com>
References: <CA+pBWhsGVnQPv3NsHzDwYYsMPahK5JM7HQyKo0KnOsAyzvm=1w@mail.gmail.com>
Message-ID: <86b69a72-d225-4c62-b77e-44b5d89686e9@oracle.com>

These deprecated methods were added to make jsr166.jar to run on 
different JDK releases.? I think it's time to remove these deprecated 
xxxObject* methods as the renames have been done since JDK 12 for 5 
years.?? I added a comment [1] to confirm with Doug and Martin.

Mandy

https://bugs.openjdk.org/browse/JDK-8207146?focusedId=14654891&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14654891

On 3/5/24 10:22 AM, Eirik Bj?rsn?s wrote:
> Hi,
>
> Now that the JDK? repo is the single source of truth for 
> java.util.concurrent [1], I'm wondering if time has come to remove the 
> deprecated *Object* methods introduced in JDK-8213043 [2]
>
> These alias methods were introduced because jsr166 used them, but 
> there no longer seems to be any use within the OpenJDK (verified by 
> removing them and running java.util.concurrent tests).
>
> Hearing no objections I'll prepare a PR to remove these 19 deprecated, 
> for removal methods.
>
> Eirik.
>
> [1] 
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119047.html
> [2] https://bugs.openjdk.org/browse/JDK-8213043

From duke at openjdk.org  Tue Mar  5 23:00:16 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 5 Mar 2024 23:00:16 GMT
Subject: RFR: 8326718: Test java/util/Formatter/Padding.java should timeout
 on large inputs before fix in JDK-8299677 [v3]
In-Reply-To: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
References: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
Message-ID: <nmdhjce7rqWQBMCyNhCt8vIs6kbKRuk-2ITlOC3DTiA=.b7dd99c3-ee5b-41e0-98aa-22d447e7fa16@github.com>

> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after.
> 
> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent.

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

  Add underscores to large number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18033/files
  - new: https://git.openjdk.org/jdk/pull/18033/files/45d0acdd..2e24a459

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

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

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

From stuart.marks at oracle.com  Tue Mar  5 23:20:39 2024
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 5 Mar 2024 15:20:39 -0800
Subject: Result: New Core Libraries Group Member: Viktor Klang
Message-ID: <0ef835c5-3475-8370-77c7-64c7477644ce@oracle.com>


The vote for Viktor Klang [1] is now closed.

Yes: 9
Veto: 0
Abstain: 0

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

s'marks

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

From iklam at openjdk.org  Tue Mar  5 23:40:46 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 5 Mar 2024 23:40:46 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java
In-Reply-To: <Dn6fbSLGyLZXogBi7TSJ-6UUm65AjtVOiWvLBHLkQ0M=.9de5619f-5d44-4f6d-a675-cf83eeb48354@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <Dn6fbSLGyLZXogBi7TSJ-6UUm65AjtVOiWvLBHLkQ0M=.9de5619f-5d44-4f6d-a675-cf83eeb48354@github.com>
Message-ID: <gjgmUTFhcFhql7GeKvPgrnvLMynPa5LXcv2J5leRrkE=.ae438ad8-7526-4c1d-b8c5-eea0ab89cee6@github.com>

On Tue, 5 Mar 2024 20:39:10 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A few clean ups:
>> 
>> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
>> 
>> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
>> 
>> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
>> 
>> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
>> 
>> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.
>
> src/hotspot/share/cds/cdsConfig.hpp line 94:
> 
>> 92:   static bool   is_dumping_full_module_graph()               { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
>> 93:   static void   stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
>> 94:   static bool     is_using_full_module_graph()                NOT_CDS_JAVA_HEAP_RETURN_(false);
> 
> Please align this with line #90.

Do you mean aligning like this: 


  static bool is_dumping_heap()                              NOT_CDS_JAVA_HEAP_RETURN_(false);
  static void stop_dumping_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
  static bool is_dumping_full_module_graph()                 { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
  static void stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
  static bool is_using_full_module_graph()                   NOT_CDS_JAVA_HEAP_RETURN_(false);


I think this is more messy, and you can't easily tell that these four functions are all related to the same feature (full_module_graph).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1513626841

From alexey.semenyuk at oracle.com  Tue Mar  5 23:48:57 2024
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 5 Mar 2024 18:48:57 -0500
Subject: creating macOS universal applications
In-Reply-To: <E17DCF9E-971F-467C-A527-F91330ABCCA7@cbfiddle.com>
References: <E17DCF9E-971F-467C-A527-F91330ABCCA7@cbfiddle.com>
Message-ID: <b79c09b7-8797-44a4-9dc2-71dfa8a7cd12@oracle.com>

On 2/29/2024 2:22 PM, Alan Snyder wrote:
> For anyone interested in building Java-based macOS universal 
> applications, it is possible to create a bundled application that 
> contains two Java runtimes, one for x86 and one for arm. A custom 
> launcher is required to select the appropriate runtime based on the 
> execution environment. I have created such a launcher; it is a very 
> small modification of the macOS launcher used by jpackage.
>
> The custom launcher is available on GitHub: 
> https://github.com/violetlib/mac-universal-java-launcher
Do you think any of the changes you made in this repo are worth bringing 
to jpackage launcher?

- Alexey
>
> There is some discussion of this issue in?JDK-8266259 
> [https://bugs.openjdk.org/browse/JDK-8266259].
> So far, there does not seem to be much interest in this topic.
>
> On a related note, is there a place where developers using Java on 
> macOS who are not associated with OpenJDK can share information?
>
>
>
>
>


From ccheung at openjdk.org  Tue Mar  5 23:51:45 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 5 Mar 2024 23:51:45 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java
In-Reply-To: <gjgmUTFhcFhql7GeKvPgrnvLMynPa5LXcv2J5leRrkE=.ae438ad8-7526-4c1d-b8c5-eea0ab89cee6@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <Dn6fbSLGyLZXogBi7TSJ-6UUm65AjtVOiWvLBHLkQ0M=.9de5619f-5d44-4f6d-a675-cf83eeb48354@github.com>
 <gjgmUTFhcFhql7GeKvPgrnvLMynPa5LXcv2J5leRrkE=.ae438ad8-7526-4c1d-b8c5-eea0ab89cee6@github.com>
Message-ID: <NP_-Ld7XAWETk9i3CIdPFXdhGUe4g1mieqO0aXY4ZFY=.44be47f5-e94a-4711-9e71-f4244d494cc2@github.com>

On Tue, 5 Mar 2024 23:38:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/cdsConfig.hpp line 94:
>> 
>>> 92:   static bool   is_dumping_full_module_graph()               { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
>>> 93:   static void   stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
>>> 94:   static bool     is_using_full_module_graph()                NOT_CDS_JAVA_HEAP_RETURN_(false);
>> 
>> Please align this with line #90.
>
> Do you mean aligning like this: 
> 
> 
>   static bool is_dumping_heap()                              NOT_CDS_JAVA_HEAP_RETURN_(false);
>   static void stop_dumping_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
>   static bool is_dumping_full_module_graph()                 { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
>   static void stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
>   static bool is_using_full_module_graph()                   NOT_CDS_JAVA_HEAP_RETURN_(false);
> 
> 
> I think this is more messy, and you can't easily tell that these four functions are all related to the same feature (full_module_graph).

I meant the following. Just the last line #94 needs to be changed - shift one space to the left after `bool`.

static bool   is_dumping_heap()                            NOT_CDS_JAVA_HEAP_RETURN_(false);
static void stop_dumping_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
static bool   is_dumping_full_module_graph()               { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
static void   stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
static bool   is_using_full_module_graph()                 NOT_CDS_JAVA_HEAP_RETURN_(false);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1513633931

From mik3hall at gmail.com  Wed Mar  6 00:31:30 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 5 Mar 2024 18:31:30 -0600
Subject: [External] : Re: jpackage requests permission via a dialog
In-Reply-To: <BFEE7025-C914-42D2-88C2-7BB28E649B59@cbfiddle.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
 <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
 <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>
 <98870774-91FA-4631-8E79-32C748D93400@gmail.com>
 <BFEE7025-C914-42D2-88C2-7BB28E649B59@cbfiddle.com>
Message-ID: <1E4C28C0-E33C-4688-8B8E-5896EE8AB44E@gmail.com>

I?m not sure hacking the .DS_Store file would be Apple supported.

Is install4j still actively supporting this or is this something they used to do?

What happens if they stop?

The result of my bug report included the icons being resized to fit better with multiple files. 

I think Alexander?s layout is alright. I just sort of preferred mine which I remember as somewhat different.

Changing the background image is I believe supported by jpackage. I think I saw this mentioned somewhere on a verbose run?

I used Gimp to change the coloring of the javafx SceneBuilder application dmg background to better match the application icon. It didn?t generate any interest on their dev list but I thought it looked sort of nice. A little more customized to the app.

You could also hack your own version of the jpackage  dmg build. I did for testing. Then modify the AppleScript to do whatever you want. I could see if I could dig up what I used. I?m not sure if any of it would violate openjdk intellectual property.

> On Mar 5, 2024, at 10:50?AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> I?m wondering whether some developers might prefer to arrange the DMG layout by hand.
> 
> That would require jpackage to use a .DS_Store file provided by the developer and not running the script.
> 
> The issue is whether a .DS_Store file created using a previous DMG would work in a new DMG.
> 
> The documentation for install4j suggests that there is a way.
> 
> [https://www.ej-technologies.com/resources/install4j/help/doc/concepts/dmgStyling.html]
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/208422c9/attachment.htm>

From alexey.semenyuk at oracle.com  Wed Mar  6 00:33:57 2024
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 5 Mar 2024 19:33:57 -0500
Subject: [External] : Re: creating macOS universal applications
In-Reply-To: <C528AB4F-F04F-4DDE-8B8C-DEBA25487BEF@cbfiddle.com>
References: <E17DCF9E-971F-467C-A527-F91330ABCCA7@cbfiddle.com>
 <b79c09b7-8797-44a4-9dc2-71dfa8a7cd12@oracle.com>
 <C528AB4F-F04F-4DDE-8B8C-DEBA25487BEF@cbfiddle.com>
Message-ID: <a3cfe3ae-5a18-454c-8bb5-ab8b2b58e150@oracle.com>

Great, you can file a CR, publish a PR. I'll be happy to review it.

- Alexey

On 3/5/2024 7:19 PM, Alan Snyder wrote:
> Yes, I do. The changes are very small.
>
>> On Mar 5, 2024, at 3:48?PM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>>
>> On 2/29/2024 2:22 PM, Alan Snyder wrote:
>>> For anyone interested in building Java-based macOS universal applications, it is possible to create a bundled application that contains two Java runtimes, one for x86 and one for arm. A custom launcher is required to select the appropriate runtime based on the execution environment. I have created such a launcher; it is a very small modification of the macOS launcher used by jpackage.
>>>
>>> The custom launcher is available on GitHub: https://urldefense.com/v3/__https://github.com/violetlib/mac-universal-java-launcher__;!!ACWV5N9M2RV99hQ!Nul4wCJCz3vxtnT4CbMiAAFVAlPVbTHuLFFYYIRSo-KvXLlow1s1wRsCRTMCwZkeU2IOH4djqopjRROvv6nLSDOUkeM$
>> Do you think any of the changes you made in this repo are worth bringing to jpackage launcher?
>>
>> - Alexey
>>> There is some discussion of this issue in JDK-8266259 [https://bugs.openjdk.org/browse/JDK-8266259].
>>> So far, there does not seem to be much interest in this topic.
>>>
>>> On a related note, is there a place where developers using Java on macOS who are not associated with OpenJDK can share information?
>>>
>>>
>>>
>>>
>>>


From javalists at cbfiddle.com  Wed Mar  6 00:39:18 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 5 Mar 2024 16:39:18 -0800
Subject: [External] : Re: jpackage requests permission via a dialog
In-Reply-To: <1E4C28C0-E33C-4688-8B8E-5896EE8AB44E@gmail.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
 <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
 <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>
 <98870774-91FA-4631-8E79-32C748D93400@gmail.com>
 <BFEE7025-C914-42D2-88C2-7BB28E649B59@cbfiddle.com>
 <1E4C28C0-E33C-4688-8B8E-5896EE8AB44E@gmail.com>
Message-ID: <E38DBAA5-E343-414A-87B5-AFE203529B1D@cbfiddle.com>



> On Mar 5, 2024, at 4:31?PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> I?m not sure hacking the .DS_Store file would be Apple supported.
> 

Is that what they are doing? I couldn?t tell from the web site.



> Is install4j still actively supporting this or is this something they used to do?
> 

All I know is that is described on their web site.



> What happens if they stop?
> 

I?m not sure what you mean. I?m not suggesting that OpenJDK use this product.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/54ee4f19/attachment.htm>

From jpai at openjdk.org  Wed Mar  6 00:58:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 6 Mar 2024 00:58:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <qUywPUBxrFPqmBQt0CmeoIjDdY__AaxZ1RnqbqpKtxs=.19abd551-8a3b-40e0-a148-0701fbce0405@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
 <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
 <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>
 <qUywPUBxrFPqmBQt0CmeoIjDdY__AaxZ1RnqbqpKtxs=.19abd551-8a3b-40e0-a148-0701fbce0405@github.com>
Message-ID: <pR_tzy5Mm3VY2y4uJfeE8MxORUmVZ8yv_3fyFJvz-ho=.345d8490-f43b-4757-8ae7-ac0e353e4bd9@github.com>

On Tue, 5 Mar 2024 16:13:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I see. I then misunderstood a part of the PR description.
>
> I believe we could technically reuse the list for boot/platform modules. But, the intent here is to provide more control over the modules with native access, not only being able to add to the list, but also remove from the list. So, to me, it seemed better to have an explicit list, from/to which we can remove/add modules easily.

Hello Jan, my suggestion was based on a misunderstanding that NATIVE_ACCESS_MODULES is always a superset of boot and platform modules. What you currently have looks fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1513674172

From ccheung at openjdk.org  Wed Mar  6 01:11:55 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 6 Mar 2024 01:11:55 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L
Message-ID: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>

To avoid the CDS dump error message, a fix is during dumping a classlist, check if an invoker can be archived. 
If not, don't write the invoker info into the classlist, i.e. don't call `logLambdaFormInvoker()`. While generating holder classes (in `generateHolderClasses()`), don't add the `MethodType` to the `invokerTypes` if will fail the check in the `build()` method which would result in a `RuntimeException`.

Also updated the `MethodHandlesInvokersTest.java` under `appcds/methodHandles` and `appcds/dynamicArchive/methodHandles` to check that the "Failed to generate LambdaForm holder classes" error is not in the output;

Passed tiers 1 - 3 testing.

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

Commit messages:
 - update fix
 - Merge branch 'master' into 8314250-dump-error
 - Merge branch 'master' into 8314250-dump-error
 - 8314250: CDS dump error message: Invoker type parameter must start and end with Object: L3I_L

Changes: https://git.openjdk.org/jdk/pull/17953/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17953&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314250
  Stats: 133 lines in 17 files changed: 105 ins; 2 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/17953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17953/head:pull/17953

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

From mik3hall at gmail.com  Wed Mar  6 01:49:38 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 5 Mar 2024 19:49:38 -0600
Subject: [External] : Re: jpackage requests permission via a dialog
In-Reply-To: <E38DBAA5-E343-414A-87B5-AFE203529B1D@cbfiddle.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
 <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
 <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>
 <98870774-91FA-4631-8E79-32C748D93400@gmail.com>
 <BFEE7025-C914-42D2-88C2-7BB28E649B59@cbfiddle.com>
 <1E4C28C0-E33C-4688-8B8E-5896EE8AB44E@gmail.com>
 <E38DBAA5-E343-414A-87B5-AFE203529B1D@cbfiddle.com>
Message-ID: <0483E3A6-CE37-4930-9304-884A799E9BF4@gmail.com>

Fwiw screenshots

DMG with a customized background image (SceneBuilder demo)

http://mikehall.pairserver.com/custom_dmg.png

DMG with extra files. Default layout and background image.

http://mikehall.pairserver.com/additional_dmg.png


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/06e61c1a/attachment-0001.htm>

From iklam at openjdk.org  Wed Mar  6 02:00:47 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Mar 2024 02:00:47 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java
In-Reply-To: <NP_-Ld7XAWETk9i3CIdPFXdhGUe4g1mieqO0aXY4ZFY=.44be47f5-e94a-4711-9e71-f4244d494cc2@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <Dn6fbSLGyLZXogBi7TSJ-6UUm65AjtVOiWvLBHLkQ0M=.9de5619f-5d44-4f6d-a675-cf83eeb48354@github.com>
 <gjgmUTFhcFhql7GeKvPgrnvLMynPa5LXcv2J5leRrkE=.ae438ad8-7526-4c1d-b8c5-eea0ab89cee6@github.com>
 <NP_-Ld7XAWETk9i3CIdPFXdhGUe4g1mieqO0aXY4ZFY=.44be47f5-e94a-4711-9e71-f4244d494cc2@github.com>
Message-ID: <KSlqTPGNLB6ZK1X5gIofzEj0PKAOpKGk2N5oxwBJNjI=.5dedd3c4-c307-4c6e-a038-840a83c0a3cf@github.com>

On Tue, 5 Mar 2024 23:49:02 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Do you mean aligning like this: 
>> 
>> 
>>   static bool is_dumping_heap()                              NOT_CDS_JAVA_HEAP_RETURN_(false);
>>   static void stop_dumping_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
>>   static bool is_dumping_full_module_graph()                 { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
>>   static void stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
>>   static bool is_using_full_module_graph()                   NOT_CDS_JAVA_HEAP_RETURN_(false);
>> 
>> 
>> I think this is more messy, and you can't easily tell that these four functions are all related to the same feature (full_module_graph).
>
> I meant the following. Just the last line #94 needs to be changed - shift one space to the left after `bool`.
> 
> static bool   is_dumping_heap()                            NOT_CDS_JAVA_HEAP_RETURN_(false);
> static void stop_dumping_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
> static bool   is_dumping_full_module_graph()               { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
> static void   stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
> static bool   is_using_full_module_graph()                 NOT_CDS_JAVA_HEAP_RETURN_(false);

I wanted line 94 to align the "using_full_module_graph" part with the function at line 93.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1513713821

From duke at openjdk.org  Wed Mar  6 02:04:52 2024
From: duke at openjdk.org (duke)
Date: Wed, 6 Mar 2024 02:04:52 GMT
Subject: Withdrawn: JDK-8319122: Improve documentation of various Zip-file
 related APIs
In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com>
Message-ID: <nPsEwz_VDBFLVKKia0WQ1MpyveZdDV7q2yxtNmpKgp4=.320618f0-b5fe-46f8-9720-686d16c4b455@github.com>

On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich <duke at openjdk.org> wrote:

> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following:
> - Cache of JAR files in JarURLConnection class
> - Cache of JAR/ZIP files in JarFile and ZipFile classes
> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider
> - Directories and filenames with the same name considered to be the same in ZipFile class
> - Possible issues when local and central headers conflict in ZipInputStream class
> 
> Related JBS report:
> https://bugs.openjdk.org/browse/JDK-8319122

This pull request has been closed without being integrated.

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

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

From ccheung at openjdk.org  Wed Mar  6 02:12:46 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 6 Mar 2024 02:12:46 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java
In-Reply-To: <KSlqTPGNLB6ZK1X5gIofzEj0PKAOpKGk2N5oxwBJNjI=.5dedd3c4-c307-4c6e-a038-840a83c0a3cf@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <Dn6fbSLGyLZXogBi7TSJ-6UUm65AjtVOiWvLBHLkQ0M=.9de5619f-5d44-4f6d-a675-cf83eeb48354@github.com>
 <gjgmUTFhcFhql7GeKvPgrnvLMynPa5LXcv2J5leRrkE=.ae438ad8-7526-4c1d-b8c5-eea0ab89cee6@github.com>
 <NP_-Ld7XAWETk9i3CIdPFXdhGUe4g1mieqO0aXY4ZFY=.44be47f5-e94a-4711-9e71-f4244d494cc2@github.com>
 <KSlqTPGNLB6ZK1X5gIofzEj0PKAOpKGk2N5oxwBJNjI=.5dedd3c4-c307-4c6e-a038-840a83c0a3cf@github.com>
Message-ID: <wDJlT_AFraG27Y0lrhwOa0tnPAo4Op-RsZz4m38j0hI=.f638a96f-fe3b-47c8-b8e2-7a0c666c944f@github.com>

On Wed, 6 Mar 2024 01:58:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I meant the following. Just the last line #94 needs to be changed - shift one space to the left after `bool`.
>> 
>> static bool   is_dumping_heap()                            NOT_CDS_JAVA_HEAP_RETURN_(false);
>> static void stop_dumping_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
>> static bool   is_dumping_full_module_graph()               { return CDS_ONLY(_is_dumping_full_module_graph) NOT_CDS(false); }
>> static void   stop_using_full_module_graph(const char* reason = nullptr) NOT_CDS_JAVA_HEAP_RETURN;
>> static bool   is_using_full_module_graph()                 NOT_CDS_JAVA_HEAP_RETURN_(false);
>
> I wanted line 94 to align the "using_full_module_graph" part with the function at line 93.

In that case, it looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1513723384

From javalists at cbfiddle.com  Wed Mar  6 02:13:07 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 5 Mar 2024 18:13:07 -0800
Subject: jpackage requests permission via a dialog
In-Reply-To: <5066A5E2-D9AF-4181-AC4B-5162A2600BC0@gmail.com>
References: <A05D788F-C526-4411-AD52-3A2906CD9EA4@cbfiddle.com>
 <PH7PR10MB70558112B3FDE5E1AFD0131199232@PH7PR10MB7055.namprd10.prod.outlook.com>
 <7033D47D-CE01-4287-AF68-882B3C2E8413@cbfiddle.com>
 <715B217B-BBEB-4F79-8DFE-BF956395004E@gmail.com>
 <PH7PR10MB7055DF638475B5187F9CECF099222@PH7PR10MB7055.namprd10.prod.outlook.com>
 <98870774-91FA-4631-8E79-32C748D93400@gmail.com>
 <BFEE7025-C914-42D2-88C2-7BB28E649B59@cbfiddle.com>
 <1E4C28C0-E33C-4688-8B8E-5896EE8AB44E@gmail.com>
 <E38DBAA5-E343-414A-87B5-AFE203529B1D@cbfiddle.com>
 <5066A5E2-D9AF-4181-AC4B-5162A2600BC0@gmail.com>
Message-ID: <51561144-94EF-4CB4-9147-1FFBC2FCFCF6@cbfiddle.com>



> On Mar 5, 2024, at 4:42?PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> What happens if Apple changes the file format and InstallJ isn?t actively supporting this anymore and doesn?t change their code. Your builds could stop working. Have you tried it to be sure it even works now?

If Apple changes the file format, then the .DS_Store files in your already distributed DMG files may also be broken.

That would be a good reason for Apple to make only compatible changes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240305/0d81ee7b/attachment-0001.htm>

From duke at openjdk.org  Wed Mar  6 04:00:54 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 6 Mar 2024 04:00:54 GMT
Subject: RFR: 8327425: String Template FMT Refactor use call direct instead of
 MethodHandler
Message-ID: <xKwdFc_9-CPdbH4J1FHUFlLEgzlh_yxgZ-1HbtnzLCQ=.da068c07-6337-450d-bcc3-433bb194f3a4@github.com>

Currently FormatItem uses MethodHandler to handle latin1 and utf16, which is not readable. This PR uses direct calls instead of MethodHandler.

Please review and don't hesitate to critique my approach and patch.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into refactor_format_item_x
 - Merge remote-tracking branch 'upstream/master' into refactor_format_item_x
 - refactor FormatItem, call directly instead of using MethodHandler

Changes: https://git.openjdk.org/jdk/pull/16021/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16021&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327425
  Stats: 682 lines in 10 files changed: 344 ins; 245 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/16021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16021/head:pull/16021

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

From duke at openjdk.org  Wed Mar  6 04:53:00 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 6 Mar 2024 04:53:00 GMT
Subject: RFR: 8327429: String Template FMT built-in optimization for DateTimes
Message-ID: <oOeZZrsycU5QG-QuxIzh-TEaS4F5vHAzu7-wyd3sC1g=.7e37116d-36f7-4e01-ad58-9b67004e4b0e@github.com>

# 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 (+443.74)
+StringTemplateFMT.ldtFormat             avgt   15   27.208 ?  0.073  ns/op (+280.87)
+StringTemplateFMT.localTimeFormat       avgt   15    8.430 ?  0.017  ns/op (+430.85)
+StringTemplateFMT.zdtFormat             avgt   15   37.774 ?  0.135  ns/op (+374.25)


# The next

Use DateTimeUtils in the patch to refactor the toString methods of Date/Instant/LocalDate/LocalTime/LocalDateTime/OffsetTime/OffsetDateTime/ZonedDateTime/Instant to optimize performance and ensure consistency.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into st_fmt_support_datetime
 - add copyright info
 - fix codestyle & merge two array (weeks & months)
 - String Template FMT built-in optimization for java.time.DateTimes

Changes: https://git.openjdk.org/jdk/pull/16044/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16044&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327429
  Stats: 1775 lines in 14 files changed: 1769 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16044/head:pull/16044

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

From jpai at openjdk.org  Wed Mar  6 04:53:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 6 Mar 2024 04:53:01 GMT
Subject: RFR: 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: <mKeMrOgTr1q9fbxAJBKTBNPewtXFsr69SjJRttgGZHE=.06a89c8b-16c2-41b6-b0ab-4a0d7a7b135f@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 ...

Hello @wenshao, it's better to create a mailing list discussion https://openjdk.org/guide/#socialize-your-change before opening a PR for a change like this. core-libs-dev will be the right mailing list for this discussion https://mail.openjdk.org/mailman/listinfo/core-libs-dev. That way, it gets better attention and guidance on how to proceed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16044#issuecomment-1951820602

From duke at openjdk.org  Wed Mar  6 05:05:49 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 6 Mar 2024 05:05:49 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: <XEl3TPWPedeYgO-vITmdX_0GEi3J07lP2A7HI5CDeNA=.e6dbbbea-452f-45a8-aa7e-a010271696cf@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.

@JimLaskey could you please help review the code? Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/16017#issuecomment-1980093305

From asotona at openjdk.org  Wed Mar  6 06:17:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Mar 2024 06:17:51 GMT
Subject: Integrated: 8294961: Convert
 java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to
 generate proxy classes
In-Reply-To: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
References: <7WfYKU7vLT-I8dQKbRL5-3dBWJvc5qTW1aKnpVQVlGk=.33609f70-abd7-4d5d-99eb-c40758cd4830@github.com>
Message-ID: <_3Mpr63TplDQleGHq2RPxS7gYKCqohC1pdUCLJKFhWA=.5ff67a68-93c6-46b6-9dea-3d2bba6e9148@github.com>

On Fri, 15 Dec 2023 12:54:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
> 
> This patch converts it to use Classfile API.
> 
> It is continuation of https://github.com/openjdk/jdk/pull/10991
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: bee50cd3
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bee50cd330c9f31bf8830caf87f97cd72e7adc95
Stats:     543 lines in 2 files changed: 129 ins; 189 del; 225 mod

8294961: Convert java.base/java.lang.reflect.ProxyGenerator to use the Classfile API to generate proxy classes

Reviewed-by: mchung

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

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

From asotona at openjdk.org  Wed Mar  6 06:39:57 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Mar 2024 06:39:57 GMT
Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v3]
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: <QIfA4i83L67pU2GKI0NGoL52iY7oRsEyOtN4zjVoE7A=.a096683e-56bd-4fe9-a667-12d3c5eb75c3@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 11 commits:

 - 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
 - fixed benchmarks
 - fixed jdk.jfr and jdk.jlink
 - fixed java.base
 - ... and 1 more: https://git.openjdk.org/jdk/compare/bee50cd3...5854a866

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

Changes: https://git.openjdk.org/jdk/pull/17282/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17282&range=02
  Stats: 898 lines in 44 files changed: 41 ins; 207 del; 650 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 dholmes at openjdk.org  Wed Mar  6 07:18:50 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Mar 2024 07:18:50 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries [v4]
In-Reply-To: <ToHTphWoxPgLOENkn9ZDyzSMn5UFc4dn_rojw0Wn798=.e1abf667-53e7-4199-ab73-e2869a120454@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <UF3mP44thXI-j_zj8_m4or5scjDJbS62vhYUqB8uJKo=.6f7ffb5f-a476-44e5-8ff1-99fff5e1d753@github.com>
 <2E3wi6IUpcYa0hPInwu1QuQyvEe8YWZWTnXJDwc-dSQ=.670c3032-aa88-48d9-9c0c-5b04a27eab8b@github.com>
 <ToHTphWoxPgLOENkn9ZDyzSMn5UFc4dn_rojw0Wn798=.e1abf667-53e7-4199-ab73-e2869a120454@github.com>
Message-ID: <YCHXeQWp2oboypj0GATw6CgYyb0Ax9XyV44FvdAIaDs=.b8dd8cbc-5808-4b9b-9981-d268f3d4d874@github.com>

On Tue, 5 Mar 2024 14:19:14 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Does the release note also looks ok?

Yes.

> Is there any process to formally review release notes?

No. Typically just add a comment to the RN sub-task indicating it is okay. My comment, that I had made some minor changes was meant as an indicator of that.

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

PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1980229076

From Alan.Bateman at oracle.com  Wed Mar  6 09:22:21 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 6 Mar 2024 09:22:21 +0000
Subject: RFD: Can we remove the deprecated internal Unsafe *Object*
 methods?
In-Reply-To: <86b69a72-d225-4c62-b77e-44b5d89686e9@oracle.com>
References: <CA+pBWhsGVnQPv3NsHzDwYYsMPahK5JM7HQyKo0KnOsAyzvm=1w@mail.gmail.com>
 <86b69a72-d225-4c62-b77e-44b5d89686e9@oracle.com>
Message-ID: <7c33eb88-e520-4387-9625-3d6764e0322f@oracle.com>

On 05/03/2024 22:57, mandy.chung at oracle.com wrote:
> These deprecated methods were added to make jsr166.jar to run on 
> different JDK releases.? I think it's time to remove these deprecated 
> xxxObject* methods as the renames have been done since JDK 12 for 5 
> years.

Yes, I think they can be removed. They aren't accessible outside of the 
JDK so nothing should be dependent on them.

-Alan

From alanb at openjdk.org  Wed Mar  6 09:22:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 09:22:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
Message-ID: <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>

On Tue, 5 Mar 2024 22:44:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Many of these modules do not need native access in the current implementation.

In addition this will eventually need jlink support. I view the change to ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as very temporary. It may include many standard/JDK modules that aren't in the image. In addition we'll need some way to grant native access at link-time. The workaround for the latter right now is to configure default options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514113280

From shade at openjdk.org  Wed Mar  6 09:29:48 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Mar 2024 09:29:48 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <SQzEN8LebbOLvzKUKF5Om3ZZtu1QSdclvpE3q33znNE=.8572807b-1156-44db-b98a-eabc52867c9f@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <Wh7mlhwLnhoh9J1ajGDFA9OBC2D39OlPpMLlWP4G08M=.1eb79fb0-240e-4c6a-9188-46bcc4cdb54b@github.com>
 <SQzEN8LebbOLvzKUKF5Om3ZZtu1QSdclvpE3q33znNE=.8572807b-1156-44db-b98a-eabc52867c9f@github.com>
Message-ID: <i7eZH9jfhDL8IK0csTae_jRmR_uVJK7Kvzp1JmE_-SM=.c10e7a7d-1bde-458b-9aab-1a4cbe4f8f63@github.com>

On Tue, 5 Mar 2024 20:34:47 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> > The change in jspawnhelper looks good.
> > I think it would be simpler to have a separate `jdk/java/lang/ProcessBuilder/JspawnhelperMisuse.java` test that simply invokes the `jspawnhelper` and verifies the proper message is printed. It would be more straightforward than trying to fit the _protocol_ test? Plus, we can test 0, 1, 3, 4 args, not only 0 args in that test, and we can also test 2 args with bad format.
> 
> Yes, this makes the test cleaner[1]. 

Note that we have `OutputAnalyzer` for these test cases: https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/process/OutputAnalyzer.java -- lots of test use it, and it would be something like just:


  Process p = ProcessTools.startProcess(...);
  OutputAnalyzer oa = new OutputAnalyzer(p);
  oa.shouldNotHaveExitValue(0);
  oa.shouldContain("This command is not for general use");

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

PR Comment: https://git.openjdk.org/jdk/pull/18112#issuecomment-1980434240

From mbaesken at openjdk.org  Wed Mar  6 09:30:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 09:30:54 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
Message-ID: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>

We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

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

Commit messages:
 - JDK-8327444

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

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

From shaojin.wensj at alibaba-inc.com  Wed Mar  6 10:56:11 2024
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Wed, 06 Mar 2024 18:56:11 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaUkZEOiBDYW4gd2UgcmVtb3ZlIHRoZSBkZXByZWNhdGVkIGludGVybmFsIFVu?=
 =?UTF-8?B?c2FmZSAqT2JqZWN0KiBtZXRob2RzPw==?=
In-Reply-To: <7c33eb88-e520-4387-9625-3d6764e0322f@oracle.com>
References: <CA+pBWhsGVnQPv3NsHzDwYYsMPahK5JM7HQyKo0KnOsAyzvm=1w@mail.gmail.com>
 <86b69a72-d225-4c62-b77e-44b5d89686e9@oracle.com>,
 <7c33eb88-e520-4387-9625-3d6764e0322f@oracle.com>
Message-ID: <574d3804-72e7-4292-a3a5-320bcabc4186.shaojin.wensj@alibaba-inc.com>

Many libraries use Unsafe to improve performance, especially in many performance-critical scenarios of big data, such as Apache Flink/Apache Arrow, etc. Direct removal will make it difficult to adopt the new version of JDK. 
It is recommended to use it similar to JEP 396, which needs to be opened through parameters before it can be used and configured. The JVM startup parameter "--illegal-unsafe=warn" can be enabled. 
Removal should be after JDK 26.
------------------------------------------------------------------
????Alan Bateman <Alan.Bateman at oracle.com>
?????2024?3?6?(???) 17:22
????mandy.chung <mandy.chung at oracle.com>; core-libs-dev <core-libs-dev at openjdk.org>
????Re: RFD: Can we remove the deprecated internal Unsafe *Object* methods?
On 05/03/2024 22:57, mandy.chung at oracle.com wrote:
> These deprecated methods were added to make jsr166.jar to run on 
> different JDK releases. I think it's time to remove these deprecated 
> xxxObject* methods as the renames have been done since JDK 12 for 5 
> years.
Yes, I think they can be removed. They aren't accessible outside of the 
JDK so nothing should be dependent on them.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240306/eb59f16d/attachment-0001.htm>

From gli at openjdk.org  Wed Mar  6 11:00:45 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 6 Mar 2024 11:00:45 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <CEkugr_uiWOQVlTh-FSsLj6fdUX5OYfruGxJYRgSGJA=.9dcff5f4-f18d-454f-8bfd-ee6c2785780d@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

Looks good. Nice refactor.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1919422137

From jlaskey at openjdk.org  Wed Mar  6 12:03:58 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 6 Mar 2024 12:03:58 GMT
Subject: Integrated: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test
In-Reply-To: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
References: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
Message-ID: <jmewGf_h4ogJleJvlKICmj_RSxs2OBxd8CfSZ2kEieU=.3ad80197-6308-4c25-8e6c-453917b90b4e@github.com>

On Tue, 6 Feb 2024 12:52:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.

This pull request has now been integrated.

Changeset: a7461de2
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7461de231da20ed78a7c6ad8275f1bafbfa556c
Stats:     33 lines in 3 files changed: 32 ins; 0 del; 1 mod

8325255: jdk.internal.util.ReferencedKeySet::add using wrong test

Reviewed-by: rriggs, liach

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

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

From ihse at openjdk.org  Wed Mar  6 12:04:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 12:04:17 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as product
 code
Message-ID: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>

Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.

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

Commit messages:
 - 8327460: Compile tests with the same visibility rules as product code

Changes: https://git.openjdk.org/jdk/pull/18135/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327460
  Stats: 303 lines in 38 files changed: 69 ins; 159 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/18135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18135/head:pull/18135

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

From ihse at openjdk.org  Wed Mar  6 12:16:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 12:16:45 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code
In-Reply-To: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
Message-ID: <D4VnoA_AetZT4vT_WasTrnfsavTpUH4oy8bCTL7HAWY=.5f2b4617-5854-4913-922e-aa84cd9c04a9@github.com>

On Wed, 6 Mar 2024 11:33:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.

Most of these changes is just putting the `EXPORT` define in `export.h` instead (where support for `__attribute__((visibility("default")))` is also added). However, there are a few other changes worth mentioning:

* `test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c` was missing an export. This had not been discovered before since that file was not compiled on Windows.
* On macOS, the `main` function of a Java launcher needs to be exported, since we re-launch the main function when starting a new thread. (This is utterly weird behavior driven by how on macOS the main thread is reserved for Cocoa events, and I'm not sure this is properly documented by the JNI specification). 
* The `dereference_null` function from `libTestDwarfHelper.h` is looked for in the Hotspot hs_err stack trace in `test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java`. When compiling with `-fvisibility=hidden`, it became inline and the test failed. I solved this by exporting the function, thus restoring the same situation as was before. I'm not sure this is the correct or best solution though, since it depends on what you expect `TestDwarf.java` to really achieve. (You can't expect of it to perform miracles and show functions that has been inlined in stack traces, though...)

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1980739771

From ihse at openjdk.org  Wed Mar  6 13:43:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 13:43:00 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
Message-ID: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>

> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update line number for dereference_null  in TestDwarf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18135/files
  - new: https://git.openjdk.org/jdk/pull/18135/files/1dc79758..b1bf01ad

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

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

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

From erikj at openjdk.org  Wed Mar  6 13:51:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Mar 2024 13:51:46 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <T9joul4A3qCerggx27eSyiUW5npWCAJo46tukWvEyy4=.66d8eb4d-3747-4741-b2aa-c313b9523829@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

Build system changes look good to me. The specific test changes probably needs other reviewers.

I assume you have run all the affected tests on a wide variety of platforms?

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18135#pullrequestreview-1919814110

From ihse at openjdk.org  Wed Mar  6 13:55:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 13:55:46 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <qrvOs87-Kt6FXps9AhHaYb4uBfwN-zdNkvgy4ym6H8Q=.eeca8b49-0baf-4c8e-9217-f4133b41830f@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

I have run the tests in tier1, tier2 and tier3 on the Oracle internal CI, which includes linux/x64, linux/aarch64, windows/x64, macosx/x64 and macosx/aarch64. 

I am currently running tier 4-10; this will take a while (and I won't integrate until this has finished running). When running multiple high-tier tests like this, the likelihood that I encounter intermittent problems increase. I will ignore test failures that seem likely to be intermittent and not caused by this patch. I might be overdoing the testing, but since this change affects **all** native tests, I want to be absolutely sure I don't break any tests that only execute as part of a high tier.

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1980924971

From Alan.Bateman at oracle.com  Wed Mar  6 14:03:37 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 6 Mar 2024 14:03:37 +0000
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGRDogQ2FuIHdlIHJlbW92ZSB0aGUgZGVwcmVj?=
 =?UTF-8?Q?ated_internal_Unsafe_*Object*_methods=3F?=
In-Reply-To: <574d3804-72e7-4292-a3a5-320bcabc4186.shaojin.wensj@alibaba-inc.com>
References: <CA+pBWhsGVnQPv3NsHzDwYYsMPahK5JM7HQyKo0KnOsAyzvm=1w@mail.gmail.com>
 <86b69a72-d225-4c62-b77e-44b5d89686e9@oracle.com>
 <7c33eb88-e520-4387-9625-3d6764e0322f@oracle.com>
 <574d3804-72e7-4292-a3a5-320bcabc4186.shaojin.wensj@alibaba-inc.com>
Message-ID: <5265c494-5584-4f00-9c37-77ff9ac80e1f@oracle.com>

On 06/03/2024 10:56, wenshao wrote:
> Many libraries use Unsafe to improve performance, especially in many 
> performance-critical scenarios of big data, such as Apache 
> Flink/Apache Arrow, etc. Direct removal will make it difficult to 
> adopt the new version of JDK.
>
> It is recommended to use it similar to JEP 396, which needs to be 
> opened through parameters before it can be used and configured. The 
> JVM startup parameter "--illegal-unsafe=warn" can be enabled.
>
> Removal should be after JDK 26.

This discussion is about the JDK's internal Unsafe, not sun.misc.Unsafe.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240306/6f4b1d27/attachment-0001.htm>

From alanb at openjdk.org  Wed Mar  6 14:15:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 14:15:48 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

src/java.base/share/native/libjava/jni_util.h line 243:

> 241:   } while((_result == -1) && (errno == EINTR)); \
> 242: } while(0)
> 243: 

jni_util.h is for all platforms so not the right place for a Unix specific macro. We need think where the right place for this, might have to introduce a jni_util_md.h.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514555111

From jpai at openjdk.org  Wed Mar  6 14:19:51 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 6 Mar 2024 14:19:51 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v6]
In-Reply-To: <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com>
Message-ID: <xQiA9MXMCs9PX-evhlpSTVxmQ-oEgeTZIcINJFjznl0=.bdec41d9-28e7-4cec-a31a-210ee78114b6@github.com>

On Mon, 5 Feb 2024 23:53:06 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 six additional commits since the last revision:
> 
>  - 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, I hope to finish off running the necessary analysis to see if there is any obvious impact because of this change, in the coming days. Based on the intial runs, the changes proposed in this PR look OK to me.

In the meantime, given the nature of this change, I am marking this as requiring a CSR. Would you be willing to come up with the CSR text for this (https://wiki.openjdk.org/display/csr/Main)?

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

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1980967387

From mbaesken at openjdk.org  Wed Mar  6 14:27:48 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 14:27:48 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
In-Reply-To: <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
Message-ID: <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>

On Wed, 6 Mar 2024 14:13:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> src/java.base/share/native/libjava/jni_util.h line 243:
> 
>> 241:   } while((_result == -1) && (errno == EINTR)); \
>> 242: } while(0)
>> 243: 
> 
> jni_util.h is for all platforms so not the right place for a Unix specific macro. We need think where the right place for this, might have to introduce a jni_util_md.h.

We could maybe also use the existing  https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h  - what do you think ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514574059

From liangchenblue at gmail.com  Wed Mar  6 14:31:37 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 6 Mar 2024 08:31:37 -0600
Subject: RFD: Can we remove the deprecated internal Unsafe *Object*
 methods?
In-Reply-To: <574d3804-72e7-4292-a3a5-320bcabc4186.shaojin.wensj@alibaba-inc.com>
References: <CA+pBWhsGVnQPv3NsHzDwYYsMPahK5JM7HQyKo0KnOsAyzvm=1w@mail.gmail.com>
 <86b69a72-d225-4c62-b77e-44b5d89686e9@oracle.com>
 <7c33eb88-e520-4387-9625-3d6764e0322f@oracle.com>
 <574d3804-72e7-4292-a3a5-320bcabc4186.shaojin.wensj@alibaba-inc.com>
Message-ID: <CABe8uE0z2aR2SADN2TYu=V+g1gzvK4dex-DCat_=sf956zNO+w@mail.gmail.com>

Hi Wen,
I think this change is for jdk.internal's Unsafe (JDK 9+) instead of for
sun.misc's Unsafe. The sun.misc.Unsafe's methods have stayed "getObject"
https://github.com/openjdk/jdk/blob/ae5e3fdd5922a232c9b48fc846c4fcdc8f2b2645/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java#L197
instead of getReference.

Also the preferred way since JDK 9 to access these operations is via
java.lang.invoke.VarHandle, which exposes more fine-grained access modes
like plain/acquire-release/compareAndExchange, all of which are backed by
the newer jdk.internal's Unsafe. I think the main reason JSR 166
(java.util.concurrent) code uses Unsafe directly is that it wants to avoid
an early startup dependency on VarHandle (like in the case of your decimal
toString optimization).

On Wed, Mar 6, 2024 at 4:56?AM wenshao <shaojin.wensj at alibaba-inc.com>
wrote:

> Many libraries use Unsafe to improve performance, especially in many
> performance-critical scenarios of big data, such as Apache Flink/Apache
> Arrow, etc. Direct removal will make it difficult to adopt the new version
> of JDK.
>
> It is recommended to use it similar to JEP 396, which needs to be opened
> through parameters before it can be used and configured. The JVM startup
> parameter "--illegal-unsafe=warn" can be enabled.
>
> Removal should be after JDK 26.
>
> ------------------------------------------------------------------
> ????Alan Bateman <Alan.Bateman at oracle.com>
> ?????2024?3?6?(???) 17:22
> ????mandy.chung <mandy.chung at oracle.com>; core-libs-dev <
> core-libs-dev at openjdk.org>
> ? ??Re: RFD: Can we remove the deprecated internal Unsafe *Object* methods?
>
> On 05/03/2024 22:57, mandy.chung at oracle.com wrote:
> > These deprecated methods were added to make jsr166.jar to run on
> > different JDK releases.  I think it's time to remove these deprecated
> > xxxObject* methods as the renames have been done since JDK 12 for 5
> > years.
>
> Yes, I think they can be removed. They aren't accessible outside of the
> JDK so nothing should be dependent on them.
>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240306/b26e47c0/attachment-0001.htm>

From alanb at openjdk.org  Wed Mar  6 14:35:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 14:35:46 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
In-Reply-To: <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
 <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>
Message-ID: <BVmjS3qMP7guv_LjBz9fvwLS6JAmt2GX_00IGe-_7-w=.3b422e7b-1d0a-4ff7-9e4f-eae6879e44b2@github.com>

On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We could maybe also use the existing https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h - what do you think ?

jni_md.h goes into the JDK run-time image (for jni.h to include) so I don't think we should be changing that.  jni_util.* is JDK internal so I think we're just missing a platform dependent include file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514586726

From aefimov at openjdk.org  Wed Mar  6 14:44:48 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 6 Mar 2024 14:44:48 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v7]
In-Reply-To: <r__SpoJaRXPAH-aJNSrMxetk4OkTGCILvAcDVRRxSxo=.53101fde-2aaa-4368-ba56-89167be8ad53@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <r__SpoJaRXPAH-aJNSrMxetk4OkTGCILvAcDVRRxSxo=.53101fde-2aaa-4368-ba56-89167be8ad53@github.com>
Message-ID: <QIfdwXrR8lPxYCESnBy6nxxfhAZCK_BfKJzNceSjjIU=.10a61f3e-8328-4f91-a3b0-1cb10fbd8a2f@github.com>

On Fri, 1 Mar 2024 10:44:14 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer 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:
> 
>  - Indentation
>  - Merge branch 'master' into JDK-8325579
>  - Review feedback
>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>  - Merge branch 'master' into JDK-8325579
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - Enhance test
>  - JDK-8325579

src/java.naming/share/classes/module-info.java line 42:

> 40:  *         <br>The value of this environment property specifies the fully
> 41:  *         qualified class name of the socket factory used by the LDAP provider.
> 42:  *         This class must implement the javax.net.SocketFactory abstract class.

We need to mention here that `getDefault` method needs to be implemented by the provided socket factory class.

 Something like: `and provide an implementation of the static "getDefault()" method that returns an instance of the socket factory.`
The CSR needs to be updated too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1514602203

From jlahoda at openjdk.org  Wed Mar  6 15:01:47 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Mar 2024 15:01:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <CQCdfDP6785EDomU2zdtqsi6DpyHYpnHo20Sucs7xPc=.58038e72-419c-40a5-a378-a7bd6b766809@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <CQCdfDP6785EDomU2zdtqsi6DpyHYpnHo20Sucs7xPc=.58038e72-419c-40a5-a378-a7bd6b766809@github.com>
Message-ID: <RGk0UCU1r30IQjKZ7qWruBHAB7xzmRCrCUCRslQ0Bss=.59b69ff9-efb2-4c3d-a4b8-e7ecedd25dde@github.com>

On Tue, 5 Mar 2024 13:58:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jan Lahoda 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>
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 817:
> 
>> 815:                 JLA.addEnableNativeAccessToAllUnnamed();
>> 816:             } else if (!JLA.addEnableNativeAccess(layer, name) && shouldWarn) {
>> 817:                 warnUnknownModule(ENABLE_NATIVE_ACCESS, name);
> 
> Should we instead warn irrespective of whether or not it's user configured native access module name or a module name configured in JDK's build configuration? Or are the build misconfiguration in the `NATIVE_ACCESS_MODULES` expected to be caught much earlier in some other place?

For normal "full" JDK build, all the modules with pre-set native access should be present, and the warning might make sense there. But, the user may jlink a smaller version of the platform, or use `--limit-modules`, and that may cause some of the modules are not present. So I don't think it is realistic to produce a warning here for the modules with pre-set native access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514633918

From asotona at openjdk.org  Wed Mar  6 15:00:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Mar 2024 15:00:09 GMT
Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v4]
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: <rp0X2av2m-l1sfRfRrbVvjhDoFZiJw38HM8cLtHSoDU=.24e42358-9b55-4f26-b28f-d18548777ea4@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 incrementally with one additional commit since the last revision:

  fixed ClassFile API use in new tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17282/files
  - new: https://git.openjdk.org/jdk/pull/17282/files/5854a866..4479ccee

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

  Stats: 18 lines in 8 files changed: 0 ins; 0 del; 18 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 jlahoda at openjdk.org  Wed Mar  6 15:04:46 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Mar 2024 15:04:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
 <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
Message-ID: <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>

On Wed, 6 Mar 2024 09:19:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Many of these modules do not need native access in the current implementation.   Should this list be trimmed to list the ones that need native access in the current implementation?
>
>> Many of these modules do not need native access in the current implementation.
> 
> In addition this will eventually need jlink support. I view the change to ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as very temporary. It may include many standard/JDK modules that aren't in the image. In addition we'll need some way to grant native access at link-time. The workaround for the latter right now is to configure default options.

> Many of these modules do not need native access in the current implementation. Should this list be trimmed to list the ones that need native access in the current implementation?

Not sure if I know enough to do the pruning, so I was hoping that could be done separately (I'd file a bug as Alan suggests). But I can try to prune the list, if you prefer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514640785

From liach at openjdk.org  Wed Mar  6 15:34:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 6 Mar 2024 15:34:45 GMT
Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v4]
In-Reply-To: <rp0X2av2m-l1sfRfRrbVvjhDoFZiJw38HM8cLtHSoDU=.24e42358-9b55-4f26-b28f-d18548777ea4@github.com>
References: <HnSlddnQJi47nmj_MTxi2SooHNzaI_JCAuLk68DuxzY=.25dcf5e9-657f-4225-8952-aa4c741edb08@github.com>
 <rp0X2av2m-l1sfRfRrbVvjhDoFZiJw38HM8cLtHSoDU=.24e42358-9b55-4f26-b28f-d18548777ea4@github.com>
Message-ID: <yn56NvkAddz7ZiT81j5OvQh7e_RZMTCdfa9JLqBo9HQ=.da06ad8e-077b-42ee-86c5-b7c10282a400@github.com>

On Wed, 6 Mar 2024 15:00:09 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> `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 incrementally with one additional commit since the last revision:
> 
>   fixed ClassFile API use in new tests

Looking at 8326836 #18030, we might need `@since` tags on the new API methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/17282#issuecomment-1981141337

From mbaesken at openjdk.org  Wed Mar  6 15:45:16 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 15:45:16 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v2]
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

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

  introduce unix jni_util_md.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18132/files
  - new: https://git.openjdk.org/jdk/pull/18132/files/014ab1fd..f30a189d

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

  Stats: 68 lines in 19 files changed: 52 ins; 7 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18132/head:pull/18132

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

From alanb at openjdk.org  Wed Mar  6 15:51:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 15:51:46 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v2]
In-Reply-To: <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
Message-ID: <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>

On Wed, 6 Mar 2024 15:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   introduce unix jni_util_md.h

src/java.base/aix/native/libnio/ch/Pollset.c line 29:

> 27: #include "jni.h"
> 28: #include "jni_util.h"
> 29: #include "jni_util_md.h"

When I suggested jni_util_md.h then I meant create one for Unix and another for Windows, then have jni_util.h include it. This will avoid needing to add an include to all these files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514724921

From rgiulietti at openjdk.org  Wed Mar  6 15:58:51 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 6 Mar 2024 15:58:51 GMT
Subject: RFR: 8326718: Test java/util/Formatter/Padding.java should timeout
 on large inputs before fix in JDK-8299677 [v3]
In-Reply-To: <nmdhjce7rqWQBMCyNhCt8vIs6kbKRuk-2ITlOC3DTiA=.b7dd99c3-ee5b-41e0-98aa-22d447e7fa16@github.com>
References: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
 <nmdhjce7rqWQBMCyNhCt8vIs6kbKRuk-2ITlOC3DTiA=.b7dd99c3-ee5b-41e0-98aa-22d447e7fa16@github.com>
Message-ID: <VCn3qKPNqTwDduo_deEj0VtBqz3YxgdO2vNFqdlQLWQ=.26e61c5b-0d6c-43f9-b3df-99a2c0cbebb3@github.com>

On Tue, 5 Mar 2024 23:00:16 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after.
>> 
>> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add underscores to large number

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18033#pullrequestreview-1920152315

From mbaesken at openjdk.org  Wed Mar  6 16:08:45 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 16:08:45 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v2]
In-Reply-To: <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
 <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>
Message-ID: <k8YDbMN1Y1cM_HIgm6gqsdDDDXXQEgSDDWd98ZfhjEk=.869ed36b-dcd5-477c-9e96-db6aa1817ed5@github.com>

On Wed, 6 Mar 2024 15:49:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   introduce unix jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line 29:
> 
>> 27: #include "jni.h"
>> 28: #include "jni_util.h"
>> 29: #include "jni_util_md.h"
> 
> When I suggested jni_util_md.h then I meant create one for Unix and another for Windows, then have jni_util.h include it. This will avoid needing to add an include to all these files.

I considered this too,  but the one on Windows would be empty for now -> looks a bit strange . But I can do it why not .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514752727

From asotona at openjdk.org  Wed Mar  6 16:15:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Mar 2024 16:15:03 GMT
Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v5]
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: <WD4AK22Qzf-5yqgfaJdJG_tKeYJ9A-heygH46JyhOPA=.4be31e6d-04ef-4ef8-ad23-19fe620fd70e@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 incrementally with one additional commit since the last revision:

  added @since 23 tags for new CodeBuilder methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17282/files
  - new: https://git.openjdk.org/jdk/pull/17282/files/4479ccee..ec9af60f

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

  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 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 asotona at openjdk.org  Wed Mar  6 16:15:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Mar 2024 16:15:03 GMT
Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v4]
In-Reply-To: <yn56NvkAddz7ZiT81j5OvQh7e_RZMTCdfa9JLqBo9HQ=.da06ad8e-077b-42ee-86c5-b7c10282a400@github.com>
References: <HnSlddnQJi47nmj_MTxi2SooHNzaI_JCAuLk68DuxzY=.25dcf5e9-657f-4225-8952-aa4c741edb08@github.com>
 <rp0X2av2m-l1sfRfRrbVvjhDoFZiJw38HM8cLtHSoDU=.24e42358-9b55-4f26-b28f-d18548777ea4@github.com>
 <yn56NvkAddz7ZiT81j5OvQh7e_RZMTCdfa9JLqBo9HQ=.da06ad8e-077b-42ee-86c5-b7c10282a400@github.com>
Message-ID: <6f-qi9LVm6y34w69r1ALIBMA9I3WDGG5cSVIbyaL9gE=.a8a90b95-46cc-4c81-af8d-afc5477e98b0@github.com>

On Wed, 6 Mar 2024 15:31:40 GMT, Chen Liang <liach at openjdk.org> wrote:

> Looking at 8326836 #18030, we might need `@since` tags on the new API methods.

Thanks for pointing it out, I've added them.

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

PR Comment: https://git.openjdk.org/jdk/pull/17282#issuecomment-1981230434

From naoto at openjdk.org  Wed Mar  6 16:17:51 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Mar 2024 16:17:51 GMT
Subject: RFR: 8327261: Parsing test for Double/Float succeeds w/o testing
 all bad cases [v2]
In-Reply-To: <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
 <t5mYNwOjh3CSXraxggNnpkvWsiW4IWUt5zl2Y0nsI7Y=.ef0a812d-646e-499c-8796-0bb72a0f61f3@github.com>
Message-ID: <T3gLqFFXVXv2gw5ssQrrXKSUD6qOAKUi-LVo1Zs9_3Y=.f21921d6-cab0-4cc3-bf69-abd76428dd08@github.com>

On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/18113#issuecomment-1981238638

From naoto at openjdk.org  Wed Mar  6 16:17:51 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Mar 2024 16:17:51 GMT
Subject: Integrated: 8327261: Parsing test for Double/Float succeeds w/o
 testing all bad cases
In-Reply-To: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
References: <xCZeDbSIg9-PF-fpB88R_nEI_7LX_e3TtXfOh91FlVw=.c5eae236-2059-4548-a906-15638bdf38cb@github.com>
Message-ID: <b-PzVEGyo0JVAmmcflMN8RypXuttjjegR_VfPhk5bQg=.7082b8b8-72ed-4597-a773-4d0b7952a2bd@github.com>

On Tue, 5 Mar 2024 00:51:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing test cases. For bad test cases, only the first case was run, and the rest were ignored.

This pull request has now been integrated.

Changeset: 9f709407
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f7094079b6eb6b60b345955dba358a2d5c90931
Stats:     24 lines in 2 files changed: 0 ins; 6 del; 18 mod

8327261: Parsing test for Double/Float succeeds w/o testing all bad cases

Reviewed-by: darcy, gli, joehw, jlu, bpb, lancea

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

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

From mbaesken at openjdk.org  Wed Mar  6 16:30:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 16:30:23 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

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

  Introduce windows jni_util_md.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18132/files
  - new: https://git.openjdk.org/jdk/pull/18132/files/f30a189d..2930075d

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

  Stats: 24 lines in 19 files changed: 1 ins; 22 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18132/head:pull/18132

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

From ihse at openjdk.org  Wed Mar  6 17:13:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 17:13:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
Message-ID: <SIUFVO3RcgYnIay7F33-PfFy-T0zu3AbaG5uuWF6Bao=.35edf894-58de-47c1-9c74-79ec609e8425@github.com>

On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda 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>
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Build changes are ok.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1920357192

From ihse at openjdk.org  Wed Mar  6 17:13:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 17:13:47 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <pR_tzy5Mm3VY2y4uJfeE8MxORUmVZ8yv_3fyFJvz-ho=.345d8490-f43b-4757-8ae7-ac0e353e4bd9@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <BaYcVWdgY2ZW8a1QJ3WeJAvMm-ZK_aLeaEc7jwHU7dA=.b816444e-ab6c-49eb-8b76-a0b7e791da24@github.com>
 <HMAbUF_RZKszCFPl9nS4rapV8EnZKp16Zh8sRYRXOtI=.64ef7b06-0265-4b99-9487-1a722fafead0@github.com>
 <hTaiuAMEYyBqXeiA3_TD84m63GmJiMmo1K0l5tGk6QU=.03ffc7b1-d93f-4fca-8b49-e6e6fb0ce7c8@github.com>
 <qUywPUBxrFPqmBQt0CmeoIjDdY__AaxZ1RnqbqpKtxs=.19abd551-8a3b-40e0-a148-0701fbce0405@github.com>
 <pR_tzy5Mm3VY2y4uJfeE8MxORUmVZ8yv_3fyFJvz-ho=.345d8490-f43b-4757-8ae7-ac0e353e4bd9@github.com>
Message-ID: <XciX2jKt36bYzbEQzIIFFc2D0oOk_tPuMX3xPtZhn1g=.870478b8-a203-4074-92bb-c7672c74073d@github.com>

On Wed, 6 Mar 2024 00:56:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I believe we could technically reuse the list for boot/platform modules. But, the intent here is to provide more control over the modules with native access, not only being able to add to the list, but also remove from the list. So, to me, it seemed better to have an explicit list, from/to which we can remove/add modules easily.
>
> Hello Jan, my suggestion was based on a misunderstanding that NATIVE_ACCESS_MODULES is always a superset of boot and platform modules. What you currently have looks fine to me.

And also, for the record, the .conf files are supposed to be in a syntactical subset compatible with both bash and make syntax, so this would not have been possible anyway. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514865999

From clanger at openjdk.org  Wed Mar  6 17:21:50 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 6 Mar 2024 17:21:50 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce windows jni_util_md.h

Looks good to me modulo a few license year things...

src/java.base/macosx/native/libnio/ch/KQueue.c line 2:

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

Here you only change the license year?

src/java.base/share/native/libjava/jni_util.h line 30:

> 28: 
> 29: #include "jni.h"
> 30: #include "jni_util_md.h"

This file needs copyright year update

src/java.base/unix/native/libjava/childproc.h line 75:

> 73: #define FAIL_FILENO (STDERR_FILENO + 1)
> 74: 
> 75: /* TODO: Refactor. */

Copyright year update missing.

src/java.base/unix/native/libnio/ch/nio_util.h line 34:

> 32: #include <sys/un.h>
> 33: 
> 34: #define RESTARTABLE(_cmd, _result) do { \

Copyright year update

src/java.base/unix/native/libnio/fs/UnixFileSystem.c line 38:

> 36: #include "sun_nio_fs_UnixFileSystem.h"
> 37: 
> 38: #define RESTARTABLE(_cmd, _result) do { \

Copyright year update

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

Changes requested by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1920355323
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514867262
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514873505
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514876266
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514878580
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514878995

From ihse at openjdk.org  Wed Mar  6 17:30:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 17:30:50 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
Message-ID: <WZTbspyfV7iA3PiJrVtHFsuCsgkR9eREl5mba-mQ5qg=.386b664f-dc56-4817-9509-da3b1912c82b@github.com>

On Tue, 27 Feb 2024 15:23:09 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:
> 
>   Only show runtime image suffix for JDK modules

make/ToolsJdk.gmk line 88:

> 86:     --add-modules=jdk.jlink --add-exports=java.base/jdk.internal.module=ALL-UNNAMED \
> 87:     --add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED \
> 88:     build.tools.runtimelink.JimageDiffGenerator

While it might be a bit redundant, we try to keep the same name in the make name, the package and the main class, e.g. something like:

Suggestion:

TOOL_JIMAGE_DIFF_GENERATOR = $(BUILD_JAVA_SMALL) -cp $(BUILDTOOLS_OUTPUTDIR)/jdk_tools_classes \
    --add-modules=jdk.jlink --add-exports=java.base/jdk.internal.module=ALL-UNNAMED \
    --add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED \
    build.tools.jimagediffgenerator.JimageDiffGenerator


This is of course not consistently followed, but for new tooling I think it would be a good idea to try and follow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1514894494

From eirbjo at gmail.com  Wed Mar  6 17:34:57 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 6 Mar 2024 18:34:57 +0100
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGRDogQ2FuIHdlIHJlbW92ZSB0aGUgZGVwcmVjYXRlZCBpbnRlcg==?=
 =?UTF-8?B?bmFsIFVuc2FmZSAqT2JqZWN0KiBtZXRob2RzPw==?=
In-Reply-To: <5265c494-5584-4f00-9c37-77ff9ac80e1f@oracle.com>
References: <CA+pBWhsGVnQPv3NsHzDwYYsMPahK5JM7HQyKo0KnOsAyzvm=1w@mail.gmail.com>
 <86b69a72-d225-4c62-b77e-44b5d89686e9@oracle.com>
 <7c33eb88-e520-4387-9625-3d6764e0322f@oracle.com>
 <574d3804-72e7-4292-a3a5-320bcabc4186.shaojin.wensj@alibaba-inc.com>
 <5265c494-5584-4f00-9c37-77ff9ac80e1f@oracle.com>
Message-ID: <CA+pBWhu6XKX1=xc0MgrV7RcF7Mo4HkRs+Z0ef5TNdzDtK-1ZFQ@mail.gmail.com>

On Wed, Mar 6, 2024 at 5:41?PM Alan Bateman <Alan.Bateman at oracle.com> wrote:

This discussion is about the JDK's internal Unsafe, not sun.misc.Unsafe.
>

Thanks Alan, I guess I should have made this more clear from the beginning.

I'll await a response from the wise men on Mandy's JDK-8207146 comment
before proposing a PR.

Side note: It's a tad unfortunate that these classes erase the same simple
name. Something like InternalUnsafe would possibly make confusion like this
less likely.

Cheers,
Eirik :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240306/446b0316/attachment-0001.htm>

From darcy at openjdk.org  Wed Mar  6 18:00:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Mar 2024 18:00:05 GMT
Subject: RFR: JDK-8327487: Further augment WorstCaseTests with more cases
Message-ID: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>

The atan2 and hypot cases added would fail for a particular test library that has errors in the millions of ulps for those inputs, rather than the small number of ulps specified for the error.

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

Commit messages:
 - JDK-8327487: Further augment WorstCaseTests with more cases

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

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

From mchung at openjdk.org  Wed Mar  6 18:02:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 6 Mar 2024 18:02:45 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
 <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
 <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>
Message-ID: <xeO5tMijH6YcZoYCcnK-pqtNSkS_23yM1wETU-kyLG8=.7be74845-5e39-409f-9498-29c9e9e48331@github.com>

On Wed, 6 Mar 2024 15:02:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> Many of these modules do not need native access in the current implementation.
>> 
>> In addition this will eventually need jlink support. I view the change to ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as very temporary. It may include many standard/JDK modules that aren't in the image. In addition we'll need some way to grant native access at link-time. The workaround for the latter right now is to configure default options.
>
>> Many of these modules do not need native access in the current implementation. Should this list be trimmed to list the ones that need native access in the current implementation?
> 
> Not sure if I know enough to do the pruning, so I was hoping that could be done separately (I'd file a bug as Alan suggests). But I can try to prune the list, if you prefer.

Native access is needed for modules which calls restricted methods [1].   AFAICT, java.base, java.desktop and jdk.incubator.vector use java.lang.foreign but I don't know if they call restricted methods or not.

https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/foreign/package-summary.html#restricted

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514932944

From duke at openjdk.org  Wed Mar  6 18:33:08 2024
From: duke at openjdk.org (Korov)
Date: Wed, 6 Mar 2024 18:33:08 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly check
 key and value
Message-ID: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>

When the specified key did not associated with a value, should check the `key` and `value` type.

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

Commit messages:
 - 8292955: Collections.checkedMap Map.merge does not properly check key and value
 - 8292955: Collections.checkedMap Map.merge does not properly check key and value
 - 8292955: Collections.checkedMap Map.merge does not properly check key and value

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

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

From acobbs at openjdk.org  Wed Mar  6 18:32:49 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 6 Mar 2024 18:32:49 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v6]
In-Reply-To: <xQiA9MXMCs9PX-evhlpSTVxmQ-oEgeTZIcINJFjznl0=.bdec41d9-28e7-4cec-a31a-210ee78114b6@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com>
 <xQiA9MXMCs9PX-evhlpSTVxmQ-oEgeTZIcINJFjznl0=.bdec41d9-28e7-4cec-a31a-210ee78114b6@github.com>
Message-ID: <CVmAZe7fD-566VIrextpyf2So_USaXtA9tbvNxjj94g=.e1be95f1-0ae5-4eef-8e62-0663d0b71d98@github.com>

On Wed, 6 Mar 2024 14:14:56 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 six additional commits since the last revision:
>> 
>>  - 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, I hope to finish off running the necessary analysis to see if there is any obvious impact because of this change, in the coming days. Based on the intial runs, the changes proposed in this PR look OK to me.
> 
> In the meantime, given the nature of this change, I am marking this as requiring a CSR. Would you be willing to come up with the CSR text for this (https://wiki.openjdk.org/display/csr/Main)?

Hi @jaikiran,

> Would you be willing to come up with the CSR text for this

Happy to - please see [JDK-8327489](https://bugs.openjdk.org/browse/JDK-8327489).

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

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1981533001

From matsaave at openjdk.org  Wed Mar  6 18:48:47 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 6 Mar 2024 18:48:47 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java
In-Reply-To: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
Message-ID: <K1GEAZ9rkpnAiiKMor77osGRBYUZMnM_2uUySAHoDlc=.271aeb1b-7cf1-4a62-8923-0c1979fccf40@github.com>

On Sat, 2 Mar 2024 01:18:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> A few clean ups:
> 
> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
> 
> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
> 
> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
> 
> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
> 
> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.

Looks good, thanks! Just one comment on format below.

src/hotspot/share/cds/cdsConfig.hpp line 72:

> 70:   static void  enable_dumping_dynamic_archive()              { CDS_ONLY(_is_dumping_dynamic_archive = true); }
> 71:   static void disable_dumping_dynamic_archive()              { CDS_ONLY(_is_dumping_dynamic_archive = false); }
> 72:   static bool      is_using_archive()                        NOT_CDS_RETURN_(false);

Could you fix the alignment of the method names here?

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18095#pullrequestreview-1920532000
PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1514980583

From alanb at openjdk.org  Wed Mar  6 19:02:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 19:02:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <xeO5tMijH6YcZoYCcnK-pqtNSkS_23yM1wETU-kyLG8=.7be74845-5e39-409f-9498-29c9e9e48331@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
 <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
 <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>
 <xeO5tMijH6YcZoYCcnK-pqtNSkS_23yM1wETU-kyLG8=.7be74845-5e39-409f-9498-29c9e9e48331@github.com>
Message-ID: <KGp6SKKepujiMeOiDiWGs__WZAYXZl_VjX8qyKNVkj8=.5a145d54-15dd-4724-af59-4306a4c7e5b9@github.com>

On Wed, 6 Mar 2024 18:00:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Native access is needed for modules which calls restricted methods [1].

In time, we'll need it for modules using JNI too. We can do this trimming in another PR to avoid Jan getting pulled into deeply.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1514999868

From mchung at openjdk.org  Wed Mar  6 19:11:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 6 Mar 2024 19:11:46 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <KGp6SKKepujiMeOiDiWGs__WZAYXZl_VjX8qyKNVkj8=.5a145d54-15dd-4724-af59-4306a4c7e5b9@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <p9iRsQla8-0LQAI3NYtQY-FzY1Y0FZNvZeiXBXLpJxI=.bcd6ba33-1fbc-48b2-aac4-c5cf9c4aea7b@github.com>
 <Mq21f2lIHLg4wWscv4SaCnx19U6wXcP537o1cYUFLTM=.4d6de564-498e-4258-aca5-7c86c0c594d1@github.com>
 <klsV86kAAGdaS9wSXk21Xiv7gOgsU-RGXfFaTDBt3Jo=.ed448c20-9e5a-4d69-952a-261f7ee808c3@github.com>
 <xeO5tMijH6YcZoYCcnK-pqtNSkS_23yM1wETU-kyLG8=.7be74845-5e39-409f-9498-29c9e9e48331@github.com>
 <KGp6SKKepujiMeOiDiWGs__WZAYXZl_VjX8qyKNVkj8=.5a145d54-15dd-4724-af59-4306a4c7e5b9@github.com>
Message-ID: <QbcMhlKDpFc4WsFmv9Tp16btRZ4ySk0IWo5XYX9RTyQ=.5b7dd50c-8ec8-4f07-bda4-479712c5c661@github.com>

On Wed, 6 Mar 2024 19:00:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Native access is needed for modules which calls restricted methods [1].   AFAICT, java.base, java.desktop and jdk.incubator.vector use java.lang.foreign but I don't know if they call restricted methods or not.
>> 
>> https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/foreign/package-summary.html#restricted
>
>> Native access is needed for modules which calls restricted methods [1].
> 
> In time, we'll need it for modules using JNI too. We can do this trimming in another PR to avoid Jan getting pulled into deeply.

Doing it in another PR is fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515009659

From sgehwolf at openjdk.org  Wed Mar  6 19:29:52 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 6 Mar 2024 19:29:52 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <WZTbspyfV7iA3PiJrVtHFsuCsgkR9eREl5mba-mQ5qg=.386b664f-dc56-4817-9509-da3b1912c82b@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <WZTbspyfV7iA3PiJrVtHFsuCsgkR9eREl5mba-mQ5qg=.386b664f-dc56-4817-9509-da3b1912c82b@github.com>
Message-ID: <IKkanmccCp0zDmrOUWEmXS6Y7RgCFypmE5JRIvUFAjE=.58915405-b81d-442b-b0c5-b7bfd1727a32@github.com>

On Wed, 6 Mar 2024 17:28:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only show runtime image suffix for JDK modules
>
> make/ToolsJdk.gmk line 88:
> 
>> 86:     --add-modules=jdk.jlink --add-exports=java.base/jdk.internal.module=ALL-UNNAMED \
>> 87:     --add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED \
>> 88:     build.tools.runtimelink.JimageDiffGenerator
> 
> While it might be a bit redundant, we try to keep the same name in the make name, the package and the main class, e.g. something like:
> 
> Suggestion:
> 
> TOOL_JIMAGE_DIFF_GENERATOR = $(BUILD_JAVA_SMALL) -cp $(BUILDTOOLS_OUTPUTDIR)/jdk_tools_classes \
>     --add-modules=jdk.jlink --add-exports=java.base/jdk.internal.module=ALL-UNNAMED \
>     --add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED \
>     build.tools.jimagediffgenerator.JimageDiffGenerator
> 
> 
> This is of course not consistently followed, but for new tooling I think it would be a good idea to try and follow.

Based on some private feedback I've got it seems this will change a bit (move to the `jdk.jlink` module instead). But if still relevant, I'll keep that in mind. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1515040874

From duke at openjdk.org  Wed Mar  6 19:57:49 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Wed, 6 Mar 2024 19:57:49 GMT
Subject: Integrated: 8326718: Test java/util/Formatter/Padding.java should
 timeout on large inputs before fix in JDK-8299677
In-Reply-To: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
References: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
Message-ID: <v6gDQQG1UmXirs58KvQDPmkCxI3VefuPha50bGvAc6w=.8ac46d2f-610e-422a-b7c1-c09dde1be112@github.com>

On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after.
> 
> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent.

This pull request has now been integrated.

Changeset: 4f336085
Author:    Chad Rakoczy <chadrako at amazon.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f336085d1098e7fba7b58f0a73c028179a2a13d
Stats:     41 lines in 1 file changed: 39 ins; 0 del; 2 mod

8326718: Test java/util/Formatter/Padding.java should timeout on large inputs before fix in JDK-8299677

Reviewed-by: rgiulietti

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

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

From darcy at openjdk.org  Wed Mar  6 20:49:55 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Mar 2024 20:49:55 GMT
Subject: RFR: JDK-8327487: Further augment WorstCaseTests with more cases
 [v2]
In-Reply-To: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
References: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
Message-ID: <xhxbP_hqaoheV5zsDJ2l5voSX4VJ0nWquvmKX6Xy0bg=.8e8091bf-9fab-4b67-aa2d-c59e694420a1@github.com>

> The atan2 and hypot cases added would fail for a particular test library that has errors in the millions of ulps for those inputs, rather than the small number of ulps specified for the error.

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

  Remove unneeded lines.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18140/files
  - new: https://git.openjdk.org/jdk/pull/18140/files/3aba735c..6b2d7870

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

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

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

From jlahoda at openjdk.org  Wed Mar  6 21:16:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Mar 2024 21:16:25 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v3]
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

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

 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
 - Reflecting review feedback.
 - Updating copyright headers.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18106/files
  - new: https://git.openjdk.org/jdk/pull/18106/files/6127044d..e30e4529

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

  Stats: 36 lines in 9 files changed: 11 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18106.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18106/head:pull/18106

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

From jlahoda at openjdk.org  Wed Mar  6 21:25:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Mar 2024 21:25:00 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
Message-ID: <N8fFio6sYBUPAleJmOsMnImlJNVyrxsMvnNqtiUzXaA=.dba56111-be6f-4b13-a996-3b1acd626a19@github.com>

On Tue, 5 Mar 2024 18:54:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda 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>
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/ModuleLayer.java line 896:
> 
>> 894:         return nameToModule.get(name);
>> 895:     }
>> 896: 
> 
> What would you think about replacing this with addEnableNativeAccess(String name) so it can be called by JLA. addEnableNativeAccess. The reason is that the JLA methods are usually just calls to some non-public method but the changes mean mean there is "core" in the JLA method that is not easy to find.

I've tried to that here:
https://github.com/openjdk/jdk/pull/18106/commits/e17cd3722724cbc6aa298f7b789c6574554af6ea

> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 812:
> 
>> 810:     }
>> 811: 
>> 812:     private static void addEnableNativeAccess(ModuleLayer layer, Set<String> moduleNames, boolean shouldWarn) {
> 
> The private methods in this class have a short comment to summarise what they do.

I've tried to add a comment here:
https://github.com/openjdk/jdk/pull/18106/commits/e17cd3722724cbc6aa298f7b789c6574554af6ea

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515171359
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515171099

From naoto at openjdk.org  Wed Mar  6 21:37:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Mar 2024 21:37:00 GMT
Subject: RFR: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
Message-ID: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>

Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

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

Commit messages:
 - initial commit

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

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

From iklam at openjdk.org  Wed Mar  6 22:07:00 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Mar 2024 22:07:00 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L
In-Reply-To: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
Message-ID: <TS2X62jd_-EuksocYXf3V_ntQHZMMBWB3ON4Mb4PXjc=.e1f404e4-4c4e-468e-999e-9413f00805a7@github.com>

On Wed, 21 Feb 2024 19:10:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> To avoid the CDS dump error message, a fix is during dumping a classlist, check if an invoker can be archived. 
> If not, don't write the invoker info into the classlist, i.e. don't call `logLambdaFormInvoker()`. While generating holder classes (in `generateHolderClasses()`), don't add the `MethodType` to the `invokerTypes` if will fail the check in the `build()` method which would result in a `RuntimeException`.
> 
> Also updated the `MethodHandlesInvokersTest.java` under `appcds/methodHandles` and `appcds/dynamicArchive/methodHandles` to check that the "Failed to generate LambdaForm holder classes" error is not in the output;
> 
> Passed tiers 1 - 3 testing.

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 333:

> 331:                                                     .warning("Invalid LF_RESOLVE " + parts[1] + " " + parts[2] + " " + parts[3]);
> 332:                                         }
> 333:                                     }

The underlying cause of the failure in CDS is [JDK-8327499](https://bugs.openjdk.org/browse/JDK-8327499) -- MethodHandleStatics.traceLambdaForm() includes methods that cannot be handle by GenerateJLIClassesHelper.java.

Therefore, I think the warning should always be printed (e.g., when jdk.tools.jlink.internal.plugins.GenerateJLIClassesPlugin is used during the JDK build).

Also, maybe add a comment above line 326: 


// Work around JDK-8327499

src/java.base/share/classes/jdk/internal/misc/CDS.java line 127:

> 125:      */
> 126:     public static void traceLambdaFormInvoker(String prefix, String holder, String name, String type, MethodType mt) {
> 127:         if (isDumpingClassList && isInvokerArchivable(mt, holder)) {

Is this check still needed after you added the filtering in GenerateJLIClassesHelper.java?

Since the logic here is not 100% the same as the logic in GenerateJLIClassesHelper.java, we might be filtering more things than necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17953#discussion_r1515211752
PR Review Comment: https://git.openjdk.org/jdk/pull/17953#discussion_r1515214286

From iklam at openjdk.org  Wed Mar  6 22:23:05 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Mar 2024 22:23:05 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v2]
In-Reply-To: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
Message-ID: <dLOt-hmX4w7I5tLGkQboFJohh0Q1gQMPmr4Bjcpr7dM=.7ccd61fe-ab29-4c77-9748-6967fcfaaf36@github.com>

> A few clean ups:
> 
> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
> 
> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
> 
> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
> 
> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
> 
> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.

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

  fixed alignments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18095/files
  - new: https://git.openjdk.org/jdk/pull/18095/files/78e828de..ae0e0acc

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

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

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

From iklam at openjdk.org  Wed Mar  6 22:23:05 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Mar 2024 22:23:05 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v2]
In-Reply-To: <K1GEAZ9rkpnAiiKMor77osGRBYUZMnM_2uUySAHoDlc=.271aeb1b-7cf1-4a62-8923-0c1979fccf40@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <K1GEAZ9rkpnAiiKMor77osGRBYUZMnM_2uUySAHoDlc=.271aeb1b-7cf1-4a62-8923-0c1979fccf40@github.com>
Message-ID: <dbEfmW32eov7TMXNuX9h0g2ClP5r5C6FLgy4n_mUmxE=.f003216b-d84d-497b-8c4b-4abeeccfb89f@github.com>

On Wed, 6 Mar 2024 18:42:01 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed alignments
>
> src/hotspot/share/cds/cdsConfig.hpp line 72:
> 
>> 70:   static void  enable_dumping_dynamic_archive()              { CDS_ONLY(_is_dumping_dynamic_archive = true); }
>> 71:   static void disable_dumping_dynamic_archive()              { CDS_ONLY(_is_dumping_dynamic_archive = false); }
>> 72:   static bool      is_using_archive()                        NOT_CDS_RETURN_(false);
> 
> Could you fix the alignment of the method names here?

Since several people are confused by the alignment style (align same words to the right), I fixed the grouping of the functions so that the text is aligned to the left, as in most header files.

Please take a look at [ae0e0ac](https://github.com/openjdk/jdk/pull/18095/commits/ae0e0acc72bcf1bba81dc4218a64766eb2f2549a) -- it's best viewed on GutHub with white spaces hidden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1515229517

From vklang at openjdk.org  Wed Mar  6 23:05:01 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 6 Mar 2024 23:05:01 GMT
Subject: RFR: 8327501: Common ForkJoinPool prevents class unloading in some
 cases
Message-ID: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>

creating threads in the common ForkJoinPool preventing class unloading. This fix avoids that when no SecurityManager is configured.

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

Commit messages:
 - Addresses a capture of AccessControlContext when

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

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

From jlu at openjdk.org  Wed Mar  6 23:06:51 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 6 Mar 2024 23:06:51 GMT
Subject: RFR: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
In-Reply-To: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
References: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
Message-ID: <Aq7Q9WbtpSA9f4t1QAAc2rMhxut3PKQ3PJBzGu-kV1s=.25f65a9f-7bc0-4bfd-868c-fe9bf714570b@github.com>

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

Solution makes sense, LGTM

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18143#pullrequestreview-1921004473

From rriggs at openjdk.org  Wed Mar  6 23:10:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Mar 2024 23:10:53 GMT
Subject: RFR: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
In-Reply-To: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
References: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
Message-ID: <fORsWZE79weq74parUVApKm4kKMSqfuXj-35S3x1lCs=.adec313c-bae3-466a-9d1a-17415f6e4658@github.com>

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

Looks good; will save a lot of of CI time and still cover the cases.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18143#pullrequestreview-1921008397

From bpb at openjdk.org  Wed Mar  6 23:17:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Mar 2024 23:17:56 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <fhQS5gSfJY97afRfza4rCgMmYn5PgFCn5R-0kzh9cEw=.940f0924-03be-49f0-878f-d2724c164e59@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce windows jni_util_md.h

src/java.base/unix/native/libnio/ch/Net.c line 2:

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

Is the year change needed as it looks like nothing was changed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515273416

From vklang at openjdk.org  Wed Mar  6 23:17:55 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 6 Mar 2024 23:17:55 GMT
Subject: RFR: 8327501: Common ForkJoinPool prevents class unloading in some
 cases
In-Reply-To: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
References: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
Message-ID: <zdpB2oby_KwFL93IgpKchWpKOyIjF0--SMrZOcSAD9w=.578065cb-c9d8-4298-871c-4ace56293c18@github.com>

On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> The common ForkJoinPool creating threads as a result of submitting tasks is preventing class unloading when the thread construction is initiated from a class loaded in a separate classloader. This fix avoids that when no SecurityManager is configured.

Adding @DougLea and @AlanBateman for comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/18144#issuecomment-1982015865

From viktor.klang at oracle.com  Wed Mar  6 23:19:25 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 6 Mar 2024 23:19:25 +0000
Subject: Class loader leaked when ForkJoinPool is used in loaded class,
 with Java 19+
In-Reply-To: <CACcnpz0uu6_Qeq2an_7J6fA4WB=MW1vS6_eJaJVd4rPANzB2Qg@mail.gmail.com>
References: <CACcnpz0uu6_Qeq2an_7J6fA4WB=MW1vS6_eJaJVd4rPANzB2Qg@mail.gmail.com>
Message-ID: <MW4PR10MB5774B457364B3E5F504339AFFF212@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Simeon,

Thanks for your email.

After discussing this with Doug Lea and Alan Bateman I've opened the following PR: https://github.com/openjdk/jdk/pull/18144
[https://opengraph.githubassets.com/70f2d1af34c3f8422fb6cf90cf7d15d742843422bf90a10cf4c49bf729aea656/openjdk/jdk/pull/18144]<https://github.com/openjdk/jdk/pull/18144>
8327501: Common ForkJoinPool prevents class unloading in some cases by viktorklang-ora ? Pull Request #18144 ? openjdk/jdk<https://github.com/openjdk/jdk/pull/18144>
The common ForkJoinPool creating threads as a result of submitting tasks is preventing class unloading when the thread construction is initiated from a class loaded in a separate classloader. This ...
github.com


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of S A <simeon.danailov.andreev at gmail.com>
Sent: Monday, 4 March 2024 13:23
To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Subject: Class loader leaked when ForkJoinPool is used in loaded class, with Java 19+

Hi all,

after moving our application to Java 21 (up from Java 17), we noticed a class loader leak. A memory snapshot points to a ProtectionDomain object held by a ForkJoinWorkerThread, the protection domain holds the class loader and prevents GC.

To reproduce outside of our application, we use this snippet:

import java.lang.ref.WeakReference;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.nio.file.Paths;
public class TestClassloaderLeak {
    public static void main(String[] args) throws Exception {
        WeakReference<Object> wr = load();
        gc();
        System.out.println("wr=" + wr.get());
    }
    private static void gc() {
        System.gc();
        System.runFinalization();
    }
    private static WeakReference<Object> load() throws Exception {
        URLClassLoader cl = new URLClassLoader(new URL[] { url() }, TestClassloaderLeak.class.getClassLoader());
        WeakReference<Object> wr = new WeakReference<>(cl);
        Class<?> ca = cl.loadClass("A");
        ca.getConstructor(String.class).newInstance("A");
        cl.close();
        return wr;
    }
    private static URL url() throws MalformedURLException {
        return Paths.get("/data/tmp/testleak/lib/").toUri().toURL();
    }
}

import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.ForkJoinTask;
public class A {
    public final String s;
    public A(String s) {
        this.s = s;
        ForkJoinTask<?> task = ForkJoinPool.commonPool().submit(() -> { System.out.println("A constructor"); });
        try {
            task.get();
        } catch (Exception e) {
            e.printStackTrace(System.out);
        }
    }
}

Place the compiled A.class at the hard-coded location "/data/tmp/testleak/lib/", then run the main method with JVM flags "-Xlog:class+unload". Observe that no class is unloaded, which is not the case if the main() code runs twice, or if the snippet is executed e.g. with Java 17.

It seems each time ForkJoinPool creates a new ForkJoinWorkerThread from a loaded class, it is no longer possible to GC the class loader of the class using ForkJoinPool.

The leak occurs after this commit, with Java 19+:

https://github.com/openjdk/jdk19u/commit/00e6c63cd12e3f92d0c1d007aab4f74915616ffb

Essentially, our application loads and runs user code. The user changes their code, runs their code again - we use a new class loader to run the changed code in the same JVM. We unload the previous class loader, to free up memory and to avoid problems with hot swapping code (an old version of a loaded class can cause an error when trying to hot swap the latest loaded version of that class). So the leaked class loader is giving us trouble.

What possible workarounds can we use to avoid this problem?

Best regards and thanks,
Simeon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240306/e747dac1/attachment-0001.htm>

From iklam at openjdk.org  Wed Mar  6 23:36:09 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Mar 2024 23:36:09 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v3]
In-Reply-To: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
Message-ID: <cE9s-ZP_WHLA_fEe2GiLf_eCpTpkj076CmRyw9596vo=.94c1577d-2748-4e52-9747-cb596e538e8e@github.com>

> A few clean ups:
> 
> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
> 
> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
> 
> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
> 
> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
> 
> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.

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

  more alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18095/files
  - new: https://git.openjdk.org/jdk/pull/18095/files/ae0e0acc..5a28f865

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

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

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

From dl at openjdk.org  Wed Mar  6 23:39:54 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 6 Mar 2024 23:39:54 GMT
Subject: RFR: 8327501: Common ForkJoinPool prevents class unloading in some
 cases
In-Reply-To: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
References: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
Message-ID: <RlKImXXLK_6NkLyfB6WNZri_pE9irboncgVsnO00r0I=.9fec2508-bccc-4d37-b58a-d8bf122d9525@github.com>

On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> The common ForkJoinPool creating threads as a result of submitting tasks is preventing class unloading when the thread construction is initiated from a class loaded in a separate classloader. This fix avoids that when no SecurityManager is configured.

Yes, this seems like the simplest practical solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/18144#issuecomment-1982042229

From iris at openjdk.org  Wed Mar  6 23:39:54 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 6 Mar 2024 23:39:54 GMT
Subject: RFR: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
In-Reply-To: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
References: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
Message-ID: <333BLYvYF_WIN_sYOxnxVpqcSYjgvigSL-8iG5qfjbk=.40deba36-4111-4b8d-925e-b6b4d31c095b@github.com>

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18143#pullrequestreview-1921039503

From naoto at openjdk.org  Thu Mar  7 00:54:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Mar 2024 00:54:57 GMT
Subject: Integrated: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
In-Reply-To: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
References: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
Message-ID: <xxi5VGZa8qUDHK8oOk97fz7MzIl7LZ8Nj6AHc4Pvfeg=.b156cfb6-4639-4b27-9c7a-0f3401bcb2e5@github.com>

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

This pull request has now been integrated.

Changeset: 1bd4abf9
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bd4abf98e26d04076f330c0b2e44f666f8c27a1
Stats:     6 lines in 1 file changed: 2 ins; 1 del; 3 mod

8327434: Test java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out

Reviewed-by: jlu, rriggs, iris

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

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

From gli at openjdk.org  Thu Mar  7 03:02:57 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 7 Mar 2024 03:02:57 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce windows jni_util_md.h

src/java.base/aix/native/libnio/ch/Pollset.c line 3:

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

It seems you only need to update the copyright of the company you work for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515417217

From vpetko at openjdk.org  Thu Mar  7 03:34:52 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 7 Mar 2024 03:34:52 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <i7eZH9jfhDL8IK0csTae_jRmR_uVJK7Kvzp1JmE_-SM=.c10e7a7d-1bde-458b-9aab-1a4cbe4f8f63@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <Wh7mlhwLnhoh9J1ajGDFA9OBC2D39OlPpMLlWP4G08M=.1eb79fb0-240e-4c6a-9188-46bcc4cdb54b@github.com>
 <SQzEN8LebbOLvzKUKF5Om3ZZtu1QSdclvpE3q33znNE=.8572807b-1156-44db-b98a-eabc52867c9f@github.com>
 <i7eZH9jfhDL8IK0csTae_jRmR_uVJK7Kvzp1JmE_-SM=.c10e7a7d-1bde-458b-9aab-1a4cbe4f8f63@github.com>
Message-ID: <PPySNDHwLqgvfP310kO787mIzhOMWCIREM-UHd_5b6Q=.dfea6455-398a-48e4-b3b4-5fb51645c83d@github.com>

On Wed, 6 Mar 2024 09:26:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> ```
>   Process p = ProcessTools.startProcess(...);
>   OutputAnalyzer oa = new OutputAnalyzer(p);
>   oa.shouldNotHaveExitValue(0);
>   oa.shouldContain("This command is not for general use");
> ```
Thank you! This shortens things quite a bit[1]

[1] https://github.com/openjdk/jdk/commit/bb65fc8551ae759df88171463445ecdb9676eed3

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

PR Comment: https://git.openjdk.org/jdk/pull/18112#issuecomment-1982286476

From gli at openjdk.org  Thu Mar  7 03:47:55 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 7 Mar 2024 03:47:55 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value
In-Reply-To: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
Message-ID: <80OlKGK7mF8Oyn1YZ9GrDDcnM7DUnO8gfNgl9hlz5NI=.f033ecf1-783f-4f6b-a700-b147ccfff3d1@github.com>

On Wed, 6 Mar 2024 18:26: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.

Good caught. A trivial suggestion.

test/jdk/java/util/Collections/CheckedMapBash.java line 192:

> 190:             Map m = Collections.checkedMap(new HashMap<>(), Integer.class, Integer.class);
> 191:             m.merge("key", "value", (v1, v2) -> null);
> 192:             m.merge("key", 3, (v1, v2) -> v2);

May be better to seperate these two cases into two tests. Because if the first case fails, the latter can't be verified now.

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

Changes requested by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18141#pullrequestreview-1921381700
PR Review Comment: https://git.openjdk.org/jdk/pull/18141#discussion_r1515457837

From duke at openjdk.org  Thu Mar  7 04:13:17 2024
From: duke at openjdk.org (Korov)
Date: Thu, 7 Mar 2024 04:13:17 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v2]
In-Reply-To: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
Message-ID: <AUhQhA1PCVd6m59j9YVJWJAlhxDphzullVYURxhqP_Y=.d548cedd-eafc-48c1-98dd-cb96e95299b4@github.com>

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

  modify the code based on the review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18141/files
  - new: https://git.openjdk.org/jdk/pull/18141/files/aac03cfc..14827cf3

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

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

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

From duke at openjdk.org  Thu Mar  7 04:19:53 2024
From: duke at openjdk.org (Korov)
Date: Thu, 7 Mar 2024 04:19:53 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v2]
In-Reply-To: <80OlKGK7mF8Oyn1YZ9GrDDcnM7DUnO8gfNgl9hlz5NI=.f033ecf1-783f-4f6b-a700-b147ccfff3d1@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <80OlKGK7mF8Oyn1YZ9GrDDcnM7DUnO8gfNgl9hlz5NI=.f033ecf1-783f-4f6b-a700-b147ccfff3d1@github.com>
Message-ID: <-t2rRLcdUpBumD7rTuJuhxdGVa5Qsy9tWbcbphVFj9s=.65610bc5-ca1e-4c43-8861-5058ae82dee9@github.com>

On Thu, 7 Mar 2024 03:44:55 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Good caught. A trivial suggestion.

Thanks for your suggestion, the code has been modified.

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

PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-1982318659

From liach at openjdk.org  Thu Mar  7 04:39:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 7 Mar 2024 04:39:53 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v2]
In-Reply-To: <AUhQhA1PCVd6m59j9YVJWJAlhxDphzullVYURxhqP_Y=.d548cedd-eafc-48c1-98dd-cb96e95299b4@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <AUhQhA1PCVd6m59j9YVJWJAlhxDphzullVYURxhqP_Y=.d548cedd-eafc-48c1-98dd-cb96e95299b4@github.com>
Message-ID: <PySf1KbvVs31JuMJe0w3J1MgVFMdMd5Hf9o-UpCtDtE=.376084db-9a59-4f91-b80e-4f85b505090a@github.com>

On Thu, 7 Mar 2024 04:13:17 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:
> 
>   modify the code based on the review

test/jdk/java/util/Collections/CheckedMapBash.java line 193:

> 191:             m.merge("key", "value", (v1, v2) -> null);
> 192:             fail("Should throw ClassCastException");
> 193:         } catch (ClassCastException ignore) {

Since this test is already running with testNG, we should just use its builtin functionalities:

    @Test(groups = "type_check")
    public static void testTypeCheck() {
        Map m = Collections.checkedMap(new HashMap<>(), Integer.class, Integer.class);
        Assert.assertThrows(ClassCastException.class, () -> m.merge("key", "value", (v1, v2) -> null));
        Assert.assertThrows(ClassCastException.class, () -> m.merge("key", 3, (v1, v2) -> v2));
    }


In addition, the checked map tests are in general, only checking the map functionality works without checking if the type checking functionality works. But adding a comprehensive test for checking functionalites would be much more work and is out of this patch's scope, so you don't need to worry about it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18141#discussion_r1515507158

From duke at openjdk.org  Thu Mar  7 05:33:16 2024
From: duke at openjdk.org (Korov)
Date: Thu, 7 Mar 2024 05:33:16 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v3]
In-Reply-To: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
Message-ID: <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18141/files
  - new: https://git.openjdk.org/jdk/pull/18141/files/14827cf3..98980106

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

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

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

From duke at openjdk.org  Thu Mar  7 05:35:53 2024
From: duke at openjdk.org (Korov)
Date: Thu, 7 Mar 2024 05:35:53 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v2]
In-Reply-To: <PySf1KbvVs31JuMJe0w3J1MgVFMdMd5Hf9o-UpCtDtE=.376084db-9a59-4f91-b80e-4f85b505090a@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <AUhQhA1PCVd6m59j9YVJWJAlhxDphzullVYURxhqP_Y=.d548cedd-eafc-48c1-98dd-cb96e95299b4@github.com>
 <PySf1KbvVs31JuMJe0w3J1MgVFMdMd5Hf9o-UpCtDtE=.376084db-9a59-4f91-b80e-4f85b505090a@github.com>
Message-ID: <NbboNIUwRbFsbXEak83hhcuVdMGzIMXBYiOeU2MpoBQ=.8218ef22-8f80-4e1a-b242-b1ce2a864997@github.com>

On Thu, 7 Mar 2024 04:37:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Korov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify the code based on the review
>
> test/jdk/java/util/Collections/CheckedMapBash.java line 193:
> 
>> 191:             m.merge("key", "value", (v1, v2) -> null);
>> 192:             fail("Should throw ClassCastException");
>> 193:         } catch (ClassCastException ignore) {
> 
> Since this test is already running with testNG, we should just use its builtin functionalities:
> 
>     @Test(groups = "type_check")
>     public static void testTypeCheck() {
>         Map m = Collections.checkedMap(new HashMap<>(), Integer.class, Integer.class);
>         Assert.assertThrows(ClassCastException.class, () -> m.merge("key", "value", (v1, v2) -> null));
>         Assert.assertThrows(ClassCastException.class, () -> m.merge("key", 3, (v1, v2) -> v2));
>     }
> 
> 
> In addition, the checked map tests are in general, only checking the map functionality works without checking if the type checking functionality works. But adding a comprehensive test for checking functionalites would be much more work and is out of this patch's scope, so you don't need to worry about it.

Thank you very much for informing me about these things. I have modified the test function name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18141#discussion_r1515562837

From gli at openjdk.org  Thu Mar  7 05:50:52 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 7 Mar 2024 05:50:52 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: <SMV7h_o1ItEr_Wy46w9_gBu1VtUS_oV-HmcGb7uQpS0=.60ec877e-947d-43e9-b575-06d9e8cfa82c@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

Looks good.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18141#pullrequestreview-1921495029

From dholmes at openjdk.org  Thu Mar  7 06:57:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 06:57:56 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v3]
In-Reply-To: <cE9s-ZP_WHLA_fEe2GiLf_eCpTpkj076CmRyw9596vo=.94c1577d-2748-4e52-9747-cb596e538e8e@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <cE9s-ZP_WHLA_fEe2GiLf_eCpTpkj076CmRyw9596vo=.94c1577d-2748-4e52-9747-cb596e538e8e@github.com>
Message-ID: <dHvicly-47AmTgp80WJmWgF3FlSUFqI9gxBaCchbAY4=.cb27421a-d433-4664-8537-47edd6506ffa@github.com>

On Wed, 6 Mar 2024 23:36:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A few clean ups:
>> 
>> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
>> 
>> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
>> 
>> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
>> 
>> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
>> 
>> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more alignment

Some drive-by nits. (But copyright needs fixing.)

src/hotspot/share/cds/cdsConfig.cpp line 2:

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

Incorrect copyright update - should be "2023, 2024,"

src/hotspot/share/cds/cdsConfig.cpp line 54:

> 52:          (is_dumping_static_archive()        ? IS_DUMPING_STATIC_ARCHIVE : 0) |
> 53:          (is_logging_lambda_form_invokers()  ? IS_LOGGING_LAMBDA_FORM_INVOKERS : 0) |
> 54:          (is_using_archive()                 ? IS_USING_ARCHIVE : 0);

You can remove one space before the ? in each line

src/hotspot/share/cds/cdsConfig.hpp line 56:

> 54:   static const int IS_DUMPING_STATIC_ARCHIVE              = 1 << 1;
> 55:   static const int IS_LOGGING_LAMBDA_FORM_INVOKERS        = 1 << 2;
> 56:   static const int IS_USING_ARCHIVE                       = 1 << 3;

why is the = sign so far away?

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

PR Review: https://git.openjdk.org/jdk/pull/18095#pullrequestreview-1921571088
PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1515626568
PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1515628561
PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1515629728

From dholmes at openjdk.org  Thu Mar  7 07:22:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 07:22:54 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
Message-ID: <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>

On Thu, 7 Mar 2024 03:00:11 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce windows jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2024, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2012, 2024 SAP SE. All rights reserved.
> 
> It seems you only need to update the copyright of the company you work for.

Oracle requests/requires that the Oracle copyright always be updated when a file is modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515660944

From gli at openjdk.org  Thu Mar  7 07:32:53 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 7 Mar 2024 07:32:53 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
 <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>
Message-ID: <3Oc7Dtnp_h7ivbUNx3RvJI1ltC3elMhB6V8Jijp2k_0=.d3081a47-6f3b-4051-8baa-a7254be58293@github.com>

On Thu, 7 Mar 2024 07:20:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Oracle requests/requires that the Oracle copyright always be updated when a file is modified.

Got it. Thanks for your explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515672685

From alanb at openjdk.org  Thu Mar  7 08:11:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 08:11:05 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce windows jni_util_md.h

Latest version looks good to me. As have been pointed out, there at least 2 files where the copyright header was updated but there are no changes, I assume left over from previous iterations. I assume the RESTARTABLE-close in libattach/VirtualMachineImpl.c will be tracked as a separate issue.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1921724534

From mbaesken at openjdk.org  Thu Mar  7 08:16:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Mar 2024 08:16:26 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
Message-ID: <9srUL7ZFMpINp-3Ub6V1mN5RYsiwkPxsQZnET_9sBVk=.3a051bf1-cc2f-47cb-b2f3-d220f32a91ce@github.com>

On Wed, 6 Mar 2024 17:14:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce windows jni_util_md.h
>
> src/java.base/share/native/libjava/jni_util.h line 30:
> 
>> 28: 
>> 29: #include "jni.h"
>> 30: #include "jni_util_md.h"
> 
> This file needs copyright year update

Agree, updated !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515719458

From mbaesken at openjdk.org  Thu Mar  7 08:16:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Mar 2024 08:16:26 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

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

  adjust COPYRIGHT year info

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18132/files
  - new: https://git.openjdk.org/jdk/pull/18132/files/2930075d..25a65a71

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

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

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

From mbaesken at openjdk.org  Thu Mar  7 08:16:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Mar 2024 08:16:26 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
Message-ID: <5LGbdPzlc3oIQ3TGaN5iglmGa5MCt5YnJzLvE7KUu6s=.b2a22f10-8331-4f15-8a2d-affbef828876@github.com>

On Wed, 6 Mar 2024 17:16:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust COPYRIGHT year info
>
> src/java.base/unix/native/libjava/childproc.h line 75:
> 
>> 73: #define FAIL_FILENO (STDERR_FILENO + 1)
>> 74: 
>> 75: /* TODO: Refactor. */
> 
> Copyright year update missing.

Thanks, I updated this too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515719859

From alanb at openjdk.org  Thu Mar  7 08:19:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 08:19:52 GMT
Subject: RFR: 8327501: Common ForkJoinPool prevents class unloading in some
 cases
In-Reply-To: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
References: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
Message-ID: <fCdK4G9EZKV6RXrdfctw1hNFXTcYT2tfo6c_5vcWH2I=.d75ce8f2-0e3b-4b5f-81e7-f60bb207d74f@github.com>

On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> The common ForkJoinPool creating threads as a result of submitting tasks is preventing class unloading when the thread construction is initiated from a class loaded in a separate classloader. This fix avoids that when no SecurityManager is configured.

Marked as reviewed by alanb (Reviewer).

The inherited access control context bites again. Creating a Thread takes a snapshot of the caller context which can include several protection domains. In the bug report it includes a ProtectionDomain for a custom class loader. The good news is that removal of the security manager mode of execution means that this can go away.

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

PR Review: https://git.openjdk.org/jdk/pull/18144#pullrequestreview-1921749299
PR Comment: https://git.openjdk.org/jdk/pull/18144#issuecomment-1982882897

From mbaesken at openjdk.org  Thu Mar  7 08:54:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Mar 2024 08:54:54 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>
Message-ID: <YhcFIomZE7c7bxw3SqUp2wOkKUZOBq1CnJriSGgjcFg=.dfa9f18c-51f3-47e1-b88c-caabbe2d7a3f@github.com>

On Thu, 7 Mar 2024 08:08:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Latest version looks good to me. As have been pointed out, there at least 2 files where the copyright header was updated but there are no changes, I assume left over from previous iterations. I assume the RESTARTABLE-close in libattach/VirtualMachineImpl.c will be tracked as a separate issue.


Yes  this was from the commit iterations.
The RESTARTABLE-close issue will be tracked here 
https://bugs.openjdk.org/browse/JDK-8327468
8327468: Do not restart close if errno is EINTR [macOS/linux]

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18132#issuecomment-1982996784

From alanb at openjdk.org  Thu Mar  7 09:36:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 09:36:54 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v3]
In-Reply-To: <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
Message-ID: <bRjHFpQGmLDFi0kRP_ciClevcZZ1QfvRdCjaqiP3nLw=.57aad825-beca-401e-af14-87a641fb756c@github.com>

On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
>  - Reflecting review feedback.
>  - Updating copyright headers.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/lang/ModuleLayer.java line 891:

> 889:      *         {@code false} otherwise
> 890:      */
> 891:     boolean addEnableNativeAccess(String name) {

Do you mind changing the method description to "Updates the module with the given name in this layer to allow access to restricted methods"? This will be keep it more consistent with the exiting methods.

Also "was present" in the return description hints that it may not now be present. A module layer is immutable so it can just say that it returns true if the  module is in this layer.

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

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1921919290
PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515834537

From alanb at openjdk.org  Thu Mar  7 09:36:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 09:36:55 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v2]
In-Reply-To: <N8fFio6sYBUPAleJmOsMnImlJNVyrxsMvnNqtiUzXaA=.dba56111-be6f-4b13-a996-3b1acd626a19@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pSiXCwFqzkCjO5S-QwYfSHosZLADoJUSj0AOT1_lx6k=.2f13cadf-8a8a-416b-acb0-6ed0a16edd4f@github.com>
 <efAyOJAlCc_jPFgwtJnn_OsHy-4JRGdMOvC3oGug7j4=.61ef5326-c9b3-487b-bd1d-c9a9b49f74ba@github.com>
 <N8fFio6sYBUPAleJmOsMnImlJNVyrxsMvnNqtiUzXaA=.dba56111-be6f-4b13-a996-3b1acd626a19@github.com>
Message-ID: <dtV1dHFyE5Reo9dkH7Z82kUZsNYtflxITZL0sexuQvQ=.5cd0ce0e-3acd-4ae5-bbbe-d0e79d3a3ed8@github.com>

On Wed, 6 Mar 2024 21:22:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 812:
>> 
>>> 810:     }
>>> 811: 
>>> 812:     private static void addEnableNativeAccess(ModuleLayer layer, Set<String> moduleNames, boolean shouldWarn) {
>> 
>> The private methods in this class have a short comment to summarise what they do.
>
> I've tried to add a comment here:
> https://github.com/openjdk/jdk/pull/18106/commits/e17cd3722724cbc6aa298f7b789c6574554af6ea

Thanks. I view these changes to ModuleBootstrap to be temporary. We'll need to create a few follow on issues in JBS, one of which is to update jlink so that we have the exact set of modules in the run-time image that have been granted native access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1515838474

From vklang at openjdk.org  Thu Mar  7 09:46:59 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 7 Mar 2024 09:46:59 GMT
Subject: Integrated: 8327501: Common ForkJoinPool prevents class unloading in
 some cases
In-Reply-To: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
References: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
Message-ID: <yNcDKxs2_J3xZ3_im3R4D-tOo_C_Qe_GuI8Z1E_pncM=.f8bf5af4-bff9-46f2-84b5-15bb45d6acc1@github.com>

On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> The common ForkJoinPool creating threads as a result of submitting tasks is preventing class unloading when the thread construction is initiated from a class loaded in a separate classloader. This fix avoids that when no SecurityManager is configured.

This pull request has now been integrated.

Changeset: 53c4714a
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53c4714aab2e072ba18631875dcaa3b2d5d22243
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

8327501: Common ForkJoinPool prevents class unloading in some cases

Reviewed-by: alanb

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

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

From clanger at openjdk.org  Thu Mar  7 09:48:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 7 Mar 2024 09:48:56 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <okOd6cZT8f3vs6OvAfShpYuA_m1jny4FP-pNRjFJBDY=.d45787d7-5344-4d08-bb9a-19f1645526fd@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust COPYRIGHT year info

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1921955570

From dfuchs at openjdk.org  Thu Mar  7 10:12:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 7 Mar 2024 10:12:55 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
 <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
 <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>
Message-ID: <o903TWvm-n5rqeKURwyNYxtab9UPMSrTwyMUgLWBk-A=.31cb42ae-4aa2-43fc-bb4e-27b00b6ba891@github.com>

On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> 
>> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
>> https://github.com/openjdk/jdk/pull/18025 )
>> 
>> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
>> 
>> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.
>
> I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.
> 
> I?ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.
> 
> Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

Yes - the JMX implementation stores and retrieve subjects in the AccessControlContext and then uses doPrivileged. Subject.doAs is not used in the JMX implementation.

There are two different uses of Subject in JMX: 

1. one is a simplified role-based authentication/authorization at the default agent level. 
2. The other one is a permission check where different subjects can be granted different privileges in the policy file. 

The latter will go away since the SM is going away, but needs to be preserved until then.
The former we want to keep and needs to keep working (by changing the code to use callAs) even after the SM is gone.

Subject delegation allows an authenticated subject (1. above) to perform actions on behalf of a delegation subject, where the privileged granted by 2. are the intersection of the privileges of the two subjects.
@kevinjwalls is currently working on removing subject delegation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1515896397

From vklang at openjdk.org  Thu Mar  7 10:24:18 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 7 Mar 2024 10:24:18 GMT
Subject: RFR: 8269428: java/util/concurrent/ConcurrentHashMap/ToArray.java
 timed out [v2]
In-Reply-To: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
References: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
Message-ID: <ZNBvjDRpRdz8Bq0wcwJpHk3r9Rp84IHZaywQWwZP-Jk=.d5ac3f5c-887b-47b9-a791-4fa0c0a7a91d@github.com>

> As an intermediate fix to the test, switching to explicit usage of an ExecutorService seems to do the trick to make this test reliably pass.
> 
> With that said, this test (CHM::ToArray.java) seems to trigger an issue in ForkJoinPool, so that would need to be fixed separately.
> 
> Tagging @DougLea as an FYI. :)

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

  Updating copyright year of CHM/ToArray.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18023/files
  - new: https://git.openjdk.org/jdk/pull/18023/files/1426b837..a073256a

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

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

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

From jpai at openjdk.org  Thu Mar  7 10:24:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Mar 2024 10:24:18 GMT
Subject: RFR: 8269428: java/util/concurrent/ConcurrentHashMap/ToArray.java
 timed out [v2]
In-Reply-To: <ZNBvjDRpRdz8Bq0wcwJpHk3r9Rp84IHZaywQWwZP-Jk=.d5ac3f5c-887b-47b9-a791-4fa0c0a7a91d@github.com>
References: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
 <ZNBvjDRpRdz8Bq0wcwJpHk3r9Rp84IHZaywQWwZP-Jk=.d5ac3f5c-887b-47b9-a791-4fa0c0a7a91d@github.com>
Message-ID: <p9kCOg5tbTgHpBPiv5TjKzzL3ciuzKQkqEqDjy9mg3k=.ba9875b7-f2c0-4d27-a4da-03d0f76e1181@github.com>

On Thu, 7 Mar 2024 10:20:55 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> As an intermediate fix to the test, switching to explicit usage of an ExecutorService seems to do the trick to make this test reliably pass.
>> 
>> With that said, this test (CHM::ToArray.java) seems to trigger an issue in ForkJoinPool, so that would need to be fixed separately.
>> 
>> Tagging @DougLea as an FYI. :)
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year of CHM/ToArray.java

The intention of this `ToArray` as noted in the summary of this test is to verify the thread safety of the `toArray()` methods of collection views. As noted in the JBS issue, the reason why this test keeps timing out intermittently appears to be an issue in the `ForkJoinPool` and thus those timeouts aren't exposing any issues within `toArray()` implementations itself. So it seems fine that we are switching over to using a thread pool that doesn't exhibit those issues.

This proposed change looks good to me. Since Doug has already approved this too, I will go ahead and officially mark this as reviewed.

Before integrating, please update the copyright year on this file.

Marked as reviewed by jpai (Reviewer).

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18023#pullrequestreview-1922028143
PR Review: https://git.openjdk.org/jdk/pull/18023#pullrequestreview-1922040153

From jpai at openjdk.org  Thu Mar  7 10:24:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Mar 2024 10:24:18 GMT
Subject: RFR: 8269428: java/util/concurrent/ConcurrentHashMap/ToArray.java
 timed out
In-Reply-To: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
References: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
Message-ID: <6JWhiEVCkF-CDb1c5l9SR2EGNMt3hsKA8ClpigNBM48=.654840be-1078-46b8-8df4-519df46b7f8e@github.com>

On Tue, 27 Feb 2024 10:30:44 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> As an intermediate fix to the test, switching to explicit usage of an ExecutorService seems to do the trick to make this test reliably pass.
> 
> With that said, this test (CHM::ToArray.java) seems to trigger an issue in ForkJoinPool, so that would need to be fixed separately.
> 
> Tagging @DougLea as an FYI. :)

Hello Viktor, Doug,

> failures due to unrelated FJP and/or GC issues (for which it may be better to develop a separate test).

Since the test has (unintentionally) exposed an issue within the ForkJoinPool, should we open a separate issue to track that (or do we already have one)?

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

PR Comment: https://git.openjdk.org/jdk/pull/18023#issuecomment-1983186827

From vklang at openjdk.org  Thu Mar  7 10:24:18 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 7 Mar 2024 10:24:18 GMT
Subject: RFR: 8269428: java/util/concurrent/ConcurrentHashMap/ToArray.java
 timed out
In-Reply-To: <6JWhiEVCkF-CDb1c5l9SR2EGNMt3hsKA8ClpigNBM48=.654840be-1078-46b8-8df4-519df46b7f8e@github.com>
References: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
 <6JWhiEVCkF-CDb1c5l9SR2EGNMt3hsKA8ClpigNBM48=.654840be-1078-46b8-8df4-519df46b7f8e@github.com>
Message-ID: <4VTig85zjJGlwVaOkKXPIHP8z_tplCFxPJchAscunq0=.64be3fb4-2658-4860-b30b-c7bc56fd148f@github.com>

On Thu, 7 Mar 2024 10:15:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> As an intermediate fix to the test, switching to explicit usage of an ExecutorService seems to do the trick to make this test reliably pass.
>> 
>> With that said, this test (CHM::ToArray.java) seems to trigger an issue in ForkJoinPool, so that would need to be fixed separately.
>> 
>> Tagging @DougLea as an FYI. :)
>
> Hello Viktor, Doug,
> 
>> failures due to unrelated FJP and/or GC issues (for which it may be better to develop a separate test).
> 
> Since the test has (unintentionally) exposed an issue within the ForkJoinPool, should we open a separate issue to track that (or do we already have one)?

Thanks @jaikiran, I have issued another commit: updating the copyright year

@jaikiran I suspect that we might already have a JBS issue which relates to the FJP bug itself, but I'll have to go find it first. I'll sync with Doug next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/18023#issuecomment-1983192724
PR Comment: https://git.openjdk.org/jdk/pull/18023#issuecomment-1983195200

From jpai at openjdk.org  Thu Mar  7 10:41:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Mar 2024 10:41:52 GMT
Subject: RFR: 8269428: java/util/concurrent/ConcurrentHashMap/ToArray.java
 timed out
In-Reply-To: <6JWhiEVCkF-CDb1c5l9SR2EGNMt3hsKA8ClpigNBM48=.654840be-1078-46b8-8df4-519df46b7f8e@github.com>
References: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
 <6JWhiEVCkF-CDb1c5l9SR2EGNMt3hsKA8ClpigNBM48=.654840be-1078-46b8-8df4-519df46b7f8e@github.com>
Message-ID: <TZ6pGJOdAT-QkHDZM7OnJJ089-3anD67QU2icbbwdQc=.5739679a-009c-496b-ad18-c8436e550dc5@github.com>

On Thu, 7 Mar 2024 10:15:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> As an intermediate fix to the test, switching to explicit usage of an ExecutorService seems to do the trick to make this test reliably pass.
>> 
>> With that said, this test (CHM::ToArray.java) seems to trigger an issue in ForkJoinPool, so that would need to be fixed separately.
>> 
>> Tagging @DougLea as an FYI. :)
>
> Hello Viktor, Doug,
> 
>> failures due to unrelated FJP and/or GC issues (for which it may be better to develop a separate test).
> 
> Since the test has (unintentionally) exposed an issue within the ForkJoinPool, should we open a separate issue to track that (or do we already have one)?

> @jaikiran I suspect that we might already have a JBS issue which relates to the FJP bug itself, but I'll have to go find it first. I'll sync with Doug next week.

Thank you - that sounds fine to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/18023#issuecomment-1983226656

From dholmes at openjdk.org  Thu Mar  7 12:06:59 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 12:06:59 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <zlGKCDnKizB8QBmTV4zoyB_Tu2sc6eAlaz8t7Wg09lc=.c3015b98-4071-48fc-85d9-d816b0945420@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust COPYRIGHT year info

LGTM. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1922263102

From duke at openjdk.org  Thu Mar  7 12:46:54 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 7 Mar 2024 12:46:54 GMT
Subject: RFR: 8327425: String Template FMT Refactor use call direct instead
 of MethodHandler
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: <02gnwm-uTZlyz8l9ZYPJTLcMFYJXUpjnmaiQUPPLMsw=.75d17f5c-186e-4425-b898-d71fd9557168@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 MethodHandler.
> 
> Please review and don't hesitate to critique my approach and patch.

It?s?`MethodHandle`, not?`MethodHandler`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16021#issuecomment-1983432845

From davidalayachew at gmail.com  Thu Mar  7 14:26:51 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 7 Mar 2024 09:26:51 -0500
Subject: Any plans to make resource leaks easier to detect?
In-Reply-To: <CAA9v-_NYVX4XXdsW6fBe5VhgR8EuYgsthN5uBua48B6Rz+WekQ@mail.gmail.com>
References: <CAA9v-_PxpOGkq1gAo3CdQyZNYq=DwCrRjL7ugjgQn39NiZNAmQ@mail.gmail.com>
 <CAA9v-_NYVX4XXdsW6fBe5VhgR8EuYgsthN5uBua48B6Rz+WekQ@mail.gmail.com>
Message-ID: <CAA9v-_MbnKcYhKbU6UG-afExMmkr-Qz+=pKBg5i-iOrUshzCJw@mail.gmail.com>

Further adding on, here is my final implementation. The folks on Code
Review also informed me, in no uncertain terms, that it was a very
problematic solution. And I agree with them. However, for all of its flaws,
at least it cannot leak due to user's forgetting a TWR.

https://codereview.stackexchange.com/questions/290912/implementation-of-java-util-stream-stream-and-friends-that-reads-lines-from-th

But of course, this is a terrible solution to deal with a non-trivial
problem -- forgetting TWR is not a compiler error/warning. Is there any
chance that we could get better compile time support for detecting resource
leaks?

On Sun, Mar 3, 2024 at 10:02?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> And as a side note, I did some pretty in-depth research on the topic, and
> stumbled on this post on the lambda mailing list during Java 8's creation.
> I am adding it, as it seems to be considering many of the same concerns I
> have now.
>
>
> https://mail.openjdk.org/pipermail/lambda-libs-spec-experts/2013-August/002195.html
>
> On Sun, Mar 3, 2024 at 10:00?PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>>
>> Hello Amber Dev Team and Core Libs Dev Team,
>>
>> I am making my own implementation of java.util.stream.Stream that reads
>> data from the internet lazily. It's basically
>> java.nio.file.Files.lines(...), but the file is on the internet instead.
>> Here is a StackOverflow post I made that basically gave birth to idea. Just
>> for context. [1]
>>
>> I used composition -- I held my resource and the stream inside of my
>> container data type. However, I also had this container data type implement
>> java.util.stream.Stream too. This way, the end user can use this object
>> exactly like a Stream.
>>
>> In my implementation, I delegated all method calls to the underlying
>> stream. But, for each terminal operation, I would wrap the delegated calls
>> with try-with-resources for my resources, to prevent resource leak upon
>> exception.
>>
>> Now, I know that this is taking an uphill path to a solution. We could
>> easily tell the user that they have to close the resources themself. Or we
>> could let the user provide their own resources and thus, leave the
>> responsibility on their plate. Or we could use the escape-hatch provided by
>> stream lol, and tell the user to use try-with-resources on my custom
>> stream. As you all intended us to do, I'm sure.
>>
>> I know the reason might seem poorly justified (StackOverflow told me as
>> much -- [1]), but I did this so that none of the users of my stream would
>> have to concern themselves doing try-with-resources. Try-with-resources is
>> an excellent utility, but I have no way to know if I left a resource
>> unclosed because there are no compiler warnings or errors if I do so.
>>
>> Are there any plans to make it easier to detect potential resource leaks?
>> Ideally with a compiler warning or error?
>>
>> Thank you for your time and help!
>> David Alayachew
>>
>> [1] = https://stackoverflow.com/questions/77959436
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240307/6ba2b2d9/attachment.htm>

From acobbs at openjdk.org  Thu Mar  7 15:56:28 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 7 Mar 2024 15:56:28 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v7]
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <XURv1f57WRJea5fmmckRmiVGUaha6RxUDzwdKwT-9d0=.fc74be17-1fa8-41f9-bb1f-9392bea422f1@github.com>

> `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 eight additional commits since the last revision:

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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17113/files
  - new: https://git.openjdk.org/jdk/pull/17113/files/f4178acc..d557d8c6

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

  Stats: 123995 lines in 2894 files changed: 27722 ins; 83983 del; 12290 mod
  Patch: https://git.openjdk.org/jdk/pull/17113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17113/head:pull/17113

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

From duke at openjdk.org  Thu Mar  7 16:12:16 2024
From: duke at openjdk.org (Elif Aslan)
Date: Thu, 7 Mar 2024 16:12:16 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v2]
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <diLw84Ajc32r-W0Dl3zFCk0aR586PEYf6kBXO5Fx7QA=.b3bf8021-4239-4eec-8a52-4ddcb93ee410@github.com>

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.
> 
> Existing tests passes since it does not check behavior without args.
> After test update the test fails without 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> code block
> 
>> Test results: failed: 1
>> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
>> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>> Error: Some tests failed or other problems occurred.
>> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
>> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>  
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>> >>                                                       1     0     1     0 <<
>> ==============================
>> TEST FAILURE
> 
> 
> 
> after added the code block back 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> 
> updated test passes
> 
> 
> lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
>         -Xmx768m \\
>         -XX:MaxRAMPercentage=1.04167 \\
>         -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
>         -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
>         -ea \\
>         -esa \\
>         -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
>         com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/java/lang/ProcessBuilder/JspawnhelperPr...

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

  Seperate out jspawnhelper tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18112/files
  - new: https://git.openjdk.org/jdk/pull/18112/files/7a486eda..3f382e74

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

  Stats: 124 lines in 3 files changed: 84 ins; 39 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18112/head:pull/18112

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

From duke at openjdk.org  Thu Mar  7 16:29:12 2024
From: duke at openjdk.org (Elif Aslan)
Date: Thu, 7 Mar 2024 16:29:12 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v3]
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <Acl0IB3LR24AAI__QHothafm2KfjRb9zbxIdWLNr7zo=.95deec37-7f4e-4025-bf7f-19da98bbac6b@github.com>

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.
> 
> Existing tests passes since it does not check behavior without args.
> After test update the test fails without 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> code block
> 
>> Test results: failed: 1
>> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
>> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>> Error: Some tests failed or other problems occurred.
>> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
>> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>  
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>> >>                                                       1     0     1     0 <<
>> ==============================
>> TEST FAILURE
> 
> 
> 
> after added the code block back 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> 
> updated test passes
> 
> 
> lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
>         -Xmx768m \\
>         -XX:MaxRAMPercentage=1.04167 \\
>         -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
>         -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
>         -ea \\
>         -esa \\
>         -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
>         com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/java/lang/ProcessBuilder/JspawnhelperPr...

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

  Use outputanalyzer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18112/files
  - new: https://git.openjdk.org/jdk/pull/18112/files/3f382e74..8fbf24e2

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

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

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

From duke at openjdk.org  Thu Mar  7 16:33:11 2024
From: duke at openjdk.org (Elif Aslan)
Date: Thu, 7 Mar 2024 16:33:11 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v4]
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <WDihG_tkVQ1xT2qsgGId3MKyx1O6Svf1_EAa0ZDddGs=.62866d55-094a-4005-aae0-8fa72d9600ce@github.com>

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments, and it includes an updated test to verify the behavior in such cases.
> 
> Existing tests passes since it does not check behavior without args.
> After test update the test fails without 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> code block
> 
>> Test results: failed: 1
>> Report written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/html/report.html
>> Results written to /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>> Error: Some tests failed or other problems occurred.
>> Finished running test 'jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java'
>> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
>>  
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>> >>                                                       1     0     1     0 <<
>> ==============================
>> TEST FAILURE
> 
> 
> 
> after added the code block back 
> 
>    if (argc != 2) {
>         shutItDown();
>     }
> 
> 
> updated test passes
> 
> 
> lang/ProcessBuilder/JspawnhelperProtocol.d:/home/ec2-user/moe/ws/openjdk/jdk/test/jdk/java/lang/ProcessBuilder:/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/classes/0/test/lib \\
>         -Xmx768m \\
>         -XX:MaxRAMPercentage=1.04167 \\
>         -Dtest.boot.jdk=/home/ec2-user/moe/soft/jdk/jdk-21 \\
>         -Djava.io.tmpdir=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/tmp \\
>         -ea \\
>         -esa \\
>         -Djava.library.path=/home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/images/test/jdk/jtreg/native \\
>         com.sun.javatest.regtest.agent.MainWrapper /home/ec2-user/moe/ws/openjdk/jdk/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java/java/lang/ProcessBuilder/JspawnhelperPr...

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

  Revert JspawnhelperProtocol.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18112/files
  - new: https://git.openjdk.org/jdk/pull/18112/files/8fbf24e2..ef803b4c

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

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

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

From shade at openjdk.org  Thu Mar  7 16:41:58 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Mar 2024 16:41:58 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v4]
In-Reply-To: <WDihG_tkVQ1xT2qsgGId3MKyx1O6Svf1_EAa0ZDddGs=.62866d55-094a-4005-aae0-8fa72d9600ce@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <WDihG_tkVQ1xT2qsgGId3MKyx1O6Svf1_EAa0ZDddGs=.62866d55-094a-4005-aae0-8fa72d9600ce@github.com>
Message-ID: <YsZx6_14LiFLIAx5gfD7cg5uc7V4XYRG2wmBRgX91W8=.280870fe-59ad-431a-9953-2c7d7163ebc8@github.com>

On Thu, 7 Mar 2024 16:33:11 GMT, Elif Aslan <duke at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert JspawnhelperProtocol.java

So, the test is "passing" with `argc == 2` because jspawnhelper shuts down on illegal `argv[1]`, right? This is probably fine.

More stylistic comments:

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 31:

> 29:  * @requires (os.family == "linux") | (os.family == "aix")
> 30:  * @library /test/lib
> 31:  * @run main/othervm/timeout=300 JspawnhelperWarnings

This test does not have to be `othervm`, it could be `driver`:


  @run driver JspawnhelperWarnings

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 61:

> 59:      public static void main(String[] args) throws Exception {
> 60:         for (int nArgs = 0; nArgs < 10; ++nArgs)
> 61:             jspawnhelperWithNArgs(nArgs);

Style: braces for loop body. There is also no point in using `++nArgs`, when `nArgs++` is sufficient.

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 63:

> 61:             jspawnhelperWithNArgs(nArgs);
> 62:     }
> 63: }

Needs newline at the end of the file.

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

PR Review: https://git.openjdk.org/jdk/pull/18112#pullrequestreview-1922949264
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516478694
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516481779
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516482020

From shade at openjdk.org  Thu Mar  7 16:42:00 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Mar 2024 16:42:00 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v3]
In-Reply-To: <Acl0IB3LR24AAI__QHothafm2KfjRb9zbxIdWLNr7zo=.95deec37-7f4e-4025-bf7f-19da98bbac6b@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <Acl0IB3LR24AAI__QHothafm2KfjRb9zbxIdWLNr7zo=.95deec37-7f4e-4025-bf7f-19da98bbac6b@github.com>
Message-ID: <IduQJeR_iV5VGk6f2zHooP90ZeGyLJZXqJ1Uhplapr8=.1bacfe15-feee-4c33-98fa-b99bc5ff656b@github.com>

On Thu, 7 Mar 2024 16:29:12 GMT, Elif Aslan <duke at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use outputanalyzer

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 238:

> 236:         }
> 237:     }
> 238: }

This looks like a leftover, please revert.

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 46:

> 44: 
> 45:     private static void jspawnhelperWithNArgs(int nArgs) throws Exception {
> 46:         System.out.println("Running jspawnhelper with "+nArgs+" args");

Style: spaces around `+` operator.

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 47:

> 45:     private static void jspawnhelperWithNArgs(int nArgs) throws Exception {
> 46:         System.out.println("Running jspawnhelper with "+nArgs+" args");
> 47:         String[] args = new String[nArgs +1];

Style: spaces around `+` operator.

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 54:

> 52:         if (!p.waitFor(TIMEOUT, TimeUnit.SECONDS)) {
> 53:             throw new RuntimeException("jspawnhelper timed out after " + TIMEOUT + " seconds");
> 54:         }

I don't think we need to wait here, the `shouldHaveExitValue` waits for us.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516472478
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516472833
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516477172
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516476881

From duke at openjdk.org  Thu Mar  7 16:48:12 2024
From: duke at openjdk.org (Elif Aslan)
Date: Thu, 7 Mar 2024 16:48:12 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v5]
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <_YL1oRtXcDjCLY3mHIEfnPTva_ZgGLdb17eQjHRTn-g=.c663e6d9-5142-425d-bc96-e4d2b0c7cfe3@github.com>

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
> There is a new test added  to verify the behavior in such cases.
> 
> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
> 
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS

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

  Address the comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18112/files
  - new: https://git.openjdk.org/jdk/pull/18112/files/ef803b4c..d34a1403

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

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

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

From syan at openjdk.org  Thu Mar  7 16:51:21 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 7 Mar 2024 16:51:21 GMT
Subject: RFR: 8327486: java/util/Properties/PropertiesStoreTest.java fails
 "Text 'xxx' could not be parsed at index 20" after 8174269
Message-ID: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>

The DATE_FORMAT_PATTERN is set to "EEE MMM dd HH:mm:ss zzz uuuu", is the time format of US. So, creates a formatter should using Locale.US, rather than Locale.ROOT, which means empty.

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

Commit messages:
 - 8327486: java/util/Properties/PropertiesStoreTest.java fails "Text 'xxx' could not be parsed at index 20" after 8174269

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

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

From duke at openjdk.org  Thu Mar  7 17:04:12 2024
From: duke at openjdk.org (Elif Aslan)
Date: Thu, 7 Mar 2024 17:04:12 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v6]
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <NAkfdud-hlvXoQQG5afKRdtLTOsWoxbEsDXdD9F3z-g=.2affa0c9-802b-4072-8b92-d97e0910a734@github.com>

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
> There is a new test added  to verify the behavior in such cases.
> 
> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
> 
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS

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

  more styling fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18112/files
  - new: https://git.openjdk.org/jdk/pull/18112/files/d34a1403..fb9cb777

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

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

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

From duke at openjdk.org  Thu Mar  7 17:13:12 2024
From: duke at openjdk.org (Elif Aslan)
Date: Thu, 7 Mar 2024 17:13:12 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
> There is a new test added  to verify the behavior in such cases.
> 
> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
> 
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS

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

  Add args[0] back

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18112/files
  - new: https://git.openjdk.org/jdk/pull/18112/files/fb9cb777..c82fb77b

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

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

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

From shade at openjdk.org  Thu Mar  7 17:28:58 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Mar 2024 17:28:58 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
Message-ID: <kAYVYOD9BMJQkUvmMPtsGy7eZYOT8YPMo31Izqfd9M4=.1af9376e-d71d-419d-8567-669f85db718d@github.com>

On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan <duke at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add args[0] back

I am good with this version.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18112#pullrequestreview-1923081130

From bpb at openjdk.org  Thu Mar  7 17:34:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Mar 2024 17:34:57 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <aCwdTOl0-rkQj9VyYVBDEaZ5D3PJut6U2vy07APIWoU=.bed1e600-78d7-4d26-8231-3a39d079aa93@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust COPYRIGHT year info

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1923092889

From clanger at openjdk.org  Thu Mar  7 17:40:58 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 7 Mar 2024 17:40:58 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v7]
In-Reply-To: <QIfdwXrR8lPxYCESnBy6nxxfhAZCK_BfKJzNceSjjIU=.10a61f3e-8328-4f91-a3b0-1cb10fbd8a2f@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <r__SpoJaRXPAH-aJNSrMxetk4OkTGCILvAcDVRRxSxo=.53101fde-2aaa-4368-ba56-89167be8ad53@github.com>
 <QIfdwXrR8lPxYCESnBy6nxxfhAZCK_BfKJzNceSjjIU=.10a61f3e-8328-4f91-a3b0-1cb10fbd8a2f@github.com>
Message-ID: <pLld_-f0QJxH9-cT3Pyramf5CfMwEoEgxneb8Q7iF9Q=.6994ce78-de28-4fa4-a156-1f69b1ece385@github.com>

On Wed, 6 Mar 2024 14:42:09 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Christoph Langer 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:
>> 
>>  - Indentation
>>  - Merge branch 'master' into JDK-8325579
>>  - Review feedback
>>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>>  - Merge branch 'master' into JDK-8325579
>>  - Typo
>>  - Merge branch 'master' into JDK-8325579
>>  - Rename test and refine comment
>>  - Enhance test
>>  - JDK-8325579
>
> src/java.naming/share/classes/module-info.java line 42:
> 
>> 40:  *         <br>The value of this environment property specifies the fully
>> 41:  *         qualified class name of the socket factory used by the LDAP provider.
>> 42:  *         This class must implement the javax.net.SocketFactory abstract class.
> 
> We need to mention here that `getDefault` method needs to be implemented by the provided socket factory class.
> 
>  Something like: `and provide an implementation of the static "getDefault()" method that returns an instance of the socket factory.`
> The CSR needs to be updated too.

Good point. I will amend that in both, source code and CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1516570214

From clanger at openjdk.org  Thu Mar  7 17:40:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 7 Mar 2024 17:40:56 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: <36-uLVrsexBrgtOwUkfGEY9DYq7kVtZG58b_bQoBe0s=.49a0d4b1-e141-4863-bc9f-80a8bd7b8196@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <Gfc5nSHywS0SkSv33Bgu9htQapPQgbH1SAXmjtU6UIA=.82fe269b-3a6a-40cb-b77d-c878b4d12210@github.com>
 <rNceCTggSqL-bJVTTj4X4HEzVsmanlKNIhrbrPCf-g0=.395f0162-d5d9-4840-98dd-199def542269@github.com>
 <RaKJiTLW6li4_S5-HsffyRqDNOwd-vFCkLH8b0_dD1k=.4bff88c5-04f4-498d-af4d-14c437bb369a@github.com>
 <QZU5goh25uLufkMD76XbPw1yrRDok-cl995sUZ602pI=.536873ab-d1bb-457e-88a9-d180f3720f8b@github.com>
 <ysYpm97ehjB1vmPga-F6V81vmdDwbQ_s-67oNUKbmrQ=.601fadce-df07-4a25-8559-819025c1a7ce@github.com>
 <rxsscNAo3wJCLQ-Zr3HSAN2PdTNdwMe9fIOiYNUzrSg=.9cde53d2-43f0-4b35-93d2-52e7f0820683@github.com>
 <36-uLVrsexBrgtOwUkfGEY9DYq7kVtZG58b_bQoBe0s=.49a0d4b1-e141-4863-bc9f-80a8bd7b8196@github.com>
Message-ID: <pifXUv8AYzbfmVZ45hlfSfJ250bjyy-4PGsbKupleJM=.f7240984-56cc-4606-bb14-c1a35cbc5c35@github.com>

On Mon, 4 Mar 2024 15:02:45 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> > Thanks for exploring the possibility of improving tracebility of test invocations to reported bugs.
> > >
> 
> I've given this test change a second thought, maybe you can try to separate the test into two separate test classes? One possibility to avoid duplicating code and have a separate test for each bug is to introduce a base test class that will contain the common functionality for [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) and [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) tests.

I will have a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1984087841

From shade at openjdk.org  Thu Mar  7 18:07:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Mar 2024 18:07:54 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <ylVfkXxoZYKiwHQEjUr3VqquY4yZukOSmAhLkwx5m7c=.c7eeee37-e34b-44c8-8865-f38a92071ee3@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <ylVfkXxoZYKiwHQEjUr3VqquY4yZukOSmAhLkwx5m7c=.c7eeee37-e34b-44c8-8865-f38a92071ee3@github.com>
Message-ID: <YPqoLuA-dgFXUvoXDCVCtiUoKtGC-s0eMieba4ipL7Y=.f358ce01-f5ee-483a-8c51-aa470f6fad61@github.com>

On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> I'm curious why this test is requires `vm.debug`?  That means it generally won't get run on release builds.

Let's see if @RogerRiggs and @vpa1977 have any additional feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/18112#issuecomment-1984137117

From javalists at cbfiddle.com  Thu Mar  7 18:16:35 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 7 Mar 2024 10:16:35 -0800
Subject: reducing the size of multi-architecture applications
Message-ID: <581BEDEB-51EB-4524-8FDE-7FE0E68E3892@cbfiddle.com>

As mentioned in a previous message, I am creating universal macOS bundled applications by including two Java runtimes in the application bundle, one for arm and one for x86. The primary disadvantage of universal applications is their size. For Java applications, there is an obvious opportunity to share the class files, which are architecture neutral. In the current JDK, that would mean sharing the lib/modules file, which would reduce the application size by 100MB or so.
This would be a no-brainer, except for one small detail: the lib/modules file contains two class files that are different in the two runtimes.
These classes are PlatformProps (whose source is architecture-specific) and Architecture (which inlines constants from PlatformProps). I presume the motivation for this design is the performance improvement that results from the compiler knowing the constant values. Is that correct?
It appears that these architecture-specific constants are used mostly, if not exclusively, in jtreg and test programs. I tested this theory by replacing the modules file in an arm runtime with the modules file from the corresponding x86 runtime. An application using this hybrid runtime started up normally. While not an exhaustive test, the fact that it did not fall over dead is encouraging.
Another potential issue with sharing class files is that the module-info classes in lib/modules identify the target architecture. My little experiment suggests that this metadata is not used, but it would be nice to guarantee that.
It would good if sharing lib/modules was a supported feature, rather than just hoping that it works and continues to work in the future.
I can see several possible options for supporting sharing of the lib/modules file, based in part of how the above classes are used and how important the inline performance gains are:
1. Split lib/modules into two files, one for architecture-specific class files and one for architecture-independent class files.
2. Replace the inlining support with a conventional implementation that initializes the constants using data obtained from a dynamic library.
3. Move the above classes into a test support module, one that jlink excludes by default. If there are other clients of architecture related constants, they can use conventional implementation classes, as described in the second option.
Thoughts?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240307/b67486f8/attachment.htm>

From vpetko at openjdk.org  Thu Mar  7 19:01:54 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 7 Mar 2024 19:01:54 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
Message-ID: <VgXzuaibFcf3D4c43Bp7GW_dmrjUzvS5lSiysLboldM=.5ada6465-d31e-45b9-a3d7-87af46c9371d@github.com>

On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan <duke at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add args[0] back

Marked as reviewed by vpetko (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/18112#pullrequestreview-1923293793

From vpetko at openjdk.org  Thu Mar  7 19:18:56 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 7 Mar 2024 19:18:56 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <ylVfkXxoZYKiwHQEjUr3VqquY4yZukOSmAhLkwx5m7c=.c7eeee37-e34b-44c8-8865-f38a92071ee3@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <ylVfkXxoZYKiwHQEjUr3VqquY4yZukOSmAhLkwx5m7c=.c7eeee37-e34b-44c8-8865-f38a92071ee3@github.com>
Message-ID: <QGKenoQppj8IAUnuLI5q38QDgZ2Tlt56uueTjL0d6Zs=.e64255a2-b591-4bd7-b57c-c8674c538d30@github.com>

On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> I'm curious why this test is requires `vm.debug`?  That means it generally won't get run on release builds.

> Let's see if @RogerRiggs and @vpa1977 have any additional feedback.

Hi, the changes look good, just a minor note regarding waitFor() removal. OutputAnalyzer/LazyOutputBuffer do not have timeout on waitFor() so in a rare case when jspawnhelper is stuck, the test might block the CI.
It is hardly possible with the current implementation, but might become a possibility in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/18112#issuecomment-1984253692

From naoto at openjdk.org  Thu Mar  7 19:32:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Mar 2024 19:32:03 GMT
Subject: RFR: 8327167: Add add() example for Leap Day in Calendar's doc
Message-ID: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>

A simple doc update to include a leap day example in the `Calendar` class.

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

Commit messages:
 - initial commit

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

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

From rriggs at openjdk.org  Thu Mar  7 19:54:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Mar 2024 19:54:57 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
Message-ID: <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>

On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan <duke at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add args[0] back

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 29:

> 27:  * @test
> 28:  * @bug 8325567
> 29:  * @requires (os.family == "linux") | (os.family == "aix")

Unless I'm mistaken, jspawn helper is used on Mac as well.

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 36:

> 34: import java.nio.file.Paths;
> 35: import java.util.Arrays;
> 36: import java.util.concurrent.TimeUnit;

Unused import.

test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 56:

> 54:     public static void main(String[] args) throws Exception {
> 55:         for (int nArgs = 0; nArgs < 10; nArgs++) {
> 56:             tryWithNArgs(nArgs);

Running with more than 3 arguments is unnecessary. Yes, its quick but just burns cpu.

When running with 2 arguments, the failure mode is not due to the number of arguments but is because argument 1 is formatted incorrectly;  should be `"%d:%d:%d"`. Though I supposed this falls into the "incorrect use category".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516736692
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516738195
PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516733166

From vpetko at openjdk.org  Thu Mar  7 20:06:59 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 7 Mar 2024 20:06:59 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
 <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>
Message-ID: <f0qW2JMEqCCJbVo8bDHsH1ynIJu1Jfd0OIXEubDAZVY=.87fce65b-e9bf-4b7a-8503-515f1e55e657@github.com>

On Thu, 7 Mar 2024 19:44:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add args[0] back
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 56:
> 
>> 54:     public static void main(String[] args) throws Exception {
>> 55:         for (int nArgs = 0; nArgs < 10; nArgs++) {
>> 56:             tryWithNArgs(nArgs);
> 
> Running with more than 3 arguments is unnecessary. Yes, its quick but just burns cpu.
> 
> When running with 2 arguments, the failure mode is not due to the number of arguments but is because argument 1 is formatted incorrectly;  should be `"%d:%d:%d"`. Though I supposed this falls into the "incorrect use category".

I wonder if it would make sense to add a test with a correct argument format?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1516754742

From duke at openjdk.org  Thu Mar  7 20:18:57 2024
From: duke at openjdk.org (Louis Bergelson)
Date: Thu, 7 Mar 2024 20:18:57 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v6]
In-Reply-To: <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com>
Message-ID: <dIdi2jyLN-W6PhfS04BEksNJL58NH0_kMczRFgz7EXU=.fc4c2f86-3556-4e8a-a576-8f2eb919025c@github.com>

On Mon, 5 Feb 2024 23:53:06 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 six additional commits since the last revision:
> 
>  - 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, I just wanted to check if there was anything way I could help move this along.

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

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1962025424

From archie.cobbs at gmail.com  Thu Mar  7 20:30:31 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 7 Mar 2024 14:30:31 -0600
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v6]
In-Reply-To: <dIdi2jyLN-W6PhfS04BEksNJL58NH0_kMczRFgz7EXU=.fc4c2f86-3556-4e8a-a576-8f2eb919025c@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
 <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com>
 <dIdi2jyLN-W6PhfS04BEksNJL58NH0_kMczRFgz7EXU=.fc4c2f86-3556-4e8a-a576-8f2eb919025c@github.com>
Message-ID: <CANSoFxvjkMu-_DCiv6PsqJ+YtTPGAT3U_isqYR0kAqbBtMTz=Q@mail.gmail.com>

On Thu, Mar 7, 2024 at 2:20?PM Louis Bergelson <duke 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.
>
> Hello, I just wanted to check if there was anything way I could help move
> this along.
>

Hi Louis,

Thanks for offering to help. The process is slow but moving forward and we
are getting close. Because there are implications to the specified behavior
it is being reviewed for backward compatibility, etc.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240307/0a498948/attachment.htm>

From iklam at openjdk.org  Thu Mar  7 21:00:01 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 7 Mar 2024 21:00:01 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v4]
In-Reply-To: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
Message-ID: <17levG82EcbT5zXdxDurs1tNJ07sWRXxtZqBphDPGJE=.acf2e6c0-24fd-418d-ac03-96b2047c4837@github.com>

> A few clean ups:
> 
> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
> 
> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
> 
> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
> 
> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
> 
> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.

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

  @dholmes-ora comments -- white spaces and copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18095/files
  - new: https://git.openjdk.org/jdk/pull/18095/files/5a28f865..c8f08f7f

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

  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18095/head:pull/18095

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

From iklam at openjdk.org  Thu Mar  7 21:00:03 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 7 Mar 2024 21:00:03 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v3]
In-Reply-To: <dHvicly-47AmTgp80WJmWgF3FlSUFqI9gxBaCchbAY4=.cb27421a-d433-4664-8537-47edd6506ffa@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <cE9s-ZP_WHLA_fEe2GiLf_eCpTpkj076CmRyw9596vo=.94c1577d-2748-4e52-9747-cb596e538e8e@github.com>
 <dHvicly-47AmTgp80WJmWgF3FlSUFqI9gxBaCchbAY4=.cb27421a-d433-4664-8537-47edd6506ffa@github.com>
Message-ID: <lik4TLOqwVcs0ssW4u47Sv7hJbBSkWE_J8joW46_TiA=.e9aedb03-71e0-40c6-a4e3-75059563b468@github.com>

On Thu, 7 Mar 2024 06:50:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more alignment
>
> src/hotspot/share/cds/cdsConfig.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Incorrect copyright update - should be "2023, 2024,"

Fixed.

> src/hotspot/share/cds/cdsConfig.cpp line 54:
> 
>> 52:          (is_dumping_static_archive()        ? IS_DUMPING_STATIC_ARCHIVE : 0) |
>> 53:          (is_logging_lambda_form_invokers()  ? IS_LOGGING_LAMBDA_FORM_INVOKERS : 0) |
>> 54:          (is_using_archive()                 ? IS_USING_ARCHIVE : 0);
> 
> You can remove one space before the ? in each line

Fixed.

> src/hotspot/share/cds/cdsConfig.hpp line 56:
> 
>> 54:   static const int IS_DUMPING_STATIC_ARCHIVE              = 1 << 1;
>> 55:   static const int IS_LOGGING_LAMBDA_FORM_INVOKERS        = 1 << 2;
>> 56:   static const int IS_USING_ARCHIVE                       = 1 << 3;
> 
> why is the = sign so far away?

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1516811557
PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1516811622
PR Review Comment: https://git.openjdk.org/jdk/pull/18095#discussion_r1516811711

From naoto at openjdk.org  Thu Mar  7 21:09:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Mar 2024 21:09:53 GMT
Subject: RFR: 8327486: java/util/Properties/PropertiesStoreTest.java fails
 "Text 'xxx' could not be parsed at index 20" after 8174269
In-Reply-To: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
Message-ID: <QUGIURhhsXZ8pXEigDw84wCcjQo0utA-7aQIcwMP2G4=.3284b529-6296-4889-a29f-bd24692947af@github.com>

On Thu, 7 Mar 2024 16:47:01 GMT, SendaoYan <syan at openjdk.org> wrote:

> The DATE_FORMAT_PATTERN is set to "EEE MMM dd HH:mm:ss zzz uuuu", is the time format of US. So, creates a formatter should using Locale.US, rather than Locale.ROOT, which means empty.

Thanks for the fix. Although setting `Locale.US` to acquire the formatter is correct, the reasoning is not. The real reason is that `Date.toString()` uses `Locale.US` explicitly for printing the time zone https://github.com/openjdk/jdk/blob/972e81d1adb232b02114a5260d06144eb5b08849/src/java.base/share/classes/java/util/Date.java#L1045

Also, update the copyright year to 2024.

test/jdk/java/util/Properties/PropertiesStoreTest.java line 59:

> 57:     private static final String DATE_FORMAT_PATTERN = "EEE MMM dd HH:mm:ss zzz uuuu";
> 58:     // use a neutral locale, since when the date comment was written by Properties.store(...),
> 59:     // it internally calls the Date.toString() which always writes in a locale insensitive manner

The comment here does not hold true any longer

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

PR Review: https://git.openjdk.org/jdk/pull/18155#pullrequestreview-1923533880
PR Review Comment: https://git.openjdk.org/jdk/pull/18155#discussion_r1516821399

From bpb at openjdk.org  Thu Mar  7 21:11:52 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Mar 2024 21:11:52 GMT
Subject: RFR: 8327167: Add add() example for Leap Day in Calendar's doc
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <LE5lVn6-15Hity9enQTP7JI7Y9sV8w8txglwk4aXaXI=.49a1142d-48a3-4a69-a558-47735a35aa4b@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Looks good.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923550002

From joehw at openjdk.org  Thu Mar  7 21:14:54 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 7 Mar 2024 21:14:54 GMT
Subject: RFR: 8327167: Add add() example for Leap Day in Calendar's doc
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <1he6cAEu-i3EueuYlMMLLf6hIFmO5mmtRVS0WMYKmvQ=.44a8ecae-9f42-4920-82fd-7bc74766b96a@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923559732

From lancea at openjdk.org  Thu Mar  7 21:19:56 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 7 Mar 2024 21:19:56 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v3]
In-Reply-To: <JwZxCNT0ulu-RLMOQ5P65OG5cR5QjqzOKtJ-rMswuTY=.f1ec3dff-081b-4485-b8e7-f580a4709ff6@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <JwZxCNT0ulu-RLMOQ5P65OG5cR5QjqzOKtJ-rMswuTY=.f1ec3dff-081b-4485-b8e7-f580a4709ff6@github.com>
Message-ID: <G6gWV5IS1LXkZFgE3Vg9248Q3qTlxof-kZgQaH_4Cg4=.c9a35e27-8bb9-432c-9783-4eaadb9213a8@github.com>

On Sat, 3 Feb 2024 17:28:29 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s 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:
> 
>  - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
>  - For clarity, use "externalFileAttributes" instead of "externalAttributes"
>  - Merge branch 'master' into zipentry-external-attributes
>  - Update copyright years for 2024
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-1923567034

From lancea at openjdk.org  Thu Mar  7 21:23:55 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 7 Mar 2024 21:23:55 GMT
Subject: RFR: 8327167: Add add() example for Leap Day in Calendar's doc
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <40T77DVsSyHvCqXBmem6pDOZBtM8UUTLrnDaCJg-hiM=.877db9ce-a53b-4c88-b37d-080c5085fbcb@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923575615

From mik3hall at gmail.com  Thu Mar  7 21:24:21 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 7 Mar 2024 15:24:21 -0600
Subject: reducing the size of multi-architecture applications
In-Reply-To: <581BEDEB-51EB-4524-8FDE-7FE0E68E3892@cbfiddle.com>
References: <581BEDEB-51EB-4524-8FDE-7FE0E68E3892@cbfiddle.com>
Message-ID: <7B1EC320-1944-4EBF-AA77-2E04A55E6F1C@gmail.com>

Not directly in response to your prior. But curious, are you doing something like described here?

https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary

If not why not?

It indicates

> For universal binaries, the system prefers to execute the slice that is native to the current platform. 

Isn?t that saying the OS will just do the right thing? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240307/1918923a/attachment-0001.htm>

From jlu at openjdk.org  Thu Mar  7 21:39:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Mar 2024 21:39:52 GMT
Subject: RFR: 8327167: Add an example for Leap Day in Calendar's doc
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <eg-nuzP7O1vUAa9aCqXqCv2rf7P3a4aUyCz-i3XvV1g=.2beca255-2e22-4904-95d5-5ea961d2a62f@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923601796

From javalists at cbfiddle.com  Thu Mar  7 21:39:34 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 7 Mar 2024 13:39:34 -0800
Subject: reducing the size of multi-architecture applications
In-Reply-To: <7B1EC320-1944-4EBF-AA77-2E04A55E6F1C@gmail.com>
References: <581BEDEB-51EB-4524-8FDE-7FE0E68E3892@cbfiddle.com>
 <7B1EC320-1944-4EBF-AA77-2E04A55E6F1C@gmail.com>
Message-ID: <B8EDEA54-DF67-4F38-8481-E10AC9A4D335@cbfiddle.com>

That could be done, but it would require more work with no obvious benefit.

Only the Java launcher needs to be universal from the perspective of the OS.




> On Mar 7, 2024, at 1:24?PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Not directly in response to your prior. But curious, are you doing something like described here?
> 
> https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary
> 
> If not why not?
> 
> It indicates
> 
>> For universal binaries, the system prefers to execute the slice that is native to the current platform. 
> 
> Isn?t that saying the OS will just do the right thing? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240307/5ea371cc/attachment.htm>

From mcimadamore at openjdk.org  Thu Mar  7 21:46:55 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Mar 2024 21:46:55 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v3]
In-Reply-To: <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
Message-ID: <1C8Qw4DoYVjv_b73GmWY6EA_UrcqogbRWlqfAeVjepA=.46aa205b-9202-4e8c-bf3d-b6e638b0135d@github.com>

On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
>  - Reflecting review feedback.
>  - Updating copyright headers.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1923612749

From mik3hall at gmail.com  Thu Mar  7 21:48:49 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 7 Mar 2024 15:48:49 -0600
Subject: reducing the size of multi-architecture applications
In-Reply-To: <B8EDEA54-DF67-4F38-8481-E10AC9A4D335@cbfiddle.com>
References: <581BEDEB-51EB-4524-8FDE-7FE0E68E3892@cbfiddle.com>
 <7B1EC320-1944-4EBF-AA77-2E04A55E6F1C@gmail.com>
 <B8EDEA54-DF67-4F38-8481-E10AC9A4D335@cbfiddle.com>
Message-ID: <6339774D-3897-44C2-AB11-6C90DD15A9AE@gmail.com>

OK. I didn?t follow exactly what you?re doing. So I don?t know what would be extra. I also assume it wouldn?t address any other architecture specific parts of the jdk that you mentioned.

How are you planning on replacing the executables and getting valid signed applications? I think it could be managed if you jpackage an application only image. Then replace the executables. Then sign and dmg.

> On Mar 7, 2024, at 3:39?PM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> That could be done, but it would require more work with no obvious benefit.
> 
> Only the Java launcher needs to be universal from the perspective of the OS.
> 
> 
> 
> 
>> On Mar 7, 2024, at 1:24?PM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> Not directly in response to your prior. But curious, are you doing something like described here?
>> 
>> https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary
>> 
>> If not why not?
>> 
>> It indicates
>> 
>>> For universal binaries, the system prefers to execute the slice that is native to the current platform. 
>> 
>> Isn?t that saying the OS will just do the right thing? 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240307/37d1810d/attachment-0001.htm>

From jlahoda at openjdk.org  Thu Mar  7 21:53:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Mar 2024 21:53:07 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v4]
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

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

  Adjusting javadoc as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18106/files
  - new: https://git.openjdk.org/jdk/pull/18106/files/e30e4529..6af399ee

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

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

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

From jlahoda at openjdk.org  Thu Mar  7 21:53:08 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Mar 2024 21:53:08 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v3]
In-Reply-To: <bRjHFpQGmLDFi0kRP_ciClevcZZ1QfvRdCjaqiP3nLw=.57aad825-beca-401e-af14-87a641fb756c@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <pcaIG6NIxLCFBO0VGuIwFjTH-i-4giTnp8phPpRu6ao=.79af91ee-7846-4ebc-8c7b-1bb38dd7d29c@github.com>
 <bRjHFpQGmLDFi0kRP_ciClevcZZ1QfvRdCjaqiP3nLw=.57aad825-beca-401e-af14-87a641fb756c@github.com>
Message-ID: <Xhzv0NgCzdvlZ1vROhcFfPu9CBPpAyDKoukDE5cHTOc=.0b44fab2-eef9-4908-9104-1b2653e4147f@github.com>

On Thu, 7 Mar 2024 09:30:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
>>  - Reflecting review feedback.
>>  - Updating copyright headers.
>
> src/java.base/share/classes/java/lang/ModuleLayer.java line 891:
> 
>> 889:      *         {@code false} otherwise
>> 890:      */
>> 891:     boolean addEnableNativeAccess(String name) {
> 
> Do you mind changing the method description to "Updates the module with the given name in this layer to allow access to restricted methods"? This will be keep it more consistent with the exiting methods.
> 
> Also "was present" in the return description hints that it may not now be present. A module layer is immutable so it can just say that it returns true if the  module is in this layer.

Adjusted here:
https://github.com/openjdk/jdk/pull/18106/commits/6af399ee4a3e908cb7c6b983b9747310e23a888e
please let me know if further/other changes/adjustment are desirable.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1516878109

From ecki at zusammenkunft.net  Thu Mar  7 22:00:38 2024
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu,  7 Mar 2024 23:00:38 +0100 (CET)
Subject: reducing the size of multi-architecture applications
In-Reply-To: <B8EDEA54-DF67-4F38-8481-E10AC9A4D335@cbfiddle.com>
References: <581BEDEB-51EB-4524-8FDE-7FE0E68E3892@cbfiddle.com>
 <7B1EC320-1944-4EBF-AA77-2E04A55E6F1C@gmail.com><B8EDEA54-DF67-4F38-8481-E10AC9A4D335@cbfiddle.com>
Message-ID: <20240307220038.ADCD26606EB@dd33810.kasserver.com>

Alan Snyder wrote on 7. Mar 2024 22:39 (GMT +01:00):

> That could be done, but it would require more work with no obvious
> benefit.
> 
> Only the Java launcher needs to be universal from the perspective of the
> OS.

it?s however not only the exetables. You have also the shared libraries, possibly the class
data archives, and when it comes to multiple OS there are different classes
In the JCL and even templates for JDK resources differ by OS. Some modules are OS
Specific (like SunMSCAPI provider for 64Bit Windows)

Gruss
Bernd
? 
https://bernd.eckenfels.net

From javalists at cbfiddle.com  Thu Mar  7 22:13:38 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 7 Mar 2024 14:13:38 -0800
Subject: reducing the size of multi-architecture applications
In-Reply-To: <20240307220038.ADCD26606EB@dd33810.kasserver.com>
References: <581BEDEB-51EB-4524-8FDE-7FE0E68E3892@cbfiddle.com>
 <7B1EC320-1944-4EBF-AA77-2E04A55E6F1C@gmail.com>
 <B8EDEA54-DF67-4F38-8481-E10AC9A4D335@cbfiddle.com>
 <20240307220038.ADCD26606EB@dd33810.kasserver.com>
Message-ID: <94A32167-D0B7-430D-833C-328744034021@cbfiddle.com>

I?m only interested in macOS universal applications. I don?t see a need for multi-OS applications.

The shared libraries do not need to be merged as the runtime is not itself universal, only the launcher is.
The launcher finds the appropriate single-architecture runtime and launches it.


> On Mar 7, 2024, at 2:00?PM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> 
> Alan Snyder wrote on 7. Mar 2024 22:39 (GMT +01:00):
> 
>> That could be done, but it would require more work with no obvious
>> benefit.
>> 
>> Only the Java launcher needs to be universal from the perspective of the
>> OS.
> 
> it?s however not only the exetables. You have also the shared libraries, possibly the class
> data archives, and when it comes to multiple OS there are different classes
> In the JCL and even templates for JDK resources differ by OS. Some modules are OS
> Specific (like SunMSCAPI provider for 64Bit Windows)
> 
> Gruss
> Bernd
> ? 
> https://bernd.eckenfels.net
> 


From ccheung at openjdk.org  Thu Mar  7 23:01:54 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 7 Mar 2024 23:01:54 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v4]
In-Reply-To: <17levG82EcbT5zXdxDurs1tNJ07sWRXxtZqBphDPGJE=.acf2e6c0-24fd-418d-ac03-96b2047c4837@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <17levG82EcbT5zXdxDurs1tNJ07sWRXxtZqBphDPGJE=.acf2e6c0-24fd-418d-ac03-96b2047c4837@github.com>
Message-ID: <6FOFK8n6A5Kqpsg6BbEKTaaqiQgzQKfKflbIopBkD8A=.b58cff05-5f6b-46f7-ab55-1075dad877e7@github.com>

On Thu, 7 Mar 2024 21:00:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A few clean ups:
>> 
>> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
>> 
>> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
>> 
>> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
>> 
>> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
>> 
>> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments -- white spaces and copyright

Marked as reviewed by ccheung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18095#pullrequestreview-1923734079

From ccheung at openjdk.org  Thu Mar  7 23:33:53 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 7 Mar 2024 23:33:53 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L
In-Reply-To: <TS2X62jd_-EuksocYXf3V_ntQHZMMBWB3ON4Mb4PXjc=.e1f404e4-4c4e-468e-999e-9413f00805a7@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
 <TS2X62jd_-EuksocYXf3V_ntQHZMMBWB3ON4Mb4PXjc=.e1f404e4-4c4e-468e-999e-9413f00805a7@github.com>
Message-ID: <JulWZZIOtSXPwo6M3EFlgJphFAx0rO1kMzMsodgTMY0=.61eea8c9-fe2f-43a8-931b-3a512a635c76@github.com>

On Wed, 6 Mar 2024 22:00:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> To avoid the CDS dump error message, a fix is during dumping a classlist, check if an invoker can be archived. 
>> If not, don't write the invoker info into the classlist, i.e. don't call `logLambdaFormInvoker()`. While generating holder classes (in `generateHolderClasses()`), don't add the `MethodType` to the `invokerTypes` if will fail the check in the `build()` method which would result in a `RuntimeException`.
>> 
>> Also updated the `MethodHandlesInvokersTest.java` under `appcds/methodHandles` and `appcds/dynamicArchive/methodHandles` to check that the "Failed to generate LambdaForm holder classes" error is not in the output;
>> 
>> Passed tiers 1 - 3 testing.
>
> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 333:
> 
>> 331:                                                     .warning("Invalid LF_RESOLVE " + parts[1] + " " + parts[2] + " " + parts[3]);
>> 332:                                         }
>> 333:                                     }
> 
> The underlying cause of the failure in CDS is [JDK-8327499](https://bugs.openjdk.org/browse/JDK-8327499) -- MethodHandleStatics.traceLambdaForm() includes methods that cannot be handle by GenerateJLIClassesHelper.java.
> 
> Therefore, I think the warning should always be printed (e.g., when jdk.tools.jlink.internal.plugins.GenerateJLIClassesPlugin is used during the JDK build).
> 
> Also, maybe add a comment above line 326: 
> 
> 
> // Work around JDK-8327499

Fixed.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 127:
> 
>> 125:      */
>> 126:     public static void traceLambdaFormInvoker(String prefix, String holder, String name, String type, MethodType mt) {
>> 127:         if (isDumpingClassList && isInvokerArchivable(mt, holder)) {
> 
> Is this check still needed after you added the filtering in GenerateJLIClassesHelper.java?
> 
> Since the logic here is not 100% the same as the logic in GenerateJLIClassesHelper.java, we might be filtering more things than necessary.

I did some sanity tests without the changes in CDS.java and it seems to work.
I'll do more testing before pushing another commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17953#discussion_r1516980404
PR Review Comment: https://git.openjdk.org/jdk/pull/17953#discussion_r1516980534

From jlu at openjdk.org  Thu Mar  7 23:36:01 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Mar 2024 23:36:01 GMT
Subject: RFR: JDK-8327631: Update IANA Language Subtag Registry to Version
 2024-03-07
Message-ID: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>

Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-03-07. Tests pass as expected after update.

Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/000090.html

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

Commit messages:
 - init

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

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

From iris at openjdk.org  Fri Mar  8 00:59:53 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 8 Mar 2024 00:59:53 GMT
Subject: RFR: 8327167: Clarify the handling of Leap year by Calendar
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <Cm_KCTXzp7-bByXrrTaT5gU2-NNsYGHTbCrXtCG1VEY=.b5e5b300-c40b-45c5-a887-213df680ef4c@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923843891

From syan at openjdk.org  Fri Mar  8 02:41:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 8 Mar 2024 02:41:06 GMT
Subject: RFR: 8327486: java/util/Properties/PropertiesStoreTest.java fails
 "Text 'xxx' could not be parsed at index 20" after 8174269 [v2]
In-Reply-To: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
Message-ID: <TIM2O9xS2qCMSKwlku6XYK5kISSmnVHjNrbQvF83EuQ=.0ab31ad1-270d-49e7-bb56-3be9317c6f07@github.com>

> The DATE_FORMAT_PATTERN is set to "EEE MMM dd HH:mm:ss zzz uuuu", is the time format of US. So, creates a formatter should using Locale.US, rather than Locale.ROOT, which means empty.

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

  1. modify copyright year to 2024; 2. delete unmatch comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18155/files
  - new: https://git.openjdk.org/jdk/pull/18155/files/7d8c0104..6827b2be

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

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

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

From amenkov at openjdk.org  Fri Mar  8 02:59:22 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 8 Mar 2024 02:59:22 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record component
 annotation fails with CFE
Message-ID: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>

RecordComponent class has _attributes_count field.
The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
The fix updates ClassFileParser to calculate correct attributes_count.

Testing: 
- tier1,tier2,hs-tier5-svc;
 - redefineClasses/retransformClasses tests:
   - test/jdk/java/lang/instrument
   - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

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

Commit messages:
 - fix

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

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

From syan at openjdk.org  Fri Mar  8 03:51:54 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 8 Mar 2024 03:51:54 GMT
Subject: RFR: 8327486: java/util/Properties/PropertiesStoreTest.java fails
 "Text 'xxx' could not be parsed at index 20" after 8174269 [v2]
In-Reply-To: <QUGIURhhsXZ8pXEigDw84wCcjQo0utA-7aQIcwMP2G4=.3284b529-6296-4889-a29f-bd24692947af@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
 <QUGIURhhsXZ8pXEigDw84wCcjQo0utA-7aQIcwMP2G4=.3284b529-6296-4889-a29f-bd24692947af@github.com>
Message-ID: <4uKv0pcSx-G-lIkiRCUIx98eCmtxa2tohoAjXw5Pdl0=.64939ad0-48c6-447c-a200-07ba3b39ea05@github.com>

On Thu, 7 Mar 2024 21:07:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Thanks for the fix. Although setting `Locale.US` to acquire the formatter is correct, the reasoning is not. The real reason is that `Date.toString()` uses `Locale.US` explicitly for printing the time zone
> 
> https://github.com/openjdk/jdk/blob/972e81d1adb232b02114a5260d06144eb5b08849/src/java.base/share/classes/java/util/Date.java#L1045
> 
> Also, update the copyright year to 2024.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/18155#issuecomment-1984993010

From syan at openjdk.org  Fri Mar  8 03:54:53 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 8 Mar 2024 03:54:53 GMT
Subject: RFR: 8327486: java/util/Properties/PropertiesStoreTest.java fails
 "Text 'xxx' could not be parsed at index 20" after 8174269 [v2]
In-Reply-To: <TIM2O9xS2qCMSKwlku6XYK5kISSmnVHjNrbQvF83EuQ=.0ab31ad1-270d-49e7-bb56-3be9317c6f07@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
 <TIM2O9xS2qCMSKwlku6XYK5kISSmnVHjNrbQvF83EuQ=.0ab31ad1-270d-49e7-bb56-3be9317c6f07@github.com>
Message-ID: <ZQiLRM9GAF2ED5Wpuy1ODETtTtPLqDPXFlph6Zqhrb0=.3e4ea56a-ad37-4dd4-ba4a-67770752f25e@github.com>

On Fri, 8 Mar 2024 02:41:06 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:
> 
>   1. modify copyright year to 2024; 2. delete unmatch comment

GHA: riscv cross compile fail. It's unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18155#issuecomment-1984994736

From ccheung at openjdk.org  Fri Mar  8 06:51:21 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 8 Mar 2024 06:51:21 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L [v2]
In-Reply-To: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
Message-ID: <cw28aE2NtWnw9d5Wm1HLOSO6_pUjbDoO4OG29WA70fE=.7d39c879-367e-4dff-a20a-ec508d4842cd@github.com>

> To avoid the CDS dump error message, a fix is during dumping a classlist, check if an invoker can be archived. 
> If not, don't write the invoker info into the classlist, i.e. don't call `logLambdaFormInvoker()`. While generating holder classes (in `generateHolderClasses()`), don't add the `MethodType` to the `invokerTypes` if will fail the check in the `build()` method which would result in a `RuntimeException`.
> 
> Also updated the `MethodHandlesInvokersTest.java` under `appcds/methodHandles` and `appcds/dynamicArchive/methodHandles` to check that the "Failed to generate LambdaForm holder classes" error is not in the output;
> 
> Passed tiers 1 - 3 testing.

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

  @iklam comments and copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17953/files
  - new: https://git.openjdk.org/jdk/pull/17953/files/092171f2..38d64c10

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

  Stats: 49 lines in 17 files changed: 1 ins; 13 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/17953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17953/head:pull/17953

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

From ihse at openjdk.org  Fri Mar  8 07:37:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 07:37:54 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
 <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>
Message-ID: <JccRFVQkVQmZqt3Ri2w-Rm3VFba_MG_MV3Cwq-BKCCk=.c6507fc3-621e-40fb-aaad-9b409d2bc020@github.com>

On Thu, 7 Mar 2024 19:47:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add args[0] back
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 8325567
>> 29:  * @requires (os.family == "linux") | (os.family == "aix")
> 
> Unless I'm mistaken, jspawn helper is used on Mac as well.

Yes indeed, it is used for all Unix OSes (that is, everything but Windows).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1517332878

From alanb at openjdk.org  Fri Mar  8 08:08:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Mar 2024 08:08:55 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v4]
In-Reply-To: <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>
Message-ID: <tV4-kylrA3ztHguo975Tt-s-FslkJ2v5v3e3SDXFstE=.3a194eef-ed88-40f2-bcd5-86b36ae10e60@github.com>

On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting javadoc as suggested.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18106#pullrequestreview-1924302699

From ihse at openjdk.org  Fri Mar  8 08:10:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 08:10:53 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <qrvOs87-Kt6FXps9AhHaYb4uBfwN-zdNkvgy4ym6H8Q=.eeca8b49-0baf-4c8e-9217-f4133b41830f@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <qrvOs87-Kt6FXps9AhHaYb4uBfwN-zdNkvgy4ym6H8Q=.eeca8b49-0baf-4c8e-9217-f4133b41830f@github.com>
Message-ID: <fjS6N3QoLZ6q-2scpsHhs5z6eQOo920Toq9o-ACeNT8=.b1cc8955-ee9f-4b8a-bbd0-59573c34e9e5@github.com>

On Wed, 6 Mar 2024 13:53:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I am currently running tier 4-10

This is now done. A handful of tests failed, but all are due to transient environmental problems, known errors, or seemingly intermittent product errors -- none are due to symbol visibility.

So I'd argue that this is one of the most well-tested PRs posted ever. :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1985232111

From mbaesken at openjdk.org  Fri Mar  8 08:34:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Mar 2024 08:34:01 GMT
Subject: Integrated: JDK-8327444: simplify RESTARTABLE macro usage in JDK
 codebase
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <bAbzLLRP89_PJUmeQMuGg37Djvavu4QQ1k94VFDHUUU=.a08c190a-9c3c-429f-af8f-ddca2e471161@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

This pull request has now been integrated.

Changeset: fb4610e6
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb4610e6b7a339d0a95a99d6e113e3ddda291561
Stats:     185 lines in 18 files changed: 69 ins; 106 del; 10 mod

8327444: simplify RESTARTABLE macro usage in JDK codebase

Reviewed-by: gli, clanger, alanb, dholmes, bpb

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

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

From shade at openjdk.org  Fri Mar  8 09:23:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Mar 2024 09:23:54 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <JccRFVQkVQmZqt3Ri2w-Rm3VFba_MG_MV3Cwq-BKCCk=.c6507fc3-621e-40fb-aaad-9b409d2bc020@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
 <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>
 <JccRFVQkVQmZqt3Ri2w-Rm3VFba_MG_MV3Cwq-BKCCk=.c6507fc3-621e-40fb-aaad-9b409d2bc020@github.com>
Message-ID: <HFARfCeSDE-BVYt8bpI91ZFIKGUN50_di-0cWGrkQdM=.faaecc3e-6a06-4997-b1c7-3e88eeeef273@github.com>

On Fri, 8 Mar 2024 07:35:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 29:
>> 
>>> 27:  * @test
>>> 28:  * @bug 8325567
>>> 29:  * @requires (os.family == "linux") | (os.family == "aix")
>> 
>> Unless I'm mistaken, jspawn helper is used on Mac as well.
>
> Yes indeed, it is used for all Unix OSes (that is, everything but Windows).

I think what matters for this test test most is which platforms we build `jspawnhelper` for, and those platforms indeed are:


ifeq ($(call isTargetOs, macosx aix linux), true)
  $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \


So I'd say we just add `(os.family == "mac")` here. I would find it a bit weird to ask for `os.family != "windows"`, which would implicitly rely on exhaustiveness of current os family types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1517455696

From shade at openjdk.org  Fri Mar  8 09:23:55 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Mar 2024 09:23:55 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <f0qW2JMEqCCJbVo8bDHsH1ynIJu1Jfd0OIXEubDAZVY=.87fce65b-e9bf-4b7a-8503-515f1e55e657@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
 <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>
 <f0qW2JMEqCCJbVo8bDHsH1ynIJu1Jfd0OIXEubDAZVY=.87fce65b-e9bf-4b7a-8503-515f1e55e657@github.com>
Message-ID: <uk0u_Q-2hjW_sSdZuNkCADpy27ykj0WJGOpJiOYi6Qs=.113949d0-d8a1-486a-a785-23abe05d63f3@github.com>

On Thu, 7 Mar 2024 20:04:13 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> I wonder if it would make sense to add a test with a correct argument format?

I would say that is what current jspawnhelper tests already test, and it is also tested implicitly with `Process` tests. Let's keep this test for testing that warning messages are printed on most common cases of misuse -- that is why `JspawnhelperWarnings` is a good name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1517458419

From eirbjo at openjdk.org  Fri Mar  8 09:34:05 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 8 Mar 2024 09:34:05 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16952/files
  - new: https://git.openjdk.org/jdk/pull/16952/files/10db9803..243887b4

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

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

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

From eirbjo at openjdk.org  Fri Mar  8 09:41:02 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 8 Mar 2024 09:41:02 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v12]
In-Reply-To: <gS1-42kPZ4_NmtLfGkyDYm-ubE5OFOWgT-xoAWPqNLk=.1326d04e-98fe-405c-aef9-637b6d6b6c92@github.com>
References: <T1cRMdy0pbReTAlAxPs_IaydJYSgtZpBhlQW2Wkb5fI=.bdef4ba3-93d4-493b-95c7-78c791b949a1@github.com>
 <gS1-42kPZ4_NmtLfGkyDYm-ubE5OFOWgT-xoAWPqNLk=.1326d04e-98fe-405c-aef9-637b6d6b6c92@github.com>
Message-ID: <7lg5CunLzjmfv7Dy5BRyEO9tGqrFox75UiD6m817c-k=.434d8a81-cedc-4d5b-94b6-094c85e698f4@github.com>

On Sat, 2 Mar 2024 18:51:16 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
>> 
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> * `Deflater.getTotalOut()`
>> 
>> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
>> 
>> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
>> 
>> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is greater than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the new specification text an @implSpec

Thanks a lot to Jai, Lance & Alan for all your help in getting this PR across the finish line!

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

PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1985362189

From eirbjo at openjdk.org  Fri Mar  8 09:41:02 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 8 Mar 2024 09:41:02 GMT
Subject: Integrated: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater
In-Reply-To: <T1cRMdy0pbReTAlAxPs_IaydJYSgtZpBhlQW2Wkb5fI=.bdef4ba3-93d4-493b-95c7-78c791b949a1@github.com>
References: <T1cRMdy0pbReTAlAxPs_IaydJYSgtZpBhlQW2Wkb5fI=.bdef4ba3-93d4-493b-95c7-78c791b949a1@github.com>
Message-ID: <ny2vsyto1sAIYOGO_eUeyQYwAlD9Qj21889QHCiAUPg=.e7845ca2-1f96-47f3-9cce-901205360e2d@github.com>

On Mon, 19 Feb 2024 18:35:58 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is greater than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.

This pull request has now been integrated.

Changeset: d0d4912c
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0d4912c3bbc06e9a9c5273308d5f4ef7bac1b24
Stats:     28 lines in 2 files changed: 16 ins; 0 del; 12 mod

8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater

Co-authored-by: Jaikiran Pai <jpai at openjdk.org>
Reviewed-by: lancea, alanb

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

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

From ihse at openjdk.org  Fri Mar  8 10:12:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 10:12:53 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <HFARfCeSDE-BVYt8bpI91ZFIKGUN50_di-0cWGrkQdM=.faaecc3e-6a06-4997-b1c7-3e88eeeef273@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
 <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>
 <JccRFVQkVQmZqt3Ri2w-Rm3VFba_MG_MV3Cwq-BKCCk=.c6507fc3-621e-40fb-aaad-9b409d2bc020@github.com>
 <HFARfCeSDE-BVYt8bpI91ZFIKGUN50_di-0cWGrkQdM=.faaecc3e-6a06-4997-b1c7-3e88eeeef273@github.com>
Message-ID: <i4EZ34js4SllEel3vu6WKsQN0HSbLlC1dovJU0Nn2Yw=.100a6b5e-b607-4cc2-849b-b1ae548ffb1b@github.com>

On Fri, 8 Mar 2024 09:19:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yes indeed, it is used for all Unix OSes (that is, everything but Windows).
>
> I think what matters for this test test most is which platforms we build `jspawnhelper` for, and those platforms indeed are:
> 
> 
> ifeq ($(call isTargetOs, macosx aix linux), true)
>   $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \
> 
> 
> So I'd say we just add `(os.family == "mac")` here. I would find it a bit weird to ask for `os.family != "windows"`, which would implicitly rely on exhaustiveness of current os family types.

Hm, that is not ideal code in the makefile. `jspawnhelper` is called from `src/java.base/unix/classes/java/lang/ProcessImpl.java`, so it is relied upon for all Unix implementation. Granted, this is currently the same as the list "macosx aix linux", but it would be better to express the same logic in the makefile as in the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1517516188

From ihse at openjdk.org  Fri Mar  8 10:22:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 10:22:01 GMT
Subject: RFR: 8327675: jspawnhelper should be built on all unix platforms
Message-ID: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>

We should match the building of jspawnhelper in make/modules/java.base/Launcher.gmk with the usage for all unix platforms in src/java.base/unix/classes/java/lang/ProcessImpl.java.

Granted, the list of OSes in the makefile amounts to the current list of all Unix OSes in the JDK, but there is no need to have this logical disparity. 

This was inspired by the discovery in https://github.com/openjdk/jdk/pull/18112#discussion_r1517455696.

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

Commit messages:
 - 8327675: jspawnhelper should be built on all unix platforms

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

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

From shade at openjdk.org  Fri Mar  8 10:37:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Mar 2024 10:37:52 GMT
Subject: RFR: 8327675: jspawnhelper should be built on all unix platforms
In-Reply-To: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
References: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
Message-ID: <ObK8EgtSVM65DzG-toLoQbC9d1K90dIxA_ICA1RKfM4=.d2346676-ce4c-4e78-8d17-17768104a8d0@github.com>

On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should match the building of jspawnhelper in make/modules/java.base/Launcher.gmk with the usage for all unix platforms in src/java.base/unix/classes/java/lang/ProcessImpl.java.
> 
> Granted, the list of OSes in the makefile amounts to the current list of all Unix OSes in the JDK, but there is no need to have this logical disparity. 
> 
> This was inspired by the discovery in https://github.com/openjdk/jdk/pull/18112#discussion_r1517455696.

Looks good!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18165#pullrequestreview-1924580539

From stuefe at openjdk.org  Fri Mar  8 10:45:52 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Mar 2024 10:45:52 GMT
Subject: RFR: 8327675: jspawnhelper should be built on all unix platforms
In-Reply-To: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
References: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
Message-ID: <4iJlGCZ5sRQtOEk3XMUdnEfUFeBx35uOYzkgFpei_Sw=.2721533f-ddec-4fbc-bf2c-f11145c80b88@github.com>

On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should match the building of jspawnhelper in make/modules/java.base/Launcher.gmk with the usage for all unix platforms in src/java.base/unix/classes/java/lang/ProcessImpl.java.
> 
> Granted, the list of OSes in the makefile amounts to the current list of all Unix OSes in the JDK, but there is no need to have this logical disparity. 
> 
> This was inspired by the discovery in https://github.com/openjdk/jdk/pull/18112#discussion_r1517455696.

+1

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18165#pullrequestreview-1924593320

From jlahoda at openjdk.org  Fri Mar  8 11:24:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Mar 2024 11:24:00 GMT
Subject: Integrated: 8327218: Add an ability to specify modules which should
 have native access enabled
In-Reply-To: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
Message-ID: <PspfSo5N2K5QM43DLB17r8fl_x0INERRapg23AUQ2Wk=.487bbfaf-f063-4ebf-8eee-f765c6b16840@github.com>

On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
> 
> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.

This pull request has now been integrated.

Changeset: 27a03e0d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27a03e0dc3e08094aebc3524f68617f7e7fb5c5d
Stats:     132 lines in 9 files changed: 106 ins; 9 del; 17 mod

8327218: Add an ability to specify modules which should have native access enabled

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore, erikj, alanb, ihse

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

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

From jlahoda at openjdk.org  Fri Mar  8 11:31:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Mar 2024 11:31:57 GMT
Subject: RFR: 8327218: Add an ability to specify modules which should have
 native access enabled [v4]
In-Reply-To: <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>
References: <V7VGzF6ygL2srdO-St7fTZ5tU8J0JGHkM1CW_v4y1G0=.21bbf843-9239-42c9-83cc-718007971a29@github.com>
 <LuyQf5C7_EivKAgbdeYItXfozfGvvZUZ9J9A1jnCLzg=.03d0fd3b-bce5-49a2-9e85-66b0a77a39f0@github.com>
Message-ID: <tXfV4o18WKLPH_ke4NjEl_TBnM5eq1K8rRI4ZoOJ2s8=.fbb2e960-ae6f-4845-81f3-e35028b92a98@github.com>

On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat provided by JLine). But, for that, native access is needed for the `jdk.internal.le` module. We could possibly move the module to the platform ClassLoader, but it seems it might be better to have more control over which modules have the native access.
>> 
>> This patch introduces an explicit list of modules that will automatically be granted the native access. Note this patch is not yet intended to change the end behavior - the list of modules granted native access is supposed to be the same as modules in the boot and platform ClassLoaders.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting javadoc as suggested.

Thanks for all the feedback and comments! I've filled:
https://bugs.openjdk.org/browse/JDK-8327686
to cover the cleanup of the modules with native access enabled, and:
https://bugs.openjdk.org/browse/JDK-8327688
to allow to configure the modules with native access at link time.

I can try to take a look at either of those, if desired.

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

PR Comment: https://git.openjdk.org/jdk/pull/18106#issuecomment-1985530868

From vklang at openjdk.org  Fri Mar  8 13:59:59 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Mar 2024 13:59:59 GMT
Subject: RFR: 8327501: Common ForkJoinPool prevents class unloading in some
 cases
In-Reply-To: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
References: <1zeGU4sPrgVa3bDqGwG3ONk-1e2IIX4fL3se_9bSgLU=.a5bc3edc-a982-4481-8fc0-c40e03beef0f@github.com>
Message-ID: <fJA3OT74YBmNlHbOq-It7Sl9jP8CRSdUZmfqS_5JaLw=.363497ca-2df5-4ca6-ac5f-eb5f5cb7bda5@github.com>

On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> The common ForkJoinPool creating threads as a result of submitting tasks is preventing class unloading when the thread construction is initiated from a class loaded in a separate classloader. This fix avoids that when no SecurityManager is configured.

@trancexpress I defer all credit to @AlanBateman. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/18144#issuecomment-1985742052

From erikj at openjdk.org  Fri Mar  8 14:00:53 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Mar 2024 14:00:53 GMT
Subject: RFR: 8327675: jspawnhelper should be built on all unix platforms
In-Reply-To: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
References: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
Message-ID: <Ao9i-0TJSisUhtAEHZBWG3oOFN6gSw0XwY9TIDYPtbE=.366384c1-e897-45d5-a4f9-d65f65680d86@github.com>

On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should match the building of jspawnhelper in make/modules/java.base/Launcher.gmk with the usage for all unix platforms in src/java.base/unix/classes/java/lang/ProcessImpl.java.
> 
> Granted, the list of OSes in the makefile amounts to the current list of all Unix OSes in the JDK, but there is no need to have this logical disparity. 
> 
> This was inspired by the discovery in https://github.com/openjdk/jdk/pull/18112#discussion_r1517455696.

Looks good, but why are the tests failing?

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18165#pullrequestreview-1924937739

From ihse at openjdk.org  Fri Mar  8 14:23:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 14:23:59 GMT
Subject: RFR: 8327675: jspawnhelper should be built on all unix platforms
In-Reply-To: <Ao9i-0TJSisUhtAEHZBWG3oOFN6gSw0XwY9TIDYPtbE=.366384c1-e897-45d5-a4f9-d65f65680d86@github.com>
References: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
 <Ao9i-0TJSisUhtAEHZBWG3oOFN6gSw0XwY9TIDYPtbE=.366384c1-e897-45d5-a4f9-d65f65680d86@github.com>
Message-ID: <cNWccto_yF2J7jMYquHcz4xbvlgXlIn5lu1BhjBKUQE=.47485663-0e12-4afe-826f-0f1221262812@github.com>

On Fri, 8 Mar 2024 13:58:25 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Looks good, but why are the tests failing?

**macos-x64 / test (langtools/tier1)** fails when installing homebrew:


Error: Failure while executing; `/usr/bin/env /usr/local/Homebrew/Library/Homebrew/shims/shared/curl --disable --cookie /dev/null --globoff --user-agent Homebrew/4.2.9\ (Macintosh;\ Intel\ Mac\ OS\ X\ 13.6.4)\ curl/8.4.0 --header Accept-Language:\ en --fail --progress-bar --silent --remote-time --output /Users/runner/Library/Caches/Homebrew/api/formula.jws.json --location --disable --cookie /dev/null --globoff --show-error --user-agent Homebrew/4.2.9\ (Macintosh;\ Intel\ Mac\ OS\ X\ 13.6.4)\ curl/8.4.0 --header Accept-Language:\ en --fail --progress-bar --silent --compressed --speed-limit 100 --speed-time 5 [https://formulae.brew.sh/api/formula.jws.json`](https://formulae.brew.sh/api/formula.jws.json%60) exited with 28. Here's the output:
curl: (28) Operation too slow. Less than 100 bytes/sec transferred the last 5 seconds


**linux-cross-compile / build (riscv64)** fails when installing the sysroot:


W: Failure while configuring base packages.  This will be re-attempted up to five times.
W: See /home/runner/work/jdk/jdk/sysroot/debootstrap/debootstrap.log for details (possibly the package libpng16-16:riscv64 is at fault)


**linux-x86 / test (jdk/tier1 part 2)** fails on [java/util/Collections/RotateHuge](https://github.com/magicus/jdk/actions/runs/8201858400#summary-22432420637): (? ???)


? Test failures summary

These tests reported errors:

    [java/util/Collections/RotateHuge](https://github.com/magicus/jdk/actions/runs/8201858400#user-content-java_util_collections_rotatehuge)


I'd say that's just GHA for ya...

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

PR Comment: https://git.openjdk.org/jdk/pull/18165#issuecomment-1985779398

From ihse at openjdk.org  Fri Mar  8 14:24:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 14:24:00 GMT
Subject: Integrated: 8327675: jspawnhelper should be built on all unix
 platforms
In-Reply-To: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
References: <y65Aj8gEXdLvHrlHDhlFdjddBZIDW6gCmYuuMblIyw8=.b95be635-f21e-4384-9f02-f51dde872579@github.com>
Message-ID: <4CTQo9W4ME0OgeWcUyovkYMLndATupgjHbNEF6t-CIM=.447b1f69-b3f2-4a4b-a233-1b2a082c7776@github.com>

On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should match the building of jspawnhelper in make/modules/java.base/Launcher.gmk with the usage for all unix platforms in src/java.base/unix/classes/java/lang/ProcessImpl.java.
> 
> Granted, the list of OSes in the makefile amounts to the current list of all Unix OSes in the JDK, but there is no need to have this logical disparity. 
> 
> This was inspired by the discovery in https://github.com/openjdk/jdk/pull/18112#discussion_r1517455696.

This pull request has now been integrated.

Changeset: 585a9584
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/585a95844144da53bc43f5b6383e7c907bff7047
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8327675: jspawnhelper should be built on all unix platforms

Reviewed-by: shade, stuefe, erikj

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

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

From acobbs at openjdk.org  Fri Mar  8 15:22:11 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 8 Mar 2024 15:22:11 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v8]
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <tohDjkeCzaKUmbCjvWO6PMMnrhfxmoG5j6K-uehSjG8=.3104fba1-216b-4ace-b060-eece29d13a2f@github.com>

> `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 incrementally with one additional commit since the last revision:

  Back-out Javadoc addition; to be added in a separate issue.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17113/files
  - new: https://git.openjdk.org/jdk/pull/17113/files/d557d8c6..04072c19

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

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

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

From ihse at openjdk.org  Fri Mar  8 15:37:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 15:37:00 GMT
Subject: RFR: 8327701: Remove the xlc toolchain
Message-ID: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>

As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.

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

Commit messages:
 - 8327701: Remove the xlc toolchain

Changes: https://git.openjdk.org/jdk/pull/18172/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327701
  Stats: 333 lines in 19 files changed: 25 ins; 267 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/18172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18172/head:pull/18172

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

From ihse at openjdk.org  Fri Mar  8 15:37:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 15:37:02 GMT
Subject: RFR: 8327701: Remove the xlc toolchain
In-Reply-To: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
Message-ID: <McIPLciH42WumSGkYLGvyyqQ-tntHyzlYa-iou8p3W8=.800e6f9e-1844-4d56-8054-80477058573f@github.com>

On Fri, 8 Mar 2024 15:29:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.

make/autoconf/flags-cflags.m4 line 687:

> 685:     PICFLAG="-fPIC"
> 686:     PIEFLAG="-fPIE"
> 687:   elif test "x$TOOLCHAIN_TYPE" = xclang && test "x$OPENJDK_TARGET_OS" = xaix; then

Just a remark: This code has never been executed, since running with clang on any OS would hit the branch above. Also, the code is syntactically incorrect, missing a trailing `"`.

make/autoconf/flags-cflags.m4 line 695:

> 693:       -D$FLAGS_CPU_LEGACY"
> 694: 
> 695:   if test "x$FLAGS_CPU_BITS" = x64; then

A wise man said: "If the code and the comments contradict each other, then probably both are wrong".

I am here assuming that the comment claiming that this is only needed by xlc is correct. If it turns out that this is needed even with clang on AIX, we'll have to restore the test and update the comment to this fact.

make/autoconf/flags.m4 line 324:

> 322: AC_DEFUN([FLAGS_SETUP_TOOLCHAIN_CONTROL],
> 323: [
> 324:   # COMPILER_TARGET_BITS_FLAG  : option for selecting 32- or 64-bit output

COMPILER_TARGET_BITS_FLAG and COMPILER_BINDCMD_FILE_FLAG was introduced just for xlc, so they are not needed anymore. COMPILER_COMMAND_FILE_FLAG was introduced to support ancient versions of gcc, and then used by xlc as well. It is not needed for gcc anymore, so I remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1517871818
PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1517873282
PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1517874782

From ihse at openjdk.org  Fri Mar  8 15:40:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 15:40:57 GMT
Subject: RFR: 8327701: Remove the xlc toolchain
In-Reply-To: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
Message-ID: <ldsvuZ2jndrFP-OVZNw0oKI8hVK_T-1ItWKiUBN9g9M=.aa4a2a37-d87e-4fd5-ad72-2729748b1b5d@github.com>

On Fri, 8 Mar 2024 15:29:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.

make/autoconf/toolchain.m4 line 420:

> 418:     # Remove "Thread model:" and further details from the version string, and
> 419:     # collapse into a single line
> 420:     COMPILER_VERSION_STRING=`$ECHO $COMPILER_VERSION_OUTPUT | \

These changes are not strictly needed, but it makes printing the clang version nicer, and compensates for the removal of the extra version information that was printed by some of the removed code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1517880241

From ihse at openjdk.org  Fri Mar  8 15:48:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 15:48:08 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <hFoTfkg6kW-Eskfekboz2zsw04fhxDCtcZSJDX_5ZAE=.5d56943b-67ae-42ce-bdf5-4d972c4d03e8@github.com>

On Fri, 8 Mar 2024 15:44:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

make/autoconf/toolchain.m4 line 444:

> 442:   COMPILER_NAME=$2
> 443:   SEARCH_LIST="$3"
> 444:   SEARCH_PATH="$PATH"

I am note 100% sure about this; I think the intention of some of the old code amounted to this, but it was not entirely clear.

But, then again, I think this is a good idea, and I think we should do this on *all* platforms -- search the toolchain path before the normal path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1517884839

From ihse at openjdk.org  Fri Mar  8 15:48:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 15:48:08 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <hFoTfkg6kW-Eskfekboz2zsw04fhxDCtcZSJDX_5ZAE=.5d56943b-67ae-42ce-bdf5-4d972c4d03e8@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <hFoTfkg6kW-Eskfekboz2zsw04fhxDCtcZSJDX_5ZAE=.5d56943b-67ae-42ce-bdf5-4d972c4d03e8@github.com>
Message-ID: <HYb0qYm5jcYTQRg6E6nJZr6RfFzc4c2xg-W20M2S3WU=.2ea8e17c-1415-4eab-b9db-a70edee88b34@github.com>

On Fri, 8 Mar 2024 15:41:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 444:
> 
>> 442:   COMPILER_NAME=$2
>> 443:   SEARCH_LIST="$3"
>> 444:   SEARCH_PATH="$PATH"
> 
> I am note 100% sure about this; I think the intention of some of the old code amounted to this, but it was not entirely clear.
> 
> But, then again, I think this is a good idea, and I think we should do this on *all* platforms -- search the toolchain path before the normal path.

Hm, as I write this, it strikes me as odd that we should not do this already. And of course we do, in `TOOLCHAIN_PRE_DETECTION`, so this snippet snippet is actually redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1517889315

From ihse at openjdk.org  Fri Mar  8 15:48:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 15:48:08 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
Message-ID: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>

> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert SEARCH_PATH changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18172/files
  - new: https://git.openjdk.org/jdk/pull/18172/files/9f4a059d..53a05019

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

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

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

From ihse at openjdk.org  Fri Mar  8 15:55:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 15:55:54 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <mYm2C3YLu1415eKcAKPGBTAbToAR64cARDtZNQ2nl4w=.3422c02e-2d75-422b-9ab6-eafef1dea0f2@github.com>

On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

Also, I believe that the `HOTSPOT_TOOLCHAIN_TYPE=xlc` quirk actually is bad. This means that the clang functionality in `compilerWarnings_gcc.hpp` (where the `_gcc` is hotspot-speak for "clang or gcc") is being ignored, and it means that globalDefinitions_xlc.hpp is in big parts a direct copy of globalDefinitions_gcc.hpp, but apparently lagging in some fixes that has been made in that file.

And it means a lot of lines like this:

#if defined(TARGET_COMPILER_gcc) || defined(TARGET_COMPILER_xlc)


But cleaning up that is left as an exercise to the AIX team; my goal here just primarily to get rid of the old xlc stuff from the build system.

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

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1985939418

From iklam at openjdk.org  Fri Mar  8 16:00:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 8 Mar 2024 16:00:54 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L [v2]
In-Reply-To: <cw28aE2NtWnw9d5Wm1HLOSO6_pUjbDoO4OG29WA70fE=.7d39c879-367e-4dff-a20a-ec508d4842cd@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
 <cw28aE2NtWnw9d5Wm1HLOSO6_pUjbDoO4OG29WA70fE=.7d39c879-367e-4dff-a20a-ec508d4842cd@github.com>
Message-ID: <oS7XpZG_jajO16gcL3hWGm_qKEDOd9636UUrlSHwejE=.c34ce2cd-e5a4-44a6-bf2c-4492c23a2a1e@github.com>

On Fri, 8 Mar 2024 06:51:21 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> To avoid the CDS dump error message, a fix is during dumping a classlist, check if an invoker can be archived. 
>> If not, don't write the invoker info into the classlist, i.e. don't call `logLambdaFormInvoker()`. While generating holder classes (in `generateHolderClasses()`), don't add the `MethodType` to the `invokerTypes` if will fail the check in the `build()` method which would result in a `RuntimeException`.
>> 
>> Also updated the `MethodHandlesInvokersTest.java` under `appcds/methodHandles` and `appcds/dynamicArchive/methodHandles` to check that the "Failed to generate LambdaForm holder classes" error is not in the output;
>> 
>> Passed tiers 1 - 3 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comments and copyright update

Looks good. Just a small nit.

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 28:

> 26: package java.lang.invoke;
> 27: 
> 28: //import jdk.internal.misc.CDS;

This line can be removed.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17953#pullrequestreview-1925195828
PR Review Comment: https://git.openjdk.org/jdk/pull/17953#discussion_r1517911192

From jwaters at openjdk.org  Fri Mar  8 16:19:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Mar 2024 16:19:53 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <H74qiAaDMApqYoSWhSxsvg-xpzqcCmZnfxCjyQr6HLw=.3ecc0c42-b170-43a9-ae2c-bb43ba338287@github.com>

On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

Build changes look ok, but I'm not an AIX developer

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18172#pullrequestreview-1925243852

From rriggs at openjdk.org  Fri Mar  8 16:24:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Mar 2024 16:24:54 GMT
Subject: RFR: 8327167: Clarify the handling of Leap year by Calendar
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <dzOd5VGA78g9IcyXEjdSUFc3xQNlW-3Pambi7Wzr9H8=.61ec14c9-3ede-46aa-90e7-6cbfd55d4331@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1925260836

From ihse at openjdk.org  Fri Mar  8 16:50:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 16:50:03 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <SgsGUJfHNA8VUNYOMq84os1Z6fd65JmoL8LzCWuZ6lo=.9f170e6b-9cd6-4311-b541-32877614d325@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
 <SgsGUJfHNA8VUNYOMq84os1Z6fd65JmoL8LzCWuZ6lo=.9f170e6b-9cd6-4311-b541-32877614d325@github.com>
Message-ID: <nR3Iy0eJLNeJke0APzu9VKH7dF-etYghe_ojljC0aac=.0eac485f-51c1-458f-a35b-d91828559b7a@github.com>

On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman <alanb 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 46 commits:
>> 
>>  - Add @enablePreview for JImageValidator that uses classfile API
>>  - Fix SystemModulesPlugin after merge
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Don't show the verbose hint when already verbose
>>  - Use '_files' over '_resources' as the suffix for listing resources
>>  - Remove the hidden option hint.
>>    
>>    Also adjust the messages being printed when performing
>>    a run-time image link.
>>  - Localize messages, switch expression
>>  - Rename RunImageArchive => JRTArchive and RunImageLinkException => RuntimeImageLinkException
>>    
>>    Also moved the stamp file to jdk.jlink module. The resources files per
>>    module now get unconditionally created (empty if no resources not in the
>>    jimage).
>>  - First round of addressing review feedback.
>>    
>>    - Share resource names (JlinkTask and JlinkResourcesListPlugin)
>>    - Exclude resources in JlinkResourcesListPlugin the same way
>>      as done for other plugins.
>>  - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin
>>  - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69
>
> I tried out the latest commit (a797ea69).
> 
> The output "The default module path, '$java.home/jmods' not present. Use --verbose to show the full list of plugin options applied" is bit confusing as it looks like jlink failed but it actually succeeded. Blowing away the generated image and retrying with --verbose tripped this assert
> 
> java.lang.AssertionError: handling of scratch options failed
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already exists
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183)
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177)
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672)
> 	... 5 more
> 
> I haven't dug into this yet but I'm puzzled that the file path to where the original build was created is in the exception messages, is that recorded?

> @AlanBateman @mlchung I've now pushed an update of this patch which now uses a build-time approach as discussed elsewhere. In order to produce a linkable runtime JDK image, one needs to set --enable-runtime-link-image at configure time.

What is the rationale for introducing a special configure flag for this functionality? I've tried to look though all comments in this PR, and read the JBS issue and CSR, but I have not found any motivation for this. I'm sorry if it's there and I missed it, but this is a huge PR with a lot of discussion.

In general, it is better not to introduce variants of the build like this. The testing matrix just explodes a bit more. And my understanding from the discussion is that this functionality is likely to be turned on anyway, otherwise you'll build a crippled jlink without full functionality.

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

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

From ihse at openjdk.org  Fri Mar  8 16:54:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 16:54:59 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
Message-ID: <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>

On Tue, 27 Feb 2024 15:23:09 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:
> 
>   Only show runtime image suffix for JDK modules

make/Images.gmk line 96:

> 94: 
> 95: ifeq ($(JLINK_KEEP_PACKAGED_MODULES), true)
> 96:   ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)

I don't get it. Why don't you use the  JDK_LINK_OUTPUT_DIR from just above?

make/Images.gmk line 104:

> 102: endif
> 103: 
> 104: 

Is this extra line intentional?

make/Images.gmk line 144:

> 142:       OUTPUT_DIR := $(JDK_IMAGE_DIR), \
> 143:       SUPPORT_DIR := $(JDK_RUN_TIME_IMAGE_SUPPORT_DIR), \
> 144:       PRE_COMMAND := $(RM) -r $(JDK_IMAGE_DIR), \

This looks scary! Why the rm? Are you sure you are not racing with some other rule that tries to read from the JDK_IMAGE_DIR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1517984170
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1517983052
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1517982726

From ihse at openjdk.org  Fri Mar  8 16:58:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 16:58:00 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
Message-ID: <RfcULTVNyGGz5EGllBulkf9gKXr8KxzW9dGCIz6FTHw=.44ec1846-aaca-494e-abbc-9f1f2d75725b@github.com>

On Tue, 27 Feb 2024 15:23:09 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:
> 
>   Only show runtime image suffix for JDK modules

make/Images.gmk line 128:

> 126:   JDK_RUN_TIME_IMAGE_SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jlink-run-time
> 127:   JDK_JMODS_DIFF := $(JDK_RUN_TIME_IMAGE_SUPPORT_DIR)/jimage_packaged_modules_diff.data
> 128:   JLINK_RUNTIME_CREATE_EXTRA += --create-linkable-runtime=$(JDK_JMODS_DIFF)

My understanding is that the `--create-linkable-runtime` is the primary argument for the jlink invocation in jlink_runtime_jdk. As such, I think it would be much better if this was inlined in place in the jlink_runtime_jdk COMMAND. The "extra" makes it sound like it is optional. 

In contrast, the value of JLINK_RUNTIME_CREATE_EXTRA that is set above for JLINK_KEEP_PACKAGED_MODULES is indeed "extra".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1517986887

From ihse at openjdk.org  Fri Mar  8 17:01:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 17:01:54 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <iJXCpxHnzpiPbZBMD92Qayac44EVPs5-pAsQCKEXl7g=.eb918138-03ac-4c56-95c8-424573780d45@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

@JornVernee Are you okay with this solution? No JNI in foreign tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1986062755

From sgehwolf at openjdk.org  Fri Mar  8 17:22:03 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Mar 2024 17:22:03 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <SgsGUJfHNA8VUNYOMq84os1Z6fd65JmoL8LzCWuZ6lo=.9f170e6b-9cd6-4311-b541-32877614d325@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
 <SgsGUJfHNA8VUNYOMq84os1Z6fd65JmoL8LzCWuZ6lo=.9f170e6b-9cd6-4311-b541-32877614d325@github.com>
Message-ID: <d8auiA32eRo3tD89k7Dd5LsDwkFuytr9wUnStQYxuM4=.e5b292d8-8e0d-46e6-a9c9-e01ec0521def@github.com>

On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman <alanb 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 46 commits:
>> 
>>  - Add @enablePreview for JImageValidator that uses classfile API
>>  - Fix SystemModulesPlugin after merge
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Don't show the verbose hint when already verbose
>>  - Use '_files' over '_resources' as the suffix for listing resources
>>  - Remove the hidden option hint.
>>    
>>    Also adjust the messages being printed when performing
>>    a run-time image link.
>>  - Localize messages, switch expression
>>  - Rename RunImageArchive => JRTArchive and RunImageLinkException => RuntimeImageLinkException
>>    
>>    Also moved the stamp file to jdk.jlink module. The resources files per
>>    module now get unconditionally created (empty if no resources not in the
>>    jimage).
>>  - First round of addressing review feedback.
>>    
>>    - Share resource names (JlinkTask and JlinkResourcesListPlugin)
>>    - Exclude resources in JlinkResourcesListPlugin the same way
>>      as done for other plugins.
>>  - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin
>>  - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69
>
> I tried out the latest commit (a797ea69).
> 
> The output "The default module path, '$java.home/jmods' not present. Use --verbose to show the full list of plugin options applied" is bit confusing as it looks like jlink failed but it actually succeeded. Blowing away the generated image and retrying with --verbose tripped this assert
> 
> java.lang.AssertionError: handling of scratch options failed
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already exists
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183)
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177)
> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672)
> 	... 5 more
> 
> I haven't dug into this yet but I'm puzzled that the file path to where the original build was created is in the exception messages, is that recorded?

> > @AlanBateman @mlchung I've now pushed an update of this patch which now uses a build-time approach as discussed elsewhere. In order to produce a linkable runtime JDK image, one needs to set --enable-runtime-link-image at configure time.
> 
> What is the rationale for introducing a special configure flag for this functionality? I've tried to look though all comments in this PR, and read the JBS issue and CSR, but I have not found any motivation for this. I'm sorry if it's there and I missed it, but this is a huge PR with a lot of discussion.

Sorry, yes this was part of a meeting discussion we had outside this PR. My understanding is that by default the produced jimage isn't runtime-link enabled. We (Red Hat) would turn it on in our builds, though. @AlanBateman or @mlchung might have more details. I think it was a requirement to get this patch in. At least for the initial contribution.

> In general, it is better not to introduce variants of the build like this. The testing matrix just explodes a bit more. And my understanding from the discussion is that this functionality is likely to be turned on anyway, otherwise you'll build a crippled jlink without full functionality.

I would be happy if this could be on by default. For now, I think though we need to work on the premise that whether or not the resulting JDK image is suitable for runtime linking (without jmods) is a build-time config decision. Therefore we need the configure option.

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

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

From duke at openjdk.org  Fri Mar  8 17:24:24 2024
From: duke at openjdk.org (Elif Aslan)
Date: Fri, 8 Mar 2024 17:24:24 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v8]
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <W8D2UX7AC5bo8SXz5htPchBAr-lsGF0PHqTGZ8Z7Xas=.d474d8ad-8eb1-422a-a3d4-d17ad330108d@github.com>

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
> There is a new test added  to verify the behavior in such cases.
> 
> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
> 
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS

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

  Address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18112/files
  - new: https://git.openjdk.org/jdk/pull/18112/files/c82fb77b..ef321d2c

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

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

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

From sgehwolf at openjdk.org  Fri Mar  8 17:28:59 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Mar 2024 17:28:59 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
Message-ID: <HR5vtN-BWTARvcTPH2T1yXd5RBI1pxrUsy86poDnbew=.c3b2257f-f412-432c-a91e-a73b87856ed7@github.com>

On Fri, 8 Mar 2024 16:52:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only show runtime image suffix for JDK modules
>
> make/Images.gmk line 96:
> 
>> 94: 
>> 95: ifeq ($(JLINK_KEEP_PACKAGED_MODULES), true)
>> 96:   ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
> 
> I don't get it. Why don't you use the  JDK_LINK_OUTPUT_DIR from just above?

Makes sense. I can fold both `JLINK_JDK_EXTRA_OPTS` into one. `JLINK_JDK_EXTRA_OPTS := --keep-packaged-modules $(JDK_LINK_OUTPUT_DIR)/jmods`

> make/Images.gmk line 104:
> 
>> 102: endif
>> 103: 
>> 104: 
> 
> Is this extra line intentional?

No. I can remove it. Thanks.

> make/Images.gmk line 128:
> 
>> 126:   JDK_RUN_TIME_IMAGE_SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jlink-run-time
>> 127:   JDK_JMODS_DIFF := $(JDK_RUN_TIME_IMAGE_SUPPORT_DIR)/jimage_packaged_modules_diff.data
>> 128:   JLINK_RUNTIME_CREATE_EXTRA += --create-linkable-runtime=$(JDK_JMODS_DIFF)
> 
> My understanding is that the `--create-linkable-runtime` is the primary argument for the jlink invocation in jlink_runtime_jdk. As such, I think it would be much better if this was inlined in place in the jlink_runtime_jdk COMMAND. The "extra" makes it sound like it is optional. 
> 
> In contrast, the value of JLINK_RUNTIME_CREATE_EXTRA that is set above for JLINK_KEEP_PACKAGED_MODULES is indeed "extra".

Your understanding is correct. Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1518027506
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1518028421
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1518030091

From naoto at openjdk.org  Fri Mar  8 17:31:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Mar 2024 17:31:53 GMT
Subject: RFR: 8327486: java/util/Properties/PropertiesStoreTest.java fails
 "Text 'xxx' could not be parsed at index 20" after 8174269 [v2]
In-Reply-To: <TIM2O9xS2qCMSKwlku6XYK5kISSmnVHjNrbQvF83EuQ=.0ab31ad1-270d-49e7-bb56-3be9317c6f07@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
 <TIM2O9xS2qCMSKwlku6XYK5kISSmnVHjNrbQvF83EuQ=.0ab31ad1-270d-49e7-bb56-3be9317c6f07@github.com>
Message-ID: <PQQMR8CQSEJdux6yj1-RC-nT6RkhgiI_j-ATTFKSOgA=.8eeb6881-046e-4965-a003-871ef7b734d4@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240308/bf16e8d4/attachment.htm>

From sgehwolf at openjdk.org  Fri Mar  8 17:39:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Mar 2024 17:39:00 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
Message-ID: <gToCsx0XWYk3uFGdoJEWKimnRULPsh2GIhJMlV1K4f8=.d3da8551-91c0-47b5-a163-847ffc2e0e83@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240308/8877656a/attachment-0001.htm>

From sgehwolf at openjdk.org  Fri Mar  8 17:39:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Mar 2024 17:39:00 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <gToCsx0XWYk3uFGdoJEWKimnRULPsh2GIhJMlV1K4f8=.d3da8551-91c0-47b5-a163-847ffc2e0e83@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
 <gToCsx0XWYk3uFGdoJEWKimnRULPsh2GIhJMlV1K4f8=.d3da8551-91c0-47b5-a163-847ffc2e0e83@github.com>
Message-ID: <lhEDwRmaffeIq1qd7XgS5o1s9ynp39y4-IlBGdjFmHU=.cb39b8b7-e1de-4816-8748-67805c7970c8@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240308/710ee493/attachment.htm>

From jlu at openjdk.org  Fri Mar  8 18:12:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 8 Mar 2024 18:12:59 GMT
Subject: Integrated: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <biBtM98scIiA0Z9M2-krpwdAQkhuWspHwgmNAq1UGWc=.04e35c6e-55e2-46b4-9c74-20b4a7dbafc7@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240308/ac458786/attachment.htm>

From jvernee at openjdk.org  Fri Mar  8 18:15:53 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 8 Mar 2024 18:15:53 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <YvnZO9thUwxN_O0wk1moNpQvP8PLakWzD31_zlBQ5l0=.eee10e2d-5d7b-40ab-b5d9-c440d83671e6@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240308/3b8237ac/attachment-0001.htm>

From naoto at openjdk.org  Fri Mar  8 18:40:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Mar 2024 18:40:56 GMT
Subject: Integrated: 8327167: Clarify the handling of Leap year by Calendar
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <kMsHLW9U50TvfeEQpHYcRqBmZgbHuTz5vumMcKTPn40=.8cc13ffc-8c35-409a-9e31-81dceb19f30e@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

This pull request has now been integrated.

Changeset: 87b40c6a
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87b40c6ad2b0fa972fa6c5699a52045e82e0c7ef
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8327167: Clarify the handling of Leap year by Calendar

Reviewed-by: bpb, joehw, lancea, jlu, iris, rriggs

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

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

From ihse at openjdk.org  Fri Mar  8 18:47:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 18:47:54 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v7]
In-Reply-To: <i4EZ34js4SllEel3vu6WKsQN0HSbLlC1dovJU0Nn2Yw=.100a6b5e-b607-4cc2-849b-b1ae548ffb1b@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <-Oq7TXBG3KhdawgG1noFduwc_vyV1MqjJZL6R17kEGw=.8943ba92-e450-4d3a-a209-68171be03f74@github.com>
 <L-iZsqCHl4MDaMRKbixUVylzPXWTvRwHVkpqRwRl36s=.10735500-445f-4677-b70b-bc04f14d2643@github.com>
 <JccRFVQkVQmZqt3Ri2w-Rm3VFba_MG_MV3Cwq-BKCCk=.c6507fc3-621e-40fb-aaad-9b409d2bc020@github.com>
 <HFARfCeSDE-BVYt8bpI91ZFIKGUN50_di-0cWGrkQdM=.faaecc3e-6a06-4997-b1c7-3e88eeeef273@github.com>
 <i4EZ34js4SllEel3vu6WKsQN0HSbLlC1dovJU0Nn2Yw=.100a6b5e-b607-4cc2-849b-b1ae548ffb1b@github.com>
Message-ID: <qp8U7oniSPg-3R6bmExgvsTqartRJpcG9Oi8NhTSYA4=.9db33a89-8a55-4468-a921-a0381ff19619@github.com>

On Fri, 8 Mar 2024 10:10:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I think what matters for this test test most is which platforms we build `jspawnhelper` for, and those platforms indeed are:
>> 
>> 
>> ifeq ($(call isTargetOs, macosx aix linux), true)
>>   $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \
>> 
>> 
>> So I'd say we just add `(os.family == "mac")` here. I would find it a bit weird to ask for `os.family != "windows"`, which would implicitly rely on exhaustiveness of current os family types.
>
> Hm, that is not ideal code in the makefile. `jspawnhelper` is called from `src/java.base/unix/classes/java/lang/ProcessImpl.java`, so it is relied upon for all Unix implementation. Granted, this is currently the same as the list "macosx aix linux", but it would be better to express the same logic in the makefile as in the code.

JDK-8327675 was just integrated, which replaces the build logic for jspawnhelper to check for "unix" instead of enumerating all our unixes. I suggest the same pattern should be used here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18112#discussion_r1518152090

From erikj at openjdk.org  Fri Mar  8 18:51:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Mar 2024 18:51:54 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <AnMHKVWi_3oZVuemQQxlgm2OjFGSOcL52W6qXsBzurw=.27e93fd1-12f8-4504-bcfc-89112dc77f82@github.com>

On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

Build changes look good to me, but needs review and verification from the AIX folks.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18172#pullrequestreview-1925621925

From mchung at openjdk.org  Fri Mar  8 19:09:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 19:09:59 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
Message-ID: <LtLbIwq3lhhIbuHxTdebKfXEzRyysllmGVBa99uimRg=.1fe0638f-304f-437c-8693-91fdb438fbc8@github.com>

On Tue, 27 Feb 2024 15:23:09 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:
> 
>   Only show runtime image suffix for JDK modules

This PR is about having jlink to produce a run-time image without needing packaged modules (jmod files).   The motivation is that jmod files are huge in particular when native debug symbols are included.

The previous proposal to support jlink to create a run-time image without jmod files got too complicated and how plugins should revert/apply the transformation and how the users know what transformations are done in the resulting image.  The primary motivation for this is to produce OpenJDK run-time image without packaged modules (right now we called it _linkable JDK image_ but need to ponder on the name more) and jlink from such _linkable JDK image_ is capable of creating custom run-time image.   Per our offline discussion, the revised proposal is to add an "option" in the JDK build that can produce the linkable JDK image that does not include the packaged modules. 

The build option can be a configure option or a make target that would need advice from the build team.   Such build option would create a run-time image adjacent to `<build>/images/jdk` (for example `<build>/images/linkable-jdk`).   No proposal to change the default, i.e. the linkable image is not built by default.   This PR is to place the infrastructure and support in place.

@magicus is a make target more appropriate for this?

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

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

From naoto at openjdk.org  Fri Mar  8 19:42:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Mar 2024 19:42:52 GMT
Subject: RFR: JDK-8327631: Update IANA Language Subtag Registry to Version
 2024-03-07
In-Reply-To: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
References: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
Message-ID: <z1YqqfDbtobaAHQz6Ii0VvvitHNqMVRMuDFMY1T5pVQ=.d047c2b9-f4ac-447f-9197-76ab8b1fe820@github.com>

On Thu, 7 Mar 2024 23:31:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-03-07. Tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/000090.html

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18159#pullrequestreview-1925720318

From mchung at openjdk.org  Fri Mar  8 19:52:00 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 19:52:00 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <d8auiA32eRo3tD89k7Dd5LsDwkFuytr9wUnStQYxuM4=.e5b292d8-8e0d-46e6-a9c9-e01ec0521def@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
 <SgsGUJfHNA8VUNYOMq84os1Z6fd65JmoL8LzCWuZ6lo=.9f170e6b-9cd6-4311-b541-32877614d325@github.com>
 <d8auiA32eRo3tD89k7Dd5LsDwkFuytr9wUnStQYxuM4=.e5b292d8-8e0d-46e6-a9c9-e01ec0521def@github.com>
Message-ID: <pfmlRFINbo0U-CBIPHE1m75kkI52F78g-qTrgYcPwP0=.702c6158-3026-490f-8ddb-1fd49124f1e8@github.com>

On Fri, 8 Mar 2024 17:19:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I tried out the latest commit (a797ea69).
>> 
>> The output "The default module path, '$java.home/jmods' not present. Use --verbose to show the full list of plugin options applied" is bit confusing as it looks like jlink failed but it actually succeeded. Blowing away the generated image and retrying with --verbose tripped this assert
>> 
>> java.lang.AssertionError: handling of scratch options failed
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302)
>> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>> 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
>> Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already exists
>> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183)
>> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177)
>> 	at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672)
>> 	... 5 more
>> 
>> I haven't dug into this yet but I'm puzzled that the file path to where the original build was created is in the exception messages, is that recorded?
>
>> > @AlanBateman @mlchung I've now pushed an update of this patch which now uses a build-time approach as discussed elsewhere. In order to produce a linkable runtime JDK image, one needs to set --enable-runtime-link-image at configure time.
>> 
>> What is the rationale for introducing a special configure flag for this functionality? I've tried to look though all comments in this PR, and read the JBS issue and CSR, but I have not found any motivation for this. I'm sorry if it's there and I missed it, but this is a huge PR with a lot of discussion.
> 
> Sorry, yes this was part of a meeting discussion we had outside this PR. My understanding is that by default the produced jimage isn't runtime-link enabled. We (Red Hat) would turn it on in our builds, though. @AlanBateman or @mlchung might have more details. I think it was a requirement to get this patch in. At least for the initial contribution.
> 
>> In general, it is better not to introduce variants of the build like this. The testing matrix just explodes a bit more. And my understanding from the discussion is that this functionality is likely to be turned on anyway, otherwise you'll build a crippled jlink without full functionality.
> 
> I would be happy if this could be on by default. For now, I think though we need to work on the premise that whether or not the resulting JDK image is suitable for runtime linking (without jmods) is a build-time config decision. Therefore we need the configure option.

@jerboaa thanks for the update.  First to recap the revised proposal (based on Alan's notes shared with me earlier):

The JDK build is capable of producing a JDK run-time image that does not include packaged modules and the  new JDK image is capable to create custom run-time images (call it "linkable" JDK image for now).   To reconstitute to the original module content, the new JDK image conceptually needs to contain the "diffs" from the original packaged packaged.   This makes it possible for the jlink plugins to run "as if" the resources for each module were coming from the original packaged module.  The new image also has the checksums of at least the user-editable configuration files so that edits can be detected. 

The revised proposal has a few limitations:

1. The "linkable" JDK image can only be created by the JDK build.
2. The "linkable" JDK image is created from the JDK image produced by the JDK build today.  It contains the same set of modules, there is no possibility to combine its generation with other jlink options or code transformations.
3. The "linkable" JDK image cannot create a run-time image that contains the "jdk.jlink" module.
4. The "linkable" JDK image only reconstitutes classes/resources to the original module bits.   Other plugins such as man pages and dedup legal files are not reconstituted.

These limitations are trade-off to make for a much simpler approach. It removes the issues of creating a linkable JDK, or creating another image using a linkable JDK, while at the same time executing a pipeline of plugins that do other transformations.   

Here is my feedback to the prototype:

- I think the reader and writer code for generating the diffs should be in `jdk.jlink` so that they are always kept in sync.
- The diffs generation can be done as a tool or `jlink` option.  If it's a tool, it should be run on the interim image (like the tool generating classlist - see `GenerateLinkOptData.gmk`).

I have no strong opinion in which approach.   It seems worth exploring the tool approach residing in `jdk.jlink` to generate the diffs as well as create the linkable image could remove the need of a jlink internal `--create-linkable-runtime` option.

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

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

From rriggs at openjdk.org  Fri Mar  8 19:56:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Mar 2024 19:56:55 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v8]
In-Reply-To: <W8D2UX7AC5bo8SXz5htPchBAr-lsGF0PHqTGZ8Z7Xas=.d474d8ad-8eb1-422a-a3d4-d17ad330108d@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <W8D2UX7AC5bo8SXz5htPchBAr-lsGF0PHqTGZ8Z7Xas=.d474d8ad-8eb1-422a-a3d4-d17ad330108d@github.com>
Message-ID: <Y9dQgy2ra_jMKhPxX0-YoURHKA5kzkVogCr4l8OQzng=.ee169c1a-2b6c-4a3e-940f-c642703687ac@github.com>

On Fri, 8 Mar 2024 17:24:24 GMT, Elif Aslan <duke at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18112#pullrequestreview-1925740150

From naoto at openjdk.org  Fri Mar  8 19:59:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Mar 2024 19:59:01 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description
Message-ID: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>

Removing left over "applet" mention in the package-info doc.

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

Commit messages:
 - initial commit

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

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

From bpb at openjdk.org  Fri Mar  8 20:10:54 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 8 Mar 2024 20:10:54 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description
In-Reply-To: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
Message-ID: <5JkBUo0AOU9oZeE4DvDkUuBJ70tKw3NGDIcoKeziJbY=.e9886280-815e-4ee1-8785-34888e3fb4dc@github.com>

On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing left over "applet" mention in the package-info doc.

Farewell applets.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1925759402

From rriggs at openjdk.org  Fri Mar  8 20:40:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Mar 2024 20:40:54 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description
In-Reply-To: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
Message-ID: <qJlzO5qVuRSdtqpegZmlYqC6echQPXmiadMdR9lx9jM=.bdcd90de-6c9c-4a20-b954-89ec323cd395@github.com>

On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing left over "applet" mention in the package-info doc.

bye bye

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1925798262

From iris at openjdk.org  Fri Mar  8 20:52:53 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 8 Mar 2024 20:52:53 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description
In-Reply-To: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
Message-ID: <rI1mG4Xr9ZpO1C09JPw27F8jY0DncajwhQCtOeBXOp4=.0e49a7e4-cbde-4ad4-9c32-2ca5368abe27@github.com>

On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing left over "applet" mention in the package-info doc.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1925813600

From iris at openjdk.org  Fri Mar  8 20:56:53 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 8 Mar 2024 20:56:53 GMT
Subject: RFR: JDK-8327631: Update IANA Language Subtag Registry to Version
 2024-03-07
In-Reply-To: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
References: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
Message-ID: <wZ_QGetglDBuwFkHrmeBKu_vxvbF3QbjgIZA3sumbX8=.959667a3-c6c5-454c-93f9-3476f501e749@github.com>

On Thu, 7 Mar 2024 23:31:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-03-07. Tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/000090.html

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18159#pullrequestreview-1925817696

From jlu at openjdk.org  Fri Mar  8 21:01:53 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 8 Mar 2024 21:01:53 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description
In-Reply-To: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
Message-ID: <lPL6JNUhUWEt-KyGcXaFK-RwQySbpWFbYXY0VThqw74=.18ae1d74-88ef-4ec6-8013-8b3918b43cf3@github.com>

On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing left over "applet" mention in the package-info doc.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1925828046

From duke at openjdk.org  Fri Mar  8 22:12:07 2024
From: duke at openjdk.org (Elif Aslan)
Date: Fri, 8 Mar 2024 22:12:07 GMT
Subject: Integrated: 8325567: jspawnhelper without args fails with segfault
In-Reply-To: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
Message-ID: <ZR1a_P1bnRCXsnnZMLPCYEQQA0XfG8V1IAomhEoElJc=.f5bbeab7-496e-4cc4-8e25-006b5b0a65dd@github.com>

On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
> There is a new test added  to verify the behavior in such cases.
> 
> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
> 
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS

This pull request has now been integrated.

Changeset: 26274709
Author:    Elif Aslan <elifasln at amazon.com>
Committer: Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/262747094670b00ac63463a059074afa9b81d8a4
Stats:     62 lines in 2 files changed: 62 ins; 0 del; 0 mod

8325567: jspawnhelper without args fails with segfault

Co-authored-by: Vladimir Petko <vpetko at openjdk.org>
Reviewed-by: eastigeevich, rriggs, shade, vpetko

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

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

From eastigeevich at openjdk.org  Fri Mar  8 22:12:07 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 8 Mar 2024 22:12:07 GMT
Subject: RFR: 8325567: jspawnhelper without args fails with segfault [v8]
In-Reply-To: <W8D2UX7AC5bo8SXz5htPchBAr-lsGF0PHqTGZ8Z7Xas=.d474d8ad-8eb1-422a-a3d4-d17ad330108d@github.com>
References: <v5g-AoL0c4HldnSPOPmB7UTkyOJzOPIm0aTp_md3lOs=.d9159d7b-edc9-450b-95bf-b7ce92622ea9@github.com>
 <W8D2UX7AC5bo8SXz5htPchBAr-lsGF0PHqTGZ8Z7Xas=.d474d8ad-8eb1-422a-a3d4-d17ad330108d@github.com>
Message-ID: <DOs6eC4Ddk68ucQXgJdJNitRHr5rTj2qTsYprnyP23U=.ea15abd9-8a30-4f37-bd64-17d1491dd513@github.com>

On Fri, 8 Mar 2024 17:24:24 GMT, Elif Aslan <duke at openjdk.org> wrote:

>> This change is intended to address the segmentation fault issue that occurs when jspawnhelper is called without arguments,.
>> There is a new test added  to verify the behavior in such cases.
>> 
>> `[ec2-user at ip-172-16-0-10 jdk]$ make CONF=linux-x86_64-server-fastdebug test TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java`
>> 
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>
> Elif Aslan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

lgtm

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

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18112#pullrequestreview-1925932313

From matsaave at openjdk.org  Fri Mar  8 22:42:03 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 8 Mar 2024 22:42:03 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L [v2]
In-Reply-To: <cw28aE2NtWnw9d5Wm1HLOSO6_pUjbDoO4OG29WA70fE=.7d39c879-367e-4dff-a20a-ec508d4842cd@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
 <cw28aE2NtWnw9d5Wm1HLOSO6_pUjbDoO4OG29WA70fE=.7d39c879-367e-4dff-a20a-ec508d4842cd@github.com>
Message-ID: <5QBmIiB1d34AU5RhAvDsUq89bvE-X5GNzoB2vSBQHJM=.d938dbbf-829a-4869-a822-a42dbd98ef95@github.com>

On Fri, 8 Mar 2024 06:51:21 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> To avoid the CDS dump error message, a fix is during dumping a classlist, check if an invoker can be archived. 
>> If not, don't write the invoker info into the classlist, i.e. don't call `logLambdaFormInvoker()`. While generating holder classes (in `generateHolderClasses()`), don't add the `MethodType` to the `invokerTypes` if will fail the check in the `build()` method which would result in a `RuntimeException`.
>> 
>> Also updated the `MethodHandlesInvokersTest.java` under `appcds/methodHandles` and `appcds/dynamicArchive/methodHandles` to check that the "Failed to generate LambdaForm holder classes" error is not in the output;
>> 
>> Passed tiers 1 - 3 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comments and copyright update

LGTM! Please don't forget to address Ioi's nit before integration, thanks.

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17953#pullrequestreview-1925970472

From iklam at openjdk.org  Sat Mar  9 00:50:17 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Mar 2024 00:50:17 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v5]
In-Reply-To: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
Message-ID: <7zoQLBYjtLjHlhlme4yJ5F0zdpTuUSxMjfflSmSglY4=.a2849b60-b21f-4f42-a317-9cda62e16d9b@github.com>

> A few clean ups:
> 
> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
> 
> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
> 
> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
> 
> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
> 
> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.

Ioi Lam 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 branch 'master' into 8327138-clean-up-cdsConfig-and-CDS-java
 - @dholmes-ora comments -- white spaces and copyright
 - more alignment
 - fixed alignments
 - 8327138: Clean up status management in cdsConfig.hpp and CDS.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18095/files
  - new: https://git.openjdk.org/jdk/pull/18095/files/c8f08f7f..25c19bb4

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

  Stats: 82460 lines in 929 files changed: 7471 ins; 72858 del; 2131 mod
  Patch: https://git.openjdk.org/jdk/pull/18095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18095/head:pull/18095

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

From iklam at openjdk.org  Sat Mar  9 03:51:01 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Mar 2024 03:51:01 GMT
Subject: RFR: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java [v5]
In-Reply-To: <6FOFK8n6A5Kqpsg6BbEKTaaqiQgzQKfKflbIopBkD8A=.b58cff05-5f6b-46f7-ab55-1075dad877e7@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
 <17levG82EcbT5zXdxDurs1tNJ07sWRXxtZqBphDPGJE=.acf2e6c0-24fd-418d-ac03-96b2047c4837@github.com>
 <6FOFK8n6A5Kqpsg6BbEKTaaqiQgzQKfKflbIopBkD8A=.b58cff05-5f6b-46f7-ab55-1075dad877e7@github.com>
Message-ID: <XlBWc0J84pTN56rezNX7s6ljbIY021F8wynpsY4WWPA=.5566fa40-3492-4e9f-addd-03144f9bbfc5@github.com>

On Thu, 7 Mar 2024 22:59:38 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam 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 branch 'master' into 8327138-clean-up-cdsConfig-and-CDS-java
>>  - @dholmes-ora comments -- white spaces and copyright
>>  - more alignment
>>  - fixed alignments
>>  - 8327138: Clean up status management in cdsConfig.hpp and CDS.java
>
> Marked as reviewed by ccheung (Reviewer).

Thanks @calvinccheung @matias9927 @dholmes-ora for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18095#issuecomment-1986716664

From iklam at openjdk.org  Sat Mar  9 03:51:01 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Mar 2024 03:51:01 GMT
Subject: Integrated: 8327138: Clean up status management in cdsConfig.hpp and
 CDS.java
In-Reply-To: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
References: <ZZJ-hfAmDP3pqzjaB3lIiOWTNRIJPFRtGjtjZVlbd20=.2525b4e3-a1ae-452c-9bd7-41865aef0319@github.com>
Message-ID: <ISh9uY3R21CZq9pw4QQRu0aw5ktVlDhO5oRxKuAkajE=.ea4cd103-1243-4399-90b4-83747617f826@github.com>

On Sat, 2 Mar 2024 01:18:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> A few clean ups:
> 
> 1. Rename functions like "`s_loading_full_module_graph()` to `is_using_full_module_graph()`. The meaning of "loading" is not clear: it might be interpreted as to cover only the period where the artifact is being loaded, but not the period after the artifact is completely loaded. However, the function is meant to cover both periods, so "using" is a more precise term.
> 
> 2. The cumbersome sounding `disable_loading_full_module_graph()` is changed to `stop_using_full_module_graph()`, etc.
> 
> 3. The status of `is_using_optimized_module_handling()` is moved from metaspaceShared.hpp to cdsConfig.hpp, to be consolidated with other types of CDS status.
> 
> 4. The status of CDS was communicated to the Java class `jdk.internal.misc.CDS` by ad-hoc native methods. This is now changed to a single method, `CDS.getCDSConfigStatus()` that returns a bit field. That way we don't need to add a new native method for each type of status.
> 
> 5. `CDS.isDumpingClassList()` was a misnomer. It's changed to `CDS.isLoggingLambdaFormInvokers()`.

This pull request has now been integrated.

Changeset: 761ed250
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/761ed250ec4b0d92d091a0c316b6d5028986a019
Stats:     219 lines in 19 files changed: 58 ins; 58 del; 103 mod

8327138: Clean up status management in cdsConfig.hpp and CDS.java

Reviewed-by: ccheung, matsaave

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

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

From gli at openjdk.org  Sat Mar  9 04:35:56 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 9 Mar 2024 04:35:56 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <wJkJ2qFwd6o2UrZ2sA1pGmj9J2uHj_fa3TmmrkE80zQ=.7e76b080-600b-4eb6-947e-358bd6c57eb6@github.com>

On Fri, 8 Mar 2024 02:54:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> The fix updates ClassFileParser to calculate correct attributes_count.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 27:

> 25:  * @test
> 26:  * @bug 8315575
> 27:  * @summary test that records with invisible annotation can be retfansformed

Typo `retfansformed`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1518468461

From duke at openjdk.org  Sat Mar  9 08:12:02 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 9 Mar 2024 08:12:02 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v4]
In-Reply-To: <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
References: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
 <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
Message-ID: <K8bezHfXG3jGxppeVnojlOF1nmTzmq0wciTtlyuwrf4=.b66c26d9-0b32-41db-818e-755e4a07a3b7@github.com>

On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ReferencedKeySet::add

Should?this be?backported to?**JDK?22**, as?that was?when `jdk.internal.util.ReferencedKeySet` was?introduced?

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

PR Comment: https://git.openjdk.org/jdk/pull/17732#issuecomment-1986789023

From alanb at openjdk.org  Sat Mar  9 08:46:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Mar 2024 08:46:57 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <nR3Iy0eJLNeJke0APzu9VKH7dF-etYghe_ojljC0aac=.0eac485f-51c1-458f-a35b-d91828559b7a@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
 <SgsGUJfHNA8VUNYOMq84os1Z6fd65JmoL8LzCWuZ6lo=.9f170e6b-9cd6-4311-b541-32877614d325@github.com>
 <nR3Iy0eJLNeJke0APzu9VKH7dF-etYghe_ojljC0aac=.0eac485f-51c1-458f-a35b-d91828559b7a@github.com>
Message-ID: <WRausz5BeAa1o2Tf_IyALUGAb-fAfvOho0cqhQ8WXbg=.67205867-610f-45ca-896d-9f2a21479428@github.com>

On Fri, 8 Mar 2024 16:47:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> What is the rationale for introducing a special configure flag for this functionality? I've tried to look though all comments in this PR, and read the JBS issue and CSR, but I have not found any motivation for this. I'm sorry if it's there and I missed it, but this is a huge PR with a lot of discussion.
> 
> In general, it is better not to introduce variants of the build like this. The testing matrix just explodes a bit more. And my understanding from the discussion is that this functionality is likely to be turned on anyway, otherwise you'll build a crippled jlink without full functionality.

The JDK image (images/jdk) includes the packaged modules (as .jmod files) that the jlink tool can use to create other run-time images. The proposal here isn't meant to change this. "make images" should create the JDK image as before and that image will include the packaged modules.

The inclusion of the packaged modules has been problematic in some environments, esp. when there are debug symbols. libjvm.so can be huge, which begs the question as to why there is a copy in java.base.jmod. There are of course options to build the JDK image without --keep-packaged-modules and host the packaged modules as a separate download. Back in the JDK 9 we decided not to do this for Oracle downloads.

Severin has implemented an approach that allows "observable modules" be found in the current run-time image when using jlink. This requires some heretics and computation of diffs between the bits in the original packaged modules and the transformed bits in the run-time image. This exploration has gone through many iterations. Recently,  Severin, Mandy and I have met to try to simplify things and tame the goals in order to get to something that is maintainable, and to allow time to get experience with this direction.

So at a high-level, the intention is that the build be capable of producing an alternative JDK image that doesn't have a "jmods" directory. The jlink tool in that image has a limitation, a compromise to keep the complexity at a manageable level.  I have no opinion on whether the opt-in is at configure time or its just make target (like "make legacy-jre-image"). In the discussions it wasn't meant to be built by default. If distributions choose to distribute this image then this will likely influence what they test. Once experience builds up with using these run-time images then it may be that there is a proposal (and JEP) to make it the default, meaning images/jdk would not include .jmod files and multi-hop restriction is removed from jlink. That may be something for much further down the road.

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

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

From gli at openjdk.org  Sat Mar  9 09:18:52 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 9 Mar 2024 09:18:52 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description
In-Reply-To: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
Message-ID: <AJZEhZePgWGrMnwAHPnB2ctcXXcQnnqSiaX97egzdt0=.2f388ffb-7b19-4f42-bf25-93cce025b20b@github.com>

On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing left over "applet" mention in the package-info doc.

Marked as reviewed by gli (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1926166255

From alanb at openjdk.org  Sat Mar  9 11:14:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Mar 2024 11:14:52 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description
In-Reply-To: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
Message-ID: <FTRWM7MHekBt-x7pEP5FnkgLHVkA-hWD__8VsWBdiXc=.f32c16d1-5a3f-46b1-ad13-cb6e0a5de8c1@github.com>

On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing left over "applet" mention in the package-info doc.

src/java.base/share/classes/java/text/package-info.java line 29:

> 27:  * Provides classes and interfaces for handling text, dates, numbers,
> 28:  * and messages in a manner independent of natural languages.  This
> 29:  * means your application can be written to be

Maybe we should be broadened a bit, e.g  "an application or library" instead of "your application".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18173#discussion_r1518556238

From syan at openjdk.org  Sat Mar  9 13:18:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 9 Mar 2024 13:18:14 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: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
Message-ID: <uXMJVbzME6n126d3w9-3KcJdirDqfgovowjP80WHy2E=.2c2328d9-6d70-47b1-b134-cc026e51f3fa@github.com>

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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18155/files
  - new: https://git.openjdk.org/jdk/pull/18155/files/6827b2be..14751490

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

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

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

From syan at openjdk.org  Sat Mar  9 13:18:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 9 Mar 2024 13:18:14 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: <PQQMR8CQSEJdux6yj1-RC-nT6RkhgiI_j-ATTFKSOgA=.8eeb6881-046e-4965-a003-871ef7b734d4@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
 <TIM2O9xS2qCMSKwlku6XYK5kISSmnVHjNrbQvF83EuQ=.0ab31ad1-270d-49e7-bb56-3be9317c6f07@github.com>
 <PQQMR8CQSEJdux6yj1-RC-nT6RkhgiI_j-ATTFKSOgA=.8eeb6881-046e-4965-a003-871ef7b734d4@github.com>
Message-ID: <smP7kkPhTqW0ru44be6yUckKgjev6vEl7Eotvu1FytU=.ea84c985-b6a3-4c17-99a9-1d8e1a332ed9@github.com>

On Fri, 8 Mar 2024 17:29:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> 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>
>
> test/jdk/java/util/Properties/PropertiesStoreTest.java line 59:
> 
>> 57:     private static final String DATE_FORMAT_PATTERN = "EEE MMM dd HH:mm:ss zzz uuuu";
>> 58:     // use a neutral locale, since when the date comment was written by Properties.store(...),
>> 59:     // it internally calls the Date.toString() which always writes in a locale insensitive manner
> 
> Instead of blindly removing the comment, I'd suggest reflecting the fact that `Date.toString()` uses `Locale.US` for time zone names.

Thanks for your advice. The comment has been updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18155#discussion_r1518571662

From liach at openjdk.org  Sat Mar  9 15:41:57 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 9 Mar 2024 15:41:57 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v4]
In-Reply-To: <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
References: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
 <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
Message-ID: <wRdw4mE2UoDx9ggk4V1w5QDK1ACOZvMkDj4xVpCqnT8=.9e89be90-e9b6-4da0-9da7-bb21fbfc2e67@github.com>

On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ReferencedKeySet::add

ReferencedKeySet.add isn't used anywhere and this set implementation is not exposed to users at all. If this is backported, it will most likely become part of JDK 22 updates instead of JDK 22.

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

PR Comment: https://git.openjdk.org/jdk/pull/17732#issuecomment-1986889593

From james.laskey at oracle.com  Sat Mar  9 15:58:35 2024
From: james.laskey at oracle.com (Jim Laskey)
Date: Sat, 9 Mar 2024 15:58:35 +0000
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v4]
In-Reply-To: <wRdw4mE2UoDx9ggk4V1w5QDK1ACOZvMkDj4xVpCqnT8=.9e89be90-e9b6-4da0-9da7-bb21fbfc2e67@github.com>
References: <BgehEaftUiTczGPaSSlYzk7EN7WmyKg-CUsCLDUUe2c=.01edbd4f-449a-424e-ba97-29d5086f9d49@github.com>
 <XapQi7-zfD_SyRIlC7mZpYzPgDV-NLq_SZV5P3FuwLQ=.88ce64a1-a348-430b-9831-9819affe5e2b@github.com>
 <wRdw4mE2UoDx9ggk4V1w5QDK1ACOZvMkDj4xVpCqnT8=.9e89be90-e9b6-4da0-9da7-bb21fbfc2e67@github.com>
Message-ID: <7A8A6DF7-6425-48E3-83F3-D4BED7BBD694@oracle.com>

The class is used in java.lang.invoke.MethodType but add is not used. 

?

> On Mar 9, 2024, at 11:42?AM, Chen Liang <liach at openjdk.org> wrote:
> 
> ?On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
> 
>>> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.
>> 
>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Fix ReferencedKeySet::add
> 
> ReferencedKeySet.add isn't used anywhere and this set implementation is not exposed to users at all. If this is backported, it will most likely become part of JDK 22 updates instead of JDK 22.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/17732#issuecomment-1986889593

From eirbjo at openjdk.org  Sun Mar 10 06:23:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 10 Mar 2024 06:23:13 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe
Message-ID: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>

Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.

These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.

Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.

Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.

Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.

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

Commit messages:
 - Remove deprecated xxObject methods from jdk.internal.misc.Unsafe

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

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

From martin at openjdk.org  Sun Mar 10 06:42:55 2024
From: martin at openjdk.org (Martin Buchholz)
Date: Sun, 10 Mar 2024 06:42:55 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe
In-Reply-To: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
Message-ID: <dL5Jlqjf__V2HrNDAZkyO85v-40pUn79sU4hVFYuUQc=.468237f1-a795-4e96-8f89-2a5aaa184177@github.com>

On Sun, 10 Mar 2024 05:50:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
> 
> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
> 
> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
> 
> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
> 
> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.

Thanks for the tidying - I agree the time is right.

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

Marked as reviewed by martin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18176#pullrequestreview-1926388276

From alanb at openjdk.org  Sun Mar 10 07:32:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 10 Mar 2024 07:32:51 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe
In-Reply-To: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
Message-ID: <6aIYVj8H_9F3dLy_NlW7wZN4I30c4Wreu72kSRWmPrk=.e338b2dd-10a0-45cc-a39c-aeb5d61a91ad@github.com>

On Sun, 10 Mar 2024 05:50:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
> 
> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
> 
> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
> 
> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
> 
> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.

Removal of unused methods from an internal class, no impact to sun.misc.Unsafe.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18176#pullrequestreview-1926393501

From eirbjo at openjdk.org  Sun Mar 10 08:14:02 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 10 Mar 2024 08:14:02 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
Message-ID: <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>

> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
> 
> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
> 
> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
> 
> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
> 
> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Use getAndSetReference instead of getAndSetObject in test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18176/files
  - new: https://git.openjdk.org/jdk/pull/18176/files/997056d5..a333ed30

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

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

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

From eirbjo at openjdk.org  Sun Mar 10 08:27:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 10 Mar 2024 08:27:55 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
Message-ID: <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>

On Sun, 10 Mar 2024 08:14:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use getAndSetReference instead of getAndSetObject in test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java

Thanks for reviewing, Martin and Alan.

GHA revealed two call sites for ` getAndSetObject` in the test `test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java`. 

I have replaced these with the `getAndSetReference`, grepped for any remaining uses without finding anything. Let's see what GHA says.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987141915

From jpai at openjdk.org  Sun Mar 10 10:19:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Mar 2024 10:19:54 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
Message-ID: <KMVfpKIdNyS7-lp0oKh9BZ3XpUR2me_IJAxYaQXuhNA=.8199ca0c-7680-40d8-a430-21c79ef73f06@github.com>

On Sun, 10 Mar 2024 08:14:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use getAndSetReference instead of getAndSetObject in test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java

Hello Eirik, I've triggered internal CI testing of the current state of this PR to run tier1, tier2 and tier3.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987173153

From alanb at openjdk.org  Sun Mar 10 12:20:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 10 Mar 2024 12:20:53 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
 <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>
Message-ID: <mvqdpLUoz04ti59FH9JT8ZyKSFei-0CIjEMWkJNm3NY=.e3144ab0-1fe5-49f9-a125-bb3eac04d057@github.com>

On Sun, 10 Mar 2024 08:24:42 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> GHA revealed two call sites for `getAndSetObject` in the test `test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java`.
> 
> I have replaced these with the `getAndSetReference`, grepped for any remaining uses without finding anything. Let's see what GHA says.

Yes, you'll need to run all tests to make sure that there aren't any others, e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987207527

From eirbjo at openjdk.org  Sun Mar 10 13:47:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 10 Mar 2024 13:47:06 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
Message-ID: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>

> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
> 
> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
> 
> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
> 
> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
> 
> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Replace calls to Unsafe.putObject with Unsafe.putReference
 - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18176/files
  - new: https://git.openjdk.org/jdk/pull/18176/files/a333ed30..e199f6b0

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

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

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

From eirbjo at openjdk.org  Sun Mar 10 13:50:54 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 10 Mar 2024 13:50:54 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <mvqdpLUoz04ti59FH9JT8ZyKSFei-0CIjEMWkJNm3NY=.e3144ab0-1fe5-49f9-a125-bb3eac04d057@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
 <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>
 <mvqdpLUoz04ti59FH9JT8ZyKSFei-0CIjEMWkJNm3NY=.e3144ab0-1fe5-49f9-a125-bb3eac04d057@github.com>
Message-ID: <lWUvgOiCn6kMayaaXrtWDENNdBC_N5L01n0vIZoA__I=.0458150e-653d-40e1-91d0-4fe4e0a3cb9d@github.com>

On Sun, 10 Mar 2024 12:18:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Yes, you'll need to run all tests to make sure that there aren't any others, e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.

I've updated `TestUnstableStable` to use `putReference` and also fixed a stray code comment reference to `Unsafe.compareAndSetObject` in `BufferedInputStream`.

@jaikiran Expect `TestUnstableStable` above to fail your CI run.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987238716

From dl at openjdk.org  Sun Mar 10 14:21:54 2024
From: dl at openjdk.org (Doug Lea)
Date: Sun, 10 Mar 2024 14:21:54 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
Message-ID: <q3LJbhfrH78puUKIeJVvOVRlXGaA8pQ3o5arGgMs8SM=.33d6482c-0184-42eb-a272-7bcdeed89380@github.com>

On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace calls to Unsafe.putObject with Unsafe.putReference
>  - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

OK with me.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987248843

From jkratochvil at openjdk.org  Sun Mar 10 14:40:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sun, 10 Mar 2024 14:40:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>

> 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

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

Changes: https://git.openjdk.org/jdk/pull/17198/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=07
  Stats: 712 lines in 17 files changed: 438 ins; 214 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/17198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198

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

From jkratochvil at openjdk.org  Sun Mar 10 14:40:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sun, 10 Mar 2024 14:40:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v7]
In-Reply-To: <wXGRnXR7HJsLSZpY-MZl1jeb2t_t7W9klyJBnyWVeVE=.39b654f1-72d8-4966-b239-4fd46e26bc6d@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <wXGRnXR7HJsLSZpY-MZl1jeb2t_t7W9klyJBnyWVeVE=.39b654f1-72d8-4966-b239-4fd46e26bc6d@github.com>
Message-ID: <zFF_kjjQxqHB68LnJdl8xJ9BL7Bb0qrJ_QuBDJxDRtw=.ebbab1df-aa84-4de8-a058-ca2faac29fa2@github.com>

On Tue, 20 Feb 2024 15:15: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 23 commits:
> 
>  - Disable cgroup.subtree_control testcase on cgroup1
>  - Extend the testcase
>  - Implement cgroup.subtree_control .
>  - Remove dir_ix; only the trivial cases.
>  - Use *.effective kernel hints also in *.java
>  - Update for the kernel update *.effective
>  - Update for the kernel patch update hierarchical_memsw_limit->hierarchical_swap_limit
>  - Merge branch 'master' into master-cgroup
>  - Merge branch 'master' into master-cgroup
>  - Fail reading memory.stat only once
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/2546afe2...4d3b3aa9

After internal discussion I have realized the patch has overgrown its intended scope. And one should also consider how easy it would be for a backport down to JDK-8. I am going to split it into:
1. cgroup1 bugfix to always use kernel-side computed minimum `leaf/memory.stat` even if `leaf/memory.max` is not `max` - present in the current patch - to be split out under a new JDK Bug ID
2. cgroup1 change from reading `leaf/memory.stat` to traversal of `all-depths/memory.max`. - not present in the current patch, you have requested it, its only advantage is it does not reset some of the stats. Is it really needed? Also because cgroup1 is becoming outdated, RHEL7 ends this summer.
3. cgroup2 bugfix to implement traversal of `all-depths/memory.max` - present in the current patch - to be tracked under this JDK Bug ID.
4. cgroup2 kernel-side computed minimum in `leaf/memory.max.effective` - present in the current patch but not planned to but checked into OpenJDK before the kernel patch gets accepted.

Do you agree?

I have tried a backport to JDK-8 and it looks backportable.
[jdk8-cgroup.patch.txt](https://github.com/openjdk/jdk/files/14550104/jdk8-cgroup.patch.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1956455248
PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1987205880

From sgehwolf at openjdk.org  Sun Mar 10 14:40:09 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Sun, 10 Mar 2024 14:40:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v7]
In-Reply-To: <zFF_kjjQxqHB68LnJdl8xJ9BL7Bb0qrJ_QuBDJxDRtw=.ebbab1df-aa84-4de8-a058-ca2faac29fa2@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <wXGRnXR7HJsLSZpY-MZl1jeb2t_t7W9klyJBnyWVeVE=.39b654f1-72d8-4966-b239-4fd46e26bc6d@github.com>
 <zFF_kjjQxqHB68LnJdl8xJ9BL7Bb0qrJ_QuBDJxDRtw=.ebbab1df-aa84-4de8-a058-ca2faac29fa2@github.com>
Message-ID: <9931DvFo22AKT0JWjowYew7iej5HgUwDO5X8GKMLDhA=.bd3ffa77-7f69-42ea-a3bd-7a7838700712@github.com>

On Wed, 21 Feb 2024 11:32:46 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> After internal discussion I have realized the patch has overgrown its intended scope. And one should also consider how easy it would be for a backport down to JDK-8. I am going to split it into:
> 
>     1. cgroup1 bugfix to always use kernel-side computed minimum `leaf/memory.stat` even if `leaf/memory.max` is not `max` - present in the current patch - to be split out under a new JDK Bug ID
> 
>     2. cgroup1 change from reading `leaf/memory.stat` to traversal of `all-depths/memory.max`. - not present in the current patch, you have requested it, its only advantage is it does not reset some of the stats. Is it really needed? Also because cgroup1 is becoming outdated, RHEL7 ends this summer.
> 
>     3. cgroup2 bugfix to implement traversal of `all-depths/memory.max` - present in the current patch - to be tracked under this JDK Bug ID.
> 
>     4. cgroup2 kernel-side computed minimum in `leaf/memory.max.effective` - present in the current patch but not planned to but checked into OpenJDK before the kernel patch gets accepted.
> 
> 
> Do you agree?

I won't have time to properly review this this week. The latest version seemed to go into the right direction, though. Point 4.) above can only go in after *any* released kernel supports it to begin with.

One goal of this patch would be to unify how this works for cgroup v1 and cgroup v2. The on-init traversal for both versions makes sense as it solves the same problem (systemd slice) without using the hierarchical limit work-around (covers point 2 and 3). Point 1.) seems orthogonal to this patch, but I'm not sure I understand what it's about to begin with...

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1956638224

From jkratochvil at openjdk.org  Sun Mar 10 14:40:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sun, 10 Mar 2024 14:40:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v7]
In-Reply-To: <9931DvFo22AKT0JWjowYew7iej5HgUwDO5X8GKMLDhA=.bd3ffa77-7f69-42ea-a3bd-7a7838700712@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <wXGRnXR7HJsLSZpY-MZl1jeb2t_t7W9klyJBnyWVeVE=.39b654f1-72d8-4966-b239-4fd46e26bc6d@github.com>
 <zFF_kjjQxqHB68LnJdl8xJ9BL7Bb0qrJ_QuBDJxDRtw=.ebbab1df-aa84-4de8-a058-ca2faac29fa2@github.com>
 <9931DvFo22AKT0JWjowYew7iej5HgUwDO5X8GKMLDhA=.bd3ffa77-7f69-42ea-a3bd-7a7838700712@github.com>
Message-ID: <9nOz5LBHyxA4VAflzYqbooknEL60KovxZhETaevMxNw=.72f1dcbd-e0bd-46f3-9747-5a377026bb92@github.com>

On Wed, 21 Feb 2024 13:20:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> One goal of this patch would be to unify how this works for cgroup v1 and cgroup v2. 

That is not much possible anyway as currently cgroup2 has to traverse the directories while after the kernel patch gets accepted it will be faster using the new kernel interface.

> Point 1.) seems orthogonal to this patch, but I'm not sure I understand what it's about to begin with...

With current JDK if you set limits 1GB for memory:foo, 2GB for memory:foo/bar and you run a process in memory:foo/bar JDK will think the limit is 2GB despite the kernel will enforce a limit of 1GB.

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1956670590

From sgehwolf at openjdk.org  Sun Mar 10 14:40:09 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Sun, 10 Mar 2024 14:40:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v7]
In-Reply-To: <9nOz5LBHyxA4VAflzYqbooknEL60KovxZhETaevMxNw=.72f1dcbd-e0bd-46f3-9747-5a377026bb92@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <wXGRnXR7HJsLSZpY-MZl1jeb2t_t7W9klyJBnyWVeVE=.39b654f1-72d8-4966-b239-4fd46e26bc6d@github.com>
 <zFF_kjjQxqHB68LnJdl8xJ9BL7Bb0qrJ_QuBDJxDRtw=.ebbab1df-aa84-4de8-a058-ca2faac29fa2@github.com>
 <9931DvFo22AKT0JWjowYew7iej5HgUwDO5X8GKMLDhA=.bd3ffa77-7f69-42ea-a3bd-7a7838700712@github.com>
 <9nOz5LBHyxA4VAflzYqbooknEL60KovxZhETaevMxNw=.72f1dcbd-e0bd-46f3-9747-5a377026bb92@github.com>
Message-ID: <3cGmx4K2xnzRmPtRuyhuYvPxdSjUVgXJi1W1gAmvXYo=.cd9160d0-5146-40ac-bf3c-f02ace716a4c@github.com>

On Wed, 21 Feb 2024 13:37:22 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> > One goal of this patch would be to unify how this works for cgroup v1 and cgroup v2.
> 
> That is not much possible anyway as currently cgroup2 has to traverse the directories while after the kernel patch gets accepted it will be faster using the new kernel interface.

I think it should be using the "on-init traversal approach" for both.


>>    Point 1.) seems orthogonal to this patch, but I'm not sure I understand what it's about to begin with...
>
>With current JDK if you set limits 1GB for memory:foo, 2GB for memory:foo/bar and you run a process in memory:foo/bar JDK will think the limit is 2GB despite the kernel will enforce a limit of 1GB.

I'm surprised that the hierarchical memory limit look-up wouldn't see it for v1. Either way, using the traversal approach you'd see that `foo/bar` has `2 GB`, when traversing up the hierarchy you'd see `1 GB` for `foo` and use that as it's less than the earlier value. So would be covered by this fix? What am I missing?

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1956719869

From jkratochvil at openjdk.org  Sun Mar 10 14:40:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sun, 10 Mar 2024 14:40:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v7]
In-Reply-To: <3cGmx4K2xnzRmPtRuyhuYvPxdSjUVgXJi1W1gAmvXYo=.cd9160d0-5146-40ac-bf3c-f02ace716a4c@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <wXGRnXR7HJsLSZpY-MZl1jeb2t_t7W9klyJBnyWVeVE=.39b654f1-72d8-4966-b239-4fd46e26bc6d@github.com>
 <zFF_kjjQxqHB68LnJdl8xJ9BL7Bb0qrJ_QuBDJxDRtw=.ebbab1df-aa84-4de8-a058-ca2faac29fa2@github.com>
 <9931DvFo22AKT0JWjowYew7iej5HgUwDO5X8GKMLDhA=.bd3ffa77-7f69-42ea-a3bd-7a7838700712@github.com>
 <9nOz5LBHyxA4VAflzYqbooknEL60KovxZhETaevMxNw=.72f1dcbd-e0bd-46f3-9747-5a377026bb92@github.com>
 <3cGmx4K2xnzRmPtRuyhuYvPxdSjUVgXJi1W1gAmvXYo=.cd9160d0-5146-40ac-bf3c-f02ace716a4c@github.com>
Message-ID: <zvAcDg4XBWkT8b0bKOz2pBb_QfKDG3WG6K_uuSxoJ20=.c31a4fa1-3c60-46a7-991d-864031cf96f3@github.com>

On Wed, 21 Feb 2024 14:02:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> I'm surprised that the hierarchical memory limit look-up wouldn't see it for v1. Either way, using the traversal approach you'd see that `foo/bar` has `2 GB`, when traversing up the hierarchy you'd see `1 GB` for `foo` and use that as it's less than the earlier value. So would be covered by this fix? What am I missing?

It will be needlessly slower and it will not notice during execution changes of limits on other levels of the cgroup hierarchy than the initial chosen one.

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1956745199

From jpai at openjdk.org  Sun Mar 10 14:40:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Mar 2024 14:40:55 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <KMVfpKIdNyS7-lp0oKh9BZ3XpUR2me_IJAxYaQXuhNA=.8199ca0c-7680-40d8-a430-21c79ef73f06@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
 <KMVfpKIdNyS7-lp0oKh9BZ3XpUR2me_IJAxYaQXuhNA=.8199ca0c-7680-40d8-a430-21c79ef73f06@github.com>
Message-ID: <286GDeeFd02bderE-7wTOh0uKX_VDz7b3uu0Hc-Wqv0=.770a55b9-8d0b-4f59-8c3c-e2e28def620b@github.com>

On Sun, 10 Mar 2024 10:17:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use getAndSetReference instead of getAndSetObject in test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java
>
> Hello Eirik, I've triggered internal CI testing of the current state of this PR to run tier1, tier2 and tier3.

> @jaikiran Expect TestUnstableStable above to fail your CI run.

Right, that's the only test that failed (with a compilation error) on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987254844

From dholmes at openjdk.org  Mon Mar 11 02:39:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Mar 2024 02:39:55 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <qf1hQUA-XivudvebTcZWk3E1xkR5opV3pQy-qnNvbqo=.254083ec-ab5e-42d8-8cf2-9a5690cda466@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

Looks like a nice cleanup - great to see all the duplicated EXPORT code gone!

test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 24:

> 22:  */
> 23: 
> 24: #include <stdio.h>

Seems unneeded.

test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 27:

> 25: 
> 26: #include "export.h"
> 27: #include "jni.h"

Seems unneeded.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18135#pullrequestreview-1926822024
PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1519075894
PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1519076039

From alanb at openjdk.org  Mon Mar 11 07:00:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Mar 2024 07:00:56 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <-9V3vdX_4NWhrgoEYdqy9W-PyT8HBwjKyMwF-IzM9Uo=.c5f3e91a-017e-42c1-abc3-ab90c94f3b75@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

Good cleanup.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18135#pullrequestreview-1927041103

From alanb at openjdk.org  Mon Mar 11 07:00:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Mar 2024 07:00:56 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code
In-Reply-To: <D4VnoA_AetZT4vT_WasTrnfsavTpUH4oy8bCTL7HAWY=.5f2b4617-5854-4913-922e-aa84cd9c04a9@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <D4VnoA_AetZT4vT_WasTrnfsavTpUH4oy8bCTL7HAWY=.5f2b4617-5854-4913-922e-aa84cd9c04a9@github.com>
Message-ID: <_YFd8mgBis8mgRwfpafttLS2y1_-Aiy5aIdLr2eCXv8=.4890fb5d-cc8a-4cd8-a53d-3f18aa1dfbe6@github.com>

On Wed, 6 Mar 2024 12:14:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> * `test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c` was missing an export. This had not been discovered before since that file was not compiled on Windows.

It's a Linux/macOS specific test so it wasn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1987743188

From mbaesken at openjdk.org  Mon Mar 11 07:53:53 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Mar 2024 07:53:53 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <ymrpGsxg65O-y82OYS78OH_iUqSUP5n1irHNtpr1uhU=.8d577b81-8a93-4648-bb03-2bb866a02b1b@github.com>

On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

Hi, thanks for doing this cleanup change.  I put it into our build/test queue to see the results on AIX.

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

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1987807579

From jkern at openjdk.org  Mon Mar 11 09:23:57 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 11 Mar 2024 09:23:57 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>

On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

Changes requested by jkern (Author).

doc/building.html line 679:

> 677: <h3 id="ibm-open-xl-cc">IBM Open XL C/C++</h3>
> 678: <p>The minimum accepted version of Open XL is 17.1.1.4. This is in
> 679: essence clang 13, and will be treated as such by the OpenJDK build

It is clang 15 not 13. Clang 13 was in 17.1.0

doc/building.md line 493:

> 491: 
> 492: The minimum accepted version of Open XL is 17.1.1.4. This is in essence clang
> 493: 13, and will be treated as such by the OpenJDK build system.

clang 15 not 13

make/autoconf/toolchain.m4 line 285:

> 283:       XLC_TEST_PATH=${TOOLCHAIN_PATH}/
> 284:     fi
> 285:     if test "x$TOOLCHAIN_TYPE" = xclang; then

Why did you also remove the test for the clang compiler? Ah I see, you moved the clang compiler check down below

make/autoconf/toolchain.m4 line 409:

> 407:     #    Target: powerpc-ibm-aix7.2.0.0
> 408:     #    Thread model: posix
> 409:     #    InstalledDir: /opt/IBM/openxlC/17.1.0/bin

Please correct:
IBM Open XL C/C++ for AIX 17.1.**1** (xxxxxxxxxxxxxxx), clang version 1**5**.0.0
    #    Target: **powerpc-ibm-aix7.2.**5**.7**
    #    Thread model: posix
    #    InstalledDir: /opt/IBM/openxlC/17.1.**1**/bin

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

PR Review: https://git.openjdk.org/jdk/pull/18172#pullrequestreview-1927198641
PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1519321337
PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1519321980
PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1519358938
PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1519365934

From jkern at openjdk.org  Mon Mar 11 09:23:58 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 11 Mar 2024 09:23:58 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <McIPLciH42WumSGkYLGvyyqQ-tntHyzlYa-iou8p3W8=.800e6f9e-1844-4d56-8054-80477058573f@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <McIPLciH42WumSGkYLGvyyqQ-tntHyzlYa-iou8p3W8=.800e6f9e-1844-4d56-8054-80477058573f@github.com>
Message-ID: <U1lfAxBkklFXkNC4jPSOY9jM-uvs0vMuHH7VZgAC0AM=.4445f8df-c8c8-4363-a35e-b89c571cde03@github.com>

On Fri, 8 Mar 2024 15:31:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert SEARCH_PATH changes
>
> make/autoconf/flags-cflags.m4 line 687:
> 
>> 685:     PICFLAG="-fPIC"
>> 686:     PIEFLAG="-fPIE"
>> 687:   elif test "x$TOOLCHAIN_TYPE" = xclang && test "x$OPENJDK_TARGET_OS" = xaix; then
> 
> Just a remark: This code has never been executed, since running with clang on any OS would hit the branch above. Also, the code is syntactically incorrect, missing a trailing `"`.

OK this was a flaw in my introduction of clang toolchain for AIX. The intention was to keep the xlc options in form of their clang counterparts. I will try with a corrected version for clang on AIX and will come back to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1519347031

From jwaters at openjdk.org  Mon Mar 11 09:32:58 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 11 Mar 2024 09:32:58 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>
Message-ID: <Ioh-YZlIDNY5Uts86Hq24PW7qlhd4G0ztoY7Kyjqxqs=.620fb161-9f94-4bb0-acea-c6245869069e@github.com>

On Mon, 11 Mar 2024 08:38:53 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert SEARCH_PATH changes
>
> doc/building.html line 679:
> 
>> 677: <h3 id="ibm-open-xl-cc">IBM Open XL C/C++</h3>
>> 678: <p>The minimum accepted version of Open XL is 17.1.1.4. This is in
>> 679: essence clang 13, and will be treated as such by the OpenJDK build
> 
> It is clang 15 not 13. Clang 13 was in 17.1.0

Is Open XL C/C++ considered a compiler or more akin to a development environment like Xcode is for macOS? Depending on which, we could just say clang is the compiler for AIX without needing to say that Open XL is treated like clang, etc

Also, why did this remove the link to the Supported Build Platforms page?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1519394251

From duke at openjdk.org  Mon Mar 11 11:15:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 11 Mar 2024 11:15:14 GMT
Subject: RFR: 8315585: Optimization for new BigDecimal(String)
Message-ID: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@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..

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

Commit messages:
 - fix code style
 - optimization for new BigDecimal(char[])
 - optimization for new BigDecimal(String)

Changes: https://git.openjdk.org/jdk/pull/18177/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315585
  Stats: 407 lines in 4 files changed: 331 ins; 29 del; 47 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 duke at openjdk.org  Mon Mar 11 11:15:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 11 Mar 2024 11:15:14 GMT
Subject: RFR: 8315585: Optimization for new BigDecimal(String)
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <7MCZEKMz_4oXd0WDcFpbkBpo-fTeCeOCN1c6RMgCzAA=.7285d25e-fbde-47de-a8b2-97855ce68797@github.com>

On Sun, 10 Mar 2024 16:11:12 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..

The performance numbers under MacBookPro M1 Max are as follows:

-Benchmark                              Mode  Cnt   Score   Error  Units (master)
-BigDecimals.testConstructorWithString  avgt   15  66.005 ? 0.733  ns/op

+Benchmark                              Mode  Cnt   Score   Error  Units (current version #aaf04f6)
+BigDecimals.testConstructorWithString  avgt   15  39.720 ? 0.266  ns/op +66.17%

Compared to directly using a char[], using CharBuffer.wrap leads to a 27% decrease in performance.

The performance numbers under MacBookPro M1 Max are as follows:

Benchmark                                 Mode  Cnt   Score   Error  Units (char[] direct)
BigDecimals.testConstructorWithCharArray  avgt   15  41.998 ? 0.259  ns/op

Benchmark                                 Mode  Cnt   Score   Error  Units (CharBuffer.wrap)
BigDecimals.testConstructorWithCharArray  avgt   15  53.533 ? 1.297  ns/op -27.46%

Now, new BigDecimal(char[]) and new BigDecimal(String) are using the same algorithm. 

They are two separate paths, and both have seen performance improvements.

The performance numbers under MacBookPro M1 Max are as follows:

-Benchmark                                 Mode  Cnt    Score   Error  Units (master)
-BigDecimals.testConstructorWithCharArray  avgt   15   48.448 ? 1.879  ns/op
-BigDecimals.testConstructorWithString     avgt   15   65.203 ? 3.871  ns/op

+Benchmark                                 Mode  Cnt    Score    Error  Units ?current #)
+BigDecimals.testConstructorWithCharArray  avgt   15   41.166 ?  0.940  ns/op +17.68%
+BigDecimals.testConstructorWithString     avgt   15   39.289 ?  0.159  ns/op +65.95%

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1987283721
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1987601447
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1988185886

From liach at openjdk.org  Mon Mar 11 11:15:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Mar 2024 11:15:14 GMT
Subject: RFR: 8315585: Optimization for new BigDecimal(String)
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <Z6uV9dIsKjhcfBur5AAn-BDSmUAehJTu-p_lnb1KfAs=.61390a7c-90b8-4351-8ca7-1e79ee460191@github.com>

On Sun, 10 Mar 2024 16:11:12 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..

Good idea! Since we are now maintaining two code paths, when we update one, we might forget about the other; is it possible to create another interal constructor that takes a `CharSequence`, so we can pass the string in directly, and we pass the `char[]` via `CharBuffer.wrap()`?

Hmm, `CharBuffer.wrap()` only allocates a wrapper without copying the passed char array argument. Say we have something like this:

public BigDecimal(String val) {
    this((CharSequence) val, 0, val.length()); // cast
}

public BigDecimal(char[] val) {
    this(CharBuffer.wrap(val), 0, val.length); // allocate a wrapper without copying val
}

private BigDecimal(CharSequence seq, int start, int end) {
    // actual code
}


Can't escape analysis eliminate the `CharBuffer` wrapper here so that each char array access via `seq.charAt` becomes much slower? I know profile pollution from 2 implementations of `CharSequence` can affect JIT, but I don't think that's a good reason to duplicate a lot of code, which is bug prone.

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1987352817
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1987480225

From duke at openjdk.org  Mon Mar 11 11:15:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 11 Mar 2024 11:15:14 GMT
Subject: RFR: 8315585: Optimization for new BigDecimal(String)
In-Reply-To: <Z6uV9dIsKjhcfBur5AAn-BDSmUAehJTu-p_lnb1KfAs=.61390a7c-90b8-4351-8ca7-1e79ee460191@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <Z6uV9dIsKjhcfBur5AAn-BDSmUAehJTu-p_lnb1KfAs=.61390a7c-90b8-4351-8ca7-1e79ee460191@github.com>
Message-ID: <64z0klXgvA509tkG7f5df9fnA2PIM_kaNvrXaUXm8Sg=.b8ca4fc5-893d-4984-af6e-1ed45ec29d28@github.com>

On Sun, 10 Mar 2024 20:27:56 GMT, Chen Liang <liach at openjdk.org> wrote:

> Good idea! Since we are now maintaining two code paths, when we update one, we might forget about the other; is it possible to create another interal constructor that takes a `CharSequence`, so we can pass the string in directly, and we pass the `char[]` via `CharBuffer.wrap()`?

Your suggestion could reduce duplicate code, but it would make new BigDecimal(char[]) slower. Some programs have already optimized specifically for char[], such as:

https://github.com/mysql/mysql-connector-j/blob/release/8.x/src/main/protocol-impl/java/com/mysql/cj/protocol/a/MysqlBinaryValueDecoder.java#L275 

package com.mysql.cj.protocol.a;
public class MysqlBinaryValueDecoder {
  public <T> T decodeDecimal(byte[] bytes, int offset, int length, ValueFactory<T> vf) {
        BigDecimal d = new BigDecimal(StringUtils.toAsciiCharArray(bytes, offset, length));
        return vf.createFromBigDecimal(d);
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1987461885

From vklang at openjdk.org  Mon Mar 11 12:07:58 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Mar 2024 12:07:58 GMT
Subject: Integrated: 8269428:
 java/util/concurrent/ConcurrentHashMap/ToArray.java timed out
In-Reply-To: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
References: <j1FtwjQPwy9ytrdiu7PfUi9AuUbA5VX1i09ZXMV3u1k=.ea934bad-0c60-4904-9ffd-1b6e6e9fdf6c@github.com>
Message-ID: <DCSx-RsFvAEcOILQGmUgv4RQFCXQgBk_-qtoXhkOqOg=.69e6034e-95bd-4d8e-9a63-7176bb4e3f7d@github.com>

On Tue, 27 Feb 2024 10:30:44 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> As an intermediate fix to the test, switching to explicit usage of an ExecutorService seems to do the trick to make this test reliably pass.
> 
> With that said, this test (CHM::ToArray.java) seems to trigger an issue in ForkJoinPool, so that would need to be fixed separately.
> 
> Tagging @DougLea as an FYI. :)

This pull request has now been integrated.

Changeset: 570ad672
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/570ad67204a55dd4b45e04e5a91671fed2cc18d0
Stats:     50 lines in 1 file changed: 3 ins; 0 del; 47 mod

8269428: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out

Reviewed-by: jpai

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

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

From jkern at openjdk.org  Mon Mar 11 12:29:55 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 11 Mar 2024 12:29:55 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <0yRLC1SM9um8MIZYJP6sf8OOMeOCbzCc1LF_JQLxZHg=.e3391f4e-ab9e-423c-880c-e84aba29e87b@github.com>

On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

make/autoconf/toolchain.m4 line 940:

> 938:   if test "x$OPENJDK_TARGET_OS" = xaix; then
> 939:     # Make sure we have the Open XL version of clang on AIX
> 940:     $ECHO "$CC_VERSION_OUTPUT" | $GREP "IBM Open XL C/C++ for AIX" > /dev/null

This does not work since $CC_VERSION_OUTPUT is unset. We need 
	CC_VERSION_OUTPUT=`${XLC_TEST_PATH}ibm-clang++_r --version 2>&1 | $HEAD -n 1`
before, as in the previous code some lines above which you removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1519634810

From mbaesken at openjdk.org  Mon Mar 11 12:47:57 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Mar 2024 12:47:57 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <guGW7d1XFNl7TE84CKTrkWngW5mNZ8dEhgiUaUphTcQ=.447ec868-160f-4f96-9dc3-16e955e1c8d7@github.com>

On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

With this change added, currently  configure fails 


checking for ibm-llvm-cxxfilt... /opt/IBM/openxlC/17.1.1/tools/ibm-llvm-cxxfilt
configure: error: ibm-clang_r version output check failed, output: 
configure exiting with result code 

maybe  related to what Joachim pointed out ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1988358518

From erikj at openjdk.org  Mon Mar 11 13:10:00 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Mar 2024 13:10:00 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <lhEDwRmaffeIq1qd7XgS5o1s9ynp39y4-IlBGdjFmHU=.cb39b8b7-e1de-4816-8748-67805c7970c8@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
 <gToCsx0XWYk3uFGdoJEWKimnRULPsh2GIhJMlV1K4f8=.d3da8551-91c0-47b5-a163-847ffc2e0e83@github.com>
 <lhEDwRmaffeIq1qd7XgS5o1s9ynp39y4-IlBGdjFmHU=.cb39b8b7-e1de-4816-8748-67805c7970c8@github.com>
Message-ID: <Wc4EhkYtdpo85jdS0HKUqWM_fZvSkND-wNzJysojm-c=.0745ccb4-a7ba-4583-b8af-85d515710cb5@github.com>

On Fri, 8 Mar 2024 17:36:33 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> That was modelled similar to `jdk_jlink` target. It also does the removal. When building with `--enable-runtime-link-image`, the flow is:
>> 
>> 
>> 1. Link the initial jdk image (current `images/jdk`). Output is $(RL_INTERMEDIATE_IMAGE_DIR)
>> 2. Generate the diff to the packaged modules (target `generate_jimage_diff`)
>> 3. Do the final link creating a runtime linkable jimage with `--create-linkabel-runtime` into `JDK_IMAGE_DIR`.
>> 
>> 
>> All three steps should have appropriate dependencies on each other. So I don't think there is a race. If you see one please let me know! Thanks.
>
> Why the rm? Because jlink refuses to run if the output dir already exists.

I don't see a race. The `rm` was there in the original code and is no scarier in the modified version. The jdk image is constructed by a combination of targets and recipes. The first one to run has to be jlink, then we overlay more stuff on top. If the makefile dependency resolution concludes that we need to rerun the jlink step, we clear out the directory completely to make sure we aren't leaving anything in there that's no longer valid. This is basically a precaution to guarantee a correct incremental build. It's not incurring a big build time penalty as jlink would have overwritten all files it would have created anyway. However, if a module was removed, or a file was removed from a module, the `rm` helps guarantee that we don't include such a removed file from a previous build attempt in the final image.

Or it may even be as Severin says, that jlink refuses to run, I don't remember.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1519686906

From liach at openjdk.org  Mon Mar 11 13:20:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Mar 2024 13:20:53 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String)
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <Jcy75C9sPMbbvn9zCdAPueZPtw3zaZ8bzQ1rpTxK8qQ=.e0a82116-6b9f-49a2-8038-8eaafad427cc@github.com>

On Sun, 10 Mar 2024 16:11:12 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..

src/java.base/share/classes/java/math/BigDecimal.java line 1049:

> 1047:                         if (dot)
> 1048:                             ++scl;
> 1049:                     } else if ((c == 'e') || (c == 'E')) {

Can we keep this block in parity with the `char[]` version?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1519691857

From erikj at openjdk.org  Mon Mar 11 13:28:01 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Mar 2024 13:28:01 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
Message-ID: <pNnvkNgyVts2GAa5gnEHc99kgO1urANdUITZRRZd458=.dc589e0e-0c0d-4614-b848-f883446f52e8@github.com>

On Tue, 27 Feb 2024 15:23:09 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:
> 
>   Only show runtime image suffix for JDK modules

> > What is the rationale for introducing a special configure flag for this functionality? I've tried to look though all comments in this PR, and read the JBS issue and CSR, but I have not found any motivation for this. I'm sorry if it's there and I missed it, but this is a huge PR with a lot of discussion.
> > In general, it is better not to introduce variants of the build like this. The testing matrix just explodes a bit more. And my understanding from the discussion is that this functionality is likely to be turned on anyway, otherwise you'll build a crippled jlink without full functionality.
> 
> I have no opinion on whether the opt-in is at configure time or its just make target (like "make legacy-jre-image"). In the discussions it wasn't meant to be built by default. If distributions choose to distribute this image then this will likely influence what they test. Once experience builds up with using these run-time images then it may be that there is a proposal (and JEP) to make it the default, meaning images/jdk would not include .jmod files and multi-hop restriction is removed from jlink. That may be something for much further down the road.

The choice between a configure option to modify the meaning of the `jdk-image` target (and subsequently the `product-bundles` target), and adding an additional `foo-image` target (and bundle definition) mainly comes down to if there is ever a usecase for producing both the current/default jdk image and this new image side by side. Back when we still had a JRE, producing both the JDK and JRE from the same build was required as they were two different supported distributions that users were expected to pick between depending on usecase. This option however sounds much more like an either or choice for the OpenJDK distributor. Unless RedHat is planning on distributing both variants side by side, the configure option makes the most sense. It minimizes the need for further modifications of the makefiles (for defining a new bundle for this new image), the test makefiles (for defining a way to run tests on this new image), and other parts of the build pipeline for anyone who wants to build 
 and distribute this new image.

Based on that I agree with the choice of using a configure argument.

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

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

From rgiulietti at openjdk.org  Mon Mar 11 13:34:54 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 11 Mar 2024 13:34:54 GMT
Subject: RFR: JDK-8327487: Further augment WorstCaseTests with more cases
 [v2]
In-Reply-To: <xhxbP_hqaoheV5zsDJ2l5voSX4VJ0nWquvmKX6Xy0bg=.8e8091bf-9fab-4b67-aa2d-c59e694420a1@github.com>
References: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
 <xhxbP_hqaoheV5zsDJ2l5voSX4VJ0nWquvmKX6Xy0bg=.8e8091bf-9fab-4b67-aa2d-c59e694420a1@github.com>
Message-ID: <9fl7OoC7S5apiChUVmyb2JHzfmsNIyMwgREVU_iHB88=.7703e4f3-7f5f-4e3a-98e5-46c641c9ef17@github.com>

On Wed, 6 Mar 2024 20:49:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The atan2 and hypot cases added would fail for a particular test library that has errors in the millions of ulps for those inputs, rather than the small number of ulps specified for the error.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded lines.

Looks good

test/jdk/java/lang/Math/WorstCaseTests.java line 622:

> 620:         int failures = 0;
> 621:          // Cannot represent exact result, allow 1 additional ulp on top of documented bound, rounding up.
> 622:         double ulps = 3.0;

Suggestion:

        double ulps = 3.0;  // 1.5 + 1.0, rounded up

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

PR Review: https://git.openjdk.org/jdk/pull/18140#pullrequestreview-1927836589
PR Review Comment: https://git.openjdk.org/jdk/pull/18140#discussion_r1519723927

From jkern at openjdk.org  Mon Mar 11 13:48:56 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 11 Mar 2024 13:48:56 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
Message-ID: <dvyvE8Ej0mpD9vagOGNtC8Sq9xO_-YJNpXOBkk8tFSA=.bbce5b92-ec7a-47ea-850a-eb23aa281945@github.com>

On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert SEARCH_PATH changes

Changes requested by jkern (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/18172#pullrequestreview-1927875301

From jkern at openjdk.org  Mon Mar 11 13:48:56 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 11 Mar 2024 13:48:56 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <U1lfAxBkklFXkNC4jPSOY9jM-uvs0vMuHH7VZgAC0AM=.4445f8df-c8c8-4363-a35e-b89c571cde03@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <McIPLciH42WumSGkYLGvyyqQ-tntHyzlYa-iou8p3W8=.800e6f9e-1844-4d56-8054-80477058573f@github.com>
 <U1lfAxBkklFXkNC4jPSOY9jM-uvs0vMuHH7VZgAC0AM=.4445f8df-c8c8-4363-a35e-b89c571cde03@github.com>
Message-ID: <ym4JkRJQUoM3hQXlhx1Uwrqs0MFrKSA8TDz0ggKFMbc=.fc3722a0-a1ae-4d97-b619-56ea98402c0c@github.com>

On Mon, 11 Mar 2024 08:59:03 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 687:
>> 
>>> 685:     PICFLAG="-fPIC"
>>> 686:     PIEFLAG="-fPIE"
>>> 687:   elif test "x$TOOLCHAIN_TYPE" = xclang && test "x$OPENJDK_TARGET_OS" = xaix; then
>> 
>> Just a remark: This code has never been executed, since running with clang on any OS would hit the branch above. Also, the code is syntactically incorrect, missing a trailing `"`.
>
> OK this was a flaw in my introduction of clang toolchain for AIX. The intention was to keep the xlc options in form of their clang counterparts. I will try with a corrected version for clang on AIX and will come back to you.

OK, the `-Wl,-bbigtoc` is not a compiler option but a linker option and it is already set in the linker options.
But the `-fpic -mcmodel=large` should be set to avoid creating a jump to out-of-order code.

So we can replace the

  JVM_PICFLAG="$PICFLAG"
  JDK_PICFLAG="$PICFLAG"


code some lines below by


  if test "x$TOOLCHAIN_TYPE" = xclang && test "x$OPENJDK_TARGET_OS" = xaix; then
    JVM_PICFLAG="-fpic -mcmodel=large"
  else
    JVM_PICFLAG="$PICFLAG"
  fi
  JDK_PICFLAG="$PICFLAG"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1519747481

From duke at openjdk.org  Mon Mar 11 13:54:06 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 11 Mar 2024 13:54:06 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v2]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <QkAkgcRu4LLJSZ6DUEUfR2VHbsc89PpQgV3RhJ_y-gI=.d5d57818-e269-491e-b6f5-00a1981bfcc0@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 incrementally with one additional commit since the last revision:

  fix code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/265c6b6b..61b5531b

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

  Stats: 18 lines in 1 file changed: 6 ins; 6 del; 6 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 sgehwolf at openjdk.org  Mon Mar 11 13:56:59 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Mar 2024 13:56:59 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <pNnvkNgyVts2GAa5gnEHc99kgO1urANdUITZRRZd458=.dc589e0e-0c0d-4614-b848-f883446f52e8@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <pNnvkNgyVts2GAa5gnEHc99kgO1urANdUITZRRZd458=.dc589e0e-0c0d-4614-b848-f883446f52e8@github.com>
Message-ID: <aX3jp2e96uOZtf0MkUSpe7j7ho_XtGAqFQOB9HXFfEI=.490846cd-2cc5-42d0-b7f0-14631aa1ae22@github.com>

On Mon, 11 Mar 2024 13:24:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Based on that I agree with the choice of using a configure argument.

Thanks. The intention is that without the extra configure argument you'd get `jdk-image` as is today. Not modified. *With* `--enable-runtime-link-image` the result of what ends up in `images/jdk/lib/modules` is changed in a way that it allows linking without needing the packaged modules. Everything else should remain the same. That includes generated CDS archives, `src.zip` and so on. That is why it currently ends up in the same output directory. I hope that is acceptable as requiring downstream distributors to assemble the artefacts by hand (using the linkable jimage from some other location) would be more error prone.

My mental model for this would be similar to JVM features (e.g. `--with-jvm-features`). That also keeps the original location of `libjvm` but adds/removes features.

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

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

From liach at openjdk.org  Mon Mar 11 14:17:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Mar 2024 14:17:54 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v2]
In-Reply-To: <QkAkgcRu4LLJSZ6DUEUfR2VHbsc89PpQgV3RhJ_y-gI=.d5d57818-e269-491e-b6f5-00a1981bfcc0@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <QkAkgcRu4LLJSZ6DUEUfR2VHbsc89PpQgV3RhJ_y-gI=.d5d57818-e269-491e-b6f5-00a1981bfcc0@github.com>
Message-ID: <TeWcK_HMBkGACnkX9FIcA9KHYgpVFUNLy2WU-cTWLmc=.14cd88e1-902d-4298-ba6b-a7f4d3af1ac3@github.com>

On Mon, 11 Mar 2024 13:54:06 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 incrementally with one additional commit since the last revision:
> 
>   fix code style

Looks great to me. Sorry for the pings, but we may need @rgiulietti to verify the math correctness and @cl4es to comment on whether having these 2 separate code paths or trying to extract a common part is the better approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1988546982

From eirbjo at openjdk.org  Mon Mar 11 16:32:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 11 Mar 2024 16:32:19 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <lWUvgOiCn6kMayaaXrtWDENNdBC_N5L01n0vIZoA__I=.0458150e-653d-40e1-91d0-4fe4e0a3cb9d@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
 <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>
 <mvqdpLUoz04ti59FH9JT8ZyKSFei-0CIjEMWkJNm3NY=.e3144ab0-1fe5-49f9-a125-bb3eac04d057@github.com>
 <lWUvgOiCn6kMayaaXrtWDENNdBC_N5L01n0vIZoA__I=.0458150e-653d-40e1-91d0-4fe4e0a3cb9d@github.com>
Message-ID: <2QMf5NUmk6LlLOdbIpIQdBJqWH7jYfqafG9zZPSZVTM=.45e54122-25b0-4df5-9ec8-2e6f7c71709b@github.com>

On Sun, 10 Mar 2024 13:47:43 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Yes, you'll need to run all tests to make sure that there aren't any others, e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.

Alan,

With @jaikiran running Oracle CI tier1, tier2, tier3 and observing only the now-fixed `TestUnstableStable.java` test fail, would you consider re-approving the current state of this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1988559676

From redestad at openjdk.org  Mon Mar 11 16:32:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Mar 2024 16:32:17 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v2]
In-Reply-To: <TeWcK_HMBkGACnkX9FIcA9KHYgpVFUNLy2WU-cTWLmc=.14cd88e1-902d-4298-ba6b-a7f4d3af1ac3@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <QkAkgcRu4LLJSZ6DUEUfR2VHbsc89PpQgV3RhJ_y-gI=.d5d57818-e269-491e-b6f5-00a1981bfcc0@github.com>
 <TeWcK_HMBkGACnkX9FIcA9KHYgpVFUNLy2WU-cTWLmc=.14cd88e1-902d-4298-ba6b-a7f4d3af1ac3@github.com>
Message-ID: <qj3xcadMKtHuihXqHso9q8vObLTxfKLkqVVlzXvlGS8=.dcdcdbe6-e3ff-49aa-bbe2-2bace42252ea@github.com>

On Mon, 11 Mar 2024 14:15:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Looks great to me. Sorry for the pings, but we may need @rgiulietti to verify the math correctness and @cl4es to comment on whether having these 2 separate code paths or trying to extract a common part is the better approach.

I'd love to see less code duplication. It'd certainly be possible to refactor to one internal constructor `BigDecimal(CharSequence)` that the `String`-based constructors just delegates to, and then have the `BigDecimal(char[])` variants call with some wrapping (e.g. `this(CharBuffers.wrap(in, offset, len), mc)`). 

Such indirection might cost a few cycles per operation for the `char[]`-based constructors due the need to wrap the `char[]`, but I wonder how performance sensitive the `BigDecimal(char[], int, int)` paths really are once `BigDecimal(String)` takes another path.

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1988606133

From rgiulietti at openjdk.org  Mon Mar 11 16:32:19 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 11 Mar 2024 16:32:19 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v2]
In-Reply-To: <qj3xcadMKtHuihXqHso9q8vObLTxfKLkqVVlzXvlGS8=.dcdcdbe6-e3ff-49aa-bbe2-2bace42252ea@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <QkAkgcRu4LLJSZ6DUEUfR2VHbsc89PpQgV3RhJ_y-gI=.d5d57818-e269-491e-b6f5-00a1981bfcc0@github.com>
 <TeWcK_HMBkGACnkX9FIcA9KHYgpVFUNLy2WU-cTWLmc=.14cd88e1-902d-4298-ba6b-a7f4d3af1ac3@github.com>
 <qj3xcadMKtHuihXqHso9q8vObLTxfKLkqVVlzXvlGS8=.dcdcdbe6-e3ff-49aa-bbe2-2bace42252ea@github.com>
Message-ID: <o6A_mmOEw2h2S2bP5VQIoC0O8Y2QBaddFqkNQfNX4lU=.e326bfe4-3f25-4007-b3dc-3abeca735de0@github.com>

On Mon, 11 Mar 2024 14:42:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Looks great to me. Sorry for the pings, but we may need @rgiulietti to verify the math correctness and @cl4es to comment on whether having these 2 separate code paths or trying to extract a common part is the better approach.
>
>> Looks great to me. Sorry for the pings, but we may need @rgiulietti to verify the math correctness and @cl4es to comment on whether having these 2 separate code paths or trying to extract a common part is the better approach.
> 
> I'd love to see less code duplication. It'd certainly be possible to refactor to one internal constructor `BigDecimal(CharSequence)` that the `String`-based constructors just delegates to, and then have the `BigDecimal(char[])` variants call with some wrapping (e.g. `this(CharBuffers.wrap(in, offset, len), mc)`). 
> 
> Such indirection might cost a few cycles per operation for the `char[]`-based constructors due the need to wrap the `char[]`, but I wonder how performance sensitive the `BigDecimal(char[], int, int)` paths really are once `BigDecimal(String)` takes another path.

I second @cl4es concerns about code duplication.

While the ?-benchmarks show improvements, I wonder how much this impacts workloads out there.
In other words, we need to contrast a performance improvement that might impact, in some unknown measure, an unknown number of real-world workloads, with visible and known code duplication, code that needs maintenance over the next many many years.

IMO, @cl4es advice about code refactoring is worth giving a try, even if that costs some ns in the ?-benchmarks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1988777526

From naoto at openjdk.org  Mon Mar 11 16:32:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Mar 2024 16:32:21 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: <JWjDHa4em1JDLh1DAPV2ih_UbUh5t2qz39li_GuxBrE=.85795349-4a43-4c00-96dd-1467817554c7@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>

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18155#pullrequestreview-1928123853

From naoto at openjdk.org  Mon Mar 11 16:32:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Mar 2024 16:32:31 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description [v2]
In-Reply-To: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
Message-ID: <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>

> Removing left over "applet" mention in the package-info doc.

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18173/files
  - new: https://git.openjdk.org/jdk/pull/18173/files/9b5429d3..95d1dca8

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

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

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

From naoto at openjdk.org  Mon Mar 11 16:32:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Mar 2024 16:32:34 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description [v2]
In-Reply-To: <FTRWM7MHekBt-x7pEP5FnkgLHVkA-hWD__8VsWBdiXc=.f32c16d1-5a3f-46b1-ad13-cb6e0a5de8c1@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
 <FTRWM7MHekBt-x7pEP5FnkgLHVkA-hWD__8VsWBdiXc=.f32c16d1-5a3f-46b1-ad13-cb6e0a5de8c1@github.com>
Message-ID: <Lq8Q0_JPc4BVYcqw2E2FkcuLdw6qEt3Sq5hpjOfCwRI=.82589036-81c3-4531-a597-a1b0a8ff370f@github.com>

On Sat, 9 Mar 2024 11:12:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/java.base/share/classes/java/text/package-info.java line 29:
> 
>> 27:  * Provides classes and interfaces for handling text, dates, numbers,
>> 28:  * and messages in a manner independent of natural languages.  This
>> 29:  * means your application can be written to be
> 
> Maybe it should be broadened a bit, e.g  "an application or library" instead of "your application".

Thanks. Broadened.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18173#discussion_r1519900595

From aturbanov at openjdk.org  Mon Mar 11 16:38:04 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 11 Mar 2024 16:38:04 GMT
Subject: RFR: JDK-8327487: Further augment WorstCaseTests with more cases
 [v2]
In-Reply-To: <xhxbP_hqaoheV5zsDJ2l5voSX4VJ0nWquvmKX6Xy0bg=.8e8091bf-9fab-4b67-aa2d-c59e694420a1@github.com>
References: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
 <xhxbP_hqaoheV5zsDJ2l5voSX4VJ0nWquvmKX6Xy0bg=.8e8091bf-9fab-4b67-aa2d-c59e694420a1@github.com>
Message-ID: <qvseE0UTpJtUZvBKLII0nN9K8RB906I-j38MY3lk4ck=.298b8191-1189-47af-b338-9cbd758d1a76@github.com>

On Wed, 6 Mar 2024 20:49:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The atan2 and hypot cases added would fail for a particular test library that has errors in the millions of ulps for those inputs, rather than the small number of ulps specified for the error.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded lines.

test/jdk/java/lang/Math/WorstCaseTests.java line 612:

> 610:         };
> 611: 
> 612:         for(double[] testCase: testCases) {

Suggestion:

        for (double[] testCase: testCases) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18140#discussion_r1520037718

From duke at openjdk.org  Mon Mar 11 16:41:03 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 11 Mar 2024 16:41:03 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods added
 in Java 10
Message-ID: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>

# Issue
- JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10

I changed the @\since tags to better accurately show when the methods and constructors were introduced.

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

Commit messages:
 - fixed @ since tag for Formatter.java class Constructors
 - fixed @ since tag for Channels.java class newWriter and newReader methods

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

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

From duke at openjdk.org  Mon Mar 11 16:42:12 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 11 Mar 2024 16:42:12 GMT
Subject: RFR: JDK-8326836 Incorrect @since Tags for ClassSignature methods
Message-ID: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@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.

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

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326836
  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 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 liach at openjdk.org  Mon Mar 11 16:42:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Mar 2024 16:42:12 GMT
Subject: RFR: JDK-8326836 Incorrect @since Tags for ClassSignature methods
In-Reply-To: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
Message-ID: <eipU9-_JYtZUNNDKU1Tx41Z7YOVnKtrV70RW4YTiucA=.15f246a5-7357-4ab1-a8f3-1ead5a29731e@github.com>

On Tue, 27 Feb 2024 15:10:37 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.

Good spotting! I didn't think this was necessary as FFM API had similar new method additions before, yet they didn't add `@since` tags in existing files :(

First, the `ClassSig superclassSignature()` method has replaced the old one returning `TypeSig`, thus it's a new method (different descriptors, breaking binary compatibility, somewhat source compatible) and should get a `@since` tag.

Also, what's the definition of a signature? Do we introduce a new `@since` tag if the generic signature differs, i.e. `List<RefTypeSig>` vs `List<ClassTypeSig>`?

If we do introduce a `@since` tag for a generic signature change (but no change in bytecode descriptor), we should add a `@since` tag to `List<Signature.ClassTypeSig> superinterfaceSignatures()`, as its generic signature has changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-1968058662

From jlahoda at openjdk.org  Mon Mar 11 16:42:12 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Mar 2024 16:42:12 GMT
Subject: RFR: JDK-8326836 Incorrect @since Tags for ClassSignature methods
In-Reply-To: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
Message-ID: <Tiz06uuwbC-a1-SJC2tVXSBoBnSvPAGs0DWtAWeb-rs=.7f568458-209a-410a-bf2f-0dc8748baeb9@github.com>

On Tue, 27 Feb 2024 15:10:37 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.

We would like to have an automated way to check `@since` tags, for that, the existing mistakes should be cleaned. It is true there were some mistakes in FFM (and there are some mistakes even in production code elsewhere), but those that persist in the mainline should be cleaned as well.

I think I'd also add that `java.lang.classfile.ClassFile.JAVA_23_VERSION` should also have `@since 23`.

Regarding that is the definition of "a new method" - I would say one reasonable way to detect new methods is based on JVM descriptors. There are some methods in the JDK that have been retrofitted from non-generic to generic in a binary compatible way, and it seems unfounded to require `@since` for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-1969180172

From duke at openjdk.org  Mon Mar 11 16:42:13 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 11 Mar 2024 16:42:13 GMT
Subject: RFR: JDK-8326836 Incorrect @since Tags for ClassSignature methods
In-Reply-To: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
Message-ID: <bF2NayfvAv_WOeAU_mtVDVgkGEbVRidmLJTePKFF5nw=.38f2590d-d32e-4b97-a2cd-c072235a1c86@github.com>

On Tue, 27 Feb 2024 15:10:37 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.

I didn't realize that `java.lang.classfile.ClassFile.JAVA_23_VERSION` didn't match the `@since` of the enclosing interface. Fixed it

`/covered`

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

PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-1969568086
PR Comment: https://git.openjdk.org/jdk/pull/18030#issuecomment-1988768314

From liach at openjdk.org  Mon Mar 11 16:49:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Mar 2024 16:49:56 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v2]
In-Reply-To: <QkAkgcRu4LLJSZ6DUEUfR2VHbsc89PpQgV3RhJ_y-gI=.d5d57818-e269-491e-b6f5-00a1981bfcc0@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <QkAkgcRu4LLJSZ6DUEUfR2VHbsc89PpQgV3RhJ_y-gI=.d5d57818-e269-491e-b6f5-00a1981bfcc0@github.com>
Message-ID: <zV_8e_Xtf_dPNkg85rJMPSGuMYFccksyzppiODHWFek=.2dfd5ac5-3b86-41c8-8a7d-99d2106a0df5@github.com>

On Mon, 11 Mar 2024 13:54:06 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 incrementally with one additional commit since the last revision:
> 
>   fix code style

In case you've missed, wenshao observed a significant performance drop in https://github.com/openjdk/jdk/pull/18177#issuecomment-1987601447 in which the throughput decreased by 27%. So he decided to keep split code paths for JIT as the char[] path is used as an optimized path in user code, such as in mysql connector.

I personally wonder how profile pollution + lack of escape analysis (CharBuffer wrapper) causes such a significant overhead, maybe there's some unintended optimization in the benchmarks (recall a previous array comparison benchmark without polymorphism) that produced such results.

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1988933531

From darcy at openjdk.org  Mon Mar 11 17:17:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 11 Mar 2024 17:17:21 GMT
Subject: RFR: JDK-8327487: Further augment WorstCaseTests with more cases
 [v3]
In-Reply-To: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
References: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
Message-ID: <qOf1F_jncL2R_7jTfC6WNMdKoz8NgBC-55sY4V-bgj4=.7f672a16-3591-4cff-9f26-5d3acb556cc4@github.com>

> The atan2 and hypot cases added would fail for a particular test library that has errors in the millions of ulps for those inputs, rather than the small number of ulps specified for the error.

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

  Implement review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18140/files
  - new: https://git.openjdk.org/jdk/pull/18140/files/6b2d7870..67df3748

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

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

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

From bpb at openjdk.org  Mon Mar 11 17:39:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 11 Mar 2024 17:39:56 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description [v2]
In-Reply-To: <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
 <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>
Message-ID: <8Y9mYObLipxv2pdPoQyPYuvrOwA80P4-0orA_8n2zXc=.ca890e17-cc26-44bd-a19d-b6965f765399@github.com>

On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1928572972

From sgehwolf at openjdk.org  Mon Mar 11 17:45:06 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Mar 2024 17:45:06 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
Message-ID: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@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?

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

Commit messages:
 - 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: https://git.openjdk.org/jdk/pull/18201/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8261242
  Stats: 360 lines in 20 files changed: 258 ins; 78 del; 24 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 rriggs at openjdk.org  Mon Mar 11 17:52:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Mar 2024 17:52:54 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description [v2]
In-Reply-To: <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
 <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>
Message-ID: <LSkSnoG7sP4jnGfYceCjTD1E4R0ww0tdGhnaF7sLWZo=.89c29211-e370-41d7-a5c6-422273e4987b@github.com>

On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1928607470

From duke at openjdk.org  Mon Mar 11 17:51:16 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Mon, 11 Mar 2024 17:51:16 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks
Message-ID: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>

Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)

Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.

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

Commit messages:
 - Remove string.h include
 - Update test
 - Pass version as integer instead of string
 - Read in version using int instead of string
 - 8325621: Improve jspawnhelper version checks

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

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

From duke at openjdk.org  Mon Mar 11 18:03:06 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 11 Mar 2024 18:03:06 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v3]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <ZTpoDawWxDsYBD7sK7yvuOvkOV42CBM2iHbyHYTV0pI=.0b4d35af-67e2-4c7e-aa6c-aa6cb9f4fa5d@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 incrementally with two additional commits since the last revision:

 - less duplicate code
 - add more benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/61b5531b..bdf9f4b5

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

  Stats: 372 lines in 3 files changed: 78 ins; 287 del; 7 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 iris at openjdk.org  Mon Mar 11 18:15:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 11 Mar 2024 18:15:55 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description [v2]
In-Reply-To: <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
 <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>
Message-ID: <nTmJ6hG3PDxlSisIdbofhFO_LS3VCFWKPWLZxvy_TOw=.f7b10dd0-1e79-45d8-a4d9-8c351ad32278@github.com>

On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1928697079

From erikj at openjdk.org  Mon Mar 11 18:19:53 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Mar 2024 18:19:53 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks
In-Reply-To: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
Message-ID: <h18TPOFTNgu1lF7NnRD86WsDUS6-vmGEzJqEXWF7Hvw=.67b6d60a-0d78-4df6-9ac6-425ec166aa97@github.com>

On Mon, 11 Mar 2024 17:46:14 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
> 
> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.

If you really want to require an exact match for jspawnhelper, then these 4 numbers aren't necessarily enough, but a rather arbitrarily chosen approximation. We have 3 more potential dotted numbers (extra1-3) as well as the OPT string that could potentially describe a different build. 

I saw someone argued for using separated version variables for comparison in an issue comment, but I'm not sure I agree. We have a pretty well defined version string so comparing that would be much easier, and basically guaranteed to accomplish what I understand to be the goal of this change. Comparing any subset of other version variables will always just be an approximation, and while an approximation may be fine, it's difficult to predict exactly how that will play out in the future.

src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 172:

> 170:         // Check that JDK version and jspawnhelper version are the same
> 171:         if (jdk_feature != VERSION_FEATURE || jdk_interim != VERSION_INTERIM || jdk_update != VERSION_UPDATE || jdk_patch != VERSION_PATCH) {
> 172:             fprintf(stderr, "Expected jspawnhelper for Java %d.%d.%d+%d, ", jdk_feature, jdk_interim, jdk_update, jdk_patch);

This isn't correct. All of feature, interim, update and patch are always dot separated. The `+` is the separator for the build number.

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

PR Review: https://git.openjdk.org/jdk/pull/18204#pullrequestreview-1928706835
PR Review Comment: https://git.openjdk.org/jdk/pull/18204#discussion_r1520217129

From duke at openjdk.org  Mon Mar 11 18:23:55 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 11 Mar 2024 18:23:55 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v3]
In-Reply-To: <ZTpoDawWxDsYBD7sK7yvuOvkOV42CBM2iHbyHYTV0pI=.0b4d35af-67e2-4c7e-aa6c-aa6cb9f4fa5d@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <ZTpoDawWxDsYBD7sK7yvuOvkOV42CBM2iHbyHYTV0pI=.0b4d35af-67e2-4c7e-aa6c-aa6cb9f4fa5d@github.com>
Message-ID: <KbnHKeKTIgD0vqEGsULMCLFk_isBiTWCJBWvPc04r2U=.dc34dc17-6ecf-4e6b-9001-47ff00ce5bf5@github.com>

On Mon, 11 Mar 2024 18:03:06 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 incrementally with two additional commits since the last revision:
> 
>  - less duplicate code
>  - add more benchmark

I also prefer to reduce duplicate code. There are not many scenarios where BigDecima(char[]) is used. The most commonly used scenario is BigDecimal(String).

If performance is very important, the user can implement the parser by himself, similar to MysqlBinaryValueDecoder#decodeDecimal. He can remove the StringUtils.toAsciiCharArray conversion and implement the parser based on ascii.

I added some benchmarks, and the numbers show that the performance drops by 21.67% in the SmallCharArray scene, and by 6.52% and 5.69% in the LargeCharArray and HugeCharArray scenes.


-Benchmark                                      Mode  Cnt    Score   Error  Units #master
-BigDecimals.testConstructorWithSmallCharArray  avgt   15   16.488 ? 0.054  ns/op
-BigDecimals.testConstructorWithLargeCharArray  avgt   15   90.583 ? 1.523  ns/op
-BigDecimals.testConstructorWithHugeCharArray   avgt   15   90.683 ? 1.623  ns/op
-BigDecimals.testConstructorWithCharArray       avgt   15   47.418 ? 0.473  ns/op
-BigDecimals.testConstructorWithSmallString     avgt   15   19.725 ? 0.049  ns/op
-BigDecimals.testConstructorWithLargeString     avgt   15  113.567 ? 1.470  ns/op
-BigDecimals.testConstructorWithHugeString      avgt   15  119.712 ? 6.230  ns/op
-BigDecimals.testConstructorWithString          avgt   15   67.046 ? 0.979  ns/op


+Benchmark                                      Mode  Cnt    Score   Error  Units (01 #61b5531b)
+BigDecimals.testConstructorWithSmallCharArray  avgt   15   14.322 ? 0.063  ns/op +15.12%
+BigDecimals.testConstructorWithLargeCharArray  avgt   15   74.090 ? 0.299  ns/op +22.26%
+BigDecimals.testConstructorWithHugeCharArray   avgt   15   74.372 ? 0.461  ns/op +21.93%
+BigDecimals.testConstructorWithCharArray       avgt   15   41.606 ? 0.284  ns/op +13.96%
+BigDecimals.testConstructorWithSmallString     avgt   15   15.019 ? 0.100  ns/op +31.33%
+BigDecimals.testConstructorWithLargeString     avgt   15   70.226 ? 0.240  ns/op +61.71%
+BigDecimals.testConstructorWithHugeString      avgt   15   70.153 ? 0.455  ns/op +70.64%
+BigDecimals.testConstructorWithString          avgt   15   40.064 ? 0.298  ns/op +67.36%

+Benchmark                                      Mode  Cnt    Score   Error  Units (02 #bdf9f4b5)
+BigDecimals.testConstructorWithSmallCharArray  avgt   15   21.052 ? 0.109  ns/op -21.67%
+BigDecimals.testConstructorWithLargeCharArray  avgt   15   96.911 ? 2.921  ns/op -6.52%
+BigDecimals.testConstructorWithHugeCharArray   avgt   15   96.158 ? 3.501  ns/op -5.69%
+BigDecimals.testConstructorWithCharArray       avgt   15   54.673 ? 2.563  ns/op -13.26%
+BigDecimals.testConstructorWithSmallString     avgt   15   15.061 ? 0.082  ns/op +30.96%
+BigDecimals.testConstructorWithLargeString     avgt   15   70.670 ? 0.607  ns/op +60.70%
+BigDecimals.testConstructorWithHugeString      avgt   15   70.706 ? 0.531  ns/op +69.30%
+BigDecimals.testConstructorWithString          avgt   15   39.869 ? 0.149  ns/op +68.16%

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1989144767

From ccheung at openjdk.org  Mon Mar 11 18:24:22 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 11 Mar 2024 18:24:22 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L [v3]
In-Reply-To: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
Message-ID: <9k0sDS8DaJGN3luV8udWNquwe2byBQqG2IVwfqNUz2w=.d85400c0-97ea-4e7e-9bf6-40fa66210a66@github.com>

> To avoid the CDS dump error message, a fix is during dumping a classlist, check if an invoker can be archived. 
> If not, don't write the invoker info into the classlist, i.e. don't call `logLambdaFormInvoker()`. While generating holder classes (in `generateHolderClasses()`), don't add the `MethodType` to the `invokerTypes` if will fail the check in the `build()` method which would result in a `RuntimeException`.
> 
> Also updated the `MethodHandlesInvokersTest.java` under `appcds/methodHandles` and `appcds/dynamicArchive/methodHandles` to check that the "Failed to generate LambdaForm holder classes" error is not in the output;
> 
> Passed tiers 1 - 3 testing.

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

  remove unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17953/files
  - new: https://git.openjdk.org/jdk/pull/17953/files/38d64c10..544fa10e

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

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

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

From ccheung at openjdk.org  Mon Mar 11 18:24:22 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 11 Mar 2024 18:24:22 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L [v2]
In-Reply-To: <oS7XpZG_jajO16gcL3hWGm_qKEDOd9636UUrlSHwejE=.c34ce2cd-e5a4-44a6-bf2c-4492c23a2a1e@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
 <cw28aE2NtWnw9d5Wm1HLOSO6_pUjbDoO4OG29WA70fE=.7d39c879-367e-4dff-a20a-ec508d4842cd@github.com>
 <oS7XpZG_jajO16gcL3hWGm_qKEDOd9636UUrlSHwejE=.c34ce2cd-e5a4-44a6-bf2c-4492c23a2a1e@github.com>
Message-ID: <H01zlTahcyZ1se-l6xyoMsE0nQeWGQnYnoNCW21egJ8=.7e7808df-ffb4-4a99-9576-4a5023729b1b@github.com>

On Fri, 8 Mar 2024 15:58:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam comments and copyright update
>
> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 28:
> 
>> 26: package java.lang.invoke;
>> 27: 
>> 28: //import jdk.internal.misc.CDS;
> 
> This line can be removed.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17953#discussion_r1520232066

From amenkov at openjdk.org  Mon Mar 11 18:28:50 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 11 Mar 2024 18:28:50 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v2]
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <alzCvsdVPHUjKvKXJ6UoYOvZ2rUUNjoJsHpUq3fQ-Ew=.e359b6e2-02c0-4438-8934-535202d5152d@github.com>

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> The fix updates ClassFileParser to calculate correct attributes_count.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18161/files
  - new: https://git.openjdk.org/jdk/pull/18161/files/5f1d0116..1ad6997d

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

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

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

From shade at openjdk.org  Mon Mar 11 18:44:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Mar 2024 18:44:09 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks
In-Reply-To: <h18TPOFTNgu1lF7NnRD86WsDUS6-vmGEzJqEXWF7Hvw=.67b6d60a-0d78-4df6-9ac6-425ec166aa97@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <h18TPOFTNgu1lF7NnRD86WsDUS6-vmGEzJqEXWF7Hvw=.67b6d60a-0d78-4df6-9ac6-425ec166aa97@github.com>
Message-ID: <vFjE8rq_0RsmmgXqevkcXT2uAOty5_3iB7Fo-PtvlsU=.736ef65d-a6e9-47e1-96dd-36e1c0340a6a@github.com>

On Mon, 11 Mar 2024 18:16:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> If you really want to require an exact match for jspawnhelper, then these 4 numbers aren't necessarily enough, but a rather arbitrarily chosen approximation.

I think for our purposes, a version number quadruplet is enough to provide basic level of safety for jspawnhelper protocol updates across JDK versions, without version checking code being a safety problem itself. 

Putting in the full version string would raise more questions, at least for me. For example, are we guaranteed that version string always fits the argument line? Probably so. Would we get some interesting (Unicode?) symbols in version string that would break somewhere along the way? Would we need to dynamically allocate the buffer for arguments, instead of allocating enough to hold the version _integers_? Would we make a mistake while doing so? Etc.

All in all, it feels better to silently accept some version mismatches not captured by the version quadruplet, rather than fail trying to do a perfect match.

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

PR Comment: https://git.openjdk.org/jdk/pull/18204#issuecomment-1989179598

From duke at openjdk.org  Mon Mar 11 19:01:19 2024
From: duke at openjdk.org (Bernd)
Date: Mon, 11 Mar 2024 19:01:19 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks
In-Reply-To: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
Message-ID: <xLqrhqGiGQcIq8To2Jt19Ew5JFK17-kv0UOQQwX12h4=.39e3b52d-ebb2-461a-8ec1-db1b7059836d@github.com>

On Mon, 11 Mar 2024 17:46:14 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
> 
> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.

Since incompatible changes here are seldom, another option would be to set/send a protocol version. Because if you reject an execute() on each mismatch or if only a incompatible execute() fails is both undesireable, but much more often with version compare (of course third behavior crash/corruption would be bad, but the bugfix should avoid that).

with a protocol version you don?t have to care about micro versions and also it is more tolerant about the usual cpu updates which do not introduce incompatibilities most of the time.

having said that, if you don?t want to introduce a protocol version and don?t want to gurantee this interface - the version quadruple would be fine for the most common cases of quarterly security updates.

btw just as a datapoint: we run into this issue with a longrunning Gerrit server which could no longer invoke external ssh client for incoming hooks (ad did not log this). It was not expected to use the system-vm which was updated on the running system by ubuntu.

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

PR Comment: https://git.openjdk.org/jdk/pull/18204#issuecomment-1989211732

From duke at openjdk.org  Mon Mar 11 19:12:33 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Mon, 11 Mar 2024 19:12:33 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v2]
In-Reply-To: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
Message-ID: <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>

> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
> 
> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.

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

  Code cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18204/files
  - new: https://git.openjdk.org/jdk/pull/18204/files/cf3c20fb..7bbcc08f

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

  Stats: 48 lines in 4 files changed: 16 ins; 24 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18204.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18204/head:pull/18204

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

From shade at openjdk.org  Mon Mar 11 19:12:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Mar 2024 19:12:34 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks
In-Reply-To: <xLqrhqGiGQcIq8To2Jt19Ew5JFK17-kv0UOQQwX12h4=.39e3b52d-ebb2-461a-8ec1-db1b7059836d@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <xLqrhqGiGQcIq8To2Jt19Ew5JFK17-kv0UOQQwX12h4=.39e3b52d-ebb2-461a-8ec1-db1b7059836d@github.com>
Message-ID: <cRAa5LxdRihSUqvWNxmMedi0Ac_0Mn_ry70RikqKO_w=.5faae19b-923d-4829-93de-0fd88aa1ccf7@github.com>

On Mon, 11 Mar 2024 18:56:21 GMT, Bernd <duke at openjdk.org> wrote:

> with a protocol version you don?t have to care about micro versions and also it is more tolerant about the usual cpu updates which do not introduce incompatibilities most of the time.

I think we can only reasonably guarantee that jspawnhelper built for a particular JDK is compatible. Protocol version does not exactly capture that: there might be a slight change in JDK that jspawnhelper needs to be aware about, but which does not readily manifest in handshake protocol. Version quadruplet seems to get us what we want automatically. Plus, as you said, protocol number would probably communicate a wrong message that there is some guarantee about the protocol.

> btw just as a datapoint: we run into this issue with a longrunning Gerrit server which could no longer invoke external ssh client for incoming hooks (ad did not log this). It was not expected to use the system-vm which was updated on the running system by ubuntu.

Ouch!

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

PR Comment: https://git.openjdk.org/jdk/pull/18204#issuecomment-1989231670

From shade at openjdk.org  Mon Mar 11 19:18:15 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Mar 2024 19:18:15 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v2]
In-Reply-To: <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
Message-ID: <TQmJDW5v4anqSkC5khW5ndwaF_iHJSKweDwDffCoppU=.14441dd1-c666-47a2-a80f-464af4a41db6@github.com>

On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code cleanup

src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 173:

> 171:         if (jdk_feature != VERSION_FEATURE || jdk_interim != VERSION_INTERIM || jdk_update != VERSION_UPDATE || jdk_patch != VERSION_PATCH) {
> 172:             fprintf(stderr, "Expected jspawnhelper for Java %d.%d.%d.%d, ", jdk_feature, jdk_interim, jdk_update, jdk_patch);
> 173:             fprintf(stderr, "but jspawnhelper for Java %d.%d.%d.%d was found.\n", VERSION_FEATURE, VERSION_INTERIM, VERSION_UPDATE, VERSION_PATCH);

Minor: It is a bit odd to see that jspawnhelper found its own version odd. I'd say:


fprintf(stderr, "jspawnhelper version check failed. jspawnhelper version: %d.%d.%d.%d, JDK version: %d.%d.%d.%d\n",
        VERSION_FEATURE, VERSION_INTERIM, VERSION_UPDATE, VERSION_PATCH,
        jdk_feature, jdk_interim, jdk_update, jdk_patch);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18204#discussion_r1520296858

From duke at openjdk.org  Mon Mar 11 19:34:22 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 11 Mar 2024 19:34:22 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@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>
Message-ID: <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>

On Tue, 27 Feb 2024 20:54:03 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> Hello Vladimir (@iaroslavski),
>> 
>> Please see the data below. Each DPQS class was copied to java.util and the JDK was recompiled.
>> 
>> 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">
>> 
>> 
>> Benchmark | (builder) | (size) | Stock JDK | r20p | r20s | r25p | r25s
>> -- | -- | -- | -- | -- | -- | -- | --
>> ArraysSort.Int.p_sort | RANDOM | 600 | 1.618 | 2.601 | 2.966 | 2.898 | 3.269
>> ArraysSort.Int.p_sort | RANDOM | 2000 | 7.433 | 8.438 | 8.463 | 8.414 | 8.65
>> ArraysSort.Int.p_sort | RANDOM | 90000 | 258.853 | 355.261 | 326.378 | 347.65 | 321.894
>> ArraysSort.Int.p_sort | RANDOM | 400000 | 842.085 | 1225.929 | 899.852 | 1278.681 | 932.627
>> ArraysSort.Int.p_sort | RANDOM | 3000000 | 5723.659 | 8711.108 | 6086.974 | 8948.101 | 6122.612
>> ArraysSort.Int.p_sort | REPEATED | 600 | 0.52 | 0.585 | 0.629 | 0.586 | 0.579
>> ArraysSort.Int.p_sort | REPEATED | 2000 | 1.18 | 1.225 | 1.21 | 1.225 | 1.238
>> ArraysSort.Int.p_sort | REPEATED | 90000 | 102.142 | 85.79 | 86.131 | 87.954 | 86.036
>> ArraysSort.Int.p_sort | REPEATED | 400000 | 244.508 | 229.142 | 227.613 | 228.608 | 228.367
>> ArraysSort.Int.p_sort | REPEATED | 3000000 | 2752.745 | 2584.103 | 2544.192 | 2576.803 | 2609.833
>> ArraysSort.Int.p_sort | STAGGER | 600 | 1.146 | 0.894 | 0.898 | 0.904 | 0.912
>> ArraysSort.Int.p_sort | STAGGER | 2000 | 3.712 | 3.096 | 3.121 | 3.03 | 3.049
>> ArraysSort.Int.p_sort | STAGGER | 90000 | 72.763 | 77.575 | 78.366 | 79.158 | 77.199
>> ArraysSort.Int.p_sort | STAGGER | 400000 | 212.455 | 228.331 | 225.888 | 224.686 | 225.728
>> ArraysSort.Int.p_sort | STAGGER | 3000000 | 2290.327 | 2216.741 | 2196.138 | 2236.658 | 2262.472
>> ArraysSort.Int.p_sort | SHUFFLE | 600 | 2.01 | 2.92 | 2.907 | 2.91 | 2.926
>> ArraysSort.Int.p_sort | SHUFFLE | 2000 | 7.06 | 7.759 | 7.776 | 7.688 | 8.062
>> ArraysSort.Int.p_sort | SHUFFLE | 90000 | 157.728 | 151.871 | 151.101 | 154.03 | 151.2
>> ArraysSort.Int.p_sort | SHUFFLE | 400000 | 441.166 | 715.243 | 449...
>
> Hello Vamsi (@vamsi-parasa),
> 
> Could you please run benchmarking of 4 cases with **updated** test class **ArraysSortNew2**?
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew2.java
> 
> Put each DPQS class in java.util package and recompiling the JDK for each case as you
> did before, and run new class **ArraysSortNew2**.
> 
> Find the sources there:
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew2.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27b.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27p.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27s.java
> 
> Thank you,
> Vladimir

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.436 | 63.148 | 63.617 | 64.391 | 65.865
PERIOD | 400000 | 209.807 | 209.234 | 228.7 | 232.854 | 235.667
PERIOD | 3000000 | 1930.74 | 1943.51 | 1969.285 | 1991.225 | 1976.821
STAGGER | 600 | 1.07 | 1.068 | 0.772 | 0.78 | 0.77
STAGGER | 2000 | 3.455 | 3.451 | 2.582 | 2.579 | 2.566
STAGGER | 90000 | 148.7 | 390.833 | 123.443 | 123.166 | 123.64
STAGGER | 400000 | 661.018 | 662.037 | 568.606 | 584.962 | 594.313
STAGGER | 3000000 | 5170.135 | 5476.926 | 4431.776 | 4495.846 | 4538.187
SHUFFLE | 600 | 1.901 | 1.853 | 1.845 | 1.371 | 1.398
SHUFFLE | 2000 | 6.671 | 6.659 | 7.207 | 4.985 | 5.093
SHUFFLE | 90000 | 467.201 | 465.951 | 558.455 | 416.208 | 415.508
SHUFFLE | 400000 | 2168.29 | 2148.741 | 2633.919 | 2038.333 | 2026.282
SHUFFLE | 3000000 | 17994.7 | 17944.2 | 21180.53 | 17126.11 | 17082.88



</body>

</html>

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1989270043

From duke at openjdk.org  Mon Mar 11 19:34:22 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 11 Mar 2024 19:34:22 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@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>
Message-ID: <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>

On Mon, 11 Mar 2024 19:29:59 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Could you please run benchmarking of 4 cases with **updated** test class **ArraysSortNew2**?
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew2.java
>> 
>> Put each DPQS class in java.util package and recompiling the JDK for each case as you
>> did before, and run new class **ArraysSortNew2**.
>> 
>> Find the sources there:
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew2.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27b.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27p.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27s.java
>> 
>> Thank you,
>> Vladimir
>
> 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.436 | 63.148 | 63.617 | 64.391 | 65.865
> PERIOD | 400000 | 209.807 | 209.234 | 228.7 | 232.854 | 235.667
> PERIOD | 3000...

> 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

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1989274286

From mchung at openjdk.org  Mon Mar 11 19:37:20 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 19:37:20 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
Message-ID: <A0OlDi72q7plzVUxp-irGrIeaN6kTWK7jFGBQJ9uJxM=.d82c8e5d-bb0f-453a-9ebd-0620c9436963@github.com>

On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace calls to Unsafe.putObject with Unsafe.putReference
>  - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

This should wait for @jaikiran approval confirming the test result is good.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18176#pullrequestreview-1928982510

From erikj at openjdk.org  Mon Mar 11 19:59:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Mar 2024 19:59:12 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v2]
In-Reply-To: <vFjE8rq_0RsmmgXqevkcXT2uAOty5_3iB7Fo-PtvlsU=.736ef65d-a6e9-47e1-96dd-36e1c0340a6a@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <h18TPOFTNgu1lF7NnRD86WsDUS6-vmGEzJqEXWF7Hvw=.67b6d60a-0d78-4df6-9ac6-425ec166aa97@github.com>
 <vFjE8rq_0RsmmgXqevkcXT2uAOty5_3iB7Fo-PtvlsU=.736ef65d-a6e9-47e1-96dd-36e1c0340a6a@github.com>
Message-ID: <wNysHl59vyeuuWSbh0uZRv_f_kxTxDFzo1hnjNjUpfY=.d9388bfa-1b21-438d-b525-c3c07fc415b4@github.com>

On Mon, 11 Mar 2024 18:36:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > If you really want to require an exact match for jspawnhelper, then these 4 numbers aren't necessarily enough, but a rather arbitrarily chosen approximation.
> 
> I think for our purposes, a version number quadruplet is enough to provide basic level of safety for jspawnhelper protocol updates across JDK versions, without version checking code being a safety problem itself.
> 
> Putting in the full version string would raise more questions, at least for me. For example, are we guaranteed that version string always fits the argument line? Probably so. Would we get some interesting (Unicode?) symbols in version string that would break somewhere along the way? Would we need to dynamically allocate the buffer for arguments, instead of allocating enough to hold the version _integers_? Would we make a mistake while doing so? Etc.
> 
> All in all, it feels better to silently accept some version mismatches not captured by the version quadruplet, rather than fail trying to do a perfect match.

Legal characters for the version string are defined in https://openjdk.org/jeps/223 and verified by configure. There is no risk of weird unicode being included. If the full version string is too long, you could consider using `VERSION_SHORT`, which drops the $OPT, and the $BUILD part. 

I don't think we need to dynamically allocate the buffer. The required buffer length is known at compile time as the length of the expected version string (which we get as a command line macro) +1. If the user supplies more, we don't need to compare the rest of the string as we already know it's not equal.

To me, hardcoding of 4 version digits raises more questions. We spend unnecessary time and effort specifically serializing and de-serializing 4 numbers, always maintaining the correct order. To me that's brittle code. If the version elements, or how we use them, were to change in the future, then this code needs to be carefully revisited, whereas if we just used a standard version string, it would continue to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/18204#issuecomment-1989320103

From rriggs at openjdk.org  Mon Mar 11 20:07:18 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Mar 2024 20:07:18 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v2]
In-Reply-To: <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
Message-ID: <ww1QQHsJ7gJh3n0zC30g-e0SDxYM7FrvgivHY0D7vkA=.d8803e46-3e6c-4ddf-9efd-aad6f6baaa7f@github.com>

On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code cleanup

make/modules/java.base/Launcher.gmk line 85:

> 83:           -DVERSION_INTERIM=$(VERSION_INTERIM) \
> 84:           -DVERSION_UPDATE=$(VERSION_UPDATE) \
> 85:           -DVERSION_PATCH=$(VERSION_PATCH), \

Using all 4 is way overkill for the problem at hand.  Just the FEATURE_VERSION is sufficient.
We all know better than to make incompatible changes in minor versions let alone update or patch version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18204#discussion_r1520364358

From alanb at openjdk.org  Mon Mar 11 20:36:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Mar 2024 20:36:13 GMT
Subject: RFR: 8327705: Remove mention of "applet" from java.text package
 description [v2]
In-Reply-To: <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
 <dJss03WHUcVxVjU-TrQaHt84SEJcQ9VGefgN17QicgY=.a190adef-f8f6-4aea-acdd-83c2708fcb38@github.com>
Message-ID: <_R_zAjPx238Pw3RiDLiJ9s_zTgF3OUoJmu-aQLvz2tY=.7158fa92-779c-49cd-8e73-ce84a5a81033@github.com>

On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1929194427

From duke at openjdk.org  Mon Mar 11 20:41:25 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 11 Mar 2024 20:41:25 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v4]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <96SLiHrhxFPytd-Lk-CSRGvIbjHOxuWFc-0axGFIqRo=.f8a1d56f-3fd5-414c-9a22-de6cecf3e986@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 incrementally with one additional commit since the last revision:

  1. bug fix for CharBuffer catch IndexOutOfBoundsException
  2. reorder if statement
  3. Improve the performance of !isCompact branch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/bdf9f4b5..bb45da4d

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

  Stats: 70 lines in 1 file changed: 41 ins; 17 del; 12 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 ccheung at openjdk.org  Mon Mar 11 20:52:18 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 11 Mar 2024 20:52:18 GMT
Subject: RFR: 8314250: CDS dump error message: Invoker type parameter must
 start and end with Object: L3I_L [v2]
In-Reply-To: <oS7XpZG_jajO16gcL3hWGm_qKEDOd9636UUrlSHwejE=.c34ce2cd-e5a4-44a6-bf2c-4492c23a2a1e@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
 <cw28aE2NtWnw9d5Wm1HLOSO6_pUjbDoO4OG29WA70fE=.7d39c879-367e-4dff-a20a-ec508d4842cd@github.com>
 <oS7XpZG_jajO16gcL3hWGm_qKEDOd9636UUrlSHwejE=.c34ce2cd-e5a4-44a6-bf2c-4492c23a2a1e@github.com>
Message-ID: <Gnl04dT1Rc7KJTWl1lVgC9Ir63_VQ18FC3l7tEjLNI8=.a5f9b69d-aac5-4713-8206-d96f15cd36a8@github.com>

On Fri, 8 Mar 2024 15:58:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam comments and copyright update
>
> Looks good. Just a small nit.

Thanks @iklam, @matias9927 for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17953#issuecomment-1989416849

From ccheung at openjdk.org  Mon Mar 11 20:52:18 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 11 Mar 2024 20:52:18 GMT
Subject: Integrated: 8314250: CDS dump error message: Invoker type parameter
 must start and end with Object: L3I_L
In-Reply-To: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
References: <dM7jNmwIXuf0nwVG8RiDPgkNZAexVScgr48PouQn4lE=.49d3feb5-66d3-44a4-b595-eae1821b9f53@github.com>
Message-ID: <9LnQYSuI5kkYTA5obG7GAbQ0NYuqnJxz9o8oaIqqC6E=.e70f482e-f7c2-42d0-bd21-a8a7d9de025e@github.com>

On Wed, 21 Feb 2024 19:10:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> While generating holder classes (in `generateHolderClasses()`), don't add the `MethodType` to the `invokerTypes` if will fail the check in the `build()` method which would result in a `RuntimeException`.
> 
> Also updated the `MethodHandlesInvokersTest.java` under `appcds/methodHandles` and `appcds/dynamicArchive/methodHandles` to check that the "Failed to generate LambdaForm holder classes" error is not in the output;
> 
> Passed tiers 1 - 3 testing.

This pull request has now been integrated.

Changeset: 41450e94
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41450e94059bbdf9ee798a1fc78ef14602319567
Stats:     140 lines in 15 files changed: 92 ins; 2 del; 46 mod

8314250: CDS dump error message: Invoker type parameter must start and end with Object: L3I_L

Reviewed-by: iklam, matsaave

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

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

From duke at openjdk.org  Mon Mar 11 20:58:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 11 Mar 2024 20:58:13 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v4]
In-Reply-To: <96SLiHrhxFPytd-Lk-CSRGvIbjHOxuWFc-0axGFIqRo=.f8a1d56f-3fd5-414c-9a22-de6cecf3e986@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <96SLiHrhxFPytd-Lk-CSRGvIbjHOxuWFc-0axGFIqRo=.f8a1d56f-3fd5-414c-9a22-de6cecf3e986@github.com>
Message-ID: <jm1h0GgFPUeonFdIaJuZjgmCuN6XQf2jrG1SKjJMpXk=.e816aab9-5096-4b1f-88f5-57394d38ad12@github.com>

On Mon, 11 Mar 2024 20:41:25 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 incrementally with one additional commit since the last revision:
> 
>   1. bug fix for CharBuffer catch IndexOutOfBoundsException
>   2. reorder if statement
>   3. Improve the performance of !isCompact branch

In (03 [#bb45da4d](https://github.com/openjdk/jdk/pull/18177/files/bb45da4da1c0fcd79db85dc9c1ce17b6b3dfd8a3) ) I have fixed the build error and further optimized the branch of !isCompact, so that the performance in the BigDecimal(char[]) scenario is better than the master version.


-Benchmark                                      Mode  Cnt    Score   Error  Units #master
-BigDecimals.testConstructorWithSmallCharArray  avgt   15   16.488 ? 0.054  ns/op
-BigDecimals.testConstructorWithLargeCharArray  avgt   15   90.583 ? 1.523  ns/op
-BigDecimals.testConstructorWithHugeCharArray   avgt   15   90.683 ? 1.623  ns/op
-BigDecimals.testConstructorWithCharArray       avgt   15   47.418 ? 0.473  ns/op
-BigDecimals.testConstructorWithSmallString     avgt   15   19.725 ? 0.049  ns/op
-BigDecimals.testConstructorWithLargeString     avgt   15  113.567 ? 1.470  ns/op
-BigDecimals.testConstructorWithHugeString      avgt   15  119.712 ? 6.230  ns/op
-BigDecimals.testConstructorWithString          avgt   15   67.046 ? 0.979  ns/op


+Benchmark                                      Mode  Cnt    Score   Error  Units (01 #61b5531b)
+BigDecimals.testConstructorWithSmallCharArray  avgt   15   14.322 ? 0.063  ns/op +15.12%
+BigDecimals.testConstructorWithLargeCharArray  avgt   15   74.090 ? 0.299  ns/op +22.26%
+BigDecimals.testConstructorWithHugeCharArray   avgt   15   74.372 ? 0.461  ns/op +21.93%
+BigDecimals.testConstructorWithCharArray       avgt   15   41.606 ? 0.284  ns/op +13.96%
+BigDecimals.testConstructorWithSmallString     avgt   15   15.019 ? 0.100  ns/op +31.33%
+BigDecimals.testConstructorWithLargeString     avgt   15   70.226 ? 0.240  ns/op +61.71%
+BigDecimals.testConstructorWithHugeString      avgt   15   70.153 ? 0.455  ns/op +70.64%
+BigDecimals.testConstructorWithString          avgt   15   40.064 ? 0.298  ns/op +67.36%


+Benchmark                                      Mode  Cnt    Score   Error  Units (03 #bb45da4d)
+BigDecimals.testConstructorWithSmallCharArray  avgt   15   22.450 ? 0.334  ns/op -26.55%
+BigDecimals.testConstructorWithLargeCharArray  avgt   15   88.087 ? 1.393  ns/op +2.83%
+BigDecimals.testConstructorWithHugeCharArray   avgt   15   87.643 ? 1.081  ns/op +3.46%
+BigDecimals.testConstructorWithCharArray       avgt   15   51.357 ? 2.389  ns/op -7.66%
+BigDecimals.testConstructorWithSmallString     avgt   15   16.892 ? 0.377  ns/op +11.78%
+BigDecimals.testConstructorWithLargeString     avgt   15   65.103 ? 0.219  ns/op +74.44%
+BigDecimals.testConstructorWithHugeString      avgt   15   64.475 ? 0.464  ns/op +85.67%
+BigDecimals.testConstructorWithString          avgt   15   36.582 ? 0.286  ns/op +83.27%

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1989429207

From naoto at openjdk.org  Mon Mar 11 21:26:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Mar 2024 21:26:17 GMT
Subject: Integrated: 8327705: Remove mention of "applet" from java.text package
 description
In-Reply-To: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
References: <iB-hHS-n2OQq_z2CI6k4gXCyXx8_JwMsObTZkGUN_9Q=.60252a9a-ca45-4313-8acf-904a9221cbab@github.com>
Message-ID: <KSPaR6PSYvCiMu4cUXlTuncqgXlyQ800bFE63cwuWK4=.54f8ca59-24d4-4393-8521-642b11e96b8b@github.com>

On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing left over "applet" mention in the package-info doc.

This pull request has now been integrated.

Changeset: 586396cb
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/586396cbb55a318fd6a2b4f1d8738258c6f8deff
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8327705: Remove mention of "applet" from java.text package description

Reviewed-by: bpb, rriggs, iris, jlu, gli, alanb

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

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

From duke at openjdk.org  Mon Mar 11 23:05:21 2024
From: duke at openjdk.org (Sergey)
Date: Mon, 11 Mar 2024 23:05:21 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
Message-ID: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>

The feature allows to extract a private field value in a single expression, like so:

object.getClass().getDeclaredField().setAccessible().get(object)

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

Commit messages:
 - Add functional-style setAccessible()

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

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

From duke at openjdk.org  Mon Mar 11 23:05:21 2024
From: duke at openjdk.org (Sergey)
Date: Mon, 11 Mar 2024 23:05:21 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <dLt-ToDjK54sk1v7AmCJjbpnMHmorWBU09iYQGDRLQk=.7e0da8f5-c778-42fe-bfe7-e2cc6462bc4a@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

How do I find an eligible reviewer and create an issue to link this PR to?

Are there any specific steps I can take to get this through?

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1912160226
PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1963809913

From duke at openjdk.org  Mon Mar 11 23:05:22 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Mon, 11 Mar 2024 23:05:22 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <4nyx1t8gJdsJXbfhfgf9akAENnrPkjIDRLytTb4Kl6Y=.c0de67b8-665b-49a8-bc43-74b98d166641@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

https://openjdk.org/contribute/
u may firstly have a look at this.

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1913439047

From liach at openjdk.org  Mon Mar 11 23:05:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Mar 2024 23:05:22 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <WCZEBxdxRUIrQUowr2TczavxC8qS3u_6z6l6HHlQBVQ=.b7cbea77-8e55-4bdf-b177-2e6c45e2fc49@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

First, usually to propose a patch to core libraries, we usually submit an issue or suggest an enhancement to https://bugs.java.com, or ask at `core-libs-dev at openjdk.org`.

A field that has been "set accessible" is supposed to be reused, as future `get` calls will bypass accessibility checks too. So adding a builder-style alias isn't that useful, especially that reflection Executable objects have no other setters, and the exceptions thrown by each method in the chain should be handled separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1965852745

From duke at openjdk.org  Mon Mar 11 23:05:22 2024
From: duke at openjdk.org (Sergey)
Date: Mon, 11 Mar 2024 23:05:22 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <WCZEBxdxRUIrQUowr2TczavxC8qS3u_6z6l6HHlQBVQ=.b7cbea77-8e55-4bdf-b177-2e6c45e2fc49@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
 <WCZEBxdxRUIrQUowr2TczavxC8qS3u_6z6l6HHlQBVQ=.b7cbea77-8e55-4bdf-b177-2e6c45e2fc49@github.com>
Message-ID: <CMDt229hfoyY4HLab2LSyzfSU_yduscS7S8zvo-Hinc=.d873815d-34a2-4ec0-bab0-86b360445606@github.com>

On Tue, 27 Feb 2024 06:09:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> First, usually to propose a patch to core libraries, we usually submit an issue or suggest an enhancement to https://bugs.java.com, or ask at `core-libs-dev at openjdk.org`.
> 
> A field that has been "set accessible" is supposed to be reused, as future `get` calls will bypass accessibility checks too. So adding a builder-style alias isn't that useful, especially that reflection Executable objects have no other setters, and the exceptions thrown by each method in the chain should be handled separately.

Thanks, I'll try to make my case at bugs.java.com

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1988037377

From duke at openjdk.org  Mon Mar 11 23:09:14 2024
From: duke at openjdk.org (Sergey)
Date: Mon, 11 Mar 2024 23:09:14 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <wvwKg9mOBS4hDVXcMHYCDFApfV2NRxf5z-uCLXz7NnU=.48cd3380-1a68-469a-8720-daf9d1d69782@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

So the only thing left seems to be finding a reviewer. What is the "standard protocol" to do that? Is there a public registry of accredited JDK reviewers so that I could pull some of them into this conversation, for example?

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1989612716

From bpb at openjdk.org  Mon Mar 11 23:25:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 11 Mar 2024 23:25:14 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <wvwKg9mOBS4hDVXcMHYCDFApfV2NRxf5z-uCLXz7NnU=.48cd3380-1a68-469a-8720-daf9d1d69782@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
 <wvwKg9mOBS4hDVXcMHYCDFApfV2NRxf5z-uCLXz7NnU=.48cd3380-1a68-469a-8720-daf9d1d69782@github.com>
Message-ID: <wqJR_bDxbl7715DXZyj16-DAkDutBsf89pT1UNddzYw=.6ad795a0-cbe0-4753-ae31-96b909e881e3@github.com>

On Mon, 11 Mar 2024 23:06:53 GMT, Sergey <duke at openjdk.org> wrote:

> What is the "standard protocol" to find a reviewer?

Reviewers will generally chime in of their own accord depending on their expertise, interest, availability, the perceived importance of the issue, and so on.

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1989628572

From duke at openjdk.org  Mon Mar 11 23:39:13 2024
From: duke at openjdk.org (Sergey)
Date: Mon, 11 Mar 2024 23:39:13 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <wqJR_bDxbl7715DXZyj16-DAkDutBsf89pT1UNddzYw=.6ad795a0-cbe0-4753-ae31-96b909e881e3@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
 <wvwKg9mOBS4hDVXcMHYCDFApfV2NRxf5z-uCLXz7NnU=.48cd3380-1a68-469a-8720-daf9d1d69782@github.com>
 <wqJR_bDxbl7715DXZyj16-DAkDutBsf89pT1UNddzYw=.6ad795a0-cbe0-4753-ae31-96b909e881e3@github.com>
Message-ID: <G8mUoyfeMfi03hG6ZX5hd1XRTrk9vJh7ViFV9C0obWM=.dfb98dc9-1f0f-43e1-a1ce-ac7fab777784@github.com>

On Mon, 11 Mar 2024 23:22:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > What is the "standard protocol" to find a reviewer?
> 
> Reviewers will generally chime in of their own accord depending on their expertise, interest, availability, the perceived importance of the issue, and so on.

What can I do to encourage them to come?

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1989641176

From amenkov at openjdk.org  Mon Mar 11 23:46:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 11 Mar 2024 23:46:13 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v2]
In-Reply-To: <wJkJ2qFwd6o2UrZ2sA1pGmj9J2uHj_fa3TmmrkE80zQ=.7e76b080-600b-4eb6-947e-358bd6c57eb6@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <wJkJ2qFwd6o2UrZ2sA1pGmj9J2uHj_fa3TmmrkE80zQ=.7e76b080-600b-4eb6-947e-358bd6c57eb6@github.com>
Message-ID: <eW7cRKS52y2QZKLkkpYXwzB3jo01XdwFFRWWGnO_uH4=.81ca26f9-3386-4f0b-bc72-c2983216e7a0@github.com>

On Sat, 9 Mar 2024 03:29:26 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8315575
>> 27:  * @summary test that records with invisible annotation can be retfansformed
> 
> Typo `retfansformed`.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1520552930

From liach at openjdk.org  Mon Mar 11 23:49:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Mar 2024 23:49:14 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <MdTe1DZVSDA3JiBSPl9oE3jicDTXQkgVG1NCvP067qA=.80aa0abd-7c64-46f0-81e3-3071938108ab@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

For your information, [the proposal has been rejected](https://bugs.openjdk.org/browse/JDK-8327786?focusedId=14656208&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14656208):

> Suppressing access control checks with setAccessible(true) is not something for most developers and not something to be encouraged. Using method invocation chaining with setAccessible doesn't seem worth doing

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1989650328

From liach at openjdk.org  Tue Mar 12 00:11:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Mar 2024 00:11:17 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections
In-Reply-To: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
Message-ID: <eTqodhlZ5xiKeBIdxYFgUtEXcR9ui8vXeIJaetE-GmE=.dbc14f4d-f028-4155-8a17-89ce816b4de2@github.com>

On Wed, 20 Sep 2023 04:52:31 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.

Benchmark results of Oracle JDK 21 vs the initial revision: https://jmh.morethan.io/?gists=c7a8398f291bedb2e1ad6d07c1d5cd97,8ef1c0826e0ae4e3e9a5e43df3dda230

It might be worth experimenting if manually unrolling the loop to be:
`for (int i = startIndex(); i > 0; i--)` and `for (int i = n; i > startIndex; i--)`
will be faster than the current index fetching.

Baseline results:

Benchmark                        Mode  Cnt    Score   Error   Units
ImmutableColls.forEachOverList  thrpt   15  351.497 ? 2.108  ops/us
ImmutableColls.forEachOverSet   thrpt   15   71.954 ? 3.732  ops/us
ImmutableColls.getOrDefault     thrpt   15  243.968 ? 0.823  ops/us
ImmutableColls.iterateOverList  thrpt   15  150.105 ? 3.371  ops/us
ImmutableColls.iterateOverSet   thrpt   15   62.071 ? 4.239  ops/us


Current version 8036e9e:

Benchmark                        Mode  Cnt    Score   Error   Units
ImmutableColls.forEachOverList  thrpt   15  364.515 ? 8.076  ops/us
ImmutableColls.forEachOverSet   thrpt   15   86.012 ? 2.420  ops/us
ImmutableColls.getOrDefault     thrpt   15  243.723 ? 1.071  ops/us
ImmutableColls.iterateOverList  thrpt   15  149.392 ? 5.328  ops/us
ImmutableColls.iterateOverSet   thrpt   15   63.579 ? 4.671  ops/us


Improvements can be seen in the `forEachOver(Set|List)` benchmarks.

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

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-1727000156
PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-1811960742
PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-1989671088

From liach at openjdk.org  Tue Mar 12 00:11:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Mar 2024 00:11:17 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections
Message-ID: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@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.

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

Commit messages:
 - 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
 - Remove useless implementations
 - Implement forEach for immutable collections
 - ... and 1 more: https://git.openjdk.org/jdk/compare/d451f818...8036e9e6

Changes: https://git.openjdk.org/jdk/pull/15834/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15834&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327858
  Stats: 91 lines in 2 files changed: 89 ins; 0 del; 2 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 mchung at openjdk.org  Tue Mar 12 00:19:13 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 12 Mar 2024 00:19:13 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <sL9_bvOMx6NkNyHQUtunx6vM2n9zYw4aWTkzgsLpgL0=.d48138cb-71aa-4463-89cc-eb31d534bf61@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

I agree with the evaluation of [JDK-8327786](https://bugs.openjdk.org/browse/JDK-8327786) that `setAccessible(true)` isn't for most developers and this proposal is not worth doing.

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1989681305

From syan at openjdk.org  Tue Mar 12 01:43:16 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 12 Mar 2024 01:43:16 GMT
Subject: Integrated: 8327486: java/util/Properties/PropertiesStoreTest.java
 fails "Text 'xxx' could not be parsed at index 20" after 8174269
In-Reply-To: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
References: <giMr8QuIA98wdqriFLDjUMAR1-1XbtFf_JrGoih66Zw=.3a647b72-3e99-4c3f-8428-62d51b8d7c98@github.com>
Message-ID: <IA2fRkaTUDjpG-KFdZZLWTZFZwFVtZ2M-ZYX7V-6YUE=.ea086048-9afe-473c-b455-48faa410c00f@github.com>

On Thu, 7 Mar 2024 16:47:01 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.

This pull request has now been integrated.

Changeset: e21da4ca
Author:    SendaoYan <syan at openjdk.org>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e21da4caacb464827270d20b8fc62a50a1706316
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8327486: java/util/Properties/PropertiesStoreTest.java fails "Text 'xxx' could not be parsed at index 20" after 8174269

Reviewed-by: naoto

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

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

From darcy at openjdk.org  Tue Mar 12 02:46:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Mar 2024 02:46:16 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v4]
In-Reply-To: <96SLiHrhxFPytd-Lk-CSRGvIbjHOxuWFc-0axGFIqRo=.f8a1d56f-3fd5-414c-9a22-de6cecf3e986@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <96SLiHrhxFPytd-Lk-CSRGvIbjHOxuWFc-0axGFIqRo=.f8a1d56f-3fd5-414c-9a22-de6cecf3e986@github.com>
Message-ID: <6m6SZFnGQLYNHZ4UdLxIAY4t287Q5NVlgMW6Y5AUbpg=.6474f5e8-00c6-42b9-b99c-0de889c5f69c@github.com>

On Mon, 11 Mar 2024 20:41:25 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 incrementally with one additional commit since the last revision:
> 
>   1. bug fix for CharBuffer catch IndexOutOfBoundsException
>   2. reorder if statement
>   3. Improve the performance of !isCompact branch

A general comment here: good performance on micro (or even nano) benchmark provides information to help evaluate a change. However, an improved benchmark results it is neither strictly necessary and certainly not sufficient for the change to go back. In other words, it is acceptable and expected that some changesets that improve performance on a chosen small bechmarks will not no back into mainline.

One reason is simple: even if a change is statistically significant on a benchmark, it may not be significant in practice on more application level workloads and may not provide enough benefit to overcome expected increased complexities in maintenance, etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1989897315

From darcy at openjdk.org  Tue Mar 12 02:50:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Mar 2024 02:50:16 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <sL9_bvOMx6NkNyHQUtunx6vM2n9zYw4aWTkzgsLpgL0=.d48138cb-71aa-4463-89cc-eb31d534bf61@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
 <sL9_bvOMx6NkNyHQUtunx6vM2n9zYw4aWTkzgsLpgL0=.d48138cb-71aa-4463-89cc-eb31d534bf61@github.com>
Message-ID: <URDIJVvZjZEKFtdLYz5zJnYodySIWhLVTGHs48ahnEU=.97f7439b-cbfa-47ce-bfb8-20c4a3b8dce9@github.com>

On Tue, 12 Mar 2024 00:16:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I agree with the evaluation of [JDK-8327786](https://bugs.openjdk.org/browse/JDK-8327786) that `setAccessible(true)` isn't for most developers and this proposal is not worth doing.

I concur.

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

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1989907327

From liach at openjdk.org  Tue Mar 12 03:17:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Mar 2024 03:17:14 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v4]
In-Reply-To: <96SLiHrhxFPytd-Lk-CSRGvIbjHOxuWFc-0axGFIqRo=.f8a1d56f-3fd5-414c-9a22-de6cecf3e986@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <96SLiHrhxFPytd-Lk-CSRGvIbjHOxuWFc-0axGFIqRo=.f8a1d56f-3fd5-414c-9a22-de6cecf3e986@github.com>
Message-ID: <mc2st-XNnUfn6fnFEGupKF-Q1b2G2rrvxf5HGB6wyl0=.9f62677a-96dc-43fc-8244-459b78a529d6@github.com>

On Mon, 11 Mar 2024 20:41:25 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 incrementally with one additional commit since the last revision:
> 
>   1. bug fix for CharBuffer catch IndexOutOfBoundsException
>   2. reorder if statement
>   3. Improve the performance of !isCompact branch

src/java.base/share/classes/java/math/BigDecimal.java line 762:

> 760:     }
> 761: 
> 762:     private BigDecimal(CharSequence val, MathContext mc) {

Can we move this constructor to before `parseExp`? This way there will be less diff and it will be easier to compare old and new code side-by-side.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1520792359

From duke at openjdk.org  Tue Mar 12 03:28:24 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 03:28:24 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v5]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <GNiMzAY4z06tPnj4JgntxYyg1yMGsVHCCYjHCbNOsTk=.5fdcd0a8-fe25-4961-bff3-7a962585adc4@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 incrementally with one additional commit since the last revision:

  easier to compare

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/bb45da4d..30d4f9b0

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

  Stats: 397 lines in 1 file changed: 198 ins; 199 del; 0 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 liach at openjdk.org  Tue Mar 12 04:17:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Mar 2024 04:17:13 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v5]
In-Reply-To: <GNiMzAY4z06tPnj4JgntxYyg1yMGsVHCCYjHCbNOsTk=.5fdcd0a8-fe25-4961-bff3-7a962585adc4@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <GNiMzAY4z06tPnj4JgntxYyg1yMGsVHCCYjHCbNOsTk=.5fdcd0a8-fe25-4961-bff3-7a962585adc4@github.com>
Message-ID: <M7jt0F0Hula5WLskSRfiqlLoOLZHpQA9IW9pwmANYPQ=.9c6e6780-5d30-4111-aab2-54aaa639375a@github.com>

On Tue, 12 Mar 2024 03:28:24 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 incrementally with one additional commit since the last revision:
> 
>   easier to compare

src/java.base/share/classes/java/math/BigDecimal.java line 562:

> 560:         BigInteger rb = null;         // the inflated value in BigInteger
> 561:         // use array bounds checking to handle too-long, len == 0,
> 562:         // bad offset, etc.

Restore this line of comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1520823418

From dholmes at openjdk.org  Tue Mar 12 06:03:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Mar 2024 06:03:13 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <oe9AQIYgckwYgesLlKw8kFD1Zbr_Gmaap4U7xjwD0-s=.eb7262f2-f8eb-4046-bcda-dbc361465b9f@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

src/java.base/share/classes/java/lang/reflect/Field.java line 184:

> 182:      * @throws InaccessibleObjectException {@inheritDoc}
> 183:      * @throws SecurityException {@inheritDoc}
> 184:      */

Inherits from what?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17578#discussion_r1520897359

From duke at openjdk.org  Tue Mar 12 06:18:27 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 06:18:27 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v6]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <q5JVDsz3ZnAxRS608VglUpi8QdaJX7BcYknY7O4xCGw=.95d23b06-4327-4d44-b98a-62a1206c15fd@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 incrementally with one additional commit since the last revision:

  easier to compare

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/30d4f9b0..b5157797

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

  Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 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 jpai at openjdk.org  Tue Mar 12 06:42:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Mar 2024 06:42:13 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
Message-ID: <Jt4vHKkIB89Kru9ZYKa6VP-7GwC8LZCGlNBzSnt4gGU=.eb731d76-9c25-4c51-8903-437e16777aae@github.com>

On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace calls to Unsafe.putObject with Unsafe.putReference
>  - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

Hello Eirik, Mandy, tier1, tier2, tier3 testing of the latest approved state of this PR passed without failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1990867492

From redestad at openjdk.org  Tue Mar 12 09:44:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Mar 2024 09:44:17 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v6]
In-Reply-To: <q5JVDsz3ZnAxRS608VglUpi8QdaJX7BcYknY7O4xCGw=.95d23b06-4327-4d44-b98a-62a1206c15fd@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <q5JVDsz3ZnAxRS608VglUpi8QdaJX7BcYknY7O4xCGw=.95d23b06-4327-4d44-b98a-62a1206c15fd@github.com>
Message-ID: <qvMhq3x84z4YfTcw1zIqZmuPYLJZD6LffVgKYk0nI08=.10035b44-55b2-46eb-9f19-903e2f911365@github.com>

On Tue, 12 Mar 2024 06:18:27 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 incrementally with one additional commit since the last revision:
> 
>   easier to compare

Sorry, when I got pinged in here the earlier comments didn't render and I missed the conversation.

So first off I think it's probably acceptable to regress the `char[]`-based constructors and gently push people towards other options. In few applications are `char[]` the source, and in the example mentioned there's a transform from `byte[]` to `char[]` which would probably end up being faster now with `new BigDecimal(new String(bytes, start, end, ISO_8859_1))`. 

That said perhaps there's room for improvement. Looking at `CharBuffer::charAt` it does surprisingly complicated logic and bounds checks. And the `CharBuffer` wrapper itself is a bit bloated due quite a few state variables (that we don't need for this use case). I did an experiment with a specialized implementation here: https://github.com/wenshao/jdk/pull/7 which yields good results. Not sure this is a great idea but something to consider (note that it's not general purpose since it's exploiting a deliberately missing bounds check in `charAt`).

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1991187517

From vklang at openjdk.org  Tue Mar 12 10:15:14 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Mar 2024 10:15:14 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections
In-Reply-To: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
Message-ID: <sMItJ-gYuIR9cHM5VvGvtXnAFn3dCMFEw2B3EQhiaG8=.a3f7ca24-61c7-400a-ae15-b4bcb9d92bbd@github.com>

On Wed, 20 Sep 2023 04:52:31 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.

src/java.base/share/classes/java/util/ImmutableCollections.java line 926:

> 924:             if (!REVERSE && e1 != EMPTY) {
> 925:                 action.accept((E) e1);
> 926:             }

I'm curious to know how the following alternative would fare:

Suggestion:

            if (e1 != EMPTY) {
                action.accept(REVERSE ? (E)e1 : (E)e0); // implicit null check
                action.accept(REVERSE ? (E)e0 : (E)e1);
            } else {
                action.accept(e0); // Implicit null check
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1521196650

From duke at openjdk.org  Tue Mar 12 10:24:46 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 10:24:46 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v7]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <cOqAlCui9PYOuqanEAG3F94yB3eODLjJviOVfKmZaYY=.9c3b107c-a823-44b7-a275-b37c489c5375@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 incrementally with one additional commit since the last revision:

  Add specialized CharArraySequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/b5157797..84a10a22

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

  Stats: 32 lines in 1 file changed: 23 ins; 8 del; 1 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 duke at openjdk.org  Tue Mar 12 10:34:33 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 10:34:33 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v8]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <tCAIGQT7h80_FiRW8a3tUU-Hq_uBMx6yF2RlH7N68H0=.bfbd7f5f-d3ec-4b9b-99a6-ce8d08d70ec3@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 incrementally with one additional commit since the last revision:

  refactor CharArraySequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/84a10a22..6e40101b

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

  Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 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 yzheng at openjdk.org  Tue Mar 12 10:49:20 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 12 Mar 2024 10:49:20 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic
Message-ID: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>

Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.

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

Commit messages:
 - Simplify BigInteger.implMultiplyToLen intrinsic

Changes: https://git.openjdk.org/jdk/pull/18226/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327964
  Stats: 53 lines in 2 files changed: 4 ins; 49 del; 0 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 redestad at openjdk.org  Tue Mar 12 11:33:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Mar 2024 11:33:15 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v8]
In-Reply-To: <tCAIGQT7h80_FiRW8a3tUU-Hq_uBMx6yF2RlH7N68H0=.bfbd7f5f-d3ec-4b9b-99a6-ce8d08d70ec3@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <tCAIGQT7h80_FiRW8a3tUU-Hq_uBMx6yF2RlH7N68H0=.bfbd7f5f-d3ec-4b9b-99a6-ce8d08d70ec3@github.com>
Message-ID: <61WiZsSs8quJVTxlG_BHHKVUhOzNyOI3XEomzq1tqDo=.3af1ce09-1ad4-4782-8c1f-b32f60e86146@github.com>

On Tue, 12 Mar 2024 10:34:33 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 incrementally with one additional commit since the last revision:
> 
>   refactor CharArraySequence

src/java.base/share/classes/java/math/BigDecimal.java line 846:

> 844:         @Override
> 845:         public char charAt(int offset) {
> 846:             return array[offset];

Good refactor and correctness fix to change this to `offset, length`, but this method looks incorrect now. The parameter should be the `offset`-relative index, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1521303532

From redestad at openjdk.org  Tue Mar 12 11:39:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Mar 2024 11:39:15 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v8]
In-Reply-To: <tCAIGQT7h80_FiRW8a3tUU-Hq_uBMx6yF2RlH7N68H0=.bfbd7f5f-d3ec-4b9b-99a6-ce8d08d70ec3@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <tCAIGQT7h80_FiRW8a3tUU-Hq_uBMx6yF2RlH7N68H0=.bfbd7f5f-d3ec-4b9b-99a6-ce8d08d70ec3@github.com>
Message-ID: <tUWG3XMLNzwM1wbFgpR_sdhKFlUJoRZZzpd2Gu0XNh8=.9faf6cb0-a208-4eda-a4a8-1df8c63df048@github.com>

On Tue, 12 Mar 2024 10:34:33 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 incrementally with one additional commit since the last revision:
> 
>   refactor CharArraySequence

src/java.base/share/classes/java/math/BigInteger.java line 608:

> 606:      * Constructs a new BigInteger using a char array with radix=10.
> 607:      * Sign is precalculated outside and not allowed in the val. The {@code val}
> 608:      * array is assumed to be unchanged for the duration of the constructor

This removed comment about the array being assumed to be unchanged is still applicable to the `CharSequence` (since it'll be backed by the passed in `char[]`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1521309524

From rgiulietti at openjdk.org  Tue Mar 12 12:09:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 12 Mar 2024 12:09:14 GMT
Subject: RFR: JDK-8327487: Further augment WorstCaseTests with more cases
 [v3]
In-Reply-To: <qOf1F_jncL2R_7jTfC6WNMdKoz8NgBC-55sY4V-bgj4=.7f672a16-3591-4cff-9f26-5d3acb556cc4@github.com>
References: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
 <qOf1F_jncL2R_7jTfC6WNMdKoz8NgBC-55sY4V-bgj4=.7f672a16-3591-4cff-9f26-5d3acb556cc4@github.com>
Message-ID: <VB9r06RAfLB1NyBWZ24nNDfXE7q5dCtacCDtnh0tNQQ=.c2e3f959-5fa8-48ba-bae2-ae36fc20eef2@github.com>

On Mon, 11 Mar 2024 17:17:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The atan2 and hypot cases added would fail for a particular test library that has errors in the millions of ulps for those inputs, rather than the small number of ulps specified for the error.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18140#pullrequestreview-1930871897

From redestad at openjdk.org  Tue Mar 12 12:17:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Mar 2024 12:17:16 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v8]
In-Reply-To: <tCAIGQT7h80_FiRW8a3tUU-Hq_uBMx6yF2RlH7N68H0=.bfbd7f5f-d3ec-4b9b-99a6-ce8d08d70ec3@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <tCAIGQT7h80_FiRW8a3tUU-Hq_uBMx6yF2RlH7N68H0=.bfbd7f5f-d3ec-4b9b-99a6-ce8d08d70ec3@github.com>
Message-ID: <ecJLrIk6Fi34lei79oNYpwwxDhP8dQDQBJeglgOxIfo=.39215902-cab0-4827-942d-fbd295533be1@github.com>

On Tue, 12 Mar 2024 10:34:33 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 incrementally with one additional commit since the last revision:
> 
>   refactor CharArraySequence

src/java.base/share/classes/java/math/BigInteger.java line 628:

> 626:         // Pre-allocate array of expected size
> 627:         int numWords;
> 628:         if (len < 10) {

IMHO removing these curly braces just adds noise to the PR and change history.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1521356886

From aturbanov at openjdk.org  Tue Mar 12 12:21:19 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Mar 2024 12:21:19 GMT
Subject: RFR: JDK-8327487: Further augment WorstCaseTests with more cases
 [v3]
In-Reply-To: <qOf1F_jncL2R_7jTfC6WNMdKoz8NgBC-55sY4V-bgj4=.7f672a16-3591-4cff-9f26-5d3acb556cc4@github.com>
References: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
 <qOf1F_jncL2R_7jTfC6WNMdKoz8NgBC-55sY4V-bgj4=.7f672a16-3591-4cff-9f26-5d3acb556cc4@github.com>
Message-ID: <06_L_eQPWV-DiYaMgngTMrjQ2GvW_Kv3pWyJnCEqD6U=.457aa6ab-b4f9-4c74-a7ec-f93c9c7b4225@github.com>

On Mon, 11 Mar 2024 17:17:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The atan2 and hypot cases added would fail for a particular test library that has errors in the millions of ulps for those inputs, rather than the small number of ulps specified for the error.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

test/jdk/java/lang/Math/WorstCaseTests.java line 496:

> 494:         };
> 495: 
> 496:         for(double[] testCase: testCases) {

nit
Suggestion:

        for (double[] testCase: testCases) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18140#discussion_r1521361874

From duke at openjdk.org  Tue Mar 12 12:39:28 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 12:39:28 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v9]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <bY7n4dOFq41HtS_ZtlzBIrBEEbZdJZwES80ZbKH5Kiw=.ad982229-331a-4c52-9b6e-7a3d1b24aa30@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 incrementally with two additional commits since the last revision:

 - easier to compare
 - fix CharArraySequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/6e40101b..8b2a762c

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

  Stats: 69 lines in 2 files changed: 43 ins; 22 del; 4 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 duke at openjdk.org  Tue Mar 12 13:04:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 13:04:14 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v6]
In-Reply-To: <qvMhq3x84z4YfTcw1zIqZmuPYLJZD6LffVgKYk0nI08=.10035b44-55b2-46eb-9f19-903e2f911365@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <q5JVDsz3ZnAxRS608VglUpi8QdaJX7BcYknY7O4xCGw=.95d23b06-4327-4d44-b98a-62a1206c15fd@github.com>
 <qvMhq3x84z4YfTcw1zIqZmuPYLJZD6LffVgKYk0nI08=.10035b44-55b2-46eb-9f19-903e2f911365@github.com>
Message-ID: <XWW-fhGZXJj9-xQEk97Pcxn13cP3hzHh4e9JliJssAQ=.458cfe65-75c4-43aa-b6fe-b01832b2a368@github.com>

On Tue, 12 Mar 2024 09:41:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   easier to compare
>
> Sorry, when I got pinged in here the earlier comments didn't render and I missed the conversation.
> 
> So first off I think it's probably acceptable to regress the `char[]`-based constructors and gently push people towards other options. In few applications are `char[]` the source, and in the example mentioned there's a transform from `byte[]` to `char[]` which would probably end up being faster now with `new BigDecimal(new String(bytes, start, end, ISO_8859_1))`. 
> 
> That said perhaps there's room for improvement. Looking at `CharBuffer::charAt` it does surprisingly complicated logic and bounds checks. And the `CharBuffer` wrapper itself is a bit bloated due quite a few state variables (that we don't need for this use case). I did an experiment with a specialized implementation here: https://github.com/wenshao/jdk/pull/7 which yields good results. Not sure this is a great idea but something to consider (note that it's not general purpose since it's exploiting a deliberately missing bounds check in `charAt`).

Thanks to @cl4es for pointing out my problem. I removed the curly braces not for change, and I don?t like this coding style either, but to try to be consistent with the coding style of the context.

I found that the CharArraySequence implementation without offset and length has better performance, so there are two implementations.

In the current version, the testConstructorWithSmallCharArray scene has a performance drop of 5.73%, and the performance of other scenes has improved.


-Benchmark                                      Mode  Cnt    Score   Error  Units (base)
-BigDecimals.testConstructorWithSmallCharArray  avgt   15   16.445 ? 0.050  ns/op
-BigDecimals.testConstructorWithLargeCharArray  avgt   15   90.470 ? 1.250  ns/op
-BigDecimals.testConstructorWithHugeCharArray   avgt   15   90.324 ? 1.398  ns/op
-BigDecimals.testConstructorWithCharArray       avgt   15   48.392 ? 1.284  ns/op
-BigDecimals.testConstructorWithSmallString     avgt   15   19.598 ? 0.084  ns/op
-BigDecimals.testConstructorWithLargeString     avgt   15  124.449 ? 6.672  ns/op
-BigDecimals.testConstructorWithHugeString      avgt   15  130.646 ? 3.427  ns/op
-BigDecimals.testConstructorWithString          avgt   15   68.975 ? 2.721  ns/op

+Benchmark                                      Mode  Cnt    Score   Error  Units (v08 #8b2a762c)
+BigDecimals.testConstructorWithSmallCharArray  avgt   15   17.446 ? 0.054  ns/op -5.73%
+BigDecimals.testConstructorWithLargeCharArray  avgt   15   71.501 ? 0.684  ns/op +26.52%
+BigDecimals.testConstructorWithHugeString      avgt   15   63.814 ? 0.243  ns/op +41.54%
+BigDecimals.testConstructorWithCharArray       avgt   15   41.408 ? 0.830  ns/op +16.86%
+BigDecimals.testConstructorWithSmallString     avgt   15   16.668 ? 0.527  ns/op +17.57%
+BigDecimals.testConstructorWithLargeString     avgt   15   64.055 ? 0.183  ns/op +94.28%
+BigDecimals.testConstructorWithHugeCharArray   avgt   15   70.691 ? 0.682  ns/op +84.81%
+BigDecimals.testConstructorWithString          avgt   15   35.946 ? 0.291  ns/op +91.88%

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1991601242

From duke at openjdk.org  Tue Mar 12 13:07:26 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 13:07:26 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <EraXrOvD8Jm9Yy6ZwOB448SUHswYn9Nu_X_FMMQrTYc=.7c049574-d1c8-4c1f-9b2d-a6cd68f7f2c0@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 incrementally with one additional commit since the last revision:

  restore comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/8b2a762c..e118b939

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 ihse at openjdk.org  Tue Mar 12 13:54:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 13:54:16 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <YvnZO9thUwxN_O0wk1moNpQvP8PLakWzD31_zlBQ5l0=.eee10e2d-5d7b-40ab-b5d9-c440d83671e6@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <YvnZO9thUwxN_O0wk1moNpQvP8PLakWzD31_zlBQ5l0=.eee10e2d-5d7b-40ab-b5d9-c440d83671e6@github.com>
Message-ID: <qMUM0kdr3YlYGvvMkYv0G7HfdNrbrdu3HIHRbawKPus=.5051dd98-5622-4c43-9d1d-e016c3cf11c8@github.com>

On Fri, 8 Mar 2024 18:12:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update line number for dereference_null  in TestDwarf
>
> test/jdk/java/foreign/CallGeneratorHelper.java line 216:
> 
>> 214:         if (header) {
>> 215:             System.out.println(
>> 216:                 "#include \"export.h\"\n"
> 
> We don't generate these header files any more, so the changes to this file are not really needed.

I still wouldn't like to keep the bad hard-coded defines. Are you okay with me pushing these changes, and then you can remove the parts of the test that are not actually used anymore? If the code is not used it should not matter much to you either way.

(I mean I could back out these changes, but then we'd have the bad code in place while waiting for you to remove it, putting pressure on you to actually remove it.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1521503942

From ihse at openjdk.org  Tue Mar 12 13:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 13:59:15 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code
In-Reply-To: <_YFd8mgBis8mgRwfpafttLS2y1_-Aiy5aIdLr2eCXv8=.4890fb5d-cc8a-4cd8-a53d-3f18aa1dfbe6@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <D4VnoA_AetZT4vT_WasTrnfsavTpUH4oy8bCTL7HAWY=.5f2b4617-5854-4913-922e-aa84cd9c04a9@github.com>
 <_YFd8mgBis8mgRwfpafttLS2y1_-Aiy5aIdLr2eCXv8=.4890fb5d-cc8a-4cd8-a53d-3f18aa1dfbe6@github.com>
Message-ID: <h_Yd8OW46LtAotIz6WNFAV1rg5e2iTulRAz9ze3PDr4=.aa91d29d-5d86-43f6-86a2-d11407bfa725@github.com>

On Mon, 11 Mar 2024 06:57:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c was missing an export. This had not been discovered before since that file was not compiled on Windows.

> It's a Linux/macOS specific test so it wasn't needed.

Yeah. I understand. I just wanted to give an explanation for why this particular test needed changes that were not present elsewhere (since other exported methods all were tested on Windows).

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1991712352

From ihse at openjdk.org  Tue Mar 12 13:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 13:59:15 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <-9V3vdX_4NWhrgoEYdqy9W-PyT8HBwjKyMwF-IzM9Uo=.c5f3e91a-017e-42c1-abc3-ab90c94f3b75@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <-9V3vdX_4NWhrgoEYdqy9W-PyT8HBwjKyMwF-IzM9Uo=.c5f3e91a-017e-42c1-abc3-ab90c94f3b75@github.com>
Message-ID: <BV0oYa1m3BBtTzVWyMXkoFfeatyKzKf3yysaIZRsXzU=.710e8be3-2b21-4c4d-b3e5-ac9c1ca9e956@github.com>

On Mon, 11 Mar 2024 06:57:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Good cleanup.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1991712859

From ihse at openjdk.org  Tue Mar 12 13:59:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 13:59:16 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <qf1hQUA-XivudvebTcZWk3E1xkR5opV3pQy-qnNvbqo=.254083ec-ab5e-42d8-8cf2-9a5690cda466@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <qf1hQUA-XivudvebTcZWk3E1xkR5opV3pQy-qnNvbqo=.254083ec-ab5e-42d8-8cf2-9a5690cda466@github.com>
Message-ID: <NPNGO0vJDEQgfQ5kydJCOKSwSIrbHausWtqj1fIUy18=.a8659776-e94d-4231-927c-1abf0677b077@github.com>

On Mon, 11 Mar 2024 02:31:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update line number for dereference_null  in TestDwarf
>
> test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 24:
> 
>> 22:  */
>> 23: 
>> 24: #include <stdio.h>
> 
> Seems unneeded.

So what I did here was change:

#include "jni.h"
#include <stdio.h>


into 

#include <stdio.h>

#include "export.h"
#include "jni.h"


The reordering was strictly not needed, but putting user includes in front of system ones looked like bad coding to me, and put me in a difficult spot in where to add the new `#include "export.h"` -- next to the current user include even if I thought that was wrong, or have the system includes "sandwitched" between two user includes.

Or do you mean that it seems unneeded to include `jni.h` at all? Yes, I agree, but it was there before, and I don't want to make any other changes to the tests. This change is scary enough as it is :-). If you want, I can file a follow-up to remove this include instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1521510510

From ihse at openjdk.org  Tue Mar 12 14:05:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 14:05:16 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v2]
In-Reply-To: <ww1QQHsJ7gJh3n0zC30g-e0SDxYM7FrvgivHY0D7vkA=.d8803e46-3e6c-4ddf-9efd-aad6f6baaa7f@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
 <ww1QQHsJ7gJh3n0zC30g-e0SDxYM7FrvgivHY0D7vkA=.d8803e46-3e6c-4ddf-9efd-aad6f6baaa7f@github.com>
Message-ID: <p7Nk2XEXT45-RgggBJy_to_qsktrnoWAfxxCPkgO8-o=.cb2828f0-6d37-4b06-aecd-ac73885c2f67@github.com>

On Mon, 11 Mar 2024 20:04:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code cleanup
>
> make/modules/java.base/Launcher.gmk line 85:
> 
>> 83:           -DVERSION_INTERIM=$(VERSION_INTERIM) \
>> 84:           -DVERSION_UPDATE=$(VERSION_UPDATE) \
>> 85:           -DVERSION_PATCH=$(VERSION_PATCH), \
> 
> Using all 4 is way overkill for the problem at hand.  Just the FEATURE_VERSION is sufficient.
> We all know better than to make incompatible changes in minor versions let alone update or patch version.

There is already a `$(VERSION_CFLAGS)` variable defined. It will set all those (and some more). Please use it instead. But then, as Roger says, it is probably overkill to *check* anything but the feature version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18204#discussion_r1521525658

From redestad at openjdk.org  Tue Mar 12 14:05:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Mar 2024 14:05:17 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <EraXrOvD8Jm9Yy6ZwOB448SUHswYn9Nu_X_FMMQrTYc=.7c049574-d1c8-4c1f-9b2d-a6cd68f7f2c0@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <EraXrOvD8Jm9Yy6ZwOB448SUHswYn9Nu_X_FMMQrTYc=.7c049574-d1c8-4c1f-9b2d-a6cd68f7f2c0@github.com>
Message-ID: <UeTlF6XlFqMijlqRAt_EBrPYzMSOjLmvqPXej5m4Qz8=.c54e472c-1b98-4817-9c09-34b6188f7797@github.com>

On Tue, 12 Mar 2024 13:07:26 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 incrementally with one additional commit since the last revision:
> 
>   restore comment

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.

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

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1991727125

From ihse at openjdk.org  Tue Mar 12 14:10:22 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 14:10:22 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <Wc4EhkYtdpo85jdS0HKUqWM_fZvSkND-wNzJysojm-c=.0745ccb4-a7ba-4583-b8af-85d515710cb5@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
 <gToCsx0XWYk3uFGdoJEWKimnRULPsh2GIhJMlV1K4f8=.d3da8551-91c0-47b5-a163-847ffc2e0e83@github.com>
 <lhEDwRmaffeIq1qd7XgS5o1s9ynp39y4-IlBGdjFmHU=.cb39b8b7-e1de-4816-8748-67805c7970c8@github.com>
 <Wc4EhkYtdpo85jdS0HKUqWM_fZvSkND-wNzJysojm-c=.0745ccb4-a7ba-4583-b8af-85d515710cb5@github.com>
Message-ID: <e38etX44zABjjypVZFAYfokGwtUHKpNav2xzFyakMkg=.21049964-25d2-4e6d-b7f8-c46939903ba9@github.com>

On Mon, 11 Mar 2024 13:06:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Why the rm? Because jlink refuses to run if the output dir already exists.
>
> I don't see a race. The `rm` was there in the original code and is no scarier in the modified version. The jdk image is constructed by a combination of targets and recipes. The first one to run has to be jlink, then we overlay more stuff on top. If the makefile dependency resolution concludes that we need to rerun the jlink step, we clear out the directory completely to make sure we aren't leaving anything in there that's no longer valid. This is basically a precaution to guarantee a correct incremental build. It's not incurring a big build time penalty as jlink would have overwritten all files it would have created anyway. However, if a module was removed, or a file was removed from a module, the `rm` helps guarantee that we don't include such a removed file from a previous build attempt in the final image.
> 
> Or it may even be as Severin says, that jlink refuses to run, I don't remember.

Ok, good, thanks. I did not see the whole picture there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1521535618

From abimpoudis at openjdk.org  Tue Mar 12 14:11:32 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 12 Mar 2024 14:11:32 GMT
Subject: RFR: 8327839: Crash with unboxing and widening primitive conversion in
 switch
Message-ID: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>

In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug.

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

Commit messages:
 - 8327839: Crash with unboxing and widening primitive conversion in switch

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

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

From duke at openjdk.org  Tue Mar 12 14:30:16 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 14:30:16 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <EraXrOvD8Jm9Yy6ZwOB448SUHswYn9Nu_X_FMMQrTYc=.7c049574-d1c8-4c1f-9b2d-a6cd68f7f2c0@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <EraXrOvD8Jm9Yy6ZwOB448SUHswYn9Nu_X_FMMQrTYc=.7c049574-d1c8-4c1f-9b2d-a6cd68f7f2c0@github.com>
Message-ID: <c7vSJHje8Tl0zImuTfmuYGqnwFbXzRohmAXbX0LjtFc=.35df20a2-c7ac-4b64-89c4-025eb2739a30@github.com>

On Tue, 12 Mar 2024 13:07:26 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 incrementally with one additional commit since the last revision:
> 
>   restore comment

I agree with you, the char[] constructors is probably less performance sensitive than the others.

The performance numbers under MacBookPro M1 Max are as follows:


-Benchmark                                      Mode  Cnt   Score   Error  Units (one CharArraySequence)
-BigDecimals.testConstructorWithSmallCharArray  avgt   15  19.157 ? 0.074  ns/op

+Benchmark                                      Mode  Cnt   Score   Error  Units (two CharArraySequence)
+BigDecimals.testConstructorWithSmallCharArray  avgt   15  17.833 ? 0.124  ns/op +7.42

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1991781940

From ihse at openjdk.org  Tue Mar 12 14:46:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 14:46:19 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
Message-ID: <PciKkSAIiU4yMcmDvIRJuT4WIMIusbr7hP9WIZYx6VE=.e783df17-3fa2-426e-933c-b99e59c8c9e8@github.com>

On Tue, 27 Feb 2024 15:23:09 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:
> 
>   Only show runtime image suffix for JDK modules

Thanks for all the descriptions! They were all very clear and well-written. I'm going to paste some of them into the JBS issue for future record keeping.

With this background, I fully agree with the chosen solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1991815728

From ihse at openjdk.org  Tue Mar 12 15:16:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:16:30 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v3]
In-Reply-To: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
Message-ID: <0TOkCbNH7MaB96StWPTbQZUzo2mT-9jzCSpNlqg-PJM=.4f227516-fe08-4e6b-a5db-63d39e29a4fe@github.com>

> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Set JVM_PICFLAG="-fpic -mcmodel=large" for AIX
 -  Open XL 17.1.1.4 is clang 15.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18172/files
  - new: https://git.openjdk.org/jdk/pull/18172/files/53a05019..e7949499

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18172&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18172&range=01-02

  Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18172/head:pull/18172

PR: https://git.openjdk.org/jdk/pull/18172

From ihse at openjdk.org  Tue Mar 12 15:16:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:16:30 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <Ioh-YZlIDNY5Uts86Hq24PW7qlhd4G0ztoY7Kyjqxqs=.620fb161-9f94-4bb0-acea-c6245869069e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>
 <Ioh-YZlIDNY5Uts86Hq24PW7qlhd4G0ztoY7Kyjqxqs=.620fb161-9f94-4bb0-acea-c6245869069e@github.com>
Message-ID: <P7f5s7dJpE9cr-hDRRRiIFyJiP_A5gFjXGjE-77EiZY=.37406161-2f57-4b30-b910-88d17ef2bf9a@github.com>

On Mon, 11 Mar 2024 09:30:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Is Open XL C/C++ considered a compiler or more akin to a development environment like Xcode is for macOS? Depending on which, we could just say clang is the compiler for AIX without needing to say that Open XL is treated like clang, etc

You are raising a good point. Our current concept of "toolchain" is not working as smoothly as it should be. We should probably split it into "toolchain environment" (or whatever), like Xcode or Open XL, and "toolchain compiler" (like clang), and/or possibly also some concept of "toolchain sdk".

The work you are doing of untangling Windows from Visual Studio would probably influence such a redesign, seeing what part of the Windows adaptions which arise from cl, and which are constant given that you compile for windows (like the Windows SDK).

But this is a more architectural issue that will need to be resolved in another PR, and probably discussed quite a bit beforehand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1521637464

From ihse at openjdk.org  Tue Mar 12 15:16:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:16:30 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <P7f5s7dJpE9cr-hDRRRiIFyJiP_A5gFjXGjE-77EiZY=.37406161-2f57-4b30-b910-88d17ef2bf9a@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>
 <Ioh-YZlIDNY5Uts86Hq24PW7qlhd4G0ztoY7Kyjqxqs=.620fb161-9f94-4bb0-acea-c6245869069e@github.com>
 <P7f5s7dJpE9cr-hDRRRiIFyJiP_A5gFjXGjE-77EiZY=.37406161-2f57-4b30-b910-88d17ef2bf9a@github.com>
Message-ID: <lhFGFpyEmGC_7dM5iZA1yv4wDlgmFs4Aet3ksLzCclo=.15182a62-341b-40a1-afdd-48f4027673a9@github.com>

On Tue, 12 Mar 2024 15:04:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Is Open XL C/C++ considered a compiler or more akin to a development environment like Xcode is for macOS? Depending on which, we could just say clang is the compiler for AIX without needing to say that Open XL is treated like clang, etc
>> 
>> Also, why did this remove the link to the Supported Build Platforms page?
>
>> Is Open XL C/C++ considered a compiler or more akin to a development environment like Xcode is for macOS? Depending on which, we could just say clang is the compiler for AIX without needing to say that Open XL is treated like clang, etc
> 
> You are raising a good point. Our current concept of "toolchain" is not working as smoothly as it should be. We should probably split it into "toolchain environment" (or whatever), like Xcode or Open XL, and "toolchain compiler" (like clang), and/or possibly also some concept of "toolchain sdk".
> 
> The work you are doing of untangling Windows from Visual Studio would probably influence such a redesign, seeing what part of the Windows adaptions which arise from cl, and which are constant given that you compile for windows (like the Windows SDK).
> 
> But this is a more architectural issue that will need to be resolved in another PR, and probably discussed quite a bit beforehand.

> why did this remove the link to the Supported Build Platforms page?

You make it sound like it is a bad thing, but in fact I promoted the AIX build to be of the same status as all other platforms. I cowardly did not put anything specific about the AIX build in the readme before, but just referred to the wiki. Now I decided we should actually treat this as a proper platform and describe the compiler version in the readme, since it is checked in configure, just like all other platforms.

There is still a link to the Supported Build Platforms wiki page in the general part of the readme.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1521642995

From ihse at openjdk.org  Tue Mar 12 15:16:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:16:30 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <lhFGFpyEmGC_7dM5iZA1yv4wDlgmFs4Aet3ksLzCclo=.15182a62-341b-40a1-afdd-48f4027673a9@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>
 <Ioh-YZlIDNY5Uts86Hq24PW7qlhd4G0ztoY7Kyjqxqs=.620fb161-9f94-4bb0-acea-c6245869069e@github.com>
 <P7f5s7dJpE9cr-hDRRRiIFyJiP_A5gFjXGjE-77EiZY=.37406161-2f57-4b30-b910-88d17ef2bf9a@github.com>
 <lhFGFpyEmGC_7dM5iZA1yv4wDlgmFs4Aet3ksLzCclo=.15182a62-341b-40a1-afdd-48f4027673a9@github.com>
Message-ID: <Ar1IFhPb5b3al2ywNyc9Noe1Z6oUl2dyrX5TxF89KlQ=.46043776-03b2-4598-bcb1-f39081351abc@github.com>

On Tue, 12 Mar 2024 15:07:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> Is Open XL C/C++ considered a compiler or more akin to a development environment like Xcode is for macOS? Depending on which, we could just say clang is the compiler for AIX without needing to say that Open XL is treated like clang, etc
>> 
>> You are raising a good point. Our current concept of "toolchain" is not working as smoothly as it should be. We should probably split it into "toolchain environment" (or whatever), like Xcode or Open XL, and "toolchain compiler" (like clang), and/or possibly also some concept of "toolchain sdk".
>> 
>> The work you are doing of untangling Windows from Visual Studio would probably influence such a redesign, seeing what part of the Windows adaptions which arise from cl, and which are constant given that you compile for windows (like the Windows SDK).
>> 
>> But this is a more architectural issue that will need to be resolved in another PR, and probably discussed quite a bit beforehand.
>
>> why did this remove the link to the Supported Build Platforms page?
> 
> You make it sound like it is a bad thing, but in fact I promoted the AIX build to be of the same status as all other platforms. I cowardly did not put anything specific about the AIX build in the readme before, but just referred to the wiki. Now I decided we should actually treat this as a proper platform and describe the compiler version in the readme, since it is checked in configure, just like all other platforms.
> 
> There is still a link to the Supported Build Platforms wiki page in the general part of the readme.

> It is clang 15 not 13. Clang 13 was in 17.1.0

Thanks! Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1521646622

From ihse at openjdk.org  Tue Mar 12 15:16:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:16:30 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v3]
In-Reply-To: <ym4JkRJQUoM3hQXlhx1Uwrqs0MFrKSA8TDz0ggKFMbc=.fc3722a0-a1ae-4d97-b619-56ea98402c0c@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <McIPLciH42WumSGkYLGvyyqQ-tntHyzlYa-iou8p3W8=.800e6f9e-1844-4d56-8054-80477058573f@github.com>
 <U1lfAxBkklFXkNC4jPSOY9jM-uvs0vMuHH7VZgAC0AM=.4445f8df-c8c8-4363-a35e-b89c571cde03@github.com>
 <ym4JkRJQUoM3hQXlhx1Uwrqs0MFrKSA8TDz0ggKFMbc=.fc3722a0-a1ae-4d97-b619-56ea98402c0c@github.com>
Message-ID: <BIhbzXI75pM_diWYSgO4wf1H-wjuvFq0ox0HPypK9-I=.34a7de3c-883d-4308-bda0-96a4d163077a@github.com>

On Mon, 11 Mar 2024 13:45:46 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> OK this was a flaw in my introduction of clang toolchain for AIX. The intention was to keep the xlc options in form of their clang counterparts. I will try with a corrected version for clang on AIX and will come back to you.
>
> OK, the `-Wl,-bbigtoc` is not a compiler option but a linker option and it is already set in the linker options.
> But the `-fpic -mcmodel=large` should be set to avoid creating a jump to out-of-order code.
> 
> So we can replace the
> 
>   JVM_PICFLAG="$PICFLAG"
>   JDK_PICFLAG="$PICFLAG"
> 
> 
> code some lines below by
> 
> 
>   if test "x$TOOLCHAIN_TYPE" = xclang && test "x$OPENJDK_TARGET_OS" = xaix; then
>     JVM_PICFLAG="-fpic -mcmodel=large"
>   else
>     JVM_PICFLAG="$PICFLAG"
>   fi
>   JDK_PICFLAG="$PICFLAG"

I'm not entirely happy to do this here, as it is a bug fix, and it will change behavior, in contrast to the rest of the patch which is just about removing unused code.

But it's a small fix, and I'm messing with the part of the code anyway, so if you are sure that this is the right thing to do I'll sneak it in here. Please make sure it works.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1521652510

From ihse at openjdk.org  Tue Mar 12 15:19:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:19:18 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>
Message-ID: <TfNIppAJuRdhDtTIe7_UEZacBWEB-QQgz-syx8MaNmI=.86318625-3843-4292-ac86-ab66ef5a095e@github.com>

On Mon, 11 Mar 2024 09:14:27 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 409:
> 
>> 407:     #    Target: powerpc-ibm-aix7.2.0.0
>> 408:     #    Thread model: posix
>> 409:     #    InstalledDir: /opt/IBM/openxlC/17.1.0/bin
> 
> Please correct:
> IBM Open XL C/C++ for AIX 17.1.**1** (xxxxxxxxxxxxxxx), clang version 1**5**.0.0
>     #    Target: **powerpc-ibm-aix7.2.**5**.7**
>     #    Thread model: posix
>     #    InstalledDir: /opt/IBM/openxlC/17.1.**1**/bin

That was just intended as an example code. At one point, this has been printed by the compiler output (at least according to the source I found on the net). I tried to find a bunch of different examples from different platforms and versions. 

But sure, if it makes you happier, I can replace it with a more up to date example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1521656819

From ihse at openjdk.org  Tue Mar 12 15:19:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:19:19 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <TfNIppAJuRdhDtTIe7_UEZacBWEB-QQgz-syx8MaNmI=.86318625-3843-4292-ac86-ab66ef5a095e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <mehlNc-3I43oISWMHGfAHxhm1W5RKyEvGQk5ru5dwGY=.ebdd700d-4ca2-47c2-961c-b5fcea5c00ec@github.com>
 <TfNIppAJuRdhDtTIe7_UEZacBWEB-QQgz-syx8MaNmI=.86318625-3843-4292-ac86-ab66ef5a095e@github.com>
Message-ID: <nJyUXYL3Mt5LnI_2H0hfT7yTDFNmuPZd8LvW8msfl5Y=.3e503566-d993-463f-a37f-4d7382565a89@github.com>

On Tue, 12 Mar 2024 15:15:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/toolchain.m4 line 409:
>> 
>>> 407:     #    Target: powerpc-ibm-aix7.2.0.0
>>> 408:     #    Thread model: posix
>>> 409:     #    InstalledDir: /opt/IBM/openxlC/17.1.0/bin
>> 
>> Please correct:
>> IBM Open XL C/C++ for AIX 17.1.**1** (xxxxxxxxxxxxxxx), clang version 1**5**.0.0
>>     #    Target: **powerpc-ibm-aix7.2.**5**.7**
>>     #    Thread model: posix
>>     #    InstalledDir: /opt/IBM/openxlC/17.1.**1**/bin
>
> That was just intended as an example code. At one point, this has been printed by the compiler output (at least according to the source I found on the net). I tried to find a bunch of different examples from different platforms and versions. 
> 
> But sure, if it makes you happier, I can replace it with a more up to date example.

Actually, your example seems doctored (the `xxxxx`) string. I think I'll keep the real world example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1521659238

From ihse at openjdk.org  Tue Mar 12 15:27:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:27:29 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v4]
In-Reply-To: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
Message-ID: <Nd9G2lbssxwTvHQHeSHqaRqJ7uQIq8rVO2HulAV5V1w=.0b12fe1c-b990-4025-b24b-9636a25e424d@github.com>

> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Replace CC_VERSION_OUTPUT with CC_VERSION_STRING
 - We need CC_VERSION_OUTPUT before we can check it

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18172/files
  - new: https://git.openjdk.org/jdk/pull/18172/files/e7949499..577715b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18172&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18172&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18172/head:pull/18172

PR: https://git.openjdk.org/jdk/pull/18172

From ihse at openjdk.org  Tue Mar 12 15:27:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:27:29 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <guGW7d1XFNl7TE84CKTrkWngW5mNZ8dEhgiUaUphTcQ=.447ec868-160f-4f96-9dc3-16e955e1c8d7@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <guGW7d1XFNl7TE84CKTrkWngW5mNZ8dEhgiUaUphTcQ=.447ec868-160f-4f96-9dc3-16e955e1c8d7@github.com>
Message-ID: <3S9pyv9jOnJihfgqtK_CXhDDV62pzek2TrduKffVTnI=.4e8d8016-a299-4596-92f4-1bcf6bd206f4@github.com>

On Mon, 11 Mar 2024 12:44:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert SEARCH_PATH changes
>
> With this change added, currently  configure fails 
> 
> 
> checking for ibm-llvm-cxxfilt... /opt/IBM/openxlC/17.1.1/tools/ibm-llvm-cxxfilt
> configure: error: ibm-clang_r version output check failed, output: 
> configure exiting with result code 
> 
> maybe  related to what Joachim pointed out ?

@MBaesken Yes, it was the bug Joachim found. It should be fixed now, together will all other comments (except the example version string in the comments).

Please re-test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1991913029

From ihse at openjdk.org  Tue Mar 12 15:27:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 15:27:29 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <0yRLC1SM9um8MIZYJP6sf8OOMeOCbzCc1LF_JQLxZHg=.e3391f4e-ab9e-423c-880c-e84aba29e87b@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <0yRLC1SM9um8MIZYJP6sf8OOMeOCbzCc1LF_JQLxZHg=.e3391f4e-ab9e-423c-880c-e84aba29e87b@github.com>
Message-ID: <7IuMlu40vZGHuJYHQZvYgMVi72Hd72bn1RfkvD0gygg=.27838cfe-7ae7-42e7-ac46-b08b5610d979@github.com>

On Mon, 11 Mar 2024 12:27:08 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 940:
> 
>> 938:   if test "x$OPENJDK_TARGET_OS" = xaix; then
>> 939:     # Make sure we have the Open XL version of clang on AIX
>> 940:     $ECHO "$CC_VERSION_OUTPUT" | $GREP "IBM Open XL C/C++ for AIX" > /dev/null
> 
> This does not work since $CC_VERSION_OUTPUT is unset. We need 
> 	CC_VERSION_OUTPUT=`${XLC_TEST_PATH}ibm-clang++_r --version 2>&1 | $HEAD -n 1`
> before, as in the previous code some lines above which you removed.

Yeah, you are right. I confused it with CC_VERSION_STRING.

... duh.

Actually, that is what I should be using instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18172#discussion_r1521667916

From jvernee at openjdk.org  Tue Mar 12 15:49:13 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 12 Mar 2024 15:49:13 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <qMUM0kdr3YlYGvvMkYv0G7HfdNrbrdu3HIHRbawKPus=.5051dd98-5622-4c43-9d1d-e016c3cf11c8@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <YvnZO9thUwxN_O0wk1moNpQvP8PLakWzD31_zlBQ5l0=.eee10e2d-5d7b-40ab-b5d9-c440d83671e6@github.com>
 <qMUM0kdr3YlYGvvMkYv0G7HfdNrbrdu3HIHRbawKPus=.5051dd98-5622-4c43-9d1d-e016c3cf11c8@github.com>
Message-ID: <aDKgOefES3-P0FW9khDHtVynX6PAsjEiTVwVOViO4RM=.e8decd7f-f77f-4c53-960a-af7fc6c61820@github.com>

On Tue, 12 Mar 2024 13:51:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/java/foreign/CallGeneratorHelper.java line 216:
>> 
>>> 214:         if (header) {
>>> 215:             System.out.println(
>>> 216:                 "#include \"export.h\"\n"
>> 
>> We don't generate these header files any more, so the changes to this file are not really needed.
>
> I still wouldn't like to keep the bad hard-coded defines. Are you okay with me pushing these changes, and then you can remove the parts of the test that are not actually used anymore? If the code is not used it should not matter much to you either way.
> 
> (I mean I could back out these changes, but then we'd have the bad code in place while waiting for you to remove it, putting pressure on you to actually remove it.)

Yes, that's fine. Sorry, I meant to file a JBS issue and come back with another comment last time, but I got distracted. Filed: https://bugs.openjdk.org/browse/JDK-8327994 now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1521715617

From mbaesken at openjdk.org  Tue Mar 12 16:05:18 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Mar 2024 16:05:18 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <3S9pyv9jOnJihfgqtK_CXhDDV62pzek2TrduKffVTnI=.4e8d8016-a299-4596-92f4-1bcf6bd206f4@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <guGW7d1XFNl7TE84CKTrkWngW5mNZ8dEhgiUaUphTcQ=.447ec868-160f-4f96-9dc3-16e955e1c8d7@github.com>
 <3S9pyv9jOnJihfgqtK_CXhDDV62pzek2TrduKffVTnI=.4e8d8016-a299-4596-92f4-1bcf6bd206f4@github.com>
Message-ID: <q5kj9HuS9Z3kwwvqqgfUBu10pYPuUK7JVhHingVcUw4=.32cf7474-73be-4537-af92-ad528ef4e8d5@github.com>

On Tue, 12 Mar 2024 15:24:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Please re-test.

Hi Magnus, thanks for the adjustments.  I reenabled your patch in our build/test queue .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1992009593

From naoto at openjdk.org  Tue Mar 12 16:31:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Mar 2024 16:31:21 GMT
Subject: RFR: 8327259: Document supported CLDR versions in the javadoc
Message-ID: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>

Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/18243/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18243&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327259
  Stats: 48 lines in 1 file changed: 46 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18243/head:pull/18243

PR: https://git.openjdk.org/jdk/pull/18243

From darcy at openjdk.org  Tue Mar 12 16:48:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Mar 2024 16:48:19 GMT
Subject: Integrated: JDK-8327487: Further augment WorstCaseTests with more
 cases
In-Reply-To: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
References: <bEbW_E7_V3SrxaYsFav3tQ0yFgYTSiO-yLFOPaDQF8M=.98cb1bd1-99c3-4658-be75-a1201d837909@github.com>
Message-ID: <ynpc0OdeXee8pPE2RFohBruuva8rODIUlVP1Q7Lpz2A=.7fd3ada0-fea1-4f25-839b-d30a4089999f@github.com>

On Wed, 6 Mar 2024 17:54:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The atan2 and hypot cases added would fail for a particular test library that has errors in the millions of ulps for those inputs, rather than the small number of ulps specified for the error.

This pull request has now been integrated.

Changeset: 201042fd
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/201042fd96c73b9026c063122d5580fc4ed9c22c
Stats:     54 lines in 1 file changed: 54 ins; 0 del; 0 mod

8327487: Further augment WorstCaseTests with more cases

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/18140

From eirbjo at openjdk.org  Tue Mar 12 17:40:18 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 12 Mar 2024 17:40:18 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
Message-ID: <mM9LLxHzydMXaeJ3ulyrDg8w_klXGqOAJ8Q3eFk6Xrc=.cfac5403-2f36-4082-b0e2-d4bc49f60c37@github.com>

On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace calls to Unsafe.putObject with Unsafe.putReference
>  - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

Thanks for helping out with this cleanup effort, Jaikiran, Alan, Mandy, Doug and Martin!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1992202476

From eirbjo at openjdk.org  Tue Mar 12 17:40:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 12 Mar 2024 17:40:19 GMT
Subject: Integrated: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe
In-Reply-To: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
Message-ID: <pHXoWOb6lVroq94zjgVv7YoNkPKdjGtjRHTYhVVE6Zk=.11fc8351-62c9-43fa-92bd-1e1ee4f5961b@github.com>

On Sun, 10 Mar 2024 05:50:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
> 
> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
> 
> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
> 
> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
> 
> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.

This pull request has now been integrated.

Changeset: 5b414662
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b4146627580834bcd3ad0962d07d0d374fe3cce
Stats:     94 lines in 4 files changed: 0 ins; 87 del; 7 mod

8327729: Remove deprecated xxxObject methods from jdk.internal.misc.Unsafe

Reviewed-by: martin, alanb, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/18176

From duke at openjdk.org  Tue Mar 12 17:58:13 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 12 Mar 2024 17:58:13 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v2]
In-Reply-To: <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
Message-ID: <MD5Q7g4bIJ3Wg0EhiVtEDkHFCOepEsNQAPxwpqG4kB8=.9d1a0c64-5eb9-45ca-bc6f-5070ae1cc9a6@github.com>

On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code cleanup

Thanks for all this feedback! I am going to try and see if we can pass the full version string.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18204#issuecomment-1992241562

From bchristi at openjdk.org  Tue Mar 12 18:00:46 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 12 Mar 2024 18:00:46 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v12]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <_o5GgvZXzYz8DPC_I1gbaQcTZiKU87fE4lXp7aQhTBo=.a9192ce2-3eee-4729-b5e6-a97413b8c602@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:

  update definition of strongly reachable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/855b13a8..603ff4dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=10-11

  Stats: 4 lines in 1 file changed: 0 ins; 1 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 joehw at openjdk.org  Tue Mar 12 18:16:13 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 12 Mar 2024 18:16:13 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc
In-Reply-To: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
Message-ID: <nyshvUW1hLf_y1pQkTB_fFpqQl_cF4hDSc5_fHxs8c4=.000927e6-1008-4428-9321-325e32da4be7@github.com>

On Tue, 12 Mar 2024 16:26:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.

Irrelevant to this doc change, I happen to notice some of the jdk`<version>`-suported-locales docs might have not been updated. For example, https://www.oracle.com/java/technologies/javase/jdk20-suported-locales.html had "CLDR release 39" rather than 42 as stated here. Similarly jdk19-suported-locales.html -> 39 instead of 41, 18 was correctly -> 39, but 17 -> 35.1, and so on.

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 148:

> 146:  * "SPI" in order for the Java runtime to load them from the classpath.
> 147:  *
> 148:  * @implNote The JDK uses locale data from the Unicode Common Locale Data Repository

The full name may be moved to where the acronym was first used, e.g. "CLDR": the Unicode Common Locale Data Repository (CLDR) is a provider based on Unicode Consortium's <a href="http://cldr.unicode.org/">CLDR Project</a>. If you decide to do that, then we may use it here to state: The JDK uses CLDR to implement locale-sensitive APIs in the java.util and java.text packages.

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 154:

> 152:  * version of CLDR used in each JDK release.
> 153:  * <table class="striped">
> 154:  * <caption style="display:none">Shows JDK releases and supported CLDR versions</caption>

nit: the word "Shows" can be omitted.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18243#pullrequestreview-1931862314
PR Review Comment: https://git.openjdk.org/jdk/pull/18243#discussion_r1521907892
PR Review Comment: https://git.openjdk.org/jdk/pull/18243#discussion_r1521896890

From erikj at openjdk.org  Tue Mar 12 18:45:15 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Mar 2024 18:45:15 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v2]
In-Reply-To: <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
Message-ID: <nPD-ug1GuZXLfqwup4PDRXIhGOp4Z19X12svQ-eeg2E=.b7f0313e-3724-44d7-9959-761c29070e0b@github.com>

On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code cleanup

I'm fine with just using VERSION_FEATURE. I think it's a simple and straightforward enough simplification/approximation. If we think we need a more exact version comparison, then I think we should use one of the version strings instead of arbitrarily picking a set of version variables.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18204#issuecomment-1992318595

From naoto at openjdk.org  Tue Mar 12 18:50:38 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Mar 2024 18:50:38 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v2]
In-Reply-To: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
Message-ID: <RavPA9J9NkthFKuGNP39-qjqFGjh1wfoCi-LWbTWGvk=.025375c2-d118-4ffc-a28f-8c228a7bb8a0@github.com>

> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18243/files
  - new: https://git.openjdk.org/jdk/pull/18243/files/913f4f05..98b40f95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18243&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18243&range=00-01

  Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18243/head:pull/18243

PR: https://git.openjdk.org/jdk/pull/18243

From naoto at openjdk.org  Tue Mar 12 18:50:38 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Mar 2024 18:50:38 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v2]
In-Reply-To: <nyshvUW1hLf_y1pQkTB_fFpqQl_cF4hDSc5_fHxs8c4=.000927e6-1008-4428-9321-325e32da4be7@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
 <nyshvUW1hLf_y1pQkTB_fFpqQl_cF4hDSc5_fHxs8c4=.000927e6-1008-4428-9321-325e32da4be7@github.com>
Message-ID: <90p4iS_uItm1s7LANUFUFcS3aQCFzc2GEy326fWe99Y=.35b6ea8c-01e6-428c-853f-0e2b4c765338@github.com>

On Tue, 12 Mar 2024 18:13:28 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Irrelevant to this doc change, I happen to notice some of the jdk`<version>`-suported-locales docs might have not been updated. For example, https://www.oracle.com/java/technologies/javase/jdk20-suported-locales.html had "CLDR release 39" rather than 42 as stated here. Similarly jdk19-suported-locales.html -> 39 instead of 41, 18 was correctly -> 39, but 17 -> 35.1, and so on.

Thanks for pointing it out. Will let the doc people know. It is at least good that the latest doc for JDK21 is correct.

> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 148:
> 
>> 146:  * "SPI" in order for the Java runtime to load them from the classpath.
>> 147:  *
>> 148:  * @implNote The JDK uses locale data from the Unicode Common Locale Data Repository
> 
> The full name may be moved to where the acronym was first used, e.g. "CLDR": the Unicode Common Locale Data Repository (CLDR) is a provider based on Unicode Consortium's <a href="http://cldr.unicode.org/">CLDR Project</a>. If you decide to do that, then we may use it here to state: The JDK uses CLDR to implement locale-sensitive APIs in the java.util and java.text packages.

Used the full name in both places, as they are the locations that refer to the Unicode's locale data. Other "CLDR" represents the JDK's CLDR locale data provider.

> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 154:
> 
>> 152:  * version of CLDR used in each JDK release.
>> 153:  * <table class="striped">
>> 154:  * <caption style="display:none">Shows JDK releases and supported CLDR versions</caption>
> 
> nit: the word "Shows" can be omitted.

Good point. Removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18243#issuecomment-1992325490
PR Review Comment: https://git.openjdk.org/jdk/pull/18243#discussion_r1521969545
PR Review Comment: https://git.openjdk.org/jdk/pull/18243#discussion_r1521969490

From duke at openjdk.org  Tue Mar 12 19:09:27 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 12 Mar 2024 19:09:27 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v11]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <dVxVlB0vM4iO1yTfNKSbBDEup1ZzMUp5EHoH7VYuI6A=.1fa3ea15-f7d6-45b7-b5bc-2f819c20bb0d@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 incrementally with one additional commit since the last revision:

  one CharArraySequence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/e118b939..fcf4c818

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=09-10

  Stats: 24 lines in 1 file changed: 0 ins; 21 del; 3 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 mullan at openjdk.org  Tue Mar 12 19:10:16 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Mar 2024 19:10:16 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
Message-ID: <leVNLEnlMOT_Q12vSYN1zBocFXWkf2eoJQrj_GYXqTs=.74126c7c-6afb-483b-98e2-f8666849c3da@github.com>

On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MBeanServerFileAccessController.java

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 55:

> 53:         Subject.callAs(subject, () -> check(0, Subject.current(), "Duke"));
> 54: 
> 55:         // Observable in the same thread in ACC mode, but not in the SV mode

Should this comment actually say "Observable in a new platform thread in ACC mode, but not in the SV mode".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1521991975

From duke at openjdk.org  Tue Mar 12 19:22:25 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 12 Mar 2024 19:22:25 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v3]
In-Reply-To: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
Message-ID: <mPfMiC0ZQU19gYMUUo7paCKy7C0USeuxIwIYZZ0Ecbg=.8ca235b2-0c3b-473d-80dd-61fd7746545e@github.com>

> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
> 
> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.

Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:

 - Print to stdout instead of stderr
 - Compare version using VERSION_STRING

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18204/files
  - new: https://git.openjdk.org/jdk/pull/18204/files/7bbcc08f..62529391

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18204&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18204&range=01-02

  Stats: 71 lines in 5 files changed: 12 ins; 41 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/18204.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18204/head:pull/18204

PR: https://git.openjdk.org/jdk/pull/18204

From iris at openjdk.org  Tue Mar 12 19:47:12 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 12 Mar 2024 19:47:12 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v2]
In-Reply-To: <RavPA9J9NkthFKuGNP39-qjqFGjh1wfoCi-LWbTWGvk=.025375c2-d118-4ffc-a28f-8c228a7bb8a0@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
 <RavPA9J9NkthFKuGNP39-qjqFGjh1wfoCi-LWbTWGvk=.025375c2-d118-4ffc-a28f-8c228a7bb8a0@github.com>
Message-ID: <VsubLJ_UDjr9h4N2qcRn7jLiytHI1eGfFfy2UopHzjk=.2772731c-8c46-44b8-979f-76327b6d078c@github.com>

On Tue, 12 Mar 2024 18:50:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18243#pullrequestreview-1932235667

From jlu at openjdk.org  Tue Mar 12 20:08:13 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Mar 2024 20:08:13 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v2]
In-Reply-To: <RavPA9J9NkthFKuGNP39-qjqFGjh1wfoCi-LWbTWGvk=.025375c2-d118-4ffc-a28f-8c228a7bb8a0@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
 <RavPA9J9NkthFKuGNP39-qjqFGjh1wfoCi-LWbTWGvk=.025375c2-d118-4ffc-a28f-8c228a7bb8a0@github.com>
Message-ID: <gaE2NoYdWjYG3qBseUtu5vwmQK4N9_ULINuJ794mCRk=.53de0699-a96a-426d-8246-da04ff35ee30@github.com>

On Tue, 12 Mar 2024 18:50:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

LGTM

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 144:

> 142:  * <p>
> 143:  * The default value for looking up the preferred locale data providers is "CLDR",
> 144:  * so specifying "CLDR" is identical to the default behavior. Applications which

Separate to this issue but, rewording as `so specifying only "CLDR"` may improve clarity here.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18243#pullrequestreview-1932224881
PR Review Comment: https://git.openjdk.org/jdk/pull/18243#discussion_r1522025588

From jlu at openjdk.org  Tue Mar 12 21:13:16 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Mar 2024 21:13:16 GMT
Subject: Integrated: JDK-8327631: Update IANA Language Subtag Registry to
 Version 2024-03-07
In-Reply-To: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
References: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
Message-ID: <BsNZ4j_kpOR2XNMpELOxrjOR1SzqNnypgzNEEF8YYBM=.b41379b7-6a7e-4d10-8de5-49c0898ae85f@github.com>

On Thu, 7 Mar 2024 23:31:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-03-07. Tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/000090.html

This pull request has now been integrated.

Changeset: d5b95a0e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5b95a0ed38b10ed9f51d20255e06eb38fdd8b82
Stats:     80 lines in 2 files changed: 77 ins; 0 del; 3 mod

8327631: Update IANA Language Subtag Registry to Version 2024-03-07

Reviewed-by: naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/18159

From duke at openjdk.org  Tue Mar 12 21:58:23 2024
From: duke at openjdk.org (Elif Aslan)
Date: Tue, 12 Mar 2024 21:58:23 GMT
Subject: RFR: 8327998: Enable
 java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac
Message-ID: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>

This change enables to run JspawnhelperProtocol.java on MacOS.

In addition to GHA , the test has been run on macos and linux.


Test report is stored in build/macosx-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
                                                         1     1     0     0
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'macosx-x86_64-server-fastdebug'





Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
                                                         1     1     0     0
==============================
TEST SUCCESS

Stopping javac server
[ec2-user at ip-172-16-0-10 jdk]$ make test CONF=linux-x86_64-server-fastdebug TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java

-------------

Commit messages:
 - Enable java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac

Changes: https://git.openjdk.org/jdk/pull/18253/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18253&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327998
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18253/head:pull/18253

PR: https://git.openjdk.org/jdk/pull/18253

From joehw at openjdk.org  Tue Mar 12 22:12:14 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 12 Mar 2024 22:12:14 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v2]
In-Reply-To: <RavPA9J9NkthFKuGNP39-qjqFGjh1wfoCi-LWbTWGvk=.025375c2-d118-4ffc-a28f-8c228a7bb8a0@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
 <RavPA9J9NkthFKuGNP39-qjqFGjh1wfoCi-LWbTWGvk=.025375c2-d118-4ffc-a28f-8c228a7bb8a0@github.com>
Message-ID: <_K7-DHn7kd3T9gYuOANOFguI4VsoVzA_zzzwuCRIjAk=.2e8acc1f-408d-4fdf-ad0e-d62e4a078092@github.com>

On Tue, 12 Mar 2024 18:50:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18243#pullrequestreview-1932804695

From liach at openjdk.org  Tue Mar 12 22:43:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Mar 2024 22:43:16 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections
In-Reply-To: <sMItJ-gYuIR9cHM5VvGvtXnAFn3dCMFEw2B3EQhiaG8=.a3f7ca24-61c7-400a-ae15-b4bcb9d92bbd@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <sMItJ-gYuIR9cHM5VvGvtXnAFn3dCMFEw2B3EQhiaG8=.a3f7ca24-61c7-400a-ae15-b4bcb9d92bbd@github.com>
Message-ID: <CujVkHn7ZTbUrSltGNgF0fc9_LUPEEbb59XPKNLP9yE=.013ec2eb-7eb5-4699-995c-f33cd44e2518@github.com>

On Tue, 12 Mar 2024 10:12:18 GMT, Viktor Klang <vklang 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.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 926:
> 
>> 924:             if (!REVERSE && e1 != EMPTY) {
>> 925:                 action.accept((E) e1);
>> 926:             }
> 
> I'm curious to know how the following alternative would fare:
> 
> Suggestion:
> 
>             if (e1 != EMPTY) {
>                 action.accept(REVERSE ? (E)e1 : (E)e0); // implicit null check
>                 action.accept(REVERSE ? (E)e0 : (E)e1);
>             } else {
>                 action.accept(e0); // Implicit null check
>             }

I used this:

            if (e1 == EMPTY) {
                action.accept(e0); // Implicit null check
            } else {
                action.accept(REVERSE ? (E)e1 : e0); // implicit null check
                action.accept(REVERSE ? e0 : (E)e1);
            }


The results are about the same as the current patch.
With the alternative:

Benchmark                        Mode  Cnt    Score    Error   Units
ImmutableColls.forEachOverList  thrpt   15  367.651 ? 10.730  ops/us
ImmutableColls.forEachOverSet   thrpt   15   84.397 ? 12.235  ops/us
ImmutableColls.getOrDefault     thrpt   15  243.874 ?  1.891  ops/us
ImmutableColls.iterateOverList  thrpt   15  149.525 ?  3.652  ops/us
ImmutableColls.iterateOverSet   thrpt   15   60.202 ?  5.053  ops/us

Current patch:

Benchmark                        Mode  Cnt    Score   Error   Units
ImmutableColls.forEachOverList  thrpt   15  364.515 ? 8.076  ops/us
ImmutableColls.forEachOverSet   thrpt   15   86.012 ? 2.420  ops/us
ImmutableColls.getOrDefault     thrpt   15  243.723 ? 1.071  ops/us
ImmutableColls.iterateOverList  thrpt   15  149.392 ? 5.328  ops/us
ImmutableColls.iterateOverSet   thrpt   15   63.579 ? 4.671  ops/us

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1522201572

From ihse at openjdk.org  Tue Mar 12 23:47:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 23:47:13 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v3]
In-Reply-To: <mPfMiC0ZQU19gYMUUo7paCKy7C0USeuxIwIYZZ0Ecbg=.8ca235b2-0c3b-473d-80dd-61fd7746545e@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <mPfMiC0ZQU19gYMUUo7paCKy7C0USeuxIwIYZZ0Ecbg=.8ca235b2-0c3b-473d-80dd-61fd7746545e@github.com>
Message-ID: <mvFrMEb-2HTyT3CLDX9omqxdqRxTsqta_fnGIPvyY08=.c9c94331-7474-4aa7-8544-c0edc8cb8773@github.com>

On Tue, 12 Mar 2024 19:22:25 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Print to stdout instead of stderr
>  - Compare version using VERSION_STRING

make/modules/java.base/Launcher.gmk line 81:

> 79:       SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \
> 80:       OPTIMIZATION := LOW, \
> 81:       CFLAGS := $(CFLAGS_JDKEXE) \

There is no need to introduce a break after `$(CFLAGS_JDKEXE)`, for thing like flags we try to fill the line.
Also, the indentation rules are that a broken line should be indented with four spaces. See e.g. the CFLAGS line below in CoreLibraries.gmk.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18204#discussion_r1522267500

From redestad at openjdk.org  Wed Mar 13 00:05:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 13 Mar 2024 00:05:15 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v11]
In-Reply-To: <dVxVlB0vM4iO1yTfNKSbBDEup1ZzMUp5EHoH7VYuI6A=.1fa3ea15-f7d6-45b7-b5bc-2f819c20bb0d@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <dVxVlB0vM4iO1yTfNKSbBDEup1ZzMUp5EHoH7VYuI6A=.1fa3ea15-f7d6-45b7-b5bc-2f819c20bb0d@github.com>
Message-ID: <U56DXoXmnwA_Zelfz7GGZDDLLMdFI1NaavStSS65VLs=.0ed73481-43f7-4f45-aa8d-dd8f667d3715@github.com>

On Tue, 12 Mar 2024 19:09:27 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 incrementally with one additional commit since the last revision:
> 
>   one CharArraySequence

test/micro/org/openjdk/bench/java/math/BigDecimals.java line 103:

> 101:             stringInputs[i] = "" + value;
> 102:             stringHugeInputs[i] = "" + -(i + 1) * 5434543453454355e100;
> 103:             stringLargeInputs[i] = "" + -(i + 1) * 5434543453454355e100;

These two are the same?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1522286067

From naoto at openjdk.org  Wed Mar 13 00:27:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Mar 2024 00:27:17 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v2]
In-Reply-To: <gaE2NoYdWjYG3qBseUtu5vwmQK4N9_ULINuJ794mCRk=.53de0699-a96a-426d-8246-da04ff35ee30@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
 <RavPA9J9NkthFKuGNP39-qjqFGjh1wfoCi-LWbTWGvk=.025375c2-d118-4ffc-a28f-8c228a7bb8a0@github.com>
 <gaE2NoYdWjYG3qBseUtu5vwmQK4N9_ULINuJ794mCRk=.53de0699-a96a-426d-8246-da04ff35ee30@github.com>
Message-ID: <AhrlMiIpkNLwz5pXYk9eRNg1x-YFTaaNYpdTSLA6X-0=.890d01a5-d048-4153-9f00-33e5b182a596@github.com>

On Tue, 12 Mar 2024 19:41:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 144:
> 
>> 142:  * <p>
>> 143:  * The default value for looking up the preferred locale data providers is "CLDR",
>> 144:  * so specifying "CLDR" is identical to the default behavior. Applications which
> 
> Separate to this issue but, rewording as `so specifying only "CLDR"` may improve clarity here.

Thanks. Modified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18243#discussion_r1522302684

From amenkov at openjdk.org  Wed Mar 13 01:02:50 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 13 Mar 2024 01:02:50 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> Also annotations can be changed (added/removed) by class redefinition.
> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  removed attributes_count from RecordComponent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18161/files
  - new: https://git.openjdk.org/jdk/pull/18161/files/1ad6997d..f82e432a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18161&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18161&range=01-02

  Stats: 24 lines in 4 files changed: 3 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18161/head:pull/18161

PR: https://git.openjdk.org/jdk/pull/18161

From naoto at openjdk.org  Wed Mar 13 01:55:37 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Mar 2024 01:55:37 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v3]
In-Reply-To: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
Message-ID: <N_KrcfjJBXOnt0AKSDqK1VuHS4fLT9zT0DekJ_xLIFE=.5499d957-5b59-4393-ab33-219057770c5c@github.com>

> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressing further comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18243/files
  - new: https://git.openjdk.org/jdk/pull/18243/files/98b40f95..21e425ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18243&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18243&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18243/head:pull/18243

PR: https://git.openjdk.org/jdk/pull/18243

From liach at openjdk.org  Wed Mar 13 02:19:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Mar 2024 02:19:14 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 [v5]
In-Reply-To: <9K0A2Ct4hxHAPfUr0Sc8O_sPScSYcmGDvoz13UlD_Vg=.bf01d19a-911c-4682-ba8c-1fa6b2ef695d@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <PMGB_1SaVU5cKKosvDzvgVpjIJPyhoKs-S6bzhOyjqA=.18a84e58-6e4d-46ff-bea2-8b79fa080280@github.com>
 <9K0A2Ct4hxHAPfUr0Sc8O_sPScSYcmGDvoz13UlD_Vg=.bf01d19a-911c-4682-ba8c-1fa6b2ef695d@github.com>
Message-ID: <RDVw8QG5uLDVqCz4bVn-rij7bnHG8lAd2hgp6xdA1Bg=.b52ac814-6eb4-4035-8387-3c27984c1b36@github.com>

On Tue, 12 Dec 2023 03:58:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removing comment
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 343:
> 
>> 341:                 final Type[] out = new Type[nonGenericParamTypes.length];
>> 342:                 final Parameter[] params = getParameters();
>> 343:                 int fromidx = genericParamTypes.length - 1;
> 
> so provided that the parameters order is: synthetic parameters first, then mandated, if any, and finally explicit parameters. I think that it is safe to get as many parameters as possible from the genericParamTypes array, starting from the last element of the array, and if this array is shorter than the nonGenericParamTypes array, then the difference must be due to the presence of synthetic parameters, and we take the type of those from the nonGenericParamTypes array

Do synthetic parameters really come before mandated ones? Seems not the case for anonymous classes in instance methods that capture local variables from its enclosing method, those captured local variables are passed as synthetic parameters in the end of the pareamter list while the mandated enclosing instance is the first parameter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1522388372

From sspitsyn at openjdk.org  Wed Mar 13 04:06:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 04:06:12 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
Message-ID: <6rZ8jD99Sio4nAMAoRH7DJRjibsYam_DBJcv3xSQ1Es=.5a172281-1a61-472f-b583-d16dadf06d7a@github.com>

On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
>> Also annotations can be changed (added/removed) by class redefinition.
>> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
>> 
>> Testing: 
>> - tier1,tier2,hs-tier5-svc;
>>  - redefineClasses/retransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed attributes_count from RecordComponent

Could you, please, update the CR with your analysis and conclusion about a root cause?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18161#issuecomment-1993402337

From sspitsyn at openjdk.org  Wed Mar 13 04:41:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 04:41:13 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
Message-ID: <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>

On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
>> Also annotations can be changed (added/removed) by class redefinition.
>> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
>> 
>> Testing: 
>> - tier1,tier2,hs-tier5-svc;
>>  - redefineClasses/retransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed attributes_count from RecordComponent

This looks good in general.
I've posted a couple of minor requests.
Aside of the fix itself...
It is interesting that if an invisible attribute of a `RecordComponent` was not ignored because the `PreserveAllAnnotations` is enabled then it the `JvmtiClassFileReconstituter` treats it as a visible attribute. Not sure, if we should treat it as a bug.

Marked as reviewed by sspitsyn (Reviewer).

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 516:

> 514:                         + component->annotations() != nullptr ? 1 : 0
> 515:                         + component->type_annotations() != nullptr ? 1 : 0;
> 516:     write_u2(attributes_count);

Nit: I would suggest to define this function in the `RecordComponent` class:
  u2 attributes_count() const {
     u2 attributes_count =  generic_signature_index() != 0 ? 1 : 0
                                      + annotations() != nullptr ? 1 : 0
                                      + type_annotations() != nullptr ? 1 : 0;
     return attributes_count;
  }

test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 96:

> 94:         {
> 95:             log("Test: retransform to null");
> 96:             retransform(null);

Q: Could you add a comment why it is needed?

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18161#pullrequestreview-1933129468
PR Review: https://git.openjdk.org/jdk/pull/18161#pullrequestreview-1933147886
PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1522481272
PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1522494266

From dholmes at openjdk.org  Wed Mar 13 07:28:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 13 Mar 2024 07:28:17 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <NPNGO0vJDEQgfQ5kydJCOKSwSIrbHausWtqj1fIUy18=.a8659776-e94d-4231-927c-1abf0677b077@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <qf1hQUA-XivudvebTcZWk3E1xkR5opV3pQy-qnNvbqo=.254083ec-ab5e-42d8-8cf2-9a5690cda466@github.com>
 <NPNGO0vJDEQgfQ5kydJCOKSwSIrbHausWtqj1fIUy18=.a8659776-e94d-4231-927c-1abf0677b077@github.com>
Message-ID: <RHQle2EpproXwXQQ3kzKVeNiiV07Q-Bm-eoNyn-8j_s=.2f054d4f-de39-42f1-8fa1-bbcbaaf749a4@github.com>

On Tue, 12 Mar 2024 13:55:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 24:
>> 
>>> 22:  */
>>> 23: 
>>> 24: #include <stdio.h>
>> 
>> Seems unneeded.
>
> So what I did here was change:
> 
> #include "jni.h"
> #include <stdio.h>
> 
> 
> into 
> 
> #include <stdio.h>
> 
> #include "export.h"
> #include "jni.h"
> 
> 
> The reordering was strictly not needed, but putting user includes in front of system ones looked like bad coding to me, and put me in a difficult spot in where to add the new `#include "export.h"` -- next to the current user include even if I thought that was wrong, or have the system includes "sandwitched" between two user includes.
> 
> Or do you mean that it seems unneeded to include `jni.h` at all? Yes, I agree, but it was there before, and I don't want to make any other changes to the tests. This change is scary enough as it is :-). If you want, I can file a follow-up to remove this include instead.

Yes I meant the include is actually unnecessary, but fine to not make that change here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1522659393

From gli at openjdk.org  Wed Mar 13 07:48:12 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 13 Mar 2024 07:48:12 GMT
Subject: RFR: 8327998: Enable
 java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac
In-Reply-To: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>
References: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>
Message-ID: <XBW0HCxcbG0udQTVVsey_MZYdN6vrvYREz-wND2d7_M=.1c4e32a1-319d-4543-a67e-248e48ad4720@github.com>

On Tue, 12 Mar 2024 21:52:31 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change enables to run JspawnhelperProtocol.java on MacOS.
> 
> In addition to GHA , the test has been run on macos and linux.
> 
> 
> Test report is stored in build/macosx-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'macosx-x86_64-server-fastdebug'
> 
> 
> 
> 
> 
> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> Stopping javac server
> [ec2-user at ip-172-16-0-10 jdk]$ make test CONF=linux-x86_64-server-fastdebug TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java

LGTM.

> /approval request This change enables to run JspawnhelperProtocol.java on MacOS. In addition to GHA , the test has been run on macos and linux.

The `approval` command can only be used at a backport PR. Just a reminder.

-------------

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18253#pullrequestreview-1933358504
PR Comment: https://git.openjdk.org/jdk/pull/18253#issuecomment-1993744969

From clanger at openjdk.org  Wed Mar 13 07:58:20 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 07:58:20 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has unnecessary
 high heap requirement after JDK-8326718
Message-ID: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>

4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.

In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.

I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

-------------

Commit messages:
 - JDK-8328037

Changes: https://git.openjdk.org/jdk/pull/18264/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18264&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328037
  Stats: 473 lines in 1 file changed: 168 ins; 95 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/18264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18264/head:pull/18264

PR: https://git.openjdk.org/jdk/pull/18264

From ihse at openjdk.org  Wed Mar 13 08:12:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 08:12:19 GMT
Subject: Integrated: 8327460: Compile tests with the same visibility rules as
 product code
In-Reply-To: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
Message-ID: <LTCoRGSsPh0q-7waOa5cPfIaPaGjw0C29kVx8Xallo8=.d5acc553-cdcf-41f0-b666-b0642fee7d3d@github.com>

On Wed, 6 Mar 2024 11:33:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.

This pull request has now been integrated.

Changeset: cc9a8aba
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc9a8aba67f4e240c8de2d1ae15d1b80bfa446a0
Stats:     304 lines in 39 files changed: 69 ins; 159 del; 76 mod

8327460: Compile tests with the same visibility rules as product code

Reviewed-by: erikj, jvernee, dholmes, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/18135

From mbaesken at openjdk.org  Wed Mar 13 08:30:16 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 13 Mar 2024 08:30:16 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v2]
In-Reply-To: <q5kj9HuS9Z3kwwvqqgfUBu10pYPuUK7JVhHingVcUw4=.32cf7474-73be-4537-af92-ad528ef4e8d5@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <YVdSIUybMmPFB4eNvHAxfmfEqOzrrt5l6AA9j44DlBM=.2bb3f97e-583c-4ee5-9a5a-c02454315b33@github.com>
 <guGW7d1XFNl7TE84CKTrkWngW5mNZ8dEhgiUaUphTcQ=.447ec868-160f-4f96-9dc3-16e955e1c8d7@github.com>
 <3S9pyv9jOnJihfgqtK_CXhDDV62pzek2TrduKffVTnI=.4e8d8016-a299-4596-92f4-1bcf6bd206f4@github.com>
 <q5kj9HuS9Z3kwwvqqgfUBu10pYPuUK7JVhHingVcUw4=.32cf7474-73be-4537-af92-ad528ef4e8d5@github.com>
Message-ID: <wHSV8PuqYJ8msJuXq_LLVbFQLiA13TAPbZTCv8vwm3A=.83fdba40-b69f-454f-b48f-7c590ef89813@github.com>

On Tue, 12 Mar 2024 16:02:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Please re-test.
> 
> Hi Magnus, thanks for the adjustments. I reenabled your patch in our build/test queue .

Builds and test results on AIX (product and fastdebug) are fine with the latest version of the PR .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1993808324

From ihse at openjdk.org  Wed Mar 13 08:45:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 08:45:20 GMT
Subject: Integrated: 8327701: Remove the xlc toolchain
In-Reply-To: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
Message-ID: <fbB3ULOpMcJtTUs3SmpzWMzdzMZr1o59VOOXyR-nP04=.0c1a553c-7409-40ba-beaf-1af05a5cc97a@github.com>

On Fri, 8 Mar 2024 15:29:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.

This pull request has now been integrated.

Changeset: 107cb536
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/107cb536e75509ad63b245d20772eb2c3f73d595
Stats:     327 lines in 19 files changed: 24 ins; 266 del; 37 mod

8327701: Remove the xlc toolchain

Reviewed-by: jwaters, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/18172

From mbaesken at openjdk.org  Wed Mar 13 08:53:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 13 Mar 2024 08:53:23 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v4]
In-Reply-To: <Nd9G2lbssxwTvHQHeSHqaRqJ7uQIq8rVO2HulAV5V1w=.0b12fe1c-b990-4025-b24b-9636a25e424d@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <Nd9G2lbssxwTvHQHeSHqaRqJ7uQIq8rVO2HulAV5V1w=.0b12fe1c-b990-4025-b24b-9636a25e424d@github.com>
Message-ID: <-uA04de5qrhwkzJkst47cUY1ZdLaHDPn3KIclLd4b84=.e15c4d6c-2f79-4ab0-a1a0-8cc0dee581c8@github.com>

On Tue, 12 Mar 2024 15:27:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace CC_VERSION_OUTPUT with CC_VERSION_STRING
>  - We need CC_VERSION_OUTPUT before we can check it

Seems  `HOTSPOT_TOOLCHAIN_TYPE=xlc ` and  `TARGET_COMPILER_xlc`  macros stay, is this intended ?
(not saying this is a wrong thing to do, but I believed first that all the xlc toolchain references are replaced by clang?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1993844670

From ihse at openjdk.org  Wed Mar 13 09:03:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 09:03:23 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v4]
In-Reply-To: <-uA04de5qrhwkzJkst47cUY1ZdLaHDPn3KIclLd4b84=.e15c4d6c-2f79-4ab0-a1a0-8cc0dee581c8@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <Nd9G2lbssxwTvHQHeSHqaRqJ7uQIq8rVO2HulAV5V1w=.0b12fe1c-b990-4025-b24b-9636a25e424d@github.com>
 <-uA04de5qrhwkzJkst47cUY1ZdLaHDPn3KIclLd4b84=.e15c4d6c-2f79-4ab0-a1a0-8cc0dee581c8@github.com>
Message-ID: <VKgCPLuZgM30TmVJBCoohzba_L66Xc_VPTox6SAwQnE=.1cca38c2-49a2-4e4b-a00f-5412e2195c98@github.com>

On Wed, 13 Mar 2024 08:50:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replace CC_VERSION_OUTPUT with CC_VERSION_STRING
>>  - We need CC_VERSION_OUTPUT before we can check it
>
> Seems  `HOTSPOT_TOOLCHAIN_TYPE=xlc ` and  `TARGET_COMPILER_xlc`  macros stay, is this intended ?
> (not saying this is a wrong thing to do, but I believed first that all the xlc toolchain references are replaced by clang?)

@MBaesken Yes, I discussed this in length above: https://github.com/openjdk/jdk/pull/18172#issuecomment-1985939418.

In short, changing that would mean changing behavior, and that is not something I want to do in a removal refactoring. Also, it is up to you guys to make it work correctly.

But I really believe you should address this. Let me know if you need help with the build aspects.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1993862922

From shade at openjdk.org  Wed Mar 13 09:23:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Mar 2024 09:23:12 GMT
Subject: RFR: 8327998: Enable
 java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac
In-Reply-To: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>
References: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>
Message-ID: <wD2vjzckOb7SCBD3Qe5y0OLHID0ADYdSufPqxCSM7yQ=.1a2cd86b-f10d-45d8-98c5-070b215ab7e4@github.com>

On Tue, 12 Mar 2024 21:52:31 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change enables to run JspawnhelperProtocol.java on MacOS.
> 
> In addition to GHA , the test has been run on macos and linux.
> 
> 
> Test report is stored in build/macosx-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'macosx-x86_64-server-fastdebug'
> 
> 
> 
> 
> 
> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> Stopping javac server
> [ec2-user at ip-172-16-0-10 jdk]$ make test CONF=linux-x86_64-server-fastdebug TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java

Looks fine, thanks!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18253#pullrequestreview-1933545908

From rgiulietti at openjdk.org  Wed Mar 13 09:45:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Mar 2024 09:45:13 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <dqf1lgTC6CTTs67zMD83XpoLFCxbsXKMdM_bS-vQn4A=.1c7dd6ba-88d6-49dd-b9a3-ee401f543973@github.com>

On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

What about factoring out the 4 invocations of `tenMillionBlanks()` in each source method in a local var?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1993965369

From shade at openjdk.org  Wed Mar 13 09:52:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Mar 2024 09:52:18 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v3]
In-Reply-To: <mvFrMEb-2HTyT3CLDX9omqxdqRxTsqta_fnGIPvyY08=.c9c94331-7474-4aa7-8544-c0edc8cb8773@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <mPfMiC0ZQU19gYMUUo7paCKy7C0USeuxIwIYZZ0Ecbg=.8ca235b2-0c3b-473d-80dd-61fd7746545e@github.com>
 <mvFrMEb-2HTyT3CLDX9omqxdqRxTsqta_fnGIPvyY08=.c9c94331-7474-4aa7-8544-c0edc8cb8773@github.com>
Message-ID: <2329967UQFCbsOwZMWEVP8k8ySboYp3lsZZbK7rlQkM=.35c8f292-5b4b-41a9-9c9a-a017177b42f5@github.com>

On Tue, 12 Mar 2024 23:44:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Print to stdout instead of stderr
>>  - Compare version using VERSION_STRING
>
> make/modules/java.base/Launcher.gmk line 81:
> 
>> 79:       SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \
>> 80:       OPTIMIZATION := LOW, \
>> 81:       CFLAGS := $(CFLAGS_JDKEXE) \
> 
> There is no need to introduce a break after `$(CFLAGS_JDKEXE)`, for thing like flags we try to fill the line.
> Also, the indentation rules are that a broken line should be indented with four spaces. See e.g. the CFLAGS line below in CoreLibraries.gmk.

My fault, I suggested Chad to do this. So what's the preferred formatting here? Like BUILD_JEXEC block above does it?


      CFLAGS := $(CFLAGS_JDKEXE) $(VERSION_CFLAGS) \
          -I$(TOPDIR)/src/$(MODULE)/unix/native/libjava, \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18204#discussion_r1522886607

From duke at openjdk.org  Wed Mar 13 09:52:45 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 13 Mar 2024 09:52:45 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v12]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <xJrQp4a9X7qrIk206tLNmwsW2oLhU5xJ8XwNFaJ8AnI=.1060af87-ef5c-4c60-83ed-0fe5c6a1737f@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 incrementally with one additional commit since the last revision:

  fix benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/fcf4c818..be2119c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=10-11

  Stats: 14 lines in 1 file changed: 8 ins; 5 del; 1 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 jkern at openjdk.org  Wed Mar 13 09:53:22 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 13 Mar 2024 09:53:22 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v4]
In-Reply-To: <Nd9G2lbssxwTvHQHeSHqaRqJ7uQIq8rVO2HulAV5V1w=.0b12fe1c-b990-4025-b24b-9636a25e424d@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <Nd9G2lbssxwTvHQHeSHqaRqJ7uQIq8rVO2HulAV5V1w=.0b12fe1c-b990-4025-b24b-9636a25e424d@github.com>
Message-ID: <SDYoOHLW6KZ8qYvZlfV9X3DXqdBWJ5O18f3e76Rh3rs=.a9316152-28fa-43e8-b1e2-9ea34cfa8d5e@github.com>

On Tue, 12 Mar 2024 15:27:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain is no longer supported, and should be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace CC_VERSION_OUTPUT with CC_VERSION_STRING
>  - We need CC_VERSION_OUTPUT before we can check it

e.g. We should change the HOTSPOT_TOOLCHAIN_TYPE=xlc to aix, because it is not toolchain, but OS related. As a consequence the globalDefinitions_xlc.hpp will become globalDefinitions_aix.hpp

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1993979991

From ihse at openjdk.org  Wed Mar 13 10:28:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 10:28:25 GMT
Subject: RFR: 8327701: Remove the xlc toolchain [v4]
In-Reply-To: <SDYoOHLW6KZ8qYvZlfV9X3DXqdBWJ5O18f3e76Rh3rs=.a9316152-28fa-43e8-b1e2-9ea34cfa8d5e@github.com>
References: <ZNtnRt4ufmZ5Sp8zURIQwBVraTUPmM30KwL-sC37JeQ=.7135ee42-e9b1-4410-afea-b5c7384ae76e@github.com>
 <Nd9G2lbssxwTvHQHeSHqaRqJ7uQIq8rVO2HulAV5V1w=.0b12fe1c-b990-4025-b24b-9636a25e424d@github.com>
 <SDYoOHLW6KZ8qYvZlfV9X3DXqdBWJ5O18f3e76Rh3rs=.a9316152-28fa-43e8-b1e2-9ea34cfa8d5e@github.com>
Message-ID: <dbRq-mRFnOzoYCVnYFJohoF1ocyiPuaoaIrbkWOaIhc=.63e21a26-5b63-4b5e-bf8b-1bd69bbf163c@github.com>

On Wed, 13 Mar 2024 09:50:20 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> e.g. We should change the HOTSPOT_TOOLCHAIN_TYPE=xlc to aix, because it is not toolchain, but OS related. As a consequence the globalDefinitions_xlc.hpp will become globalDefinitions_aix.hpp

No, it's not that simple. First, the `globalDefinitions_<compiler>` files are included on a per-toolchain basis, not OS basis. Secondly, I think you will want to have the stuff in globalDefinitions_gcc.h. In fact, if you compare globalDefinitions_gcc.h and globalDefinitions_xlc.h side-by-side, you see that they are much more similar than you'd perhaps naively expect. The remaining differences will probably be better expressed as #ifdef AIX inside globalDefinitions_gcc.h, I assume. (But of course, in the end this is up to the hotspot team.)

I recommend doing such a side-by-side check yourself to get an understanding of the actual differences.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1994049434

From shade at openjdk.org  Wed Mar 13 10:29:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Mar 2024 10:29:13 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v3]
In-Reply-To: <mPfMiC0ZQU19gYMUUo7paCKy7C0USeuxIwIYZZ0Ecbg=.8ca235b2-0c3b-473d-80dd-61fd7746545e@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <mPfMiC0ZQU19gYMUUo7paCKy7C0USeuxIwIYZZ0Ecbg=.8ca235b2-0c3b-473d-80dd-61fd7746545e@github.com>
Message-ID: <obyd7MS9bu651tGzJRz-sCGlw_vtqQPGCUbZxREh5j8=.17f8599b-cf03-4ba4-9fcd-a6107aaa9cc8@github.com>

On Tue, 12 Mar 2024 19:22:25 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Print to stdout instead of stderr
>  - Compare version using VERSION_STRING

I was thinking what would happen for the first time we upgrade jspawnhelper like this. There would be no helpful message then, the `jspawnhelper` would just exit on argument count check. So I suggest we polish the failure messages a bit: always report version at `shutItDown`, and report more verbose failure messages too.

See: [jspawnhelper-messages-1.patch](https://github.com/openjdk/jdk/files/14586196/jspawnhelper-messages-1.patch)

Older JDK invoking new jspawnhelper would then fail like:


% build/macosx-aarch64-server-fastdebug/images/jdk/lib/jspawnhelper 1:1:1
Incorrect number of arguments: 2
jspawnhelper version 23-internal-adhoc.shipilev.shipilev-jdk
This command is not for general use and should only be run as the result of a call to
ProcessBuilder.start() or Runtime.exec() in a java application

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18204#issuecomment-1994051562

From ihse at openjdk.org  Wed Mar 13 10:35:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 10:35:13 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v3]
In-Reply-To: <2329967UQFCbsOwZMWEVP8k8ySboYp3lsZZbK7rlQkM=.35c8f292-5b4b-41a9-9c9a-a017177b42f5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <mPfMiC0ZQU19gYMUUo7paCKy7C0USeuxIwIYZZ0Ecbg=.8ca235b2-0c3b-473d-80dd-61fd7746545e@github.com>
 <mvFrMEb-2HTyT3CLDX9omqxdqRxTsqta_fnGIPvyY08=.c9c94331-7474-4aa7-8544-c0edc8cb8773@github.com>
 <2329967UQFCbsOwZMWEVP8k8ySboYp3lsZZbK7rlQkM=.35c8f292-5b4b-41a9-9c9a-a017177b42f5@github.com>
Message-ID: <Oen6R8Cp3eZMJzYCu6AqPlR3dWHcNtEx19N4UDsr-ww=.6c6a7911-bc43-4415-8336-935d2aab7deb@github.com>

On Wed, 13 Mar 2024 09:49:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> make/modules/java.base/Launcher.gmk line 81:
>> 
>>> 79:       SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \
>>> 80:       OPTIMIZATION := LOW, \
>>> 81:       CFLAGS := $(CFLAGS_JDKEXE) \
>> 
>> There is no need to introduce a break after `$(CFLAGS_JDKEXE)`, for thing like flags we try to fill the line.
>> Also, the indentation rules are that a broken line should be indented with four spaces. See e.g. the CFLAGS line below in CoreLibraries.gmk.
>
> My fault, I suggested Chad to do this. So what's the preferred formatting here? Like BUILD_JEXEC block above does it?
> 
> 
>       CFLAGS := $(CFLAGS_JDKEXE) $(VERSION_CFLAGS) \
>           -I$(TOPDIR)/src/$(MODULE)/unix/native/libjava, \

Yeah, that looks good. I was thinking just appending it at the end like:


     CFLAGS := $(CFLAGS_JDKEXE) -I$(TOPDIR)/src/$(MODULE)/unix/native/libjava \
          $(VERSION_CFLAGS), \


but your version definitely looks better!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18204#discussion_r1522963660

From ihse at openjdk.org  Wed Mar 13 11:59:36 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 11:59:36 GMT
Subject: RFR: 8328074: Add jcheck whitespace checking for assembly files
 [v4]
In-Reply-To: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
References: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
Message-ID: <LDHFfoNVIbxCujeYMWs28J7pzyoZnhAYrDd7To_1Oug=.2c6d6327-4de4-42d6-9575-cd81c24b2fae@github.com>

> As part of the ongoing effort to enable jcheck whitespace checking to all text files, it is now time to address assembly (.S) files. The hotspot assembly files were fixed as part of the hotspot mapfile removal, so only a single incorrect jdk library remains.
> 
> The main issue with `libjsvml` was inconsistent line starts, sometimes using tabs. I used the `expand` unix command line tool to replace these with spaces.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Make all ALIGN/.align aligned

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18268/files
  - new: https://git.openjdk.org/jdk/pull/18268/files/ce1d4c9f..4e729cb6

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18268&range=02-03

  Stats: 625 lines in 71 files changed: 0 ins; 0 del; 625 mod
  Patch: https://git.openjdk.org/jdk/pull/18268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18268/head:pull/18268

PR: https://git.openjdk.org/jdk/pull/18268

From ihse at openjdk.org  Wed Mar 13 11:59:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 11:59:37 GMT
Subject: RFR: 8328074: Add jcheck whitespace checking for assembly files
 [v3]
In-Reply-To: <bMbQw719nkRIdfbRsEquJEEzFfdFE1nfF7s_l34gk8Q=.bd8d01ee-9a82-4d1f-bb54-6e7f84586c9c@github.com>
References: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
 <bMbQw719nkRIdfbRsEquJEEzFfdFE1nfF7s_l34gk8Q=.bd8d01ee-9a82-4d1f-bb54-6e7f84586c9c@github.com>
Message-ID: <5bt-hs8bN414RvmmDi4RlnwiGN8vQSEaFqUB4GvQPXc=.89b47196-a8eb-4ca3-bc21-cf71d845fd35@github.com>

On Wed, 13 Mar 2024 11:26:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Magnus Ihse Bursie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:
>> 
>>  - Enable jcheck whitespace checks for .S files
>>  - Run expand on libjsvml
>
> src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S line 37:
> 
>> 35:         .text
>> 36: # mark_begin;
>> 37:        .align    16,0x90
> 
> .align seems to ironically not be aligned with the rest of the directives

Bad indentation like this is not something jcheck can detect or will complain about. However, I agree that it looks horrible. What's more, this seem to be problematic in multiple locations -- many, but not all, instances of `.align` (and `ALIGN` on Windows) are unaligned. I guess it is due to copy/paste error.

I'm sort of reluctant to fix this in this PR, but then again, it just looks too bad.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18268#discussion_r1523085132

From ihse at openjdk.org  Wed Mar 13 11:59:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 11:59:37 GMT
Subject: RFR: 8328074: Add jcheck whitespace checking for assembly files
 [v3]
In-Reply-To: <Dn8S3VeysIDFXpRfTOJbwXiIRo-fEWbh9JfHYfVa_BQ=.f9bb7206-be76-4364-8a5a-d8bc2aee332c@github.com>
References: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
 <Dn8S3VeysIDFXpRfTOJbwXiIRo-fEWbh9JfHYfVa_BQ=.f9bb7206-be76-4364-8a5a-d8bc2aee332c@github.com>
Message-ID: <rV5-X1w8E50AuHn0FKBKA789bgjyF5BXWpZ43xnFbL4=.05fb4d4b-4373-4aeb-80e6-74698a978525@github.com>

On Wed, 13 Mar 2024 11:45:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the ongoing effort to enable jcheck whitespace checking to all text files, it is now time to address assembly (.S) files. The hotspot assembly files were fixed as part of the hotspot mapfile removal, so only a single incorrect jdk library remains.
>> 
>> The main issue with `libjsvml` was inconsistent line starts, sometimes using tabs. I used the `expand` unix command line tool to replace these with spaces.
>
> Magnus Ihse Bursie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:
> 
>  - Enable jcheck whitespace checks for .S files
>  - Run expand on libjsvml

I tagged this `core-libs` as that is what @sviswa7 did for changes to libjsvml in https://github.com/openjdk/jdk/pull/8508. I hope this is correct. (We should really add rules to Skara for this library.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18268#issuecomment-1994211386

From redestad at openjdk.org  Wed Mar 13 12:15:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 13 Mar 2024 12:15:17 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v12]
In-Reply-To: <xJrQp4a9X7qrIk206tLNmwsW2oLhU5xJ8XwNFaJ8AnI=.1060af87-ef5c-4c60-83ed-0fe5c6a1737f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <xJrQp4a9X7qrIk206tLNmwsW2oLhU5xJ8XwNFaJ8AnI=.1060af87-ef5c-4c60-83ed-0fe5c6a1737f@github.com>
Message-ID: <dgqVm4t827DE1kmTKOdWYjN2OW5XvNaPGrTyvM7gkRg=.ac646409-9627-486d-ad55-2ebc2ede5d35@github.com>

On Wed, 13 Mar 2024 09:52:45 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 incrementally with one additional commit since the last revision:
> 
>   fix benchmark

src/java.base/share/classes/java/math/BigDecimal.java line 596:

> 594:                 // First compact case, we need not to preserve the character
> 595:                 // and we can just compute the value in place.
> 596:                 for (; ; c = val.charAt(++offset)) {

This looks gnarly, and it's unclear if it's correct for invalid inputs like `""`, `"-"` and `"+"` since you're not testing for `len > 0` before going into the loop. Can you make sure there are tests covering such inputs and try to simplify this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1523115595

From jvernee at openjdk.org  Wed Mar 13 12:21:35 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Mar 2024 12:21:35 GMT
Subject: RFR: 8327994: Update code gen in CallGeneratorHelper
Message-ID: <zFBzrJ8FEI7yrwITdz5YCmwL2cm2W100I4enNOW-mwo=.ca09bbf3-0caa-46f4-8553-143630d39dd2@github.com>

Update the code gen code in CallGeneratorHelper to reflect the latest state of the libTest(Downcall/Upcall)(Stack).c and shared.h files.

- The previous code wanted users to pipe stdout into a file. But, since we have 5 files that need to be created, and the names of those files is important too, I've changed the script to write to those files directly instead.
- I moved the definition of `S_FFFF` to libVarArgs.c where it's used, as it's not actually generated by CallGeneratorHelper.
- GitHub doesn't render the changes to some of the files, but those files only contain either white space changes (some missing spaces after `,`), and copyright header updates.

-------------

Commit messages:
 - add more run instructions
 - simplify
 - use export.h
 - factor out some shared code
 - fix test file generation
 - remove dead code from CallGeneratorHelper

Changes: https://git.openjdk.org/jdk/pull/18269/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327994
  Stats: 36078 lines in 6 files changed: 62 ins; 40 del; 35976 mod
  Patch: https://git.openjdk.org/jdk/pull/18269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18269/head:pull/18269

PR: https://git.openjdk.org/jdk/pull/18269

From ihse at openjdk.org  Wed Mar 13 12:34:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 12:34:20 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <YnEDV8WKjbtBEb-Fb-ugaSZdcxKW_Na1__l8H8PQBLE=.8da56e70-ef00-4aa4-b629-b13b253b3fd2@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

I have opened https://bugs.openjdk.org/browse/JDK-8328079 to track the ccache regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1994283777

From duke at openjdk.org  Wed Mar 13 13:15:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 13 Mar 2024 13:15:18 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v12]
In-Reply-To: <dgqVm4t827DE1kmTKOdWYjN2OW5XvNaPGrTyvM7gkRg=.ac646409-9627-486d-ad55-2ebc2ede5d35@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <xJrQp4a9X7qrIk206tLNmwsW2oLhU5xJ8XwNFaJ8AnI=.1060af87-ef5c-4c60-83ed-0fe5c6a1737f@github.com>
 <dgqVm4t827DE1kmTKOdWYjN2OW5XvNaPGrTyvM7gkRg=.ac646409-9627-486d-ad55-2ebc2ede5d35@github.com>
Message-ID: <hMpXKlvKChnXBkd6ZjSN6169MmnFWYCH54gTCXbnhCg=.24e7fa04-0ecc-45a7-9223-bca284cf1d82@github.com>

On Wed, 13 Mar 2024 12:12:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix benchmark
>
> src/java.base/share/classes/java/math/BigDecimal.java line 596:
> 
>> 594:                 // First compact case, we need not to preserve the character
>> 595:                 // and we can just compute the value in place.
>> 596:                 for (; ; c = val.charAt(++offset)) {
> 
> This looks gnarly, and it's unclear if it's correct for invalid inputs like `""`, `"-"` and `"+"` since you're not testing for `len > 0` before going into the loop. Can you make sure there are tests covering such inputs and try to simplify this?

If the input is "+" or "-" an exception will be thrown on line 583

            boolean isneg = c == '-'; // leading minus means negative
            if (isneg || c == '+') {
                c = val.charAt(++offset); 
                len--;
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1523235244

From duke at openjdk.org  Wed Mar 13 13:15:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 13 Mar 2024 13:15:18 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v12]
In-Reply-To: <hMpXKlvKChnXBkd6ZjSN6169MmnFWYCH54gTCXbnhCg=.24e7fa04-0ecc-45a7-9223-bca284cf1d82@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <xJrQp4a9X7qrIk206tLNmwsW2oLhU5xJ8XwNFaJ8AnI=.1060af87-ef5c-4c60-83ed-0fe5c6a1737f@github.com>
 <dgqVm4t827DE1kmTKOdWYjN2OW5XvNaPGrTyvM7gkRg=.ac646409-9627-486d-ad55-2ebc2ede5d35@github.com>
 <hMpXKlvKChnXBkd6ZjSN6169MmnFWYCH54gTCXbnhCg=.24e7fa04-0ecc-45a7-9223-bca284cf1d82@github.com>
Message-ID: <NgEUBKEmMwysZvGY_KZskR-kuwR0avt0GezzrDQU2iA=.96590a6e-c22d-4ac6-9a48-94cfad2ad8a9@github.com>

On Wed, 13 Mar 2024 13:11:48 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 596:
>> 
>>> 594:                 // First compact case, we need not to preserve the character
>>> 595:                 // and we can just compute the value in place.
>>> 596:                 for (; ; c = val.charAt(++offset)) {
>> 
>> This looks gnarly, and it's unclear if it's correct for invalid inputs like `""`, `"-"` and `"+"` since you're not testing for `len > 0` before going into the loop. Can you make sure there are tests covering such inputs and try to simplify this?
>
> If the input is "+" or "-" an exception will be thrown on line 583
> 
>             boolean isneg = c == '-'; // leading minus means negative
>             if (isneg || c == '+') {
>                 c = val.charAt(++offset); 
>                 len--;
>             }

if the input is "" an exception will be throw on line 579

            int offset = 0;
            char c = val.charAt(offset);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1523237018

From rgiulietti at openjdk.org  Wed Mar 13 13:18:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Mar 2024 13:18:13 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <8i5zAp-P2q5zGVzu2j2sTitj_IEUC0QWMVxWiEniE3U=.25880fe6-5555-448d-b1b7-cae193352156@github.com>

On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

L.26-27 to

 * @bug 4906370 8299677 8326718 8328037
 * @summary Tests to exercise padding on int and double values,

test/jdk/java/util/Formatter/Padding.java line 43:

> 41: public class Padding {
> 42: 
> 43:     private static final String tenMillionZeros() {

Suggestion:

    private static String tenMillionZeros() {

test/jdk/java/util/Formatter/Padding.java line 46:

> 44:         return "0".repeat(10_000_000);
> 45:     }
> 46:     private static final String tenMillionBlanks() {

Suggestion:

    private static String tenMillionBlanks() {

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1994382507
PR Review Comment: https://git.openjdk.org/jdk/pull/18264#discussion_r1523241759
PR Review Comment: https://git.openjdk.org/jdk/pull/18264#discussion_r1523241920

From rriggs at openjdk.org  Wed Mar 13 13:44:14 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Mar 2024 13:44:14 GMT
Subject: RFR: 8327998: Enable
 java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac
In-Reply-To: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>
References: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>
Message-ID: <djsx4Bxo33mue-JPlmYa9iFv0ZHjvsQqiMHfH1ZF0zA=.11c707c8-d083-40f3-bc92-288bbc356476@github.com>

On Tue, 12 Mar 2024 21:52:31 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change enables to run JspawnhelperProtocol.java on MacOS.
> 
> In addition to GHA , the test has been run on macos and linux.
> 
> 
> Test report is stored in build/macosx-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'macosx-x86_64-server-fastdebug'
> 
> 
> 
> 
> 
> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> Stopping javac server
> [ec2-user at ip-172-16-0-10 jdk]$ make test CONF=linux-x86_64-server-fastdebug TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java

LGTM
Just a reminder to keep that the PR description is copied into every email sent so it should be concise.
Extended descriptions and additional details should be added in a separate comment.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18253#pullrequestreview-1934219262

From erikj at openjdk.org  Wed Mar 13 13:45:14 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Mar 2024 13:45:14 GMT
Subject: RFR: 8328074: Add jcheck whitespace checking for assembly files
 [v4]
In-Reply-To: <LDHFfoNVIbxCujeYMWs28J7pzyoZnhAYrDd7To_1Oug=.2c6d6327-4de4-42d6-9575-cd81c24b2fae@github.com>
References: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
 <LDHFfoNVIbxCujeYMWs28J7pzyoZnhAYrDd7To_1Oug=.2c6d6327-4de4-42d6-9575-cd81c24b2fae@github.com>
Message-ID: <b0adcq-PA6CBUbGEyJ5Fl5eubUnvusfKPJQJJJ-rCjU=.9fb408e0-ebc8-47eb-910a-616c8a9398e4@github.com>

On Wed, 13 Mar 2024 11:59:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the ongoing effort to enable jcheck whitespace checking to all text files, it is now time to address assembly (.S) files. The hotspot assembly files were fixed as part of the hotspot mapfile removal, so only a single incorrect jdk library remains.
>> 
>> The main issue with `libjsvml` was inconsistent line starts, sometimes using tabs. I used the `expand` unix command line tool to replace these with spaces.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make all ALIGN/.align aligned

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18268#pullrequestreview-1934219694

From redestad at openjdk.org  Wed Mar 13 13:54:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 13 Mar 2024 13:54:16 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v12]
In-Reply-To: <NgEUBKEmMwysZvGY_KZskR-kuwR0avt0GezzrDQU2iA=.96590a6e-c22d-4ac6-9a48-94cfad2ad8a9@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <xJrQp4a9X7qrIk206tLNmwsW2oLhU5xJ8XwNFaJ8AnI=.1060af87-ef5c-4c60-83ed-0fe5c6a1737f@github.com>
 <dgqVm4t827DE1kmTKOdWYjN2OW5XvNaPGrTyvM7gkRg=.ac646409-9627-486d-ad55-2ebc2ede5d35@github.com>
 <hMpXKlvKChnXBkd6ZjSN6169MmnFWYCH54gTCXbnhCg=.24e7fa04-0ecc-45a7-9223-bca284cf1d82@github.com>
 <NgEUBKEmMwysZvGY_KZskR-kuwR0avt0GezzrDQU2iA=.96590a6e-c22d-4ac6-9a48-94cfad2ad8a9@github.com>
Message-ID: <zp4MyiJc4Bmgqytk-MVOPswHbELYgKkPp60S62x6dtw=.06a713f2-7f6c-4edd-8254-e347700788e6@github.com>

On Wed, 13 Mar 2024 13:12:54 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> If the input is "+" or "-" an exception will be thrown on line 583
>> 
>>             boolean isneg = c == '-'; // leading minus means negative
>>             if (isneg || c == '+') {
>>                 c = val.charAt(++offset); 
>>                 len--;
>>             }
>
> if the input is "" an exception will be throw on line 579
> 
>             int offset = 0;
>             char c = val.charAt(offset);

Relying on the upper bounds check of `charAt` doesn't work well with the `CharArraySequence` whose `charAt` deliberately does not throw an IIOBE if the array is longer than the provided length, ie, it'll look at chars beyond the provided range. The examples I tested still end up as a NFE, but it's clear from the cause that we're running past the length:

jshell> new BigDecimal(new char[] { '-', '1', 'e'}, 0, 1);
|  Exception java.lang.NumberFormatException
|        at BigDecimal.<init> (BigDecimal.java:754)
|        at BigDecimal.<init> (BigDecimal.java:543)
|        at BigDecimal.<init> (BigDecimal.java:518)
|        at (#4:1)
|  Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3
|        at BigDecimal$CharArraySequence.charAt (BigDecimal.java:559)
|        at BigDecimal.parseExp (BigDecimal.java:772)
|        at BigDecimal.<init> (BigDecimal.java:619)
|        ...

Baseline/expected:

jshell> new BigDecimal(new char[] { '-', '1', 'e'}, 0, 1);
|  Exception java.lang.NumberFormatException: No digits found.
|        at BigDecimal.<init> (BigDecimal.java:635)
|        at BigDecimal.<init> (BigDecimal.java:518)
|        at (#1:1)

Having a check on `len > 0` is more robust - and I'd be surprised if avoiding a redundant check on the loop entry is affecting performance?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1523301252

From clanger at openjdk.org  Wed Mar 13 14:10:29 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 14:10:29 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718 [v2]
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Generate large strings in parameter generator methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18264/files
  - new: https://git.openjdk.org/jdk/pull/18264/files/8e3e9509..be84e5e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18264&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18264&range=00-01

  Stats: 53 lines in 1 file changed: 9 ins; 8 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/18264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18264/head:pull/18264

PR: https://git.openjdk.org/jdk/pull/18264

From clanger at openjdk.org  Wed Mar 13 14:13:12 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 14:13:12 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718
In-Reply-To: <dqf1lgTC6CTTs67zMD83XpoLFCxbsXKMdM_bS-vQn4A=.1c7dd6ba-88d6-49dd-b9a3-ee401f543973@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <dqf1lgTC6CTTs67zMD83XpoLFCxbsXKMdM_bS-vQn4A=.1c7dd6ba-88d6-49dd-b9a3-ee401f543973@github.com>
Message-ID: <_GU6KezLJckwYdT1YS6-5SldXcDwyDZDD9U1fCkQ6M0=.0edcd83b-1ada-4410-ad9b-58bdc11534dd@github.com>

On Wed, 13 Mar 2024 09:42:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> What about factoring out the 4 invocations of `tenMillionBlanks()` in each source method in a local var?

OK, I inlined the generation of the ten million character strings into the parameter generator methods. I looked a bit at the test runtime and it seems like it doesn't make a lot of difference in a test JVM with larger heap but for smaller test VMs it seems to improve things.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1994497012

From rgiulietti at openjdk.org  Wed Mar 13 14:25:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Mar 2024 14:25:13 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718 [v2]
In-Reply-To: <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>
Message-ID: <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>

On Wed, 13 Mar 2024 14:10:29 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
>> 
>> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
>> 
>> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Generate large strings in parameter generator methods

I was thinking more something like

        var tenMillionBlanks = tenMillionBlanks();

and similarly for `tenMillionsZeros`, thus maintaining the `private static` (but not `final` ;-) ) methods as in your previous commit.
But if you are happy with the last commit, it's OK as well.

Can you please add the bug id to `@bug` and correct the typo, as suggested [here](https://github.com/openjdk/jdk/pull/18264#issuecomment-1994382507)?

Otherwise looks fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1994522269

From duke at openjdk.org  Wed Mar 13 15:46:30 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 13 Mar 2024 15:46:30 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v13]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <CZk9R86q9YsITK3bHsX31RjXAcgZDu_EuA_1JOVH7IE=.a3249016-d15b-4d14-8756-55f63c1efabf@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 incrementally with one additional commit since the last revision:

  bug fix for CharArraySequence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/be2119c4..f3084ba5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=11-12

  Stats: 29 lines in 2 files changed: 28 ins; 0 del; 1 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 darcy at openjdk.org  Wed Mar 13 15:46:30 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 13 Mar 2024 15:46:30 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v12]
In-Reply-To: <zp4MyiJc4Bmgqytk-MVOPswHbELYgKkPp60S62x6dtw=.06a713f2-7f6c-4edd-8254-e347700788e6@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <xJrQp4a9X7qrIk206tLNmwsW2oLhU5xJ8XwNFaJ8AnI=.1060af87-ef5c-4c60-83ed-0fe5c6a1737f@github.com>
 <dgqVm4t827DE1kmTKOdWYjN2OW5XvNaPGrTyvM7gkRg=.ac646409-9627-486d-ad55-2ebc2ede5d35@github.com>
 <hMpXKlvKChnXBkd6ZjSN6169MmnFWYCH54gTCXbnhCg=.24e7fa04-0ecc-45a7-9223-bca284cf1d82@github.com>
 <NgEUBKEmMwysZvGY_KZskR-kuwR0avt0GezzrDQU2iA=.96590a6e-c22d-4ac6-9a48-94cfad2ad8a9@github.com>
 <zp4MyiJc4Bmgqytk-MVOPswHbELYgKkPp60S62x6dtw=.06a713f2-7f6c-4edd-8254-e347700788e6@github.com>
Message-ID: <o4M6BNaHo6HVGBw3hkUU3fd_YTqsKAyTB9_ivc5hOmg=.11ce3841-2429-4cfa-bcf4-b489aec2b4aa@github.com>

On Wed, 13 Mar 2024 13:51:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Relying on the upper bounds check of `charAt` doesn't work well with the `CharArraySequence` whose `charAt` deliberately does not throw an IIOBE if the array is longer than the provided length, ie, it'll look at chars beyond the provided range. The examples I tested still end up as a NFE, but it's clear from the cause that we're running past the length:
> 
> ```
> jshell> new BigDecimal(new char[] { '-', '1', 'e'}, 0, 1);
> |  Exception java.lang.NumberFormatException
> |        at BigDecimal.<init> (BigDecimal.java:754)
> |        at BigDecimal.<init> (BigDecimal.java:543)
> |        at BigDecimal.<init> (BigDecimal.java:518)
> |        at (#4:1)
> |  Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3
> |        at BigDecimal$CharArraySequence.charAt (BigDecimal.java:559)
> |        at BigDecimal.parseExp (BigDecimal.java:772)
> |        at BigDecimal.<init> (BigDecimal.java:619)
> |        ...
> ```
> 
> Baseline/expected:
> 
> ```
> jshell> new BigDecimal(new char[] { '-', '1', 'e'}, 0, 1);
> |  Exception java.lang.NumberFormatException: No digits found.
> |        at BigDecimal.<init> (BigDecimal.java:635)
> |        at BigDecimal.<init> (BigDecimal.java:518)
> |        at (#1:1)
> ```
> 
> Having a check on `len > 0` is more robust - and I'd be surprised if avoiding a redundant check on the loop entry is affecting performance?

If the likely error/boundary conditions change, those changed conditions should be added to the regression tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1523509168

From liach at openjdk.org  Wed Mar 13 16:05:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Mar 2024 16:05:15 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v13]
In-Reply-To: <CZk9R86q9YsITK3bHsX31RjXAcgZDu_EuA_1JOVH7IE=.a3249016-d15b-4d14-8756-55f63c1efabf@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <CZk9R86q9YsITK3bHsX31RjXAcgZDu_EuA_1JOVH7IE=.a3249016-d15b-4d14-8756-55f63c1efabf@github.com>
Message-ID: <59tp-wNWgcfphHKbKqtSuo6VbF1t3LBMa6y-WnbnXVE=.c6bf6180-934f-46a0-9705-6b9871d96fed@github.com>

On Wed, 13 Mar 2024 15:46:30 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 incrementally with one additional commit since the last revision:
> 
>   bug fix for CharArraySequence

src/java.base/share/classes/java/math/BigDecimal.java line 561:

> 559:             index += offset;
> 560:             if (index >= length)
> 561:                 throw new IndexOutOfBoundsException();

This logic is wrong: if offset is 3 and length is 2, aab*bc*c would be valid, but your code will IOOBE on `charAt(0)` because `index += offset` will be 3, 3 > 2.

You should use `Objects.checkIndex(index, length)` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1523540101

From naoto at openjdk.org  Wed Mar 13 16:06:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Mar 2024 16:06:26 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v4]
In-Reply-To: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
Message-ID: <6cm2wIXFRFcKjWpKznMgQ1xhZK_5D83opqnzAvm9uko=.01f8487d-d232-45ef-ac4f-8ca5e3e233d1@github.com>

> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Further refinement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18243/files
  - new: https://git.openjdk.org/jdk/pull/18243/files/21e425ab..e1a5783a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18243&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18243&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18243/head:pull/18243

PR: https://git.openjdk.org/jdk/pull/18243

From duke at openjdk.org  Wed Mar 13 17:11:25 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Wed, 13 Mar 2024 17:11:25 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v4]
In-Reply-To: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
Message-ID: <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>

> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
> 
> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.

Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into JDK-8325621-2
 - Update style and improve error messages
 - Print to stdout instead of stderr
 - Compare version using VERSION_STRING
 - Code cleanup
 - Remove string.h include
 - Update test
 - Pass version as integer instead of string
 - Read in version using int instead of string
 - 8325621: Improve jspawnhelper version checks

-------------

Changes: https://git.openjdk.org/jdk/pull/18204/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18204&range=03
  Stats: 59 lines in 5 files changed: 47 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18204.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18204/head:pull/18204

PR: https://git.openjdk.org/jdk/pull/18204

From shade at openjdk.org  Wed Mar 13 17:47:15 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Mar 2024 17:47:15 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v4]
In-Reply-To: <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>
Message-ID: <3Njw7CUHNsT_8H46HOaMJLvRPkVhc79v3FEVwJ_guKs=.5f3feb8a-41b2-4d75-b99b-43ed957bf687@github.com>

On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into JDK-8325621-2
>  - Update style and improve error messages
>  - Print to stdout instead of stderr
>  - Compare version using VERSION_STRING
>  - Code cleanup
>  - Remove string.h include
>  - Update test
>  - Pass version as integer instead of string
>  - Read in version using int instead of string
>  - 8325621: Improve jspawnhelper version checks

I am good with this version, thanks!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18204#pullrequestreview-1934831130

From iris at openjdk.org  Wed Mar 13 17:52:13 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 13 Mar 2024 17:52:13 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v4]
In-Reply-To: <6cm2wIXFRFcKjWpKznMgQ1xhZK_5D83opqnzAvm9uko=.01f8487d-d232-45ef-ac4f-8ca5e3e233d1@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
 <6cm2wIXFRFcKjWpKznMgQ1xhZK_5D83opqnzAvm9uko=.01f8487d-d232-45ef-ac4f-8ca5e3e233d1@github.com>
Message-ID: <iMjQWql6EXxL5IvLbpmwp9S330fNBrMyQ_fEgGjuf8A=.14644fa6-74b6-4ebe-9826-fdf7196be79d@github.com>

On Wed, 13 Mar 2024 16:06:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further refinement

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18243#pullrequestreview-1934843256

From rriggs at openjdk.org  Wed Mar 13 18:05:20 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Mar 2024 18:05:20 GMT
Subject: RFR: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1
Message-ID: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>

The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.

Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
Added a run of the test using ZGC, (previously omitted)

-------------

Commit messages:
 - 8327180: Failed: java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 failed with CONF=release -XX:ReservedCodeCacheSize=8m

Changes: https://git.openjdk.org/jdk/pull/18284/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18284&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327180
  Stats: 36 lines in 1 file changed: 5 ins; 28 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18284.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18284/head:pull/18284

PR: https://git.openjdk.org/jdk/pull/18284

From iris at openjdk.org  Wed Mar 13 18:43:14 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 13 Mar 2024 18:43:14 GMT
Subject: RFR: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1
In-Reply-To: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
References: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
Message-ID: <-LiadQSz5mAui1FB2_3RrTfqJVSGezEGfiLGfKa4yVE=.d44723fe-077e-4721-ac79-3f9e93c8efed@github.com>

On Wed, 13 Mar 2024 18:01:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.
> 
> Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
> Added a run of the test using ZGC, (previously omitted)

Marked as reviewed by iris (Reviewer).

test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 53:

> 51: /*
> 52:  * Disabled for ZGC Generational.
> 53:  * TODO: Find correct appropriate solution to the flakiness of this test.

Shouldn't you also remove the comment at line 52 since this test is no longer disabled?

-------------

PR Review: https://git.openjdk.org/jdk/pull/18284#pullrequestreview-1934946970
PR Review Comment: https://git.openjdk.org/jdk/pull/18284#discussion_r1523749769

From rriggs at openjdk.org  Wed Mar 13 19:41:25 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Mar 2024 19:41:25 GMT
Subject: RFR: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v2]
In-Reply-To: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
References: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
Message-ID: <632NgUClA2tGbGN1wG6HlL6V0Pp78KV59rxvWQoHgos=.cedcf2b6-6a01-41c5-a768-261cc743971a@github.com>

> The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.
> 
> Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
> Added a run of the test using ZGC, (previously omitted)

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove obsolete note; no longer disabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18284/files
  - new: https://git.openjdk.org/jdk/pull/18284/files/de516a24..b94fe6d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18284&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18284&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18284.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18284/head:pull/18284

PR: https://git.openjdk.org/jdk/pull/18284

From rriggs at openjdk.org  Wed Mar 13 19:46:15 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Mar 2024 19:46:15 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v4]
In-Reply-To: <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>
Message-ID: <zT_y0UHVGEo-xFjJQVxQfhp1hobQfDfsJuNCCJ8I6t8=.bef66965-529e-4d5d-a6c1-3818a7862ea7@github.com>

On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into JDK-8325621-2
>  - Update style and improve error messages
>  - Print to stdout instead of stderr
>  - Compare version using VERSION_STRING
>  - Code cleanup
>  - Remove string.h include
>  - Update test
>  - Pass version as integer instead of string
>  - Read in version using int instead of string
>  - 8325621: Improve jspawnhelper version checks

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18204#pullrequestreview-1935071268

From stefank at openjdk.org  Wed Mar 13 19:51:37 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 13 Mar 2024 19:51:37 GMT
Subject: RFR: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v2]
In-Reply-To: <632NgUClA2tGbGN1wG6HlL6V0Pp78KV59rxvWQoHgos=.cedcf2b6-6a01-41c5-a768-261cc743971a@github.com>
References: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
 <632NgUClA2tGbGN1wG6HlL6V0Pp78KV59rxvWQoHgos=.cedcf2b6-6a01-41c5-a768-261cc743971a@github.com>
Message-ID: <p8zNAdAVnG2hGyf9HehTD47SVyJowEvXA3G4fz4IRSg=.b8e4ee3b-ce95-4cf9-b6d2-c7bdaee2fe5b@github.com>

On Wed, 13 Mar 2024 19:41:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.
>> 
>> Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
>> Added a run of the test using ZGC, (previously omitted)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove obsolete note; no longer disabled

Changes requested by stefank (Reviewer).

test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching.java line 57:

> 55:  * @library /test/lib/
> 56:  * @summary ObjectStreamClass caches keep ClassLoaders alive (ZGC)
> 57:  * @run testng/othervm -Xmx64m -XX:+UseZGC ObjectStreamClassCaching

This test is meant to run with Generational ZGC (according to the requires line). It needs to run with `-XX:+UseZGC -XX:+ZGenerational` to enable Generational ZGC. If you run with `-XX:+UseZGC` you get the older, non-generational ZGC.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18284#pullrequestreview-1935079550
PR Review Comment: https://git.openjdk.org/jdk/pull/18284#discussion_r1523833917

From mullan at openjdk.org  Wed Mar 13 20:09:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Mar 2024 20:09:09 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
Message-ID: <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>

On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MBeanServerFileAccessController.java

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 29:

> 27:  * @enablePreview
> 28:  * @summary Implement Subject.current and Subject.callAs using scoped values.
> 29:  *      Need @enablePreview to use StructuredTaskScope.

jtreg throws a `ParseException` because I think it tries to interpret it as an `@enablePreview` action. Suggest enclosing it in double quotes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1523838888

From rriggs at openjdk.org  Wed Mar 13 20:10:25 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Mar 2024 20:10:25 GMT
Subject: RFR: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v3]
In-Reply-To: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
References: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
Message-ID: <SN9xEvfAmhOiReAp4xuA_tyCr0Oc8lWHAI_c0cQQjOE=.e4b57d6e-149f-4956-b084-c3b32422a47e@github.com>

> The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.
> 
> Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
> Added a run of the test using ZGC, (previously omitted)

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Use the correct ZGenerational collector

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18284/files
  - new: https://git.openjdk.org/jdk/pull/18284/files/b94fe6d5..55960c41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18284&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18284&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18284.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18284/head:pull/18284

PR: https://git.openjdk.org/jdk/pull/18284

From ihse at openjdk.org  Wed Mar 13 20:12:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 20:12:18 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v4]
In-Reply-To: <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>
Message-ID: <CGRTDeeeo6d1J8cNrd_KeOuYqWi_SJDf3Qb2EO2rMz8=.e8882e32-db4f-444e-957c-7c5a646a1447@github.com>

On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into JDK-8325621-2
>  - Update style and improve error messages
>  - Print to stdout instead of stderr
>  - Compare version using VERSION_STRING
>  - Code cleanup
>  - Remove string.h include
>  - Update test
>  - Pass version as integer instead of string
>  - Read in version using int instead of string
>  - 8325621: Improve jspawnhelper version checks

Build changes look good now.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18204#pullrequestreview-1935108939

From naoto at openjdk.org  Wed Mar 13 20:30:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Mar 2024 20:30:42 GMT
Subject: Integrated: 8327242: Document supported CLDR versions in the javadoc
In-Reply-To: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
Message-ID: <KFO06hC0HK-sYHBNSHGh_juRbo1T_iRYq_2al0aKX1k=.cff3bd4f-127b-4552-bc30-815a8fb5e9bf@github.com>

On Tue, 12 Mar 2024 16:26:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding a table that maps JDK versions and corresponding CLDR releases as an implNote. A draft CSR has also been created.

This pull request has now been integrated.

Changeset: 7f6b7ebb
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f6b7ebbcc49d8023e669568c38cd301bb795983
Stats:     56 lines in 1 file changed: 48 ins; 0 del; 8 mod

8327242: Document supported CLDR versions in the javadoc

Reviewed-by: joehw, iris, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/18243

From stefank at openjdk.org  Wed Mar 13 20:31:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 13 Mar 2024 20:31:42 GMT
Subject: RFR: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v3]
In-Reply-To: <SN9xEvfAmhOiReAp4xuA_tyCr0Oc8lWHAI_c0cQQjOE=.e4b57d6e-149f-4956-b084-c3b32422a47e@github.com>
References: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
 <SN9xEvfAmhOiReAp4xuA_tyCr0Oc8lWHAI_c0cQQjOE=.e4b57d6e-149f-4956-b084-c3b32422a47e@github.com>
Message-ID: <LvFKDA-ZhO-ELlmElOxjyIymN2nqYRn7_i5RGsaTqME=.f37ed0bb-b864-4ed0-a705-11592713781b@github.com>

On Wed, 13 Mar 2024 20:10:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.
>> 
>> Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
>> Added a run of the test using ZGC, (previously omitted)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the correct ZGenerational collector

Looks good. Make sure that the test has run after the -XX:+ZGenerational flag was added.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18284#pullrequestreview-1935146818

From iris at openjdk.org  Wed Mar 13 20:51:40 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 13 Mar 2024 20:51:40 GMT
Subject: RFR: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v3]
In-Reply-To: <SN9xEvfAmhOiReAp4xuA_tyCr0Oc8lWHAI_c0cQQjOE=.e4b57d6e-149f-4956-b084-c3b32422a47e@github.com>
References: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
 <SN9xEvfAmhOiReAp4xuA_tyCr0Oc8lWHAI_c0cQQjOE=.e4b57d6e-149f-4956-b084-c3b32422a47e@github.com>
Message-ID: <pdeJUJDyJxecxRFCkcb_pd3toaKNsH0zIHb10AMdcOQ=.6320b95b-536b-4023-823c-342c523aafb9@github.com>

On Wed, 13 Mar 2024 20:10:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.
>> 
>> Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
>> Added a run of the test using ZGC, (previously omitted)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the correct ZGenerational collector

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18284#pullrequestreview-1935176824

From clanger at openjdk.org  Wed Mar 13 21:07:54 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 21:07:54 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718 [v3]
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <c7AjuntbLje8ElfRXnM6beeEqXmfRAPhbsLqMPcdhQg=.b2686d32-54f6-4db9-8671-6e4e40c0f8eb@github.com>

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18264/files
  - new: https://git.openjdk.org/jdk/pull/18264/files/be84e5e8..ca3ec0d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18264&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18264&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18264/head:pull/18264

PR: https://git.openjdk.org/jdk/pull/18264

From clanger at openjdk.org  Wed Mar 13 21:07:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 21:07:55 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718 [v2]
In-Reply-To: <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>
 <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>
Message-ID: <Bi2BI0CY9keENBJVDtRW_XjOZ5cAH7oRoO87akCpuz4=.d012ec06-bbb5-44db-9b19-9ab3737d8fc1@github.com>

On Wed, 13 Mar 2024 14:23:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Can you please add the bug id to `@bug` and correct the typo, as suggested [here](https://github.com/openjdk/jdk/pull/18264#issuecomment-1994382507)?

Done.

I kept the tenMillion... handling.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1995807615

From naoto at openjdk.org  Wed Mar 13 23:24:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Mar 2024 23:24:41 GMT
Subject: RFR: 8327242: Document supported CLDR versions in the javadoc [v4]
In-Reply-To: <90p4iS_uItm1s7LANUFUFcS3aQCFzc2GEy326fWe99Y=.35b6ea8c-01e6-428c-853f-0e2b4c765338@github.com>
References: <qdynWu_RpZM0ImFDGd4l5d_KOdM06yfLdeA44D--eRc=.fdb2f7fe-ac79-482e-afed-78687ace6498@github.com>
 <nyshvUW1hLf_y1pQkTB_fFpqQl_cF4hDSc5_fHxs8c4=.000927e6-1008-4428-9321-325e32da4be7@github.com>
 <90p4iS_uItm1s7LANUFUFcS3aQCFzc2GEy326fWe99Y=.35b6ea8c-01e6-428c-853f-0e2b4c765338@github.com>
Message-ID: <Be7NgZiwOJFkmfIQ7I95QkNsSYSLG1BBaBcPdBkTaF4=.d5634b6c-c89d-40ff-8965-89f75cc6bdb8@github.com>

On Tue, 12 Mar 2024 18:47:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>  Will let the doc people know. It is at least good that the latest doc for JDK21 is correct.

Now the previous releases' supported locales docs have been updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18243#issuecomment-1996071016

From duke at openjdk.org  Thu Mar 14 00:00:53 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 14 Mar 2024 00:00:53 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v14]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <G8nOGcGdQnJMQuDH1Pf1Dt4519wf1V-Ze2WfkiAAuJU=.34b745d2-a080-45f8-a05c-7e4eca0e1ba3@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 incrementally with one additional commit since the last revision:

  bug fix for CharArraySequence#charAt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/f3084ba5..69be44db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=12-13

  Stats: 8 lines in 2 files changed: 3 ins; 4 del; 1 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 duke at openjdk.org  Thu Mar 14 00:08:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 14 Mar 2024 00:08:42 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v13]
In-Reply-To: <59tp-wNWgcfphHKbKqtSuo6VbF1t3LBMa6y-WnbnXVE=.c6bf6180-934f-46a0-9705-6b9871d96fed@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <CZk9R86q9YsITK3bHsX31RjXAcgZDu_EuA_1JOVH7IE=.a3249016-d15b-4d14-8756-55f63c1efabf@github.com>
 <59tp-wNWgcfphHKbKqtSuo6VbF1t3LBMa6y-WnbnXVE=.c6bf6180-934f-46a0-9705-6b9871d96fed@github.com>
Message-ID: <grWyVdw1EnCcnximbfwWhWSKAWufYJH2_glsDjIAJ58=.40fc8ec6-e7e5-4c08-84c4-a69f157e2689@github.com>

On Wed, 13 Mar 2024 16:02:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bug fix for CharArraySequence
>
> src/java.base/share/classes/java/math/BigDecimal.java line 561:
> 
>> 559:             index += offset;
>> 560:             if (index >= length)
>> 561:                 throw new IndexOutOfBoundsException();
> 
> This logic is wrong: if offset is 3 and length is 2, aab*bc*c would be valid, but your code will IOOBE on `charAt(0)` because `index += offset` will be 3, 3 > 2.
> 
> You should use `Objects.checkIndex(index, length)` instead.

Oh, what a stupid mistake :)

Using Objects.checkIndex will have a redundant check for index < 0, which does not need to be done in this scenario. Objects.checkIndex will cause a slight performance degradation.

The performance numbers under MacBookPro M1 Max are as follows:


Benchmark                                      Mode  Cnt   Score   Error  Units
BigDecimals.testConstructorWithSmallCharArray  avgt   15  19.167 ? 0.070  ns/op

Benchmark                                      Mode  Cnt   Score   Error  Units # Objects.checkIndex
BigDecimals.testConstructorWithSmallCharArray  avgt   15  20.591 ? 0.241  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1524049182

From jpai at openjdk.org  Thu Mar 14 04:15:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Mar 2024 04:15:33 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap
Message-ID: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>

Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?

The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 

The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.

The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.

-------------

Commit messages:
 - 8328066: WhiteBoxResizeTest failure on linux-x86: Could not reserve enough space for 2097152KB object heap

Changes: https://git.openjdk.org/jdk/pull/18290/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18290&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328066
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18290/head:pull/18290

PR: https://git.openjdk.org/jdk/pull/18290

From duke at openjdk.org  Thu Mar 14 05:27:37 2024
From: duke at openjdk.org (Korov)
Date: Thu, 14 Mar 2024 05:27:37 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: <BFmyR0z5RiCkjLxSxprFXzH9dDfdY188Sy4Sl5ypAIU=.fb29491b-d876-4ff2-8b1e-c143e1915c59@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

Hi @liach , Can you review my newly submitted code?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-1996550991

From liach at openjdk.org  Thu Mar 14 06:00:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Mar 2024 06:00:38 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: <1gtx7D4ejN7JS6Z1HMpo1dw-o-zmG55rNRpUXgI1hwc=.e173e9c7-7491-4031-8b79-8c69dfed4541@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

Looks good to me, maybe @stuart-marks can take a look too?

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/18141#pullrequestreview-1935750299

From duke at openjdk.org  Thu Mar 14 07:01:42 2024
From: duke at openjdk.org (Sergey)
Date: Thu, 14 Mar 2024 07:01:42 GMT
Subject: RFR: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <PCOha4kEhFmAwInPEW4gepKboqLMOqeudMMA8xeNfIQ=.603ba4dd-90e0-4154-a627-b41e40f62478@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

I'm sorry to hear this. It's done all the time in tests, by third-party libraries. I figured it'd be better if such a common procedure was more convenient

As a side note, encouraging the use of switch by adding more features to it (`when`, etc.) is more questionable than accessing private fields, in my view

Anyway, thanks for your feedback

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17578#issuecomment-1996676960

From shade at openjdk.org  Thu Mar 14 07:49:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Mar 2024 07:49:39 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v2]
In-Reply-To: <nPD-ug1GuZXLfqwup4PDRXIhGOp4Z19X12svQ-eeg2E=.b7f0313e-3724-44d7-9959-761c29070e0b@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <Tq5af9j3RzvScPs_yPGLb5M9NWZnChPDzIsVrzlnmg4=.a8ae426f-eb65-4096-b2b6-9161c17410b5@github.com>
 <nPD-ug1GuZXLfqwup4PDRXIhGOp4Z19X12svQ-eeg2E=.b7f0313e-3724-44d7-9959-761c29070e0b@github.com>
Message-ID: <U0x0FgbujgAWqK6v3JgRgrzY_JXaZIiBV6x_kKSVACo=.a2116e0f-58e4-4d6e-ae3a-97dcc062d2c1@github.com>

On Tue, 12 Mar 2024 18:42:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code cleanup
>
> I'm fine with just using VERSION_FEATURE. I think it's a simple and straightforward enough simplification/approximation. If we think we need a more exact version comparison, then I think we should use one of the version strings instead of arbitrarily picking a set of version variables.

@erikj79, are you good with this version?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18204#issuecomment-1996757094

From mbaesken at openjdk.org  Thu Mar 14 08:49:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 08:49:42 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>
References: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>
Message-ID: <z5fWZyLpyYVBGxYNK4cmRyEkni-YEgC8jBqrvHPU1tg=.e4db53d7-5761-4795-aead-72a14da3608b@github.com>

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

With some rebalancing/adjustments to our test landscape the issues are gone. 
Unfortunately there was not much interest  in the resource related discussion on jtreg-dev  
https://mail.openjdk.org/pipermail/jtreg-dev/2024-February/001926.html

closing for now because the issues are currently not seen any more on our side.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1996885622
PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1996886625

From mbaesken at openjdk.org  Thu Mar 14 08:49:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 08:49:42 GMT
Subject: Withdrawn: JDK-8324930: java/lang/StringBuilder problem with
 concurrent jtreg runs
In-Reply-To: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>
References: <fJkYRK2zKVbEvurpJ8pTPdnI15nz2yaDuPbXdS20rwQ=.209d0e91-8e96-43d3-9b41-a18a4600fb8a@github.com>
Message-ID: <8ROUoY43RPclA9i--Th7jIMBsFMsTI0GUZLzhA0Ytvs=.ad4e34a7-0f2e-4544-b329-9ede0e726b85@github.com>

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/17625

From mli at openjdk.org  Thu Mar 14 08:56:51 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 14 Mar 2024 08:56:51 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <A-67wzy3_Jpj9tsxMMbMArjhDKjxhs19o6cYlJxMB7o=.2324e91d-b5c9-407a-a33c-f3b6bf959422@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
 <A-67wzy3_Jpj9tsxMMbMArjhDKjxhs19o6cYlJxMB7o=.2324e91d-b5c9-407a-a33c-f3b6bf959422@github.com>
Message-ID: <6Y1G5D_sGHAa3nOvQjxvOex9sNpwaEvLaTsgyODzwBU=.86b42ad7-0496-441d-aa5f-7fb1b3394bbe@github.com>

On Fri, 1 Mar 2024 15:10:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix potential attribute issue
>
> Iirc, your assessment is right; the code should be ready for integration; I just don't know about the state of testing.

Hi @magicus @theRealAph @dholmes-ora,
I've created the new pr to continue the work at: https://github.com/openjdk/jdk/pull/18294.
Please take another look.
Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1996902143

From rgiulietti at openjdk.org  Thu Mar 14 10:33:44 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 14 Mar 2024 10:33:44 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718 [v3]
In-Reply-To: <c7AjuntbLje8ElfRXnM6beeEqXmfRAPhbsLqMPcdhQg=.b2686d32-54f6-4db9-8671-6e4e40c0f8eb@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <c7AjuntbLje8ElfRXnM6beeEqXmfRAPhbsLqMPcdhQg=.b2686d32-54f6-4db9-8671-6e4e40c0f8eb@github.com>
Message-ID: <xOTW_0PlpFULbYkhsBpMVkV8fw1MjwIJV1RWey8-TKE=.8498acbf-d63f-4cc2-af82-100488b91029@github.com>

On Wed, 13 Mar 2024 21:07:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
>> 
>> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
>> 
>> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18264#pullrequestreview-1936282689

From sroy at openjdk.org  Thu Mar 14 10:37:17 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 14 Mar 2024 10:37:17 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library loading
 in AIX- Java Class Loader
Message-ID: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@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)

-------------

Commit messages:
 - Add support for AIX dynamic libraries in Class Loader

Changes: https://git.openjdk.org/jdk/pull/17945/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319516
  Stats: 81 lines in 1 file changed: 81 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 ihse at openjdk.org  Thu Mar 14 10:59:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Mar 2024 10:59:48 GMT
Subject: RFR: 8328146: Set LIBCXX automatically
Message-ID: <G4PfVrm0hXu7yxO8Kl2TxJ1zoxzW7NQ7WEwUWxM6zMs=.b0f7e904-1c70-4349-b987-1ca60aa2fb15@github.com>

We are adding LIBCXX to LIBS in calls to SetupJdkLibrary whenever LINK_TYPE is C++. We should do this automatically in SetupJdkLibrary for C++ linking.

I also removed the superfluous `-lc` from some places where it had been added.

-------------

Commit messages:
 - 8328146: Set LIBCXX automatically

Changes: https://git.openjdk.org/jdk/pull/18298/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328146
  Stats: 27 lines in 10 files changed: 8 ins; 4 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/18298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18298/head:pull/18298

PR: https://git.openjdk.org/jdk/pull/18298

From dfuchs at openjdk.org  Thu Mar 14 11:41:39 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 14 Mar 2024 11:41:39 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap
In-Reply-To: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
Message-ID: <KHrxti-XbqOX_LllmCaeOR3W-2PuDh8B0gHjPPF02HI=.d566cec1-4e00-4344-a1b3-eb5062589291@github.com>

On Thu, 14 Mar 2024 04:11:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
> 
> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
> 
> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
> 
> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.

LGTM.

I see that some other tests have things like:


* @requires vm.bits == "64" & os.maxMemory > 4G


Not sure what is the preferred form in such cases: two `@requires` or a single one?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18290#pullrequestreview-1936420903

From jpai at openjdk.org  Thu Mar 14 11:52:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Mar 2024 11:52:38 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap
In-Reply-To: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
Message-ID: <5S_IuP4v_lKX5NnKYC1zk0bMiIEhBWn9OmLC8PqGKSI=.ad13f334-004f-41cf-b4d1-3274dd28e54a@github.com>

On Thu, 14 Mar 2024 04:11:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
> 
> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
> 
> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
> 
> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.

Hello Daniel,



> LGTM.
> 
> I see that some other tests have things like:
> 
> ```
> * @requires vm.bits == "64" & os.maxMemory > 4G
> ```
> 
> Not sure what is the preferred form in such cases: two `@requires` or a single one?

As per jtreg doc, semantically they would be the same:

>
> The @requires tag may be used multiple times in a given test. If it is used more than once, the expressions in the individual instances will be enclosed in parentheses and combined with '&'.

However, your suggestion I think is a good one, since it makes it quicker to notice the requirements instead of having it spread across on multiple lines. I'll update the PR to implement your suggestion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18290#issuecomment-1997267874

From jpai at openjdk.org  Thu Mar 14 12:15:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Mar 2024 12:15:39 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v2]
In-Reply-To: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
Message-ID: <dzJ7-RcEWWur92nCQRT3bFUmCd6JsD91Qjys19j65P0=.dead260c-073c-4b82-93e4-d96cfaceb0e9@github.com>

> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
> 
> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
> 
> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
> 
> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  combine requires into one line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18290/files
  - new: https://git.openjdk.org/jdk/pull/18290/files/0a66d740..e819081e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18290&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18290&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18290/head:pull/18290

PR: https://git.openjdk.org/jdk/pull/18290

From ihse at openjdk.org  Thu Mar 14 12:40:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Mar 2024 12:40:59 GMT
Subject: RFR: 8328157: Move C[XX]FLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk
Message-ID: <HWRIVhg1Alb0zwfbVmKdAcAlfLX2uEblr5a06TmAzDc=.0c11539b-e1a0-44f1-9ce1-1d9e49e1f2bf@github.com>

We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`, `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively, in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.

These flag variables contain a lot of duplication.

The first step towards bringing some sanity to this mess is to move the setting of these variables into `SetupJdkLibrary/SetupJdkExecutable`.

In a few places these standard flags are not set, partially or fullly. This is handled by the new arguments `DEFAULT_CFLAGS := false` (to disable the entire setting) and `C[XX]FLAGS_FILTER_OUT` (which excludes some specific flag) to `SetupJdkLibrary/SetupJdkExecutable`.

-------------

Commit messages:
 - 8328157: Move C[XX]FLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk

Changes: https://git.openjdk.org/jdk/pull/18301/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18301&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328157
  Stats: 170 lines in 31 files changed: 45 ins; 66 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/18301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18301/head:pull/18301

PR: https://git.openjdk.org/jdk/pull/18301

From ihse at openjdk.org  Thu Mar 14 12:40:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Mar 2024 12:40:59 GMT
Subject: RFR: 8328157: Move C[XX]FLAGS_JDK[LIB/EXE] to
 JdkNativeCompilation.gmk
In-Reply-To: <HWRIVhg1Alb0zwfbVmKdAcAlfLX2uEblr5a06TmAzDc=.0c11539b-e1a0-44f1-9ce1-1d9e49e1f2bf@github.com>
References: <HWRIVhg1Alb0zwfbVmKdAcAlfLX2uEblr5a06TmAzDc=.0c11539b-e1a0-44f1-9ce1-1d9e49e1f2bf@github.com>
Message-ID: <bB4J2iWMPAT_zrDk8K3yy0fMbt0CftBhh5j0iK2hEA0=.27809d16-3c01-40b0-a19e-63f84062c4f8@github.com>

On Thu, 14 Mar 2024 12:36:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`, `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively, in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
> 
> These flag variables contain a lot of duplication.
> 
> The first step towards bringing some sanity to this mess is to move the setting of these variables into `SetupJdkLibrary/SetupJdkExecutable`.
> 
> In a few places these standard flags are not set, partially or fullly. This is handled by the new arguments `DEFAULT_CFLAGS := false` (to disable the entire setting) and `C[XX]FLAGS_FILTER_OUT` (which excludes some specific flag) to `SetupJdkLibrary/SetupJdkExecutable`.

I have verified with `COMPARE_BUILD` that there is no significant difference in the build result with or without this patch on Oracle default CI platforms (linux x64/aarch64, macos x64/aarch64, windows x64).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18301#issuecomment-1997359912

From erikj at openjdk.org  Thu Mar 14 13:25:45 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Mar 2024 13:25:45 GMT
Subject: RFR: 8325621: Improve jspawnhelper version checks [v4]
In-Reply-To: <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
 <AJnjRLGKI5vT9_zsK_rxnjNyqRSUn-ttPtOpQJQda8I=.6dc26397-77e0-4697-ba54-78d1d41efc17@github.com>
Message-ID: <fv_Eyvh3KXEXCbgjyohqULW6J809qkIBk_BFfeilOhY=.74b62ca2-f10b-4407-9df5-7e8197f7f5ef@github.com>

On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>> 
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.
>
> Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into JDK-8325621-2
>  - Update style and improve error messages
>  - Print to stdout instead of stderr
>  - Compare version using VERSION_STRING
>  - Code cleanup
>  - Remove string.h include
>  - Update test
>  - Pass version as integer instead of string
>  - Read in version using int instead of string
>  - 8325621: Improve jspawnhelper version checks

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18204#pullrequestreview-1936699901

From duke at openjdk.org  Thu Mar 14 13:28:45 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 14 Mar 2024 13:28:45 GMT
Subject: Integrated: 8325621: Improve jspawnhelper version checks
In-Reply-To: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
References: <9SA8XrKbIVM707SboB0nnQ4b2gXE8BqSEZ2uFumjDAg=.25b1b001-37d9-4341-9ee6-09bff93591f5@github.com>
Message-ID: <XIvcENA3oMzPOY4O66X4OksPftBhbo3IcQyALinnCRk=.7cbe4207-88e8-4b97-a7a9-a9801220b67e@github.com>

On Mon, 11 Mar 2024 17:46:14 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
> 
> Updates jspawnhelper to check that JDK version and jspawnhelper version are the same. Updates test to include check for version. Also tested manually by replacing jspawnhelper with incorrect version to confirm that check works.

This pull request has now been integrated.

Changeset: a232e8fb
Author:    Chad Rakoczy <chadrako at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a232e8fb4e6e9e2e9a5285bf01c93b8d1d995f04
Stats:     59 lines in 5 files changed: 47 ins; 4 del; 8 mod

8325621: Improve jspawnhelper version checks

Reviewed-by: erikj, shade, rriggs, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/18204

From msheppar at openjdk.org  Thu Mar 14 13:59:40 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 14 Mar 2024 13:59:40 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v2]
In-Reply-To: <dzJ7-RcEWWur92nCQRT3bFUmCd6JsD91Qjys19j65P0=.dead260c-073c-4b82-93e4-d96cfaceb0e9@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
 <dzJ7-RcEWWur92nCQRT3bFUmCd6JsD91Qjys19j65P0=.dead260c-073c-4b82-93e4-d96cfaceb0e9@github.com>
Message-ID: <pN7snCeVaHbKQot-YOIxG5n2RQvO0RZbzbiu6weMSHs=.31fd14a4-a410-4b06-a4ce-7bfe67a240be@github.com>

On Thu, 14 Mar 2024 12:15:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
>> 
>> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
>> 
>> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
>> 
>> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   combine requires into one line

I think the os.maxMemory is an artificial constraint.
a requirement to run on 64 bit machine should be sufficient
@requires vm.bits == "64"

as the issue relates to the max user virtual address space available on 32 bit architecture

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18290#issuecomment-1997521612

From jpai at openjdk.org  Thu Mar 14 14:04:51 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Mar 2024 14:04:51 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v3]
In-Reply-To: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
Message-ID: <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>

> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
> 
> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
> 
> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
> 
> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Mark's suggestion - no need for os.maxMemory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18290/files
  - new: https://git.openjdk.org/jdk/pull/18290/files/e819081e..ff708ecf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18290&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18290&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18290/head:pull/18290

PR: https://git.openjdk.org/jdk/pull/18290

From sgehwolf at openjdk.org  Thu Mar 14 14:11:08 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Mar 2024 14:11:08 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v19]
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: <QsMKlMNCld0wkrVhPN73QXapgmL-gDzgTDXsJQS-QrI=.292fdff8-1a0c-4117-be54-cd87a37fe67c@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 85 commits:

 - Remove no longer needed plugin options
 - Restore GenerateJLIClassesPluginTest.java
 - Update some comments
 - Add copyright header/comments
 - Ensure build-only plugin isn't propagated to the final image
 - Remove extraneous comment
 - Fix comment
 - Remove extraneous empty line
 - Further reduce exports
 - Remove unneded export
 - ... and 75 more: https://git.openjdk.org/jdk/compare/49ce85fa...5404d4e8

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=18
  Stats: 3534 lines in 38 files changed: 3400 ins; 110 del; 24 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 sgehwolf at openjdk.org  Thu Mar 14 14:21:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Mar 2024 14:21:45 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v12]
In-Reply-To: <pfmlRFINbo0U-CBIPHE1m75kkI52F78g-qTrgYcPwP0=.702c6158-3026-490f-8ddb-1fd49124f1e8@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <iHvfP1CJRkBYTMEyCGUHvsyWxPHdVp36g49nxbxZfXU=.db86d493-f32e-4faf-a3e5-cf414ac9abbb@github.com>
 <SgsGUJfHNA8VUNYOMq84os1Z6fd65JmoL8LzCWuZ6lo=.9f170e6b-9cd6-4311-b541-32877614d325@github.com>
 <d8auiA32eRo3tD89k7Dd5LsDwkFuytr9wUnStQYxuM4=.e5b292d8-8e0d-46e6-a9c9-e01ec0521def@github.com>
 <pfmlRFINbo0U-CBIPHE1m75kkI52F78g-qTrgYcPwP0=.702c6158-3026-490f-8ddb-1fd49124f1e8@github.com>
Message-ID: <caCSdHtfFPOL4EGM7mle4YXy0QCqTAl9eugP59R-W9M=.198c60fa-6b1d-49fc-8ecc-47b63b2e3148@github.com>

On Fri, 8 Mar 2024 19:49:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> > @AlanBateman @mlchung I've now pushed an update of this patch which now uses a build-time approach as discussed elsewhere. In order to produce a linkable runtime JDK image, one needs to set --enable-runtime-link-image at configure time.
>>> 
>>> What is the rationale for introducing a special configure flag for this functionality? I've tried to look though all comments in this PR, and read the JBS issue and CSR, but I have not found any motivation for this. I'm sorry if it's there and I missed it, but this is a huge PR with a lot of discussion.
>> 
>> Sorry, yes this was part of a meeting discussion we had outside this PR. My understanding is that by default the produced jimage isn't runtime-link enabled. We (Red Hat) would turn it on in our builds, though. @AlanBateman or @mlchung might have more details. I think it was a requirement to get this patch in. At least for the initial contribution.
>> 
>>> In general, it is better not to introduce variants of the build like this. The testing matrix just explodes a bit more. And my understanding from the discussion is that this functionality is likely to be turned on anyway, otherwise you'll build a crippled jlink without full functionality.
>> 
>> I would be happy if this could be on by default. For now, I think though we need to work on the premise that whether or not the resulting JDK image is suitable for runtime linking (without jmods) is a build-time config decision. Therefore we need the configure option.
>
> @jerboaa thanks for the update.  First to recap the revised proposal (based on Alan's notes shared with me earlier):
> 
> The JDK build is capable of producing a JDK run-time image that does not include packaged modules and the  new JDK image is capable to create custom run-time images (call it "linkable" JDK image for now).   To reconstitute to the original module content, the new JDK image conceptually needs to contain the "diffs" from the original packaged packaged.   This makes it possible for the jlink plugins to run "as if" the resources for each module were coming from the original packaged module.  The new image also has the checksums of at least the user-editable configuration files so that edits can be detected. 
> 
> The revised proposal has a few limitations:
> 
> 1. The "linkable" JDK image can only be created by the JDK build.
> 2. The "linkable" JDK image is created from the JDK image produced by the JDK build today.  It contains the same set of modules, there is no possibility to combine its generation with other jlink options or code transformations.
> 3. The "linkable" JDK image cannot create a run-time image that contains the "jdk.jlink" module.
> 4. The "linkable" JDK image only reconstitutes classes/resources to the original module bits.   Other plugins such as man pages and dedup legal files are not reconstituted.
> 
> These limitations are trade-off to make for a much simpler approach. It removes the issues of creating a linkable JDK, or creating another image using a linkable JDK, while at the same time executing a pipeline of plugins that do other transformations.   
> 
> Here is my feedback to the prototype:
> 
> - I think the reader and writer code for generating the diffs should be in `jdk.jlink` so that they are always kept in sync.
> - The diffs generation can be done as a tool or `jlink` option.  If it's a tool, it should be run on the interim image (like the tool generating classlist - see `GenerateLinkOptData.gmk`).
> 
> I have no strong opinion in which approach.   It seems worth exploring the tool approach residing in `jdk.jlink` to generate the diffs as well as create the linkable image could remove the need of a jlink internal `--create-linkable-runtime` option.

Hi @mlchung!

> Here is my feedback to the prototype:
> 
>     * I think the reader and writer code for generating the diffs should be in `jdk.jlink` so that they are always kept in sync.

Done in the update. The duplication of `ResourceDiff` is now gone.

>     * The diffs generation can be done as a tool or `jlink` option.  If it's a tool, it should be run on the interim image (like the tool generating classlist - see `GenerateLinkOptData.gmk`).
> 
> I have no strong opinion in which approach. It seems worth exploring the tool approach residing in `jdk.jlink` to generate the diffs as well as create the linkable image could remove the need of a jlink internal `--create-linkable-runtime` option.

The updated patch uses a **build-only** `jlink` plugin, still called `--create-linkable-runtime` which is *a)* added only at build time with `--add-modules` and *b)* now generates the diff and prepares the image for runtime linking as before in one step. The code for this now lives in `src/jdk.jlink/build/classes`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1997560773

From sgehwolf at openjdk.org  Thu Mar 14 14:21:47 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Mar 2024 14:21:47 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <HR5vtN-BWTARvcTPH2T1yXd5RBI1pxrUsy86poDnbew=.c3b2257f-f412-432c-a91e-a73b87856ed7@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
 <HR5vtN-BWTARvcTPH2T1yXd5RBI1pxrUsy86poDnbew=.c3b2257f-f412-432c-a91e-a73b87856ed7@github.com>
Message-ID: <jI786B1opeq5cyfJ4vWCcAFJSL-c6tjgwNClkgJH2t4=.b240cb46-73e6-40cb-b848-15bef7832dd4@github.com>

On Fri, 8 Mar 2024 17:25:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> make/Images.gmk line 96:
>> 
>>> 94: 
>>> 95: ifeq ($(JLINK_KEEP_PACKAGED_MODULES), true)
>>> 96:   ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
>> 
>> I don't get it. Why don't you use the  JDK_LINK_OUTPUT_DIR from just above?
>
> Makes sense. I can fold both `JLINK_JDK_EXTRA_OPTS` into one. `JLINK_JDK_EXTRA_OPTS := --keep-packaged-modules $(JDK_LINK_OUTPUT_DIR)/jmods`

Fixed now.

>> make/Images.gmk line 104:
>> 
>>> 102: endif
>>> 103: 
>>> 104: 
>> 
>> Is this extra line intentional?
>
> No. I can remove it. Thanks.

Should be gone.

>> make/Images.gmk line 128:
>> 
>>> 126:   JDK_RUN_TIME_IMAGE_SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jlink-run-time
>>> 127:   JDK_JMODS_DIFF := $(JDK_RUN_TIME_IMAGE_SUPPORT_DIR)/jimage_packaged_modules_diff.data
>>> 128:   JLINK_RUNTIME_CREATE_EXTRA += --create-linkable-runtime=$(JDK_JMODS_DIFF)
>> 
>> My understanding is that the `--create-linkable-runtime` is the primary argument for the jlink invocation in jlink_runtime_jdk. As such, I think it would be much better if this was inlined in place in the jlink_runtime_jdk COMMAND. The "extra" makes it sound like it is optional. 
>> 
>> In contrast, the value of JLINK_RUNTIME_CREATE_EXTRA that is set above for JLINK_KEEP_PACKAGED_MODULES is indeed "extra".
>
> Your understanding is correct. Will fix.

Should be fixed in the update.

>> make/ToolsJdk.gmk line 88:
>> 
>>> 86:     --add-modules=jdk.jlink --add-exports=java.base/jdk.internal.module=ALL-UNNAMED \
>>> 87:     --add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED \
>>> 88:     build.tools.runtimelink.JimageDiffGenerator
>> 
>> While it might be a bit redundant, we try to keep the same name in the make name, the package and the main class, e.g. something like:
>> 
>> Suggestion:
>> 
>> TOOL_JIMAGE_DIFF_GENERATOR = $(BUILD_JAVA_SMALL) -cp $(BUILDTOOLS_OUTPUTDIR)/jdk_tools_classes \
>>     --add-modules=jdk.jlink --add-exports=java.base/jdk.internal.module=ALL-UNNAMED \
>>     --add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED \
>>     build.tools.jimagediffgenerator.JimageDiffGenerator
>> 
>> 
>> This is of course not consistently followed, but for new tooling I think it would be a good idea to try and follow.
>
> Based on some private feedback I've got it seems this will change a bit (move to the `jdk.jlink` module instead). But if still relevant, I'll keep that in mind. Thanks!

The latest update does the compilation in `make/Images.gmk` and doesn't use the tool approach any more. This should be moot.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1524960817
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1524961177
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1524960431
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1524964174

From sgehwolf at openjdk.org  Thu Mar 14 14:21:48 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Mar 2024 14:21:48 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <e38etX44zABjjypVZFAYfokGwtUHKpNav2xzFyakMkg=.21049964-25d2-4e6d-b7f8-c46939903ba9@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <96CUeFEjIzzk-oHpZCBZNN8BmYMqAc0ozkZPxavkQnU=.658d6cc7-b371-47a8-aae2-b146c80f4c85@github.com>
 <gToCsx0XWYk3uFGdoJEWKimnRULPsh2GIhJMlV1K4f8=.d3da8551-91c0-47b5-a163-847ffc2e0e83@github.com>
 <lhEDwRmaffeIq1qd7XgS5o1s9ynp39y4-IlBGdjFmHU=.cb39b8b7-e1de-4816-8748-67805c7970c8@github.com>
 <Wc4EhkYtdpo85jdS0HKUqWM_fZvSkND-wNzJysojm-c=.0745ccb4-a7ba-4583-b8af-85d515710cb5@github.com>
 <e38etX44zABjjypVZFAYfokGwtUHKpNav2xzFyakMkg=.21049964-25d2-4e6d-b7f8-c46939903ba9@github.com>
Message-ID: <vf622J3MxSvMYd7oO6TvOuGrQRTBwH4On-ZhN29ysP0=.fa3b4109-62a2-41f4-aa8e-67c555d22701@github.com>

On Tue, 12 Mar 2024 14:07:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I don't see a race. The `rm` was there in the original code and is no scarier in the modified version. The jdk image is constructed by a combination of targets and recipes. The first one to run has to be jlink, then we overlay more stuff on top. If the makefile dependency resolution concludes that we need to rerun the jlink step, we clear out the directory completely to make sure we aren't leaving anything in there that's no longer valid. This is basically a precaution to guarantee a correct incremental build. It's not incurring a big build time penalty as jlink would have overwritten all files it would have created anyway. However, if a module was removed, or a file was removed from a module, the `rm` helps guarantee that we don't include such a removed file from a previous build attempt in the final image.
>> 
>> Or it may even be as Severin says, that jlink refuses to run, I don't remember.
>
> Ok, good, thanks. I did not see the whole picture there.

Marking this as resolved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1524961788

From sgehwolf at openjdk.org  Thu Mar 14 14:21:49 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Mar 2024 14:21:49 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <GhW_EsutSYyiQDxy4m6KuWnpAZl9VL7jhyc8a3QWCUM=.f2ca2f6a-0c9d-4d9f-9a00-da6d12e09ada@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <GhW_EsutSYyiQDxy4m6KuWnpAZl9VL7jhyc8a3QWCUM=.f2ca2f6a-0c9d-4d9f-9a00-da6d12e09ada@github.com>
Message-ID: <vSBVVizyChlPChDQPKxCBI6A6bCw_0eTUULdv6OAU6k=.b7b43df4-bee6-43d4-a5cc-711c66479bf0@github.com>

On Tue, 27 Feb 2024 22:06:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only show runtime image suffix for JDK modules
>
> make/autoconf/spec.gmk.template line 904:
> 
>> 902: RL_INTERMEDIATE_IMAGE_SUBDIR := runtime-link-initial-jdk
>> 903: RL_INTERMEDIATE_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(RL_INTERMEDIATE_IMAGE_SUBDIR)
>> 904: 
> 
> This intermediate directory is only used inside the Images.gmk. I don't think we need to define it in spec. It can be a local variable in Images.gmk. Also, unless you really want this intermediate image in "images" as some kind of deliverable I would prefer to put it somewhere under `$(SUPPORT_OUTPUTDIR)/images`.

Fixed in the update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1524964780

From sgehwolf at openjdk.org  Thu Mar 14 14:24:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Mar 2024 14:24:57 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
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: <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@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 one additional commit since the last revision:

  Fix comment in autoconf file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/5404d4e8..1fe6161b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=18-19

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 sgehwolf at openjdk.org  Thu Mar 14 14:24:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Mar 2024 14:24:57 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <GhW_EsutSYyiQDxy4m6KuWnpAZl9VL7jhyc8a3QWCUM=.f2ca2f6a-0c9d-4d9f-9a00-da6d12e09ada@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
 <GhW_EsutSYyiQDxy4m6KuWnpAZl9VL7jhyc8a3QWCUM=.f2ca2f6a-0c9d-4d9f-9a00-da6d12e09ada@github.com>
Message-ID: <Ipioe_dQk5ENWjSTN-0h6-hdSNE-Y6aweq0DnOIZ-rU=.c4913368-d649-4dea-8ff8-f49594b3627e@github.com>

On Tue, 27 Feb 2024 22:04:47 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only show runtime image suffix for JDK modules
>
> make/autoconf/jdk-options.m4 line 596:
> 
>> 594: ################################################################################
>> 595: #
>> 596: # jlink related.
> 
> This part of the comment seems a bit redundant.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1524970742

From sgehwolf at openjdk.org  Thu Mar 14 14:30:46 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Mar 2024 14:30:46 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
Message-ID: <_1_d1zYvgoHoZgSf8nXoAFEFEJdV2L7SLQbL92845iU=.37d837ba-a3b1-4779-ad80-79fa9de6790e@github.com>

On Thu, 14 Mar 2024 14:24:57 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:
> 
>   Fix comment in autoconf file

make/Images.gmk line 33:

> 31: include Modules.gmk
> 32: include Utils.gmk
> 33: include ToolsJdk.gmk

This is probably no longer needed. I'll remove in a later update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1524979996

From mchung at openjdk.org  Thu Mar 14 17:39:50 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Mar 2024 17:39:50 GMT
Subject: RFR: 8326979: (jdeps) improve the error message for FindException
 caused by InvalidModuleDescriptorException
Message-ID: <Kk24dug_yvI5s_W8v636SACpzJia3TDHPDbCrOQiKHg=.edcd1d99-564c-4308-b914-53eaf7c7180d@github.com>

Trivial fix.  Improve the error message to print the cause of the module resolution failure if present.

-------------

Commit messages:
 - 8326979: (jdeps) improve the error message for FindException caused by InvalidModuleDescriptorException

Changes: https://git.openjdk.org/jdk/pull/18308/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18308&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326979
  Stats: 89 lines in 2 files changed: 88 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18308.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18308/head:pull/18308

PR: https://git.openjdk.org/jdk/pull/18308

From erikj at openjdk.org  Thu Mar 14 17:54:47 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Mar 2024 17:54:47 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
Message-ID: <kUhJgtefWZUERJXOtv1HgUfgSbCQLMsfJig0W9sFj9w=.323f0ae3-07be-4963-93ee-655839a6ad86@github.com>

On Thu, 14 Mar 2024 14:24:57 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:
> 
>   Fix comment in autoconf file

make/Images.gmk line 125:

> 123: 
> 124:   RL_BUILD_MODULE_NAME := jdk.unsupported_jlink_runtime
> 125:   RL_CREATE_PLUGIN_MOD_OUTPUT := $(SUPPORT_OUTPUTDIR)/$(RL_BUILD_MODULE_NAME)

This would go better in `$(BUILDTOOLS_OUTPUTDIR)`.

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.

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1525282378
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1525283190
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1525277218

From erikj at openjdk.org  Thu Mar 14 17:54:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Mar 2024 17:54:46 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <_1_d1zYvgoHoZgSf8nXoAFEFEJdV2L7SLQbL92845iU=.37d837ba-a3b1-4779-ad80-79fa9de6790e@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <_1_d1zYvgoHoZgSf8nXoAFEFEJdV2L7SLQbL92845iU=.37d837ba-a3b1-4779-ad80-79fa9de6790e@github.com>
Message-ID: <B2Ek5IbfIvIRWYrbDvo0nCz8n7NXVhUQD3m2mfSBYzM=.c660a437-8ad3-4623-a33e-a1ad5277aeb3@github.com>

On Thu, 14 Mar 2024 14:27:47 GMT, Severin Gehwolf <sgehwolf 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 33:
> 
>> 31: include Modules.gmk
>> 32: include Utils.gmk
>> 33: include ToolsJdk.gmk
> 
> This is probably no longer needed. I'll remove in a later update.

Yes, please do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1525288640

From weijun at openjdk.org  Thu Mar 14 18:10:42 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 18:10:42 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
 <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>
Message-ID: <sgHC9jvz_mQFWtYkX2rREXbGel4XBTzme7hu_4hxOIY=.d04a7e2c-286f-4c14-b9b7-aa5072a1cf37@github.com>

On Wed, 13 Mar 2024 19:53:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes to MBeanServerFileAccessController.java
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 29:
> 
>> 27:  * @enablePreview
>> 28:  * @summary Implement Subject.current and Subject.callAs using scoped values.
>> 29:  *      Need @enablePreview to use StructuredTaskScope.
> 
> jtreg throws a `ParseException` because I think it tries to interpret it as an `@enablePreview` action. Suggest enclosing it in double quotes.

Yes, I noticed that. Thanks.

> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 55:
> 
>> 53:         Subject.callAs(subject, () -> check(0, Subject.current(), "Duke"));
>> 54: 
>> 55:         // Observable in the same thread in ACC mode, but not in the SV mode
> 
> Should this comment actually say "Observable in a new platform thread in ACC mode, but not in the SV mode".

Yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1525308150
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1525308836

From aph at openjdk.org  Thu Mar 14 19:02:04 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 14 Mar 2024 19:02:04 GMT
Subject: RFR: JDK-8180450: secondary_super_cache does not scale well
Message-ID: <fzuKsUpfShtO_cgfnbZ3aSOdFBIjOV46MFXfgqBNC7w=.d9e0f27a-b834-42dd-8491-8f5be83a0fb5@github.com>

This PR is a redesign of subtype checking. 

The implementation of subtype checking in the HotSpot JVM is now twenty years old. There have been some performance-related bugs reported, and the only way to fix them is a redesign of the way it works.

So what's changed, so that the old design should be replaced?

Firstly, the computers of today aren't the computers of twenty years ago. It's not merely a matter of speed: the systems are much more parallel, both in the sense of having more cores and each core can run many instructions in parallel. Because of this, the speed ratio between memory accesses and the rate at which we can execute instructions has become wider and wider.

The most severe reported problem is to do with the "secondary supers cache". This is a 1-element per-class cache for interfaces (and arrays of interfaces). Unfortunately, if two threads repeatedly update this cache, the result is that a cache line ping-pongs between cores, causing a severe slowdown. 

Also, the linear search for an interface that is absent means that the entire list of interfaces has to be scanned. This plays badly with newer language features such as JEP 406, pattern matching for switch.

However, the computers of today can help us. The very high instruction-per-cycle rate of a Great Big Out-Of-Order (GBOOO) processor allows us to execute many of the instructions of a hash table lookup in parallel, as long as we avoid dependencies between instructions. 

The solution
------------

We use a hashed lookup of secondary supers. This is a 64-way hash table, with linear probing for collisions. The table is compressed, in that null entries are removed, and the resulting hash table fits into the same secondary supers array as today's unsorted array of secondary supers. This means that existing code in HotSpot that simply does a linear scan of the secondary supers array does not need to be altered.

We add a bitmap field to each Klass object. This bitmap contains an occupancy bit corresponding to each element of the hash table, with a 1 indicating element presence. As well as allowing the hash table to be decompressed, this bimap is used as a simple kind of Bloom Filter. To determine whether a superclass is present, we simply have to check a single bit in the bitmap. If the bit is clear, we know that the superclass is not present. If the bit is set, we have to do a little arithmetic and then consult the hash table.

It works like this:


       mov    sub_klass, [& sub_klass->_bitmap]
       mov    array_index, sub_klass
       shl    array_index, <hash code of class we're looking for>
  ?    jns    not_found 
  ?    popcnt array_index,array_index
  ?    mov    array_base, [& sub_klass->_secondary_supers]
  ?    cmp    super_klass, [array_base+array_index*8]
  ?    je     found


The popcount instruction returns the cardinality of a bitset. By shifting out the bits higher in number than the hash code of the element we're looking for, we leave only the lower bits. `popcount`, then, gives us the index of the element we're looking for.

If we don't get a match at the first attempt, we test the next bit in the bitset and jump to a fallback stub:


  ?    bt     sub_klass, <next hash code>
  ??   jae    not_found
  ??   ror    sub_klass, <hash code>
  ??   call   Stub::klass_subtype_fallback
  ??   je     found
  ??


Collisions are rare. Vladimir Ivanov did a survey of Java benchmark code, and it is very rare to see more than about 20 super-interfaces, and even that gives us a collision rate of only about 0.25.

The time taken for a positive lookup is somewhere between 3 - 6 cycles, or about 0.9 - 1.8 ns. This is a robust figure, confirmed across current AArch64 and x86 designs, and this rate can be sustained indefinitely. Negative lookups are slightly faster because there's usually no need to consult the secondary super cache, at about 3 - 5 cycles.

The current secondary super cache lookup is usually slightly faster than a hash table for positive lookups, at about 3 - 4 cycles, but it performs badly with negative lookups, and unless the class you're looking for is in the secondary super cache it performs badly as well. For example, a negative lookup in a class with 4 interfaces takes 10 - 47 cycles.

Limitations and disadvantages
-----------------------------

This PR is a subset of what is possible. It is only implemented for C2, in the cases where the superclass is a constant, known at compile time. Given that this is almost all uses of subtype checking, it's not really a restriction.

I would have liked to save the hashed interfaces list in the CDS archive file, but there are test cases for the Serviceability Agent that assume the interfaces are in the order in which they are declared. I think the tests are probably just wrong about this. For the same reason, I have to make copies of the interfaces array and sort the copies, rather than just using the same array at runtime.

I haven't removed the secondary super cache. It's still used by the interpreter and C2. 

In the future I'd like to delete the secondary super cache, but it is used in many places across the VM. Today is not that day.

Performance testing
-------------------

Hashing the secondary supers arrays takes a little time. I've added a perf counter for this, so you can see. It's only really a few milliseconds added to startup.

I have run Renaissance and SPECjvm, and whatever speed differences there may be are immeasurably small, down in the noise. The benchmark in this class allows you to isolate single instanceof invocations with various sets of secondary superclasses.

Finally
-------

Vladimir Ivanov was very generous with his time and his advice. He explained the problem and went into detail about his experiments, and shared with me his experimental code. This saved me a great deal of time in this work.

-------------

Commit messages:
 - Copyright dates
 - Merge branch 'JDK-8180450' of https://github.com/theRealAph/jdk into JDK-8180450
 - JDK-8180450: secondary_super_cache does not scale well
 - JDK-8180450: secondary_super_cache does not scale well
 - JDK-8180450: secondary_super_cache does not scale well
 - Merge branch 'JDK-8180450' of https://github.com/theRealAph/jdk into JDK-8180450
 - JDK-8180450: secondary_super_cache does not scale well
 - Comment typo
 - JDK-8180450: secondary_super_cache does not scale well
 - JDK-8180450: secondary_super_cache does not scale well
 - ... and 38 more: https://git.openjdk.org/jdk/compare/2482a505...a0677b71

Changes: https://git.openjdk.org/jdk/pull/18309/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18309&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8180450
  Stats: 1314 lines in 29 files changed: 1288 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/18309.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18309/head:pull/18309

PR: https://git.openjdk.org/jdk/pull/18309

From mchung at openjdk.org  Thu Mar 14 20:57:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Mar 2024 20:57:45 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
Message-ID: <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>

On Thu, 14 Mar 2024 14:24:57 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:
> 
>   Fix comment in autoconf file

> The updated patch uses a **build-only** `jlink` plugin, still called `--create-linkable-runtime` which is _a)_ added only at build time with `--add-modules` and _b)_ now generates the diff and prepares the image for runtime linking as before in one step. The code for this now lives in `src/jdk.jlink/build/classes`.

This patch introduces a new module `jdk.unsupported_jlink_runtime` .   `src/jdk.jlink` should only contain one module (see JEP 201).  If it ought to have another module, its source files should be placed under `src/$MODULE`.   

I would suggest to simplify it - drop the new module `jdk.unsupported_jlink_runtime` and simply include all its classes in `jdk.jlink` module; for example in `jdk.tools.jlink.internal.runtimelink` package to follow the existing jlink package name hierarchy.   This package can only be compiled when JDK is configured to build linkable images.  The build can simply invoke `jlink --create-linkable-runtime` and avoids all the setup to add exports to this build tool.  If jlink is running from a linkable image, --create-linkable-runtime` plugin should be disabled and hidden.   What do you think?

About the configure options, 

  --enable-keep-packaged-modules
                          enable keeping of packaged modules in jdk image [enabled]
  --enable-runtime-link-image
                          enable producing an image suitable for runtime linking [disabled]


If `--enable-runtime-link-image` is enabled, the JDK image does not include the packaged modules.  If `--enable-runtime-link-image --enable-keep-packaged-modules` are both enabled, it should probably fail?   @erikj79 should it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1998467918

From erikj at openjdk.org  Thu Mar 14 21:18:44 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Mar 2024 21:18:44 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
Message-ID: <SKolC1SQ7rvmB08teumZhfRUa0XKJ8zuylmAJsep7Jg=.0b356474-7e1d-4b0f-9a48-d4a9a72e2652@github.com>

On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> About the configure options,
> 
> ```
>   --enable-keep-packaged-modules
>                           enable keeping of packaged modules in jdk image [enabled]
>   --enable-runtime-link-image
>                           enable producing an image suitable for runtime linking [disabled]
> ```
> 
> If `--enable-runtime-link-image` is enabled, the JDK image does not include the packaged modules. If `--enable-runtime-link-image --enable-keep-packaged-modules` are both enabled, it should probably fail? @erikj79 should it?

That's a good question. I was pondering the logic myself during my last review, but didn't come to any good conclusion so didn't comment on it. The problem I think is that `--enable-keep-packaged-modules` is default enabled. I think when that option isn't explicitly set, the default needs to depend on the value of `--enable-runtime-link-image`. Setting both to enabled explicitly doesn't seem to make any sense, so that case should probably result in failure as you say.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1998496745

From clanger at openjdk.org  Thu Mar 14 21:59:54 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 14 Mar 2024 21:59:54 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v8]
In-Reply-To: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
Message-ID: <IGkgkob8lvI2h642AnVStJOe_UU6SHNtlsdm2eZid4s=.08105a6e-e49a-4d1f-921e-f9fce3864a68@github.com>

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

Christoph Langer 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:

 - Update module-info text
 - Merge branch 'master' into JDK-8325579
 - Indentation
 - Merge branch 'master' into JDK-8325579
 - Review feedback
 - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
 - Merge branch 'master' into JDK-8325579
 - Typo
 - Merge branch 'master' into JDK-8325579
 - Rename test and refine comment
 - ... and 2 more: https://git.openjdk.org/jdk/compare/584e58bb...10271159

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17797/files
  - new: https://git.openjdk.org/jdk/pull/17797/files/97299970..10271159

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17797&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17797&range=06-07

  Stats: 97262 lines in 1251 files changed: 15655 ins; 78153 del; 3454 mod
  Patch: https://git.openjdk.org/jdk/pull/17797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17797/head:pull/17797

PR: https://git.openjdk.org/jdk/pull/17797

From clanger at openjdk.org  Thu Mar 14 21:59:54 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 14 Mar 2024 21:59:54 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v7]
In-Reply-To: <pLld_-f0QJxH9-cT3Pyramf5CfMwEoEgxneb8Q7iF9Q=.6994ce78-de28-4fa4-a156-1f69b1ece385@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <r__SpoJaRXPAH-aJNSrMxetk4OkTGCILvAcDVRRxSxo=.53101fde-2aaa-4368-ba56-89167be8ad53@github.com>
 <QIfdwXrR8lPxYCESnBy6nxxfhAZCK_BfKJzNceSjjIU=.10a61f3e-8328-4f91-a3b0-1cb10fbd8a2f@github.com>
 <pLld_-f0QJxH9-cT3Pyramf5CfMwEoEgxneb8Q7iF9Q=.6994ce78-de28-4fa4-a156-1f69b1ece385@github.com>
Message-ID: <nzNSDxeBwSYqVbxCeFg9DL6_88hTAhUP3FXfVpTzyDo=.c7c6e17a-74c9-4f7e-b513-58aa074831de@github.com>

On Thu, 7 Mar 2024 17:38:24 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> src/java.naming/share/classes/module-info.java line 42:
>> 
>>> 40:  *         <br>The value of this environment property specifies the fully
>>> 41:  *         qualified class name of the socket factory used by the LDAP provider.
>>> 42:  *         This class must implement the javax.net.SocketFactory abstract class.
>> 
>> We need to mention here that `getDefault` method needs to be implemented by the provided socket factory class.
>> 
>>  Something like: `and provide an implementation of the static "getDefault()" method that returns an instance of the socket factory.`
>> The CSR needs to be updated too.
>
> Good point. I will amend that in both, source code and CSR.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1525530951

From dlutker at openjdk.org  Thu Mar 14 22:37:52 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Thu, 14 Mar 2024 22:37:52 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v3]
In-Reply-To: <AlklRqIwub9HSpD-GCYtj-DjpgVBqm3T0hg1P61zM-w=.871103d5-7753-42c7-a1d6-e2698a5d0731@github.com>
References: <AlklRqIwub9HSpD-GCYtj-DjpgVBqm3T0hg1P61zM-w=.871103d5-7753-42c7-a1d6-e2698a5d0731@github.com>
Message-ID: <3x5WJJ6ucLl3NNoBZjVf4y8xHtYX_aJ3LoEcOia1w3s=.ced7d132-31ba-49e0-8342-fec799a65ef2@github.com>

> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`

Dan Lutker has updated the pull request incrementally with two additional commits since the last revision:

 - Remove extra whitespace
 - Simplify check for coreutils single executable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17798/files
  - new: https://git.openjdk.org/jdk/pull/17798/files/3f42d85e..1df8876c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17798&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17798&range=01-02

  Stats: 17 lines in 2 files changed: 0 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17798/head:pull/17798

PR: https://git.openjdk.org/jdk/pull/17798

From dlutker at openjdk.org  Thu Mar 14 22:47:39 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Thu, 14 Mar 2024 22:47:39 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v3]
In-Reply-To: <JkVuqLoEc1BfqERvENUlMVHSH6gw_P0W-htWNLwSOSQ=.4099a86a-4a7f-4549-a3ae-57f41881369b@github.com>
References: <AlklRqIwub9HSpD-GCYtj-DjpgVBqm3T0hg1P61zM-w=.871103d5-7753-42c7-a1d6-e2698a5d0731@github.com>
 <gRvWyWAO36NyRtvFmp0HAAfkUlHoFqSEw4Vg2MqAv5A=.62a83b44-27b1-4168-a45b-cc33afe30d78@github.com>
 <qb6VOB5kOO1J_JnfhrHDfA0FIUNcmUY7mOv6diO7VII=.4c12cc9a-9698-4b86-a830-0dfe90dc6b59@github.com>
 <rad9Ho7TpAepwoIdW-bZzHcGRd8GiuSqfw8pKEuF_NY=.f8246210-c0ce-4b76-ac63-111433f8ef32@github.com>
 <JvvTml2_-aZIJV23sl5ag4WqMR98aOwEhmAVecw1Pu4=.d09a6d5d-a917-4e8d-98ff-398cf901b018@github.com>
 <8bH-nWhM3TbK68Pt5wOjoPzc5bc81VQ-rY3dMBeYE3o=.ee389cb7-46d5-48e6-a547-3cf9fa07b0ff@github.com>
 <Z6Fyk6LLXFcO8e-qSOOXsTbMTm6KVR-H5aqDbbwNTmc=.dff818a2-0816-4190-ac11-01773704318a@github.com>
 <46wD8xd0OIGGfHW5aexaJ7fzHSlUIxF6RkQnaCrrRn8=.6f968e71-4bf2-4d47-8d10-6acec20596bd@github.com>
 <JkVuqLoEc1BfqERvENUlMVHSH6gw_P0W-htWNLwSOSQ=.4099a86a-4a7f-4549-a3ae-57f41881369b@github.com>
Message-ID: <PIRIABmfzVHRrM0TNCF_Ar7jvWJjhrLC5OE-xudawoM=.ebfd0cc1-7521-4600-89b6-ae9adb8a72f3@github.com>

On Tue, 13 Feb 2024 22:02:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Any reason not to use [exesanity_SimpleNativeLauncher](https://github.com/openjdk/jdk/blob/628cd8a489fd54db18204c3bbaf4339d7ab5e9d6/test/jdk/native_sanity/simplenativelauncher/exesanity_SimpleNativeLauncher.c) or [exeBasicSleep](https://github.com/openjdk/jdk/blob/628cd8a489fd54db18204c3bbaf4339d7ab5e9d6/test/jdk/java/lang/ProcessBuilder/exeBasicSleep.c) in all cases?
>
> I'd be ok with exeBasicSleep; (currently only used on Windows and if its been built by the make files).
> Note the discovery mechanism used in Basic.java `initSleepPath()` to locate and identify the path where its built or to fallback to the OS sleep.

I opted to just check for coreutils existing as a signal that it was single executable. With Fedora and AL2023 coreutils-single package this will work. Some other distro could choose to use the symlink version of this or exclude sleep from coreutils-single in the future, but we can deal with that if it every actually comes up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1525573046

From dlutker at openjdk.org  Thu Mar 14 22:55:07 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Thu, 14 Mar 2024 22:55:07 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v4]
In-Reply-To: <AlklRqIwub9HSpD-GCYtj-DjpgVBqm3T0hg1P61zM-w=.871103d5-7753-42c7-a1d6-e2698a5d0731@github.com>
References: <AlklRqIwub9HSpD-GCYtj-DjpgVBqm3T0hg1P61zM-w=.871103d5-7753-42c7-a1d6-e2698a5d0731@github.com>
Message-ID: <2Est7log7JydEil5ZjlXng9j4CTwoKh_RnJ8oEaf-cE=.32bb3732-14cb-406b-9e6f-f90c6f7ec805@github.com>

> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`

Dan Lutker has updated the pull request incrementally with one additional commit since the last revision:

  Fix path exists check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17798/files
  - new: https://git.openjdk.org/jdk/pull/17798/files/1df8876c..3464b664

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17798&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17798&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17798/head:pull/17798

PR: https://git.openjdk.org/jdk/pull/17798

From ihse at openjdk.org  Thu Mar 14 23:12:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Mar 2024 23:12:45 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
Message-ID: <b0-Uv4vsIw1i58-7T37WX7wJIVrolMZe0S_kMxYu2mM=.d239cf2a-ce80-40b3-9d62-f66b21d1cf59@github.com>

On Thu, 14 Mar 2024 14:24:57 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:
> 
>   Fix comment in autoconf file

Maybe we need a tristate instead, "normal image only", "normal image + jmods", "linkable image only"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1998625567

From bchristi at openjdk.org  Thu Mar 14 23:23:07 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 14 Mar 2024 23:23:07 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@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:

  further tweaks to reachability

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/603ff4dc..4d6f1dce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=11-12

  Stats: 7 lines in 1 file changed: 3 ins; 1 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 jpai at openjdk.org  Fri Mar 15 01:29:37 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Mar 2024 01:29:37 GMT
Subject: RFR: 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: <2aAHIoub3_KoC-XLtG-4TRhGgzb94aLiHMM2IHvSifM=.1f1e6684-b8a6-41a0-b97a-3e537b3c8578@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.

Hello Mandy, this change to use the underlying cause of `ResolutionExcepion` and `FindException` when reporting the error message, appears OK to me.

I didn't know if `ResolutionException` too wraps the actual cause underneath, so I looked around a few JBS issues where `ResolutionException` was reported as being thrown and it does appear that the actual cause lies underneath. So I think this change is fine.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18308#pullrequestreview-1937969339

From duke at openjdk.org  Fri Mar 15 05:41:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 15 Mar 2024 05:41:42 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v12]
In-Reply-To: <o4M6BNaHo6HVGBw3hkUU3fd_YTqsKAyTB9_ivc5hOmg=.11ce3841-2429-4cfa-bcf4-b489aec2b4aa@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <xJrQp4a9X7qrIk206tLNmwsW2oLhU5xJ8XwNFaJ8AnI=.1060af87-ef5c-4c60-83ed-0fe5c6a1737f@github.com>
 <dgqVm4t827DE1kmTKOdWYjN2OW5XvNaPGrTyvM7gkRg=.ac646409-9627-486d-ad55-2ebc2ede5d35@github.com>
 <hMpXKlvKChnXBkd6ZjSN6169MmnFWYCH54gTCXbnhCg=.24e7fa04-0ecc-45a7-9223-bca284cf1d82@github.com>
 <NgEUBKEmMwysZvGY_KZskR-kuwR0avt0GezzrDQU2iA=.96590a6e-c22d-4ac6-9a48-94cfad2ad8a9@github.com>
 <zp4MyiJc4Bmgqytk-MVOPswHbELYgKkPp60S62x6dtw=.06a713f2-7f6c-4edd-8254-e347700788e6@github.com>
 <o4M6BNaHo6HVGBw3hkUU3fd_YTqsKAyTB9_ivc5hOmg=.11ce3841-2429-4cfa-bcf4-b489aec2b4aa@github.com>
Message-ID: <1fp-bprzsormET7nxMad9D8DHMOGSVedy4UJfWo-vQU=.8ca3fd04-d43e-4c5d-924f-f5792b7df81f@github.com>

On Wed, 13 Mar 2024 15:43:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Relying on the upper bounds check of `charAt` doesn't work well with the `CharArraySequence` whose `charAt` deliberately does not throw an IIOBE if the array is longer than the provided length, ie, it'll look at chars beyond the provided range. The examples I tested still end up as a NFE, but it's clear from the cause that we're running past the length:
>> 
>> jshell> new BigDecimal(new char[] { '-', '1', 'e'}, 0, 1);
>> |  Exception java.lang.NumberFormatException
>> |        at BigDecimal.<init> (BigDecimal.java:754)
>> |        at BigDecimal.<init> (BigDecimal.java:543)
>> |        at BigDecimal.<init> (BigDecimal.java:518)
>> |        at (#4:1)
>> |  Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3
>> |        at BigDecimal$CharArraySequence.charAt (BigDecimal.java:559)
>> |        at BigDecimal.parseExp (BigDecimal.java:772)
>> |        at BigDecimal.<init> (BigDecimal.java:619)
>> |        ...
>> 
>> Baseline/expected:
>> 
>> jshell> new BigDecimal(new char[] { '-', '1', 'e'}, 0, 1);
>> |  Exception java.lang.NumberFormatException: No digits found.
>> |        at BigDecimal.<init> (BigDecimal.java:635)
>> |        at BigDecimal.<init> (BigDecimal.java:518)
>> |        at (#1:1)
>> 
>> Having a check on `len > 0` is more robust - and I'd be surprised if avoiding a redundant check on the loop entry is affecting performance?
>
>> Relying on the upper bounds check of `charAt` doesn't work well with the `CharArraySequence` whose `charAt` deliberately does not throw an IIOBE if the array is longer than the provided length, ie, it'll look at chars beyond the provided range. The examples I tested still end up as a NFE, but it's clear from the cause that we're running past the length:
>> 
>> ```
>> jshell> new BigDecimal(new char[] { '-', '1', 'e'}, 0, 1);
>> |  Exception java.lang.NumberFormatException
>> |        at BigDecimal.<init> (BigDecimal.java:754)
>> |        at BigDecimal.<init> (BigDecimal.java:543)
>> |        at BigDecimal.<init> (BigDecimal.java:518)
>> |        at (#4:1)
>> |  Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3
>> |        at BigDecimal$CharArraySequence.charAt (BigDecimal.java:559)
>> |        at BigDecimal.parseExp (BigDecimal.java:772)
>> |        at BigDecimal.<init> (BigDecimal.java:619)
>> |        ...
>> ```
>> 
>> Baseline/expected:
>> 
>> ```
>> jshell> new BigDecimal(new char[] { '-', '1', 'e'}, 0, 1);
>> |  Exception java.lang.NumberFormatException: No digits found.
>> |        at BigDecimal.<init> (BigDecimal.java:635)
>> |        at BigDecimal.<init> (BigDecimal.java:518)
>> |        at (#1:1)
>> ```
>> 
>> Having a check on `len > 0` is more robust - and I'd be surprised if avoiding a redundant check on the loop entry is affecting performance?
> 
> If the likely error/boundary conditions change, those changed conditions should be added to the regression tests.

Thanks for pointing out this BUG. I hadn't considered it before. I added a boundary check in the CharArraySequence#charAt method and added regression testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1525782394

From clanger at openjdk.org  Fri Mar 15 06:40:40 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 15 Mar 2024 06:40:40 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: <pifXUv8AYzbfmVZ45hlfSfJ250bjyy-4PGsbKupleJM=.f7240984-56cc-4606-bb14-c1a35cbc5c35@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <Gfc5nSHywS0SkSv33Bgu9htQapPQgbH1SAXmjtU6UIA=.82fe269b-3a6a-40cb-b77d-c878b4d12210@github.com>
 <rNceCTggSqL-bJVTTj4X4HEzVsmanlKNIhrbrPCf-g0=.395f0162-d5d9-4840-98dd-199def542269@github.com>
 <RaKJiTLW6li4_S5-HsffyRqDNOwd-vFCkLH8b0_dD1k=.4bff88c5-04f4-498d-af4d-14c437bb369a@github.com>
 <QZU5goh25uLufkMD76XbPw1yrRDok-cl995sUZ602pI=.536873ab-d1bb-457e-88a9-d180f3720f8b@github.com>
 <ysYpm97ehjB1vmPga-F6V81vmdDwbQ_s-67oNUKbmrQ=.601fadce-df07-4a25-8559-819025c1a7ce@github.com>
 <rxsscNAo3wJCLQ-Zr3HSAN2PdTNdwMe9fIOiYNUzrSg=.9cde53d2-43f0-4b35-93d2-52e7f0820683@github.com>
 <36-uLVrsexBrgtOwUkfGEY9DYq7kVtZG58b_bQoBe0s=.49a0d4b1-e141-4863-bc9f-80a8bd7b8196@github.com>
 <pifXUv8AYzbfmVZ45hlfSfJ250bjyy-4PGsbKupleJM=.f7240984-56cc-4606-bb14-c1a35cbc5c35@github.com>
Message-ID: <l7znsekW3BqCqexVybDV1UgOwcea85Oyj3Oi6GUY7vs=.ad1381a0-0025-412b-999c-5c8c3f1f40ee@github.com>

On Thu, 7 Mar 2024 17:37:59 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > > Thanks for exploring the possibility of improving tracebility of test invocations to reported bugs.
> > > >
> > 
> > 
> > I've given this test change a second thought, maybe you can try to separate the test into two separate test classes? One possibility to avoid duplicating code and have a separate test for each bug is to introduce a base test class that will contain the common functionality for [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) and [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) tests.
> 
> I will have a look.

I stared at the test once more but it still doesn't make sense to me to split it into multiple tests because the purposes of each test run intertwine, as stated [above](https://github.com/openjdk/jdk/pull/17797#issuecomment-1959271452). The only thing that would really make sense is to rename from LdapSSLHandshakeFailureTest to LdapSSLHandshakeTest since it in fact tests various variations of the SSL handshaking.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1999031201

From alanb at openjdk.org  Fri Mar 15 06:42:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Mar 2024 06:42:38 GMT
Subject: RFR: 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: <PInFXtyjI67Qkr0q6olVsf07kvYDziMPN1W43Zwpy10=.0842eda2-82bf-4853-9ca5-1178ce303a64@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.

Tests that depend on exception messages can be problematic but this one is easy to change if/when the exception message changes.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18308#pullrequestreview-1938210400

From clanger at openjdk.org  Fri Mar 15 06:44:42 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 15 Mar 2024 06:44:42 GMT
Subject: RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718 [v2]
In-Reply-To: <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>
 <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>
Message-ID: <ISXiplfASW3-h_sNJnJvxXE2EoxNlnfjRU9zPm_gEfc=.1f8c9e2a-5cd0-4fa0-95c7-b856230eabe3@github.com>

On Wed, 13 Mar 2024 14:23:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Generate large strings in parameter generator methods
>
> I was thinking more something like
> 
>         var tenMillionBlanks = tenMillionBlanks();
> 
> and similarly for `tenMillionsZeros`, thus maintaining the `private static` (but not `final` ;-) ) methods as in your previous commit.
> But if you are happy with the last commit, it's OK as well.
> 
> Can you please add the bug id to `@bug` and correct the typo, as suggested [here](https://github.com/openjdk/jdk/pull/18264#issuecomment-1994382507)?
> 
> Otherwise looks fine.

Thanks, @rgiulietti for reviewing this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1999033956

From clanger at openjdk.org  Fri Mar 15 06:44:42 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 15 Mar 2024 06:44:42 GMT
Subject: Integrated: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <Zdts3gVXfAX1LBJ09-41hqcb1LQEeyQ6nkICxVH7mZM=.5f79d47f-e0c3-4ee9-a702-0fc558eb5a3f@github.com>

On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

This pull request has now been integrated.

Changeset: 128e60a2
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/128e60a29f1bd1e1fbe165ac382107070858ecc6
Stats:     650 lines in 1 file changed: 343 ins; 269 del; 38 mod

8328037: Test java/util/Formatter/Padding.java has unnecessary high heap requirement after JDK-8326718

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/18264

From dfuchs at openjdk.org  Fri Mar 15 09:54:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 15 Mar 2024 09:54:40 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v8]
In-Reply-To: <IGkgkob8lvI2h642AnVStJOe_UU6SHNtlsdm2eZid4s=.08105a6e-e49a-4d1f-921e-f9fce3864a68@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <IGkgkob8lvI2h642AnVStJOe_UU6SHNtlsdm2eZid4s=.08105a6e-e49a-4d1f-921e-f9fce3864a68@github.com>
Message-ID: <5B7YuBDQPmiPPI35tEx3sEJjhCaYEzZWpLbI9BgIhtk=.3259a5a9-10df-4c66-8e89-9c810b574177@github.com>

On Thu, 14 Mar 2024 21:59:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer 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:
> 
>  - Update module-info text
>  - Merge branch 'master' into JDK-8325579
>  - Indentation
>  - Merge branch 'master' into JDK-8325579
>  - Review feedback
>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>  - Merge branch 'master' into JDK-8325579
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/5d79093e...10271159

LGTM. I haven't looked at the updated test too closely.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17797#pullrequestreview-1938532665

From sgehwolf at openjdk.org  Fri Mar 15 09:57:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Mar 2024 09:57:45 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <SKolC1SQ7rvmB08teumZhfRUa0XKJ8zuylmAJsep7Jg=.0b356474-7e1d-4b0f-9a48-d4a9a72e2652@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
 <SKolC1SQ7rvmB08teumZhfRUa0XKJ8zuylmAJsep7Jg=.0b356474-7e1d-4b0f-9a48-d4a9a72e2652@github.com>
Message-ID: <W_aNdzFY9hXt5Sp4kiagTC8Ea2pXF_NTPh_0Lkm23kI=.c71371ad-7ae5-4303-a915-1c664b09d1da@github.com>

On Thu, 14 Mar 2024 21:16:04 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> About the configure options,
> 
> ```
>   --enable-keep-packaged-modules
>                           enable keeping of packaged modules in jdk image [enabled]
>   --enable-runtime-link-image
>                           enable producing an image suitable for runtime linking [disabled]
> ```
> 
> If `--enable-runtime-link-image` is enabled, the JDK image does not include the packaged modules.

That's not true. Right now `--enable-runtime-link-image` modifies how the `lib/modules` image looks like (adds a bunch of extra resources). That's it. It doesn't modify the setup of packaged modules. Since it doesn't change them, I don't see a reason to not include them in the image. The difference is that if you do `rm -rf images/jdk/jmods` you can still run `jlink` while with a not runtime link enabled image, you cannot. `jmods` become truly optional. Why is that a problem?

> If `--enable-runtime-link-image --enable-keep-packaged-modules` are both enabled, it should probably fail? @erikj79 should it?

It seems orthogonal to me whether or not packaged modules are enabled or not. If they are indeed there, the regular jlink happens based on packaged modules (without specifying a module path) as happens today. When there is no module path that includes `java.base`, and we have a runtime enabled image. The runtime image based link is performed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1999307995

From aph at openjdk.org  Fri Mar 15 10:44:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 15 Mar 2024 10:44:38 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v3]
In-Reply-To: <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
 <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
Message-ID: <HQwXC7q8C0mYKGg0B3EG2ac6UbLSoLgcPmAylMmKtLk=.c39f9b12-70d7-4b89-a9d9-489444807f45@github.com>

On Thu, 14 Mar 2024 14:04:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
>> 
>> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
>> 
>> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
>> 
>> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mark's suggestion - no need for os.maxMemory

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18290#pullrequestreview-1938630418

From sgehwolf at openjdk.org  Fri Mar 15 10:55:48 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Mar 2024 10:55:48 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
Message-ID: <uK5VYn9y1gI0QrkBbQjtTrIrB8YNiILoTGEaGobjvpg=.1da1d444-81a8-4473-925a-1eae1d14effd@github.com>

On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > The updated patch uses a **build-only** `jlink` plugin, still called `--create-linkable-runtime` which is _a)_ added only at build time with `--add-modules` and _b)_ now generates the diff and prepares the image for runtime linking as before in one step. The code for this now lives in `src/jdk.jlink/build/classes`.
> 
> This patch introduces a new module `jdk.unsupported_jlink_runtime` . `src/jdk.jlink` should only contain one module (see JEP 201). If it ought to have another module, its source files should be placed under `src/$MODULE`.

Got it, thanks. I guess it would be the first build-only module, would it?

> I would suggest to simplify it - drop the new module `jdk.unsupported_jlink_runtime` and simply include all its classes in `jdk.jlink` module; for example in `jdk.tools.jlink.internal.runtimelink` package to follow the existing jlink package name hierarchy. This package can only be compiled when JDK is configured to build linkable images. The build can simply invoke `jlink --create-linkable-runtime` and avoids all the setup to add exports to this build tool. If jlink is running from a linkable image, --create-linkable-runtime` plugin should be disabled and hidden. What do you think?

I'm a bit confused. Wasn't the intention to make "creating a linkable runtime image" a build only decision and make the relevant infrastructure classes build-only artefacts? Maybe I misunderstood what "internal option" means exactly and what the minimal requirements of "make it internal" are.

Let me paraphrase what I think you mean by the proposed simplification:

## Case 1: `--enable-runtime-link-image == disabled` 

The `jdk.jlink` module doesn't include classes for creating a runtime linkable image, because `jdk.tools.jlink.internal.runtimelink` classes and resources get excluded during compilation. We probably need to do some magic to not list the plug-in in `module-info.java` in that case.

## Case 2: `--enable-runtime-link-image == enabled`

The `jdk.jlink` module does include classes for creating a runtime linkable image because the JDK build needs those at JDK build time and invokes `--create-linkable-runtime` in order to produce the jimage which is later suitable for linking from the runtime image. It needs to distinguish between `jlink` invoked at JDK build time and other cases (such as jlink running from packaged modules, or jlink based on the runtime image later at runtime). Once the JDK is shipped, it needs to disable the plugin (since the classes are going to be part of the jimage).

In summary, we'd have a somewhat less clunky way to actually produce a linkable runtime at JDK build time. However,  the added complexity and divergence for cases 1 and 2 using that approach seem less than ideal too. Perhaps I'm missing something, though. Thoughts?

To me, going the build-only module approach seemed the cleanest as we only need some magic to enable the plugin at JDK build-time, but don't need to worry about divergence of jdk.jlink module otherwise. The difference of the `jdk.jlink` modules is the absolute minimum: Tracking files for natives/configs and anti-delta diffs to the packaged modules. Since the classes/plugins are separate from `jdk.jlink` and the extra module isn't part of the JDK modules to be shipped, we cover the case of users not having any way to create a linkable runtime with only the compiled JDK. Using the build-only module approach doesn't care whether or not it's a `--enable-runtime-link-image` produced JDK at runtime.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1999404981

From msheppar at openjdk.org  Fri Mar 15 11:01:38 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 15 Mar 2024 11:01:38 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v3]
In-Reply-To: <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
 <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
Message-ID: <uDl8cn3N31ayeZJYwRush0BQALUGruUxhaV1gPyIOaY=.223aa570-04c4-4314-ab33-5b162043ded0@github.com>

On Thu, 14 Mar 2024 14:04:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
>> 
>> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
>> 
>> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
>> 
>> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mark's suggestion - no need for os.maxMemory

maybe ask the question: why does the test need 2GB ?  Would 1Gb suffice and that would be within the allocation limits for 32 bit architectures virtual address space.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18290#issuecomment-1999413347

From jpai at openjdk.org  Fri Mar 15 11:32:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Mar 2024 11:32:39 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v3]
In-Reply-To: <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
 <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
Message-ID: <kUXevdqlyQr_TJbH4F46yL1MQQdy1k00hJTnIwIXEmY=.006f9130-b5b9-4c71-8c2b-2883c44efd5a@github.com>

On Thu, 14 Mar 2024 14:04:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
>> 
>> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
>> 
>> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
>> 
>> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mark's suggestion - no need for os.maxMemory

Hello Mark,

> maybe ask the question: why does the test need 2GB ? Would 1Gb suffice and that would be within the allocation limits for 32 bit architectures virtual address space.

The reason why 2GB is needed in this test is explained in https://bugs.openjdk.org/browse/JDK-8285386.

I see that Andrew (and previously Daniel) have approved this change and the updated version checks only for `vm.bits == 64` as suggested by you. If you think the current form of the PR looks good, then I'll go ahead and integrate this - since I don't plan to investigate an ideal heap size for running this on 32 bit VMs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18290#issuecomment-1999463552

From duke at openjdk.org  Fri Mar 15 11:34:48 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 15 Mar 2024 11:34:48 GMT
Subject: RFR: JDK-8326951 Missing @since Tags
Message-ID: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>

I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class

-------------

Commit messages:
 - fix rest of private/public since tags
 - fix PrintStream:write:(byte[]) since tag
 - Merge branch 'openjdk:master' into add-missing-since-tags
 - added missing @ since tags to multiple methods and constructors following bug report JDK-8326951

Changes: https://git.openjdk.org/jdk/pull/18055/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326951
  Stats: 19 lines in 17 files changed: 7 ins; 10 del; 2 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 duke at openjdk.org  Fri Mar 15 11:34:49 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 15 Mar 2024 11:34:49 GMT
Subject: RFR: JDK-8326951 Missing @since Tags
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <hsyr1yMaLY8vF9TS_rpj_wJQUCaqSk1n0gPyJ-ufCW0=.0701e6a2-df45-4486-b6bf-39be265dce89@github.com>

On Thu, 29 Feb 2024 09:45:35 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class

`/covered`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18055#issuecomment-1988621229

From msheppar at openjdk.org  Fri Mar 15 11:47:39 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 15 Mar 2024 11:47:39 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v3]
In-Reply-To: <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
 <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
Message-ID: <SSixLF44N4AELy90SknBwynkEq7vlu1zkZ6qAQ1ZQTQ=.0bcd3234-55cb-446d-b705-8002817f9959@github.com>

On Thu, 14 Mar 2024 14:04:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
>> 
>> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
>> 
>> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
>> 
>> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mark's suggestion - no need for os.maxMemory

Marked as reviewed by msheppar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18290#pullrequestreview-1938750496

From msheppar at openjdk.org  Fri Mar 15 11:47:39 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 15 Mar 2024 11:47:39 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v3]
In-Reply-To: <kUXevdqlyQr_TJbH4F46yL1MQQdy1k00hJTnIwIXEmY=.006f9130-b5b9-4c71-8c2b-2883c44efd5a@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
 <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
 <kUXevdqlyQr_TJbH4F46yL1MQQdy1k00hJTnIwIXEmY=.006f9130-b5b9-4c71-8c2b-2883c44efd5a@github.com>
Message-ID: <_vfAK6oNa5KSROnJll_4_MW-02y6FYKYgzO74g-MJnM=.2bf5470c-344a-461f-9fa2-3e466cb94dfc@github.com>

On Fri, 15 Mar 2024 11:30:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The reason why 2GB is needed in this test is explained in https://bugs.openjdk.org/browse/JDK-8285386.

ok thanks ... i'll re-read

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18290#issuecomment-1999485205

From jpai at openjdk.org  Fri Mar 15 12:03:43 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Mar 2024 12:03:43 GMT
Subject: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap [v3]
In-Reply-To: <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
 <WsVydolDFF7jBQcgH9TYJY0FoN49TpImzVD0u3WVfM4=.f7c10e5c-ff85-4c32-b9fa-f69c1953d324@github.com>
Message-ID: <1NKIbrcAK3_AM-Y3riI6btBArC6p0ynNEiZ7Z8rZyaE=.dbcd3f9c-b9d4-4b31-a689-4b31c719c3a2@github.com>

On Thu, 14 Mar 2024 14:04:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
>> 
>> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
>> 
>> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
>> 
>> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mark's suggestion - no need for os.maxMemory

Thank you Mark, Daniel and Andrew for the reviews. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18290#issuecomment-1999508183

From jpai at openjdk.org  Fri Mar 15 12:03:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Mar 2024 12:03:44 GMT
Subject: Integrated: 8328066: WhiteBoxResizeTest failure on linux-x86: Could
 not reserve enough space for 2097152KB object heap
In-Reply-To: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
References: <tSagJ53Ptcmxh89wJkj-XY-yNDwZwB6L8Va9qAz7BfU=.0d93d1e1-11a9-48af-9a75-eb7082f46468@github.com>
Message-ID: <rEs-3e3P8HofOvhSo8q9XfkHa0RFNScfqs0VrLh95e8=.fb22c185-bf75-4da7-966f-67c8f891996a@github.com>

On Thu, 14 Mar 2024 04:11:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address https://bugs.openjdk.org/browse/JDK-8328066?
> 
> The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, the failure was observed on linux-86 instance on a GitHub jobs run. 
> 
> The commit in this PR proposes to add relevant `@requires` so that the test is only run on 64 bit VM and expects the `os.maxMemory` to be > 2G.
> 
> The change has been tested on a linux-x86 run in GitHub actions job, plus even on local and CI 64 bit VM environments. No failures have been noticed.

This pull request has now been integrated.

Changeset: dde519dc
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dde519dc2180742c119ac07221c2a149b9f06c18
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8328066: WhiteBoxResizeTest failure on linux-x86: Could not reserve enough space for 2097152KB object heap

Reviewed-by: dfuchs, aph, msheppar

-------------

PR: https://git.openjdk.org/jdk/pull/18290

From jlahoda at openjdk.org  Fri Mar 15 13:03:54 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 15 Mar 2024 13:03:54 GMT
Subject: RFR: 8327839: Crash with unboxing and widening primitive
 conversion in switch
In-Reply-To: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>
References: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>
Message-ID: <ThmGqqoRubmPyReQEmJxRfAdWadesOKBdwAYNFMbbt0=.86a7fc70-2f88-4d80-9bd2-8c5fcd13ad16@github.com>

On Tue, 12 Mar 2024 14:06:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug.

Looks reasonable to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18236#pullrequestreview-1938900922

From ihse at openjdk.org  Fri Mar 15 14:53:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Mar 2024 14:53:33 GMT
Subject: RFR: 8328074: Add jcheck whitespace checking for assembly files
 [v4]
In-Reply-To: <LDHFfoNVIbxCujeYMWs28J7pzyoZnhAYrDd7To_1Oug=.2c6d6327-4de4-42d6-9575-cd81c24b2fae@github.com>
References: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
 <LDHFfoNVIbxCujeYMWs28J7pzyoZnhAYrDd7To_1Oug=.2c6d6327-4de4-42d6-9575-cd81c24b2fae@github.com>
Message-ID: <d0izgnnlwyEaEK3-pOveSzPlVnT_b7MX_DkJPdRbE_A=.faae5836-8fe0-48ee-aea1-5b76800992fe@github.com>

On Wed, 13 Mar 2024 11:59:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the ongoing effort to enable jcheck whitespace checking to all text files, it is now time to address assembly (.S) files. The hotspot assembly files were fixed as part of the hotspot mapfile removal, so only a single incorrect jdk library remains.
>> 
>> The main issue with `libjsvml` was inconsistent line starts, sometimes using tabs. I used the `expand` unix command line tool to replace these with spaces.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make all ALIGN/.align aligned

Maybe someone in Hotspot wants to take a look?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18268#issuecomment-1999834049

From sgehwolf at openjdk.org  Fri Mar 15 15:19:17 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Mar 2024 15:19:17 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v21]
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: <zLp_bBwO1X5tmnnKaLKzcZJ9KdlAo-11G7xXflih53k=.970ec66c-6ec4-4d74-85c5-b55cdb0e7e40@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 two additional commits since the last revision:

 - Fix comment.
 - Review feedback and Windows build fix (FixPath)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/1fe6161b..2ea9cab8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=19-20

  Stats: 16 lines in 1 file changed: 6 ins; 0 del; 10 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 sviswanathan at openjdk.org  Sat Mar 16 22:18:13 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 16 Mar 2024 22:18:13 GMT
Subject: RFR: 8328074: Add jcheck whitespace checking for assembly files
 [v4]
In-Reply-To: <LDHFfoNVIbxCujeYMWs28J7pzyoZnhAYrDd7To_1Oug=.2c6d6327-4de4-42d6-9575-cd81c24b2fae@github.com>
References: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
 <LDHFfoNVIbxCujeYMWs28J7pzyoZnhAYrDd7To_1Oug=.2c6d6327-4de4-42d6-9575-cd81c24b2fae@github.com>
Message-ID: <AB2ZOJJRuFA2cl6bCCbheAmXIb3XqsumpH3RgW_cAdI=.7a0529a5-75da-4983-81a9-e3958ac4f97e@github.com>

On Wed, 13 Mar 2024 11:59:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the ongoing effort to enable jcheck whitespace checking to all text files, it is now time to address assembly (.S) files. The hotspot assembly files were fixed as part of the hotspot mapfile removal, so only a single incorrect jdk library remains.
>> 
>> The main issue with `libjsvml` was inconsistent line starts, sometimes using tabs. I used the `expand` unix command line tool to replace these with spaces.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make all ALIGN/.align aligned

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18268#pullrequestreview-1940824156

From aturbanov at openjdk.org  Sat Mar 16 22:18:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 16 Mar 2024 22:18:23 GMT
Subject: RFR: 8327839: Crash with unboxing and widening primitive
 conversion in switch
In-Reply-To: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>
References: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>
Message-ID: <FhCxqLw_lwmJ-0F4X2MXwTogSWyaGgkYT9e18IuWr0I=.2af6c97c-6308-489e-a9c7-4237f583c709@github.com>

On Tue, 12 Mar 2024 14:06:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug.

test/langtools/tools/javac/patterns/PrimitivePatternsSwitch.java line 121:

> 119:         assertEquals(Float.MAX_VALUE, testUnboxingAndWideningFloat(Float.MAX_VALUE));
> 120:         assertEquals(Float.MAX_VALUE, testUnboxingAndWideningFloatExplicitCast(Float.MAX_VALUE));
> 121:         assertEquals(42f, testUnboxingAndWideningLong(42l));

Suggestion:

        assertEquals(42f, testUnboxingAndWideningLong(42L));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18236#discussion_r1527165787

From ihse at openjdk.org  Sat Mar 16 22:20:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 16 Mar 2024 22:20:51 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: <rgKpveCfonVCT7TsHXysUeDBuYrb28aW0QRhlt1P6Lw=.6cca9703-7335-42b7-8d8b-d871b3e54e55@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

Keep it for a bit more, bot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-2000843635

From smarks at openjdk.org  Sat Mar 16 22:23:30 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 16 Mar 2024 22:23:30 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
Message-ID: <BegquHhvEmYg4wlVFWgBCNOVaXWJzA0Nej6mfgNOzMM=.aae81ac4-4c34-49ac-b1d4-edd36de36bb8@github.com>

On Thu, 14 Mar 2024 23:23:07 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:
> 
>   further tweaks to reachability

src/java.base/share/classes/java/lang/ref/Reference.java line 402:

> 400:      * method is called, the garbage collector may already be in the process of
> 401:      * (or already completed) clearing and/or enqueueing this reference.
> 402:      *

Either this is an extra blank line, or you need a `<p>` here.

src/java.base/share/classes/java/lang/ref/Reference.java line 496:

> 494:      * Actions in a thread prior to calling
> 495:      * {@code enqueue} <b><i>successfully</i></b>
> 496:      * <a href="{@docRoot}/java.base/java/util/concurrent/package-summary.html#MemoryVisibility"><i>happen-before</i></a>

Editorial. The text here says

> Actions in a thread prior to calling `enqueue` successfully _happen-before_ the reference is removed...

This could be confusing, because "successfully" might be read to modify "happen-before". This raises questions such as "Is it possible for something to happen-before unsuccessfully?" Of course you want "successfully" to modify "enqueue" because you're relying on the definition of "successful" given previously. Suggest rewording:

> Actions in a thread prior to successful calls to `enqueue` _happen-before_ the reference is removed...

src/java.base/share/classes/java/lang/ref/package-info.java line 127:

> 125:  * thread prior to a {@link Reference#reachabilityFence Reference.reachabilityFence(x)}
> 126:  * <i>happen-before</i> cleanup code for {@code x} runs on the cleaner thread.
> 127:  *

Extra blank line or need `<p>`.

src/java.base/share/classes/java/lang/ref/package-info.java line 146:

> 144:  *
> 145:  * <li> An object is <em>strongly reachable</em> if it can be accessed without
> 146:  * traversing the referent of a Reference object.

Here, we want the definition of "strongly reachable" to build on the JLS definition of "reachable" quoted above. Suggest something like

> An object is **strongly reachable** if it is reachable and if it can be accessed without traversing the referent of a Reference object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527074234
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527080061
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527074924
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527076814

From smarks at openjdk.org  Sat Mar 16 22:23:50 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 16 Mar 2024 22:23:50 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <i1U3bkHmm7ZpUFqctnGxLPcooUM3zYyjRecIv4gnj3k=.3cbbd757-0efe-43a4-8f94-4dd88f4ef6b6@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <f7xiLmhBedF-ZWjCwx0cDlwLSmZPK76Be-XnTMPN5Ug=.75563fb4-07a4-43e6-a757-f4a7a66479b2@github.com>
 <08WIXF8evpw7ZRGFOwA39Xiop2X7epEE0G6_wX3Foo4=.01d3af7d-776b-4c05-9f81-25bbd3b2194d@github.com>
 <i1U3bkHmm7ZpUFqctnGxLPcooUM3zYyjRecIv4gnj3k=.3cbbd757-0efe-43a4-8f94-4dd88f4ef6b6@github.com>
Message-ID: <MG4LpFT1_4ZQr3m4vjJqMVzNEO5siY2GbE0AdcLbla8=.6d838206-e577-442e-af13-9c844a8d38d9@github.com>

On Wed, 31 Jan 2024 01:13:18 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/package-info.java line 109:
>> 
>>> 107:  *
>>> 108:  * <li>The clearing of a reference by the garbage collector <i>happens-before</i>
>>> 109:  * the garbage collector enqueues the reference.</li>
>> 
>> Is it worth specifying this middle step? Is there a way to tell that something has been enqueued without removing the reference or calling the deprecated (and very dubious) isEnqueued method? Could we just remove this paragraph, and instead start the next one with "The clearing of a reference by the garbage collector ..."
>
> Here, we are building a chain of _happens-befores_ that reaches from RF to dequeue (and on, to the running of the cleaning action, in the case of Cleaner).
> 
> A ref can also be cleared by a call to clear(), but that has no memory consistency effects.
> 
> So I think it's worth clarifying here that ref-clearing only forms a "link" in the _happens-before_ chain **_when performed by the GC_**.

I had also wondered why we don't just have a single edge GC-clear _happens-before_ dequeue. The reason is that there is a potential gap between GC-clear and GC-enqueue, during which some application thread can call the `enqueue` method. If the application thread's call successfully enqueues the ref, the HB edge is between the application thread's prior actions and the dequeue, and this **breaks** the HB chain that started at `reachabilityFence` and that would follow GC's actions. Thus, to keep the chain intact, GC must clear the ref and also successfully enqueue the ref.

This is rather more complex than I would have liked. It would be nicer if clear-and-enqueue were atomic (either performed by GC, or performed by an application thread's call to `enqueue`, and not a mixture). However, this isn't supported by the specification, and the implementations I'm aware of don't do this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527092160

From mchung at openjdk.org  Sat Mar 16 22:24:13 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 16 Mar 2024 22:24:13 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <uK5VYn9y1gI0QrkBbQjtTrIrB8YNiILoTGEaGobjvpg=.1da1d444-81a8-4473-925a-1eae1d14effd@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
 <uK5VYn9y1gI0QrkBbQjtTrIrB8YNiILoTGEaGobjvpg=.1da1d444-81a8-4473-925a-1eae1d14effd@github.com>
Message-ID: <IvbbzdqDkm0H7utG7L4q_YbB2izawyx_3V9fxGybPy4=.c983f7e8-4cdc-440f-b4ca-9fdc49a53ef9@github.com>

On Fri, 15 Mar 2024 10:53:29 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Wasn't the intention to make "creating a linkable runtime image" a build only decision and make the relevant infrastructure classes build-only artefacts?

Build-only decision means that the linkable runtime image is only produced by JDK build.   Supporting classes of this tool like the code generating the diffs can reside in `src/jdk.jlink` if possible as that helps keeping in other jlink code.

I misinterpreted that this is no longer a build tool approach as I was confused when seeing the source files are moved to `src/jdk.jlink`.   The build tool can stay in unnamed module as before but the tool would need to run on the newly built or interim JDK (not the boot JDK) which explains why the code of generating the diffs can be part of jlink.

Regarding my comment to "only compile those classes when JDK is configured to build linkable images" was premature.  I thought of some complexity last night and if it could be filtered easily, it would be a bonus.   If not, also no issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2000188399

From mchung at openjdk.org  Sat Mar 16 22:24:19 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 16 Mar 2024 22:24:19 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <W_aNdzFY9hXt5Sp4kiagTC8Ea2pXF_NTPh_0Lkm23kI=.c71371ad-7ae5-4303-a915-1c664b09d1da@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
 <SKolC1SQ7rvmB08teumZhfRUa0XKJ8zuylmAJsep7Jg=.0b356474-7e1d-4b0f-9a48-d4a9a72e2652@github.com>
 <W_aNdzFY9hXt5Sp4kiagTC8Ea2pXF_NTPh_0Lkm23kI=.c71371ad-7ae5-4303-a915-1c664b09d1da@github.com>
Message-ID: <lbyeiN9WvM7axR9mmugDFmPJJqBRKxm1vPbS3lq3r2A=.a8a3ec71-f0c8-48a8-bb04-3533abb9f98e@github.com>

On Fri, 15 Mar 2024 09:55:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > If `--enable-runtime-link-image` is enabled, the JDK image does not include the packaged modules.
> 
> That's not true. Right now `--enable-runtime-link-image` modifies how the `lib/modules` image looks like (adds a bunch of extra resources). That's it. It doesn't modify the setup of packaged modules. 

It is true that they are orthogonal.   jlink does allow to produce a linkable image with `--keep-packaged-modules` and the resulting JDK image would work.  

However, the goal of this work is to produce a JDK image with smaller footprint.   This is a question to JDK build to allow configuring building a linkable image with packaged modules.

In addition, `--enable-keep-packaged-modules` is enabled by default.    Do you want the linkable image includes `jmods` as it's currently implemented in this PR?   I assume not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2000322485

From jvernee at openjdk.org  Sat Mar 16 22:34:25 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 16 Mar 2024 22:34:25 GMT
Subject: RFR: 8327994: Update code gen in CallGeneratorHelper [v2]
In-Reply-To: <zFBzrJ8FEI7yrwITdz5YCmwL2cm2W100I4enNOW-mwo=.ca09bbf3-0caa-46f4-8553-143630d39dd2@github.com>
References: <zFBzrJ8FEI7yrwITdz5YCmwL2cm2W100I4enNOW-mwo=.ca09bbf3-0caa-46f4-8553-143630d39dd2@github.com>
Message-ID: <S2ts94OiirHtbF5rOdowjMRmotVq9whFzIS0K4cfR8A=.397cbf63-9991-442b-9745-5c638a7e79ef@github.com>

> Update the code gen code in CallGeneratorHelper to reflect the latest state of the libTest(Downcall/Upcall)(Stack).c and shared.h files.
> 
> - The previous code wanted users to pipe stdout into a file. But, since we have 5 files that need to be created, and the names of those files is important too, I've changed the script to write to those files directly instead.
> - I moved the definition of `S_FFFF` to libVarArgs.c where it's used, as it's not actually generated by CallGeneratorHelper.
> - GitHub doesn't render the changes to some of the files, but those files only contain either white space changes (some missing spaces after `,`), and copyright header updates.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Delete extra space
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18269/files
  - new: https://git.openjdk.org/jdk/pull/18269/files/e66b7671..d282ecbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18269&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18269&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18269/head:pull/18269

PR: https://git.openjdk.org/jdk/pull/18269

From aturbanov at openjdk.org  Sat Mar 16 22:34:26 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 16 Mar 2024 22:34:26 GMT
Subject: RFR: 8327994: Update code gen in CallGeneratorHelper [v2]
In-Reply-To: <S2ts94OiirHtbF5rOdowjMRmotVq9whFzIS0K4cfR8A=.397cbf63-9991-442b-9745-5c638a7e79ef@github.com>
References: <zFBzrJ8FEI7yrwITdz5YCmwL2cm2W100I4enNOW-mwo=.ca09bbf3-0caa-46f4-8553-143630d39dd2@github.com>
 <S2ts94OiirHtbF5rOdowjMRmotVq9whFzIS0K4cfR8A=.397cbf63-9991-442b-9745-5c638a7e79ef@github.com>
Message-ID: <0EU5CxBD2mkzQrCYToqsO5Un5yT1WJDe9zb8DshdCYU=.41518aa2-c737-4e98-9504-bf6b726536cc@github.com>

On Sat, 16 Mar 2024 15:41:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Update the code gen code in CallGeneratorHelper to reflect the latest state of the libTest(Downcall/Upcall)(Stack).c and shared.h files.
>> 
>> - The previous code wanted users to pipe stdout into a file. But, since we have 5 files that need to be created, and the names of those files is important too, I've changed the script to write to those files directly instead.
>> - I moved the definition of `S_FFFF` to libVarArgs.c where it's used, as it's not actually generated by CallGeneratorHelper.
>> - GitHub doesn't render the changes to some of the files, but those files only contain either white space changes (some missing spaces after `,`), and copyright header updates.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete extra space
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/foreign/CallGeneratorHelper.java line 195:

> 193:     }
> 194: 
> 195:     private  static void generateStructDecl(PrintStream out, List<StructFieldType> fields) {

Suggestion:

    private static void generateStructDecl(PrintStream out, List<StructFieldType> fields) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18269#discussion_r1527165383

From duke at openjdk.org  Sun Mar 17 18:31:50 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 17 Mar 2024 18:31:50 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v2]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <KuFvmtJkJrOnOmzcc5kjHbajtkzMNKQnHpperfTK9LI=.c22ef053-17ec-4ec8-8465-29b8c8eb5ef9@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  fixed @ since tag for Channels.java class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/8a829541..e80f99e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=00-01

  Stats: 6 lines in 1 file changed: 2 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032

PR: https://git.openjdk.org/jdk/pull/18032

From acobbs at openjdk.org  Sun Mar 17 22:53:55 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 17 Mar 2024 22:53:55 GMT
Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available()
 test for end-of-stream [v9]
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <LipvoLe7PSwoHFJSfWBKR9IoKHDzDO9myyQy1ur1NyE=.a9f6afd7-6783-475e-9048-0818bea2e9d1@github.com>

> `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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17113/files
  - new: https://git.openjdk.org/jdk/pull/17113/files/04072c19..d567cef2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=07-08

  Stats: 26396 lines in 568 files changed: 13590 ins; 10571 del; 2235 mod
  Patch: https://git.openjdk.org/jdk/pull/17113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17113/head:pull/17113

PR: https://git.openjdk.org/jdk/pull/17113

From duke at openjdk.org  Sun Mar 17 23:40:50 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 17 Mar 2024 23:40:50 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v3]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <bAIsgoT0mopCkvsLbpjKe8PxLNB1v_WojMMuq3k8qyA=.5d13138a-1369-4640-a123-8ecf125c65ef@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - fixed a mistake
 - fixed a mistake

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/e80f99e1..c51f6cb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=01-02

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032

PR: https://git.openjdk.org/jdk/pull/18032

From duke at openjdk.org  Sun Mar 17 23:56:48 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 17 Mar 2024 23:56:48 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v4]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <Hzb3BRT3YdYFxjfcEng90akTVQkea995UaZPKD5JrDY=.8d9664c8-b366-478b-9552-536d8eaa761c@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  final version for channels.java - might need to remove whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/c51f6cb9..8e5a711e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032

PR: https://git.openjdk.org/jdk/pull/18032

From duke at openjdk.org  Mon Mar 18 00:02:31 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 18 Mar 2024 00:02:31 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v5]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <9z0zSGIWOSNLzbXHUV0EVx88bAPaade33W-lnsPl3UI=.6ee04546-60ec-403b-bba8-2ed647b96876@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  remove whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/8e5a711e..4822dede

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032

PR: https://git.openjdk.org/jdk/pull/18032

From jlu at openjdk.org  Mon Mar 18 06:29:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Mar 2024 06:29:40 GMT
Subject: RFR: JDK-8327640: Allow NumberFormat strict parsing
Message-ID: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@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.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/18339/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327640
  Stats: 1199 lines in 6 files changed: 1157 ins; 10 del; 32 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 abimpoudis at openjdk.org  Mon Mar 18 08:53:29 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 18 Mar 2024 08:53:29 GMT
Subject: RFR: 8327839: Crash with unboxing and widening primitive
 conversion in switch [v2]
In-Reply-To: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>
References: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>
Message-ID: <2znGbxx7HVg1nNv4AURxwAs22uRivO_v35-uTHm1ceM=.b47fa1fa-92f5-4d10-832e-37f4e1a15659@github.com>

> In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Update test/langtools/tools/javac/patterns/PrimitivePatternsSwitch.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18236/files
  - new: https://git.openjdk.org/jdk/pull/18236/files/ecf909d0..50275918

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18236&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18236&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18236.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18236/head:pull/18236

PR: https://git.openjdk.org/jdk/pull/18236

From ihse at openjdk.org  Mon Mar 18 09:15:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Mar 2024 09:15:32 GMT
Subject: RFR: 8328074: Add jcheck whitespace checking for assembly files
 [v4]
In-Reply-To: <AB2ZOJJRuFA2cl6bCCbheAmXIb3XqsumpH3RgW_cAdI=.7a0529a5-75da-4983-81a9-e3958ac4f97e@github.com>
References: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
 <LDHFfoNVIbxCujeYMWs28J7pzyoZnhAYrDd7To_1Oug=.2c6d6327-4de4-42d6-9575-cd81c24b2fae@github.com>
 <AB2ZOJJRuFA2cl6bCCbheAmXIb3XqsumpH3RgW_cAdI=.7a0529a5-75da-4983-81a9-e3958ac4f97e@github.com>
Message-ID: <02Y9O24SosYFQqROvNLZ6EM4lfieC5YJQ7zJ-cn087M=.1974283f-4ff3-48dd-b234-841d1ba263e1@github.com>

On Sat, 16 Mar 2024 00:08:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make all ALIGN/.align aligned
>
> Looks good to me.

Thanks @sviswa7!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18268#issuecomment-2003271932

From ihse at openjdk.org  Mon Mar 18 09:15:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Mar 2024 09:15:32 GMT
Subject: Integrated: 8328074: Add jcheck whitespace checking for assembly files
In-Reply-To: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
References: <BK7vj0LdFYjns_1Q9k6dZWSiXnFnk_GJQ1dFNrZfJYE=.45e8792c-c374-4b6a-899f-86eaec614506@github.com>
Message-ID: <eqGaQhel9zPYhZBs1640ox3fyQgXNI0fseI5L30qRK8=.f729cc0a-ad33-4dc2-a677-c05a52c92256@github.com>

On Wed, 13 Mar 2024 11:18:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As part of the ongoing effort to enable jcheck whitespace checking to all text files, it is now time to address assembly (.S) files. The hotspot assembly files were fixed as part of the hotspot mapfile removal, so only a single incorrect jdk library remains.
> 
> The main issue with `libjsvml` was inconsistent line starts, sometimes using tabs. I used the `expand` unix command line tool to replace these with spaces.

This pull request has now been integrated.

Changeset: c342188f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c342188fd978dd94e7788fb0fb0345fd8c0eaa9a
Stats:     280027 lines in 73 files changed: 0 ins; 0 del; 280027 mod

8328074: Add jcheck whitespace checking for assembly files

Reviewed-by: erikj, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/18268

From ihse at openjdk.org  Mon Mar 18 10:56:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Mar 2024 10:56:54 GMT
Subject: RFR: 8328177: Move LDFLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk
Message-ID: <SLLx5r0atjXi0tBfduohg2HrVPUvTQxorYZR4cmqsu4=.3b0a90c0-78b2-4dd7-9d74-cc5ff084faab@github.com>

Similar to [JDK-8328157](https://bugs.openjdk.org/browse/JDK-8328157), we want to move the setting of LDFLAGS to LDFLAGS_JDK[LIB/EXE into SetupJdkLibrary and SetupJdkExecutable.

-------------

Commit messages:
 - 8328177: Move LDFLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk

Changes: https://git.openjdk.org/jdk/pull/18343/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18343&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328177
  Stats: 155 lines in 32 files changed: 29 ins; 99 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/18343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18343/head:pull/18343

PR: https://git.openjdk.org/jdk/pull/18343

From jpai at openjdk.org  Mon Mar 18 12:44:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Mar 2024 12:44:28 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: <v8qeMIltNENhSdLAJzn9DJDdDXowY1fRWT7-2dU2cAo=.1798c563-75f9-460d-ae3d-19769a4b1403@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.

The CSR for this has been approved. I will be running one final round of CI tests with this change and if those tests complete without related issues, I'll go ahead and approve this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2003810098

From duke at openjdk.org  Mon Mar 18 12:44:46 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 18 Mar 2024 12:44:46 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v6]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  added terminal new line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/4822dede..abc5a6ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032

PR: https://git.openjdk.org/jdk/pull/18032

From sgehwolf at openjdk.org  Mon Mar 18 13:03:34 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 18 Mar 2024 13:03:34 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <lbyeiN9WvM7axR9mmugDFmPJJqBRKxm1vPbS3lq3r2A=.a8a3ec71-f0c8-48a8-bb04-3533abb9f98e@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
 <SKolC1SQ7rvmB08teumZhfRUa0XKJ8zuylmAJsep7Jg=.0b356474-7e1d-4b0f-9a48-d4a9a72e2652@github.com>
 <W_aNdzFY9hXt5Sp4kiagTC8Ea2pXF_NTPh_0Lkm23kI=.c71371ad-7ae5-4303-a915-1c664b09d1da@github.com>
 <lbyeiN9WvM7axR9mmugDFmPJJqBRKxm1vPbS3lq3r2A=.a8a3ec71-f0c8-48a8-bb04-3533abb9f98e@github.com>
Message-ID: <PNV2aG9IXon7hB0ah4ZN9Z-649m39BH4wswR3nZKkW0=.a79a9ecc-d859-4ce5-94ce-f2c951aebe75@github.com>

On Fri, 15 Mar 2024 19:29:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > > If `--enable-runtime-link-image` is enabled, the JDK image does not include the packaged modules.
> > 
> > 
> > That's not true. Right now `--enable-runtime-link-image` modifies how the `lib/modules` image looks like (adds a bunch of extra resources). That's it. It doesn't modify the setup of packaged modules.
> 
> It is true that they are orthogonal. jlink does allow to produce a linkable image with `--keep-packaged-modules` and the resulting JDK image would work.

More so, the compatibility to the status quo would be better (in terms of produced build output).

> However, the goal of this work is to produce a JDK image with smaller footprint. This is a question to JDK build to allow configuring building a linkable image with packaged modules.

IMO something like that could be achieved by creating a separate bundle (take the JDK image, but don't include the packaged modules, for example).

> In addition, `--enable-keep-packaged-modules` is enabled by default. Do you want the linkable image includes `jmods` as it's currently implemented in this PR?

Yes we do. The main reason being that the `jdk` image has more to it than just the image. `src.zip`, CDS data, `demo` and so on. We don't want to duplicate that. To us, including the `jmods` folder is something that comes into play when actually producing the bundles of the JDK. The linkable runtime option allows for a more flexible distribution of the resulting JDK. With or without packaged modules without limiting `jlink` usage (for the common use-cases).

If somebody truly wanted to *not* have the packaged modules after a build with a runtime-linkable-image that's possible with the following configure options: `--enable-linkable-runtime-image --disable-keep-packaged-modules`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2003848668

From sgehwolf at openjdk.org  Mon Mar 18 13:07:33 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 18 Mar 2024 13:07:33 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <IvbbzdqDkm0H7utG7L4q_YbB2izawyx_3V9fxGybPy4=.c983f7e8-4cdc-440f-b4ca-9fdc49a53ef9@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
 <uK5VYn9y1gI0QrkBbQjtTrIrB8YNiILoTGEaGobjvpg=.1da1d444-81a8-4473-925a-1eae1d14effd@github.com>
 <IvbbzdqDkm0H7utG7L4q_YbB2izawyx_3V9fxGybPy4=.c983f7e8-4cdc-440f-b4ca-9fdc49a53ef9@github.com>
Message-ID: <bK8h41bAZeGDOOhG-CzZKndgv19y0DdyugwiJ6V77m8=.33684912-6eec-4685-a19e-b9c519f47de9@github.com>

On Fri, 15 Mar 2024 18:09:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > Wasn't the intention to make "creating a linkable runtime image" a build only decision and make the relevant infrastructure classes build-only artefacts?
> 
> Build-only decision means that the linkable runtime image is only produced by JDK build. Supporting classes of this tool like the code generating the diffs can reside in `src/jdk.jlink` if possible as that helps keeping in other jlink code.
> 
> I misinterpreted that this is no longer a build tool approach as I was confused when seeing the source files are moved to `src/jdk.jlink`. The build tool can stay in unnamed module as before but the tool would need to run on the newly built or interim JDK (not the boot JDK) which explains why the code of generating the diffs can be part of jlink.

OK. I'll move the build-only plugin to the build folder and keep the supporting classes in `jdk.tools.jlink.internal.runtimelink` of `jdk.jlink`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2003857309

From abimpoudis at openjdk.org  Mon Mar 18 13:19:31 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 18 Mar 2024 13:19:31 GMT
Subject: Integrated: 8327839: Crash with unboxing and widening primitive
 conversion in switch
In-Reply-To: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>
References: <ceAdUOq3zo8LiiSsqhUXMHtJTcfXqv03SAxrSHTg_qo=.bc9641de-34ae-478f-934b-1a1ff195bb79@github.com>
Message-ID: <6PEReV6E54AAZf2Qiiouqh89xGj3QhmgKyWla5rtChI=.ca66d96b-db04-4564-8fad-b4341c8405b3@github.com>

On Tue, 12 Mar 2024 14:06:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug.

This pull request has now been integrated.

Changeset: fb390d20
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb390d202c8bbbbb87ba48fd01387feb35a1b768
Stats:     111 lines in 5 files changed: 99 ins; 0 del; 12 mod

8327839: Crash with unboxing and widening primitive conversion in switch

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/18236

From pminborg at openjdk.org  Mon Mar 18 14:13:48 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 18 Mar 2024 14:13:48 GMT
Subject: RFR: 8326941: Remove StringUTF16::isBigEndian
Message-ID: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>

This PR proposes to remove the native method `StringUTF16::isBigEndian` and its corresponding C implementation and instead rely on the `jdk.internal.misc.Unsafe::isBigEndian` method.

-------------

Commit messages:
 - Update copyright years
 - Remove native method

Changes: https://git.openjdk.org/jdk/pull/18348/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18348&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326941
  Stats: 18 lines in 2 files changed: 2 ins; 13 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18348.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18348/head:pull/18348

PR: https://git.openjdk.org/jdk/pull/18348

From rriggs at openjdk.org  Mon Mar 18 14:25:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Mar 2024 14:25:26 GMT
Subject: RFR: 8326941: Remove StringUTF16::isBigEndian
In-Reply-To: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
References: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
Message-ID: <eAftvIvrpXHNvMTvMu3g3uqNVoCa83YS-Rv0E9kgoIc=.a5e81373-161c-41ae-af0c-e4cc4129b0f7@github.com>

On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the native method `StringUTF16::isBigEndian` and its corresponding C implementation and instead rely on the `jdk.internal.misc.Unsafe::isBigEndian` method.

Nice Cleanup.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18348#pullrequestreview-1943235796

From redestad at openjdk.org  Mon Mar 18 14:37:26 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 18 Mar 2024 14:37:26 GMT
Subject: RFR: 8326941: Remove StringUTF16::isBigEndian
In-Reply-To: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
References: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
Message-ID: <PWFbIjTf2eP-i2DSGdYlFYtzfd9Tcq_pc6jtTUb3LDE=.b5de578f-3f98-4fb0-afc5-a6d150bdac5a@github.com>

On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the native method `StringUTF16::isBigEndian` and its corresponding C implementation and instead rely on the `jdk.internal.misc.Unsafe::isBigEndian` method.

Does this change how early `Unsafe` is initialized, and does it in turn have dependencies on `StringUTF16`? `StringUTF16` is loaded very early, especially if `-XX:-CompactStrings` is supplied and I would assume the only reason this was added in the first place was to avoid some bootstrapping issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18348#issuecomment-2004086796

From prappo at openjdk.org  Mon Mar 18 14:58:46 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 18 Mar 2024 14:58:46 GMT
Subject: RFR: 8297879: javadoc link to preview JEP 1000 has grouping character
 comma
Message-ID: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>

Please review this simple bugfix to properly construct links to preview JEPs.

The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`.

For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were:

 1. slap `noreg-hard` on the JBS bug and skip testing
 2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base`

While (1) is insufficient, (2) seems overkill in this case.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/18350/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18350&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297879
  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18350.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18350/head:pull/18350

PR: https://git.openjdk.org/jdk/pull/18350

From jlahoda at openjdk.org  Mon Mar 18 15:04:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Mar 2024 15:04:27 GMT
Subject: RFR: 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: <MsldNsihcxWaN9eVZzf98WqOQ0Bo6iyvvkKrEsePHd4=.7ecab500-b876-4d12-9855-ce99be4fc42e@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.

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18021#pullrequestreview-1943355591

From jjg at openjdk.org  Mon Mar 18 15:11:28 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 18 Mar 2024 15:11:28 GMT
Subject: RFR: 8297879: javadoc link to preview JEP 1000 has grouping
 character comma
In-Reply-To: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>
References: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>
Message-ID: <nz7v-V_AlDkkcna0QR1eJ--P4xgHYqHXAwvd36SHXro=.6daad643-a58a-4bbc-a4b2-d5143da5f096@github.com>

On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple bugfix to properly construct links to preview JEPs.
> 
> The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`.
> 
> For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were:
> 
>  1. slap `noreg-hard` on the JBS bug and skip testing
>  2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base`
> 
> While (1) is insufficient, (2) seems overkill in this case.

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18350#pullrequestreview-1943374124

From prappo at openjdk.org  Mon Mar 18 15:11:29 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 18 Mar 2024 15:11:29 GMT
Subject: RFR: 8297879: javadoc link to preview JEP 1000 has grouping
 character comma
In-Reply-To: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>
References: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>
Message-ID: <k2e-QoOnPN-te3njlg3g3erUO-Uiw8qwVmWRf-QXPjI=.8ccb39a3-ea8b-4ec2-90ed-96ffe70c1ae6@github.com>

On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple bugfix to properly construct links to preview JEPs.
> 
> The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`.
> 
> For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were:
> 
>  1. slap `noreg-hard` on the JBS bug and skip testing
>  2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base`
> 
> While (1) is insufficient, (2) seems overkill in this case.

Hm... it's surprising to see that the Skara bots consider that src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java belongs to core-libs, but not to compiler. Let me manually add it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18350#issuecomment-2004168270

From pminborg at openjdk.org  Mon Mar 18 15:37:26 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 18 Mar 2024 15:37:26 GMT
Subject: RFR: 8326941: Remove StringUTF16::isBigEndian
In-Reply-To: <PWFbIjTf2eP-i2DSGdYlFYtzfd9Tcq_pc6jtTUb3LDE=.b5de578f-3f98-4fb0-afc5-a6d150bdac5a@github.com>
References: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
 <PWFbIjTf2eP-i2DSGdYlFYtzfd9Tcq_pc6jtTUb3LDE=.b5de578f-3f98-4fb0-afc5-a6d150bdac5a@github.com>
Message-ID: <UJHwiNKlduv59e9IZNizbqV8wR-qwaLd3N_pIllgk9g=.d7916dcc-27c9-429b-a498-fe4cff7d0c29@github.com>

On Mon, 18 Mar 2024 14:35:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Does this change how early `Unsafe` is initialized, and does it in turn have dependencies on `StringUTF16`? `StringUTF16` is loaded very early, especially if `-XX:-CompactStrings` is supplied and I would assume the only reason this was added in the first place was to avoid some bootstrapping issue.

I am unsure of the initialization order. Unsafe was added 2015, a few weeks before the explicit C code was added. This might indicate the previous solution was deliberate or it might be the case, the new method was not known by the author at the time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18348#issuecomment-2004235134

From rriggs at openjdk.org  Mon Mar 18 16:09:31 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Mar 2024 16:09:31 GMT
Subject: RFR: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v3]
In-Reply-To: <SN9xEvfAmhOiReAp4xuA_tyCr0Oc8lWHAI_c0cQQjOE=.e4b57d6e-149f-4956-b084-c3b32422a47e@github.com>
References: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
 <SN9xEvfAmhOiReAp4xuA_tyCr0Oc8lWHAI_c0cQQjOE=.e4b57d6e-149f-4956-b084-c3b32422a47e@github.com>
Message-ID: <CTPUNxH0GD3ZDIDxE0xT9FnMvw3LW4ectgfWJQWWlfc=.575edcdb-57d6-468b-b3d6-9f686424e403@github.com>

On Wed, 13 Mar 2024 20:10:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.
>> 
>> Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
>> Added a run of the test using ZGC, (previously omitted)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the correct ZGenerational collector

CI Tier1-3 successful

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18284#issuecomment-2004334272

From rriggs at openjdk.org  Mon Mar 18 16:09:31 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Mar 2024 16:09:31 GMT
Subject: Integrated: 8327180: Failed:
 java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1
In-Reply-To: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
References: <smmPdkofP8qzUsTIg5AvKu84s3rs2S_L9RMklleeSUI=.f5d5abb9-4133-4b67-abd6-bfcc13912b67@github.com>
Message-ID: <Rb-PhgQeXMcK9xBaIr1gAOUtgQyJTpAymGocWDcFFsc=.effa9079-c3fd-4b99-a02b-553c6b4671bf@github.com>

On Wed, 13 Mar 2024 18:01:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition.
> 
> Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences.
> Added a run of the test using ZGC, (previously omitted)

This pull request has now been integrated.

Changeset: 85fc47c8
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85fc47c81af81a595dc88e61454d8ba2d860f301
Stats:     36 lines in 1 file changed: 4 ins; 28 del; 4 mod

8327180: Failed: java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1

Reviewed-by: iris, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/18284

From sroy at openjdk.org  Mon Mar 18 16:17:41 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 18 Mar 2024 16:17:41 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
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: <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@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 seven additional commits since the last revision:

 - remove space
 - remove debug print lines
 - remove debug print lines
 - remove debug lines
 - variable name check
 - code cleanup
 - made changes to file loading procedure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/9ad12257..cd219603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=00-01

  Stats: 34 lines in 2 files changed: 32 ins; 1 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 vromero at openjdk.org  Mon Mar 18 16:28:27 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 18 Mar 2024 16:28:27 GMT
Subject: RFR: 8297879: javadoc link to preview JEP 1000 has grouping
 character comma
In-Reply-To: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>
References: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>
Message-ID: <Z6jHQE1QMiG7a6IX3zt3X-3oe9r25rI0CSi0JsnaV6E=.92574e35-a1bd-460b-ad9b-cfd86393a768@github.com>

On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple bugfix to properly construct links to preview JEPs.
> 
> The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`.
> 
> For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were:
> 
>  1. slap `noreg-hard` on the JBS bug and skip testing
>  2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base`
> 
> While (1) is insufficient, (2) seems overkill in this case.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18350#pullrequestreview-1943594610

From bhuang at openjdk.org  Mon Mar 18 16:52:47 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 18 Mar 2024 16:52:47 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests
Message-ID: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@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.

-------------

Commit messages:
 - Clean up temporary files after tests complete.

Changes: https://git.openjdk.org/jdk/pull/18352/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327474
  Stats: 42 lines in 11 files changed: 20 ins; 1 del; 21 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 dfenacci at openjdk.org  Mon Mar 18 16:58:28 2024
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 18 Mar 2024 16:58:28 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic
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: <XGgFKhPknDKGS7aGJ0DELlaueodnWAethcWem2y-5Kw=.8d88801f-6427-4504-8d5d-8d152fafd8a1@github.com>

On Tue, 12 Mar 2024 10:44: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.

Quite a simplification!
Have you checked if there are any performance differences?

-------------

PR Review: https://git.openjdk.org/jdk/pull/18226#pullrequestreview-1943670073

From jpai at openjdk.org  Mon Mar 18 17:26:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Mar 2024 17:26:29 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
Message-ID: <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>

On Mon, 18 Mar 2024 16:17: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)
>
> Suchismith Roy has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - remove space
>  - remove debug print lines
>  - remove debug print lines
>  - remove debug lines
>  - variable name check
>  - code cleanup
>  - made changes to file loading procedure

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 130:

> 128:                                 //Remove member name in brackets from file pathname, as such pathnames do not exist.
> 129:                                 //Original pathname with bracket is returned,which is handled by dlopen() in AIX.
> 130:                                 if (file.getName().contains("(")){

Hello @suchismith1993, can you provide us some context on what this check is about? Is some code application code calling `System.load("foo(bar");` and this code in then trying to remove that `(`?

Adding this code here wouldn't be right. Plus, I see that in this new `if` block, the code then goes and renames the underlying `File` to a new name, which too isn't right.

Knowing the context of why this is needed would help us understand if anything needs to change here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1528972710

From sroy at openjdk.org  Mon Mar 18 17:34:28 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 18 Mar 2024 17:34:28 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
Message-ID: <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>

On Mon, 18 Mar 2024 17:24:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - remove space
>>  - remove debug print lines
>>  - remove debug print lines
>>  - remove debug lines
>>  - variable name check
>>  - code cleanup
>>  - made changes to file loading procedure
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 130:
> 
>> 128:                                 //Remove member name in brackets from file pathname, as such pathnames do not exist.
>> 129:                                 //Original pathname with bracket is returned,which is handled by dlopen() in AIX.
>> 130:                                 if (file.getName().contains("(")){
> 
> Hello @suchismith1993, can you provide us some context on what this check is about? Is some code application code calling `System.load("foo(bar");` and this code in then trying to remove that `(`?
> 
> Adding this code here wouldn't be right. Plus, I see that in this new `if` block, the code then goes and renames the underlying `File` to a new name, which too isn't right.
> 
> Knowing the context of why this is needed would help us understand if anything needs to change here.

In AIX, we have an usecase where shared libraries have certain member objects to be referred to. 
E.g libclang.a(shr_64.o) .  
When we provide the path to loadLibrary(), it searches if the file exists as absolute path .i.e libclang.a(shr_64.o), but such a path doesn't exist, only dlopen() would be able to recognise the member object mentioned in the path and able to load it. 

So before the code transitions to native code where dlopen() happens, the member object is being removed from the filename,so that the right path is referred(libclang.a) , and then the original path name with member name is passed on to the dlopen()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1528982168

From rriggs at openjdk.org  Mon Mar 18 17:35:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Mar 2024 17:35:27 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic
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: <cSWaF0kFHSciCAQ0O130R1pXZyGwqwHcKWeL4TZNLvM=.710aa1b5-6a5a-47ce-ae31-003d946e64c7@github.com>

On Tue, 12 Mar 2024 10:44: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.

src/java.base/share/classes/java/math/BigInteger.java line 1836:

> 1834: 
> 1835:         if (z == null || z.length < (xlen+ ylen))
> 1836:              z = new int[xlen+ylen];

Spaces before and after "+" please.  Tnx

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1528984661

From sroy at openjdk.org  Mon Mar 18 17:39:47 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 18 Mar 2024 17:39:47 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v3]
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: <w1D7uLaVLcn3nZJGpQ0xHvsmZ_oiHI0xRYSBSoQgKOM=.9528d036-f6ea-40f7-80e8-788c506a2e29@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:

  trailing spaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/cd219603..c20e2862

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 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 Mar 18 17:43:45 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 18 Mar 2024 17:43:45 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
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: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@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:

  trraling spaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/c20e2862..d361656c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=02-03

  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 jpai at openjdk.org  Mon Mar 18 17:43:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Mar 2024 17:43:45 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
Message-ID: <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>

On Mon, 18 Mar 2024 17:31:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> In AIX, we have an usecase where shared libraries have certain member objects to be referred to. E.g libclang.a(shr_64.o) .

Would you happen to know any official documentation which explains that AIX syntax? 

> When we provide the path to loadLibrary()

Do you mean some application code is calling the `System.loadLibrary()` method with such values?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1528994926

From mchung at openjdk.org  Mon Mar 18 17:44:37 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 18 Mar 2024 17:44:37 GMT
Subject: RFR: 8328261: public lookup fails with IllegalAccessException when
 used while module system is being initialized
Message-ID: <enxbcyBzvO7SqGaIlSU16gzQPfMvUY1vSaFkMT6_JJM=.0401f562-8ed9-4138-b7aa-4b3fd6bc2d47@github.com>

A simple fix.   This is caused by a bug in `VerifyAccess::isClassAccessible` that checks if a class is exported from `java.base` before the exports are fully setup.    It should check if the module system is fully initialized before checking the module exports instead.

-------------

Commit messages:
 - 8328261: public lookup fails with IllegalAccessException when used while module system is being initialized

Changes: https://git.openjdk.org/jdk/pull/18356/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18356&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328261
  Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18356/head:pull/18356

PR: https://git.openjdk.org/jdk/pull/18356

From rriggs at openjdk.org  Mon Mar 18 17:54:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Mar 2024 17:54:26 GMT
Subject: RFR: 8328261: public lookup fails with IllegalAccessException when
 used while module system is being initialized
In-Reply-To: <enxbcyBzvO7SqGaIlSU16gzQPfMvUY1vSaFkMT6_JJM=.0401f562-8ed9-4138-b7aa-4b3fd6bc2d47@github.com>
References: <enxbcyBzvO7SqGaIlSU16gzQPfMvUY1vSaFkMT6_JJM=.0401f562-8ed9-4138-b7aa-4b3fd6bc2d47@github.com>
Message-ID: <W5cGNQk0P2Zncfp5MO_RXy3hg01D6YRf2i_xtBuMduQ=.0ac1800c-81ad-436e-80b7-fc1e1dc8cece@github.com>

On Mon, 18 Mar 2024 17:40:26 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A simple fix.   This is caused by a bug in `VerifyAccess::isClassAccessible` that checks if a class is exported from `java.base` before the exports are fully setup.    It should check if the module system is fully initialized before checking the module exports instead.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18356#pullrequestreview-1943799289

From mchung at openjdk.org  Mon Mar 18 18:11:33 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 18 Mar 2024 18:11:33 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <PNV2aG9IXon7hB0ah4ZN9Z-649m39BH4wswR3nZKkW0=.a79a9ecc-d859-4ce5-94ce-f2c951aebe75@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
 <SKolC1SQ7rvmB08teumZhfRUa0XKJ8zuylmAJsep7Jg=.0b356474-7e1d-4b0f-9a48-d4a9a72e2652@github.com>
 <W_aNdzFY9hXt5Sp4kiagTC8Ea2pXF_NTPh_0Lkm23kI=.c71371ad-7ae5-4303-a915-1c664b09d1da@github.com>
 <lbyeiN9WvM7axR9mmugDFmPJJqBRKxm1vPbS3lq3r2A=.a8a3ec71-f0c8-48a8-bb04-3533abb9f98e@github.com>
 <PNV2aG9IXon7hB0ah4ZN9Z-649m39BH4wswR3nZKkW0=.a79a9ecc-d859-4ce5-94ce-f2c951aebe75@github.com>
Message-ID: <EkjYia3_xaiTM13zy5RWEUcKhJA9z3EnNYtxPbfwyXM=.cbe8d515-45f3-48f2-af11-6277c2f8a6a2@github.com>

On Mon, 18 Mar 2024 13:01:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Yes we do. The main reason being that the `jdk` image has more to it than just the image. `src.zip`, CDS data, `demo` and so on. We don't want to duplicate that. To us, including the `jmods` folder is something that comes into play when actually producing the bundles of the JDK. The linkable runtime option allows for a more flexible distribution of the resulting JDK. With or without packaged modules without limiting `jlink` usage (for the common use-cases).

I'm not sure how keeping packaged modules is related to `src.zip`, CDS data, `demo` and so on as they are the targets after `images/jdk` is built.

However, I got your point that users should configure what they want the JDK image to produce as a linkable runtime image and packaged modules are orthogonal.   Okay with me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2004605507

From sgehwolf at openjdk.org  Mon Mar 18 18:43:36 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 18 Mar 2024 18:43:36 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <EkjYia3_xaiTM13zy5RWEUcKhJA9z3EnNYtxPbfwyXM=.cbe8d515-45f3-48f2-af11-6277c2f8a6a2@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
 <SKolC1SQ7rvmB08teumZhfRUa0XKJ8zuylmAJsep7Jg=.0b356474-7e1d-4b0f-9a48-d4a9a72e2652@github.com>
 <W_aNdzFY9hXt5Sp4kiagTC8Ea2pXF_NTPh_0Lkm23kI=.c71371ad-7ae5-4303-a915-1c664b09d1da@github.com>
 <lbyeiN9WvM7axR9mmugDFmPJJqBRKxm1vPbS3lq3r2A=.a8a3ec71-f0c8-48a8-bb04-3533abb9f98e@github.com>
 <PNV2aG9IXon7hB0ah4ZN9Z-649m39BH4wswR3nZKkW0=.a79a9ecc-d859-4ce5-94ce-f2c951aebe75@github.com>
 <EkjYia3_xaiTM13zy5RWEUcKhJA9z3EnNYtxPbfwyXM=.cbe8d515-45f3-48f2-af11-6277c2f8a6a2@github.com>
Message-ID: <ue23aIlyQRopOdlfdtTQPcLGMJAkSgGiHxMDbeo8gP8=.c1e91e36-cc8f-44c3-b376-c2405b0e5882@github.com>

On Mon, 18 Mar 2024 18:08:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > Yes we do. The main reason being that the `jdk` image has more to it than just the image. `src.zip`, CDS data, `demo` and so on. We don't want to duplicate that. To us, including the `jmods` folder is something that comes into play when actually producing the bundles of the JDK. The linkable runtime option allows for a more flexible distribution of the resulting JDK. With or without packaged modules without limiting `jlink` usage (for the common use-cases).
> 
> I'm not sure how keeping packaged modules is related to `src.zip`, CDS data, `demo` and so on as they are the targets after `images/jdk` is built.

What I mean to convey is that how the directory tree in `images/jdk` looks like shouldn't change based on the `--enable-linkable-runtime-image` configure flag. That is, there will be a `images/jdk/jmods` folder if not also `--disable-keep-packaged-modules` is given.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2004668722

From dlong at openjdk.org  Mon Mar 18 19:08:27 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 18 Mar 2024 19:08:27 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic
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: <tSUPgcdn3Mk3y0gULRvRvr4v5EBfjnxa4bqLb_Qwtqg=.a3d90aaf-6c7f-4771-8e81-57e3bd562ceb@github.com>

On Tue, 12 Mar 2024 10:44: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.

src/hotspot/share/opto/library_call.cpp line 5934:

> 5932:     // 'y_start' points to y array + scaled ylen
> 5933: 
> 5934:     Node* zlen = _gvn.transform(new AddINode(xlen, ylen));

Would could generate one less instruction in the code cache if we did this `add` in the native runtime function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1529102070

From erikj at openjdk.org  Mon Mar 18 19:35:32 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Mar 2024 19:35:32 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v20]
In-Reply-To: <ue23aIlyQRopOdlfdtTQPcLGMJAkSgGiHxMDbeo8gP8=.c1e91e36-cc8f-44c3-b376-c2405b0e5882@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XMf9JvIOyLAiSdpEFOwlCpgL_YMIMFNoOlP69aO0H90=.653a6e1a-e0ba-4e45-9a67-d6d0e94cd9ca@github.com>
 <7Z1jw5CHWlImqk_AYrwcHOYcinkYUNfZa0lUSVvrocE=.6a66d592-1de5-492e-89b7-eee648cbd575@github.com>
 <SKolC1SQ7rvmB08teumZhfRUa0XKJ8zuylmAJsep7Jg=.0b356474-7e1d-4b0f-9a48-d4a9a72e2652@github.com>
 <W_aNdzFY9hXt5Sp4kiagTC8Ea2pXF_NTPh_0Lkm23kI=.c71371ad-7ae5-4303-a915-1c664b09d1da@github.com>
 <lbyeiN9WvM7axR9mmugDFmPJJqBRKxm1vPbS3lq3r2A=.a8a3ec71-f0c8-48a8-bb04-3533abb9f98e@github.com>
 <PNV2aG9IXon7hB0ah4ZN9Z-649m39BH4wswR3nZKkW0=.a79a9ecc-d859-4ce5-94ce-f2c951aebe75@github.com>
 <EkjYia3_xaiTM13zy5RWEUcKhJA9z3EnNYtxPbfwyXM=.cbe8d515-45f3-48f2-af11-6277c2f8a6a2@github.com>
 <ue23aIlyQRopOdlfdtTQPcLGMJAkSgGiHxMDbeo8gP8=.c1e91e36-cc8f-44c3-b376-c2405b0e5882@github.com>
Message-ID: <q_AJhzmjO3XfL6BM60D4OaKdYhp1N20FG0We0SH4gtQ=.78fc97fe-775d-441d-a337-654dcf217f7c@github.com>

On Mon, 18 Mar 2024 18:40:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> What I mean to convey is that how the directory tree in `images/jdk` looks like shouldn't change based on the `--enable-linkable-runtime-image` configure flag. That is, there will be a `images/jdk/jmods` folder unless `--disable-keep-packaged-modules` is also given.

If that is how you want it to work, then I'm fine with it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2004761747

From mchung at openjdk.org  Mon Mar 18 20:20:32 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 18 Mar 2024 20:20:32 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v21]
In-Reply-To: <zLp_bBwO1X5tmnnKaLKzcZJ9KdlAo-11G7xXflih53k=.970ec66c-6ec4-4d74-85c5-b55cdb0e7e40@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <zLp_bBwO1X5tmnnKaLKzcZJ9KdlAo-11G7xXflih53k=.970ec66c-6ec4-4d74-85c5-b55cdb0e7e40@github.com>
Message-ID: <2Hq_LiXdJEZfVaOwfei9KUzX3hiqw-ocgszyC0R9iCo=.abdcb5bf-f1ac-438e-83cd-37408ee154c4@github.com>

On Fri, 15 Mar 2024 15:19:17 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 two additional commits since the last revision:
> 
>  - Fix comment.
>  - Review feedback and Windows build fix (FixPath)

This is what I understand from your implementation:

1. create a regular JDK image under `support/images/runtime-link-initial-jdk` using jlink from the exploded JDK build
2. create a linkable JDK image under `images/jdk` using jlink from the exploded JDK build with jlink command-line options used in step 1 plus


-create-linkable-runtime jimage=support/images/runtime-link-initial-jdk/lib/modules:module-path=support/images/jmods


jlink in step 2 has to run through the plugin pipeline as in step 1 and also the `create-linkable-runtime` plugin to generate the diffs and record the metadata for reconstituting the modules from the images (without the packaged modules).

Step 2 re-creates a new jimage file from the input packaged modules while the diffs are generated from `runtime-link-initial-jdk/lib/modules`.   In this approach, step 1 and step 2 assume that the same set of modules are linked and set set of plugin transformation is applied except `--create-linkable-runtime` as in step 1, i.e. it relies on the makefile to pass proper commands to step 1 and step 2 to result in the same `lib/modules` minus the new metadata and diffs added by `--create-linkable-runtime`.

The original idea we discussed is that step 1 creates a normal JDK image (as step 1 above) and then step 2 solely creates a new JDK linkable image without involving plugin pipeline that would be a simpler model.    The idea was something like this:


$ runtime-link-initial-jdk/bin/jlink -create-linkable-runtime support/images/jmods --output images/jdk


jlink `--create-linkable-runtime` will copy everything under `runtime-link-initial-jdk` (the runtime executing jlink) except `lib/modules` to `images/jdk` and create a new jimage `lib/modules` from `runtime-link-initial-jdk/lib/modules` (include diffs and metadata files).

Have you seen any issues with this approach over your current approach which involves the plugin transformation in both step 1 and 2?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2004888430

From bchristi at openjdk.org  Mon Mar 18 22:10:34 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 18 Mar 2024 22:10:34 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v14]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <ZXSqwQkLUTKJs0Lpn9UjIv4WgjhIndwdFdOnIt9_eIA=.2db47d60-1b84-4e8d-896f-d29744890cd3@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:

  Updates per review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/4d6f1dce..80a3973a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=12-13

  Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 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 bchristi at openjdk.org  Mon Mar 18 22:23:23 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 18 Mar 2024 22:23:23 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <BegquHhvEmYg4wlVFWgBCNOVaXWJzA0Nej6mfgNOzMM=.aae81ac4-4c34-49ac-b1d4-edd36de36bb8@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <BegquHhvEmYg4wlVFWgBCNOVaXWJzA0Nej6mfgNOzMM=.aae81ac4-4c34-49ac-b1d4-edd36de36bb8@github.com>
Message-ID: <fNQMZkFsx-Z48MzB9YQz91w5m1Pr3-QDb_o_A-5NtXg=.d0ca1643-87b3-4f7c-9a1e-64a404ba2a3b@github.com>

On Sat, 16 Mar 2024 04:21:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 127:
> 
>> 125:  * thread prior to a {@link Reference#reachabilityFence Reference.reachabilityFence(x)}
>> 126:  * <i>happen-before</i> cleanup code for {@code x} runs on the cleaner thread.
>> 127:  *
> 
> Extra blank line or need `<p>`.

Removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529361892

From bchristi at openjdk.org  Mon Mar 18 22:28:23 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 18 Mar 2024 22:28:23 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <BegquHhvEmYg4wlVFWgBCNOVaXWJzA0Nej6mfgNOzMM=.aae81ac4-4c34-49ac-b1d4-edd36de36bb8@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <BegquHhvEmYg4wlVFWgBCNOVaXWJzA0Nej6mfgNOzMM=.aae81ac4-4c34-49ac-b1d4-edd36de36bb8@github.com>
Message-ID: <TTJoBGA5yfmhjGGMZrulw-rnjtDkW0ZBGGpGmDiZd44=.4b402da5-ea73-45cc-b241-aa3877ed3847@github.com>

On Sat, 16 Mar 2024 04:20:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 402:
> 
>> 400:      * method is called, the garbage collector may already be in the process of
>> 401:      * (or already completed) clearing and/or enqueueing this reference.
>> 402:      *
> 
> Either this is an extra blank line, or you need a `<p>` here.

Removed the blank line; I thought it looked better for the API note to be a single paragraph.

> src/java.base/share/classes/java/lang/ref/Reference.java line 496:
> 
>> 494:      * Actions in a thread prior to calling
>> 495:      * {@code enqueue} <b><i>successfully</i></b>
>> 496:      * <a href="{@docRoot}/java.base/java/util/concurrent/package-summary.html#MemoryVisibility"><i>happen-before</i></a>
> 
> Editorial. The text here says
> 
>> Actions in a thread prior to calling `enqueue` successfully _happen-before_ the reference is removed...
> 
> This could be confusing, because "successfully" might be read to modify "happen-before". This raises questions such as "Is it possible for something to happen-before unsuccessfully?" Of course you want "successfully" to modify "enqueue" because you're relying on the definition of "successful" given previously. Suggest rewording:
> 
>> Actions in a thread prior to successful calls to `enqueue` _happen-before_ the reference is removed...

Updated, though I made it singular ("a successful call to enqueue"), since we talk about "the" reference being removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529365850
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529364758

From alanb at openjdk.org  Mon Mar 18 22:52:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Mar 2024 22:52:21 GMT
Subject: RFR: 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: <W4H6LMjZxokSSq71NxDkNNbQgPxQKAJ9unepFW6K2sU=.de53b1b9-60b7-4786-925c-9accf7681f7e@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.

test/jdk/java/nio/channels/unixdomain/Bind.java line 191:

> 189:             server.bind(null);
> 190:             UnixDomainSocketAddress usa = (UnixDomainSocketAddress)server.getLocalAddress();
> 191:             usa.getPath().toFile().deleteOnExit();

The test already deletes the file, I think you just want a try-finally here, same comment on a few other tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1529408542

From redestad at openjdk.org  Mon Mar 18 22:54:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 18 Mar 2024 22:54:24 GMT
Subject: RFR: 8326941: Remove StringUTF16::isBigEndian
In-Reply-To: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
References: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
Message-ID: <dLdGmfFDX2s5QpnKIZzgyOpLCIzI2f_kC2pNoErz18I=.5471f6ca-591d-4c6f-892c-7db66c0bab57@github.com>

On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the native method `StringUTF16::isBigEndian` and its corresponding C implementation and instead rely on the `jdk.internal.misc.Unsafe::isBigEndian` method.
> 
> This PR passes tier1-3 tests.

> Initialization order

```java -Xlog:class+init -XX:-CompactStrings -version```:

Before:

[0.015s][info][class,init] 71 Initializing 'java/lang/StringUTF16' (0x000000ff00063a20) by thread "main"
[0.015s][info][class,init] 72 Initializing 'jdk/internal/util/ArraysSupport' (0x000000ff00063c20) by thread "main"
[0.015s][info][class,init] 73 Initializing 'jdk/internal/misc/Unsafe' (0x000000ff00050de0) by thread "main"


After:

[0.018s][info][class,init] 71 Initializing 'java/lang/StringUTF16' (0x0000000400063a30) by thread "main"
[0.018s][info][class,init] 72 Initializing 'jdk/internal/misc/Unsafe' (0x0000000400050de0) by thread "main"
[0.018s][info][class,init] 73 Initializing 'jdk/internal/util/ArraysSupport' (0x0000000400063c30) by thread "main"

Seems the order only changes subtly. 

> Unsafe was added 2015, a few weeks before the explicit C code was added. This might indicate the previous solution was deliberate or it might be the case, the new method was not known by the author at the time.

`sun.misc.Unsafe::isBigEndian` has existed longer, and was removed when `jdk.internal.misc.Unsafe` was added. `StringUTF16::isBigEndian` was added by JEP 254 by a group of people who I believe would have been well aware of its existence. It doesn't seem that having `StringUTF16` have a `<clinit>` dependency on `Unsafe` is problematic today, though. Perhaps `sun.misc.Unsafe` did more weird things back in 2015.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18348#issuecomment-2005200875

From jlu at openjdk.org  Tue Mar 19 00:07:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 00:07:37 GMT
Subject: RFR: JDK-8327640: Allow NumberFormat strict parsing [v2]
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: <rl0Y0vv1IjraFLkn_iIpCIFgk9X4qE08snhdc3AP55s=.d7cf85ca-0b90-4145-9c5b-86dac3bed664@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 one additional commit since the last revision:

  Replace protected field with a public getter -> isStrict().
  Replace setLenient() with setStrict() to avoid messy inversion of boolean.
  Add a leniency section to NumberFormat.
  Overhaul of NumberFormat class specification to be much more organized/readable.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/8843c56f..c3a32500

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=00-01

  Stats: 208 lines in 5 files changed: 77 ins; 54 del; 77 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 ysr at openjdk.org  Tue Mar 19 00:42:22 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 19 Mar 2024 00:42:22 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
Message-ID: <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>

On Thu, 14 Mar 2024 23:23:07 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:
> 
>   further tweaks to reachability

src/java.base/share/classes/java/lang/ref/package-info.java line 137:

> 135:  *
> 136:  * A <em>reachable</em> object is any object that can be accessed in any potential
> 137:  * continuing computation from any live thread (as stated in {@jls 12.6.1}).

This seems like somewhat loose and sloppy wording to me. "Any potential continuing computation"? "Any live thread"? Could you share a pointer to JLS 12.6.1 being referenced here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529523835

From jlu at openjdk.org  Tue Mar 19 00:48:24 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 00:48:24 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v6]
In-Reply-To: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
Message-ID: <XovkM9T-EQ1X2jzj2lvn4IuxeeKVkm6BrBxtqXNBaDE=.e920c3d1-7813-47c0-b32d-0fcb5ffd6a4d@github.com>

On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added terminal new line

The `@since 10` tags look consistent with the JDK release those methods / constructors were introduced in.

Can you update the latter years for the Oracle copyrights only in both these files, thanks.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1944702560

From alanb at openjdk.org  Tue Mar 19 01:08:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Mar 2024 01:08:20 GMT
Subject: RFR: 8328261: public lookup fails with IllegalAccessException when
 used while module system is being initialized
In-Reply-To: <enxbcyBzvO7SqGaIlSU16gzQPfMvUY1vSaFkMT6_JJM=.0401f562-8ed9-4138-b7aa-4b3fd6bc2d47@github.com>
References: <enxbcyBzvO7SqGaIlSU16gzQPfMvUY1vSaFkMT6_JJM=.0401f562-8ed9-4138-b7aa-4b3fd6bc2d47@github.com>
Message-ID: <HaYEn0r6ledPd0x4QFFyZqbErREEE-V8tQYk4fxvUOw=.38d7324d-94ae-4524-ab2e-287a2f4ccf76@github.com>

On Mon, 18 Mar 2024 17:40:26 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A simple fix.   This is caused by a bug in `VerifyAccess::isClassAccessible` that checks if a class is exported from `java.base` before the exports are fully setup.    It should check if the module system is fully initialized before checking the module exports instead.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18356#pullrequestreview-1944755743

From dholmes at openjdk.org  Tue Mar 19 02:56:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Mar 2024 02:56:24 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
Message-ID: <H4pQc-SO2nGCdT2y8RyI3gUQu7rlBzLIat2cOMlcnfI=.7a4eb42e-2cc8-4c21-a1c2-6a1b54113187@github.com>

On Tue, 19 Mar 2024 00:40:02 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 137:
> 
>> 135:  *
>> 136:  * A <em>reachable</em> object is any object that can be accessed in any potential
>> 137:  * continuing computation from any live thread (as stated in {@jls 12.6.1}).
> 
> This seems like somewhat loose and sloppy wording to me. "Any potential continuing computation"? "Any live thread"? Could you share a pointer to JLS 12.6.1 being referenced here?

https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.6.1

> A reachable object is any object that can be accessed in any potential continuing computation from any live thread. 

It may be "loose" because the devil is in the details when it comes to reachability, but I disagree that it is "sloppy". This expresses reachability in simple terms, as a "first-order" or "Newtonian" model. There are of course "Quantum" effects that need to be dealt with in practice. The JLS alludes to this with:
> Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529617062

From pminborg at openjdk.org  Tue Mar 19 08:49:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 19 Mar 2024 08:49:24 GMT
Subject: RFR: 8326941: Remove StringUTF16::isBigEndian
In-Reply-To: <dLdGmfFDX2s5QpnKIZzgyOpLCIzI2f_kC2pNoErz18I=.5471f6ca-591d-4c6f-892c-7db66c0bab57@github.com>
References: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
 <dLdGmfFDX2s5QpnKIZzgyOpLCIzI2f_kC2pNoErz18I=.5471f6ca-591d-4c6f-892c-7db66c0bab57@github.com>
Message-ID: <FO22HYa7SGsXpL0kC4KK9KB7uuiKS_saxkAclERtQJM=.7e1f50a2-8f96-4238-9761-e1c0f4ccfe6c@github.com>

On Mon, 18 Mar 2024 22:51:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR proposes to remove the native method `StringUTF16::isBigEndian` and its corresponding C implementation and instead rely on the `jdk.internal.misc.Unsafe::isBigEndian` method.
>> 
>> This PR passes tier1-3 tests.
>
>> Initialization order
> 
> ```java -Xlog:class+init -XX:-CompactStrings -version```:
> 
> Before:
> 
> [0.015s][info][class,init] 71 Initializing 'java/lang/StringUTF16' (0x000000ff00063a20) by thread "main"
> [0.015s][info][class,init] 72 Initializing 'jdk/internal/util/ArraysSupport' (0x000000ff00063c20) by thread "main"
> [0.015s][info][class,init] 73 Initializing 'jdk/internal/misc/Unsafe' (0x000000ff00050de0) by thread "main"
> 
> 
> After:
> 
> [0.018s][info][class,init] 71 Initializing 'java/lang/StringUTF16' (0x0000000400063a30) by thread "main"
> [0.018s][info][class,init] 72 Initializing 'jdk/internal/misc/Unsafe' (0x0000000400050de0) by thread "main"
> [0.018s][info][class,init] 73 Initializing 'jdk/internal/util/ArraysSupport' (0x0000000400063c30) by thread "main"
> 
> Seems the order only changes subtly. 
> 
>> Unsafe was added 2015, a few weeks before the explicit C code was added. This might indicate the previous solution was deliberate or it might be the case, the new method was not known by the author at the time.
> 
> `sun.misc.Unsafe::isBigEndian` has existed longer, and was removed when `jdk.internal.misc.Unsafe` was added. `StringUTF16::isBigEndian` was added by JEP 254 by a group of people who I believe would have been well aware of its existence. It doesn't seem that having `StringUTF16` have a `<clinit>` dependency on `Unsafe` is problematic today, though. Perhaps `sun.misc.Unsafe` did more weird things back in 2015.

Thanks for the clarifications @cl4es!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18348#issuecomment-2006338283

From pminborg at openjdk.org  Tue Mar 19 08:49:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 19 Mar 2024 08:49:25 GMT
Subject: Integrated: 8326941: Remove StringUTF16::isBigEndian
In-Reply-To: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
References: <vc0f2g96Y-WZgdhrWDRVVMiBJwY9HyEiGQ__FWOhS1U=.62d6e8b2-3231-44c1-92a5-844c7d70e0c6@github.com>
Message-ID: <Tr_xJ7srTPWc1ZoMYinZOT-LfBcDF-nOj7JBr95BEQE=.3035159d-909b-4e61-aea0-391ad0c1d25d@github.com>

On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the native method `StringUTF16::isBigEndian` and its corresponding C implementation and instead rely on the `jdk.internal.misc.Unsafe::isBigEndian` method.
> 
> This PR passes tier1-3 tests.

This pull request has now been integrated.

Changeset: c59c41aa
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c59c41aa6e28ab1dc59e6051f85e3e9ade251b07
Stats:     18 lines in 2 files changed: 2 ins; 13 del; 3 mod

8326941: Remove StringUTF16::isBigEndian

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/18348

From aturbanov at openjdk.org  Tue Mar 19 08:59:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 19 Mar 2024 08:59:23 GMT
Subject: RFR: JDK-8327640: Allow NumberFormat strict parsing [v2]
In-Reply-To: <rl0Y0vv1IjraFLkn_iIpCIFgk9X4qE08snhdc3AP55s=.d7cf85ca-0b90-4145-9c5b-86dac3bed664@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
 <rl0Y0vv1IjraFLkn_iIpCIFgk9X4qE08snhdc3AP55s=.d7cf85ca-0b90-4145-9c5b-86dac3bed664@github.com>
Message-ID: <EvPX2cY93CUliSON9s06Ecx0oqLAidIj1R60PORW5ig=.b58a7655-e11d-4a02-a831-cb85ee8dbaf6@github.com>

On Tue, 19 Mar 2024 00:07:37 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 one additional commit since the last revision:
> 
>   Replace protected field with a public getter -> isStrict().
>   Replace setLenient() with setStrict() to avoid messy inversion of boolean.
>   Add a leniency section to NumberFormat.
>   Overhaul of NumberFormat class specification to be much more organized/readable.

src/java.base/share/classes/java/text/DecimalFormat.java line 2419:

> 2417:             if (gotPositive) {
> 2418:                 boolean containsPosSuffix =
> 2419:                         text.regionMatches(position, positiveSuffix,0, positiveSuffix.length());

Suggestion:

                        text.regionMatches(position, positiveSuffix, 0, positiveSuffix.length());

src/java.base/share/classes/java/text/DecimalFormat.java line 2426:

> 2424:             if (gotNegative) {
> 2425:                 boolean containsNegSuffix =
> 2426:                         text.regionMatches(position, negativeSuffix,0, negativeSuffix.length());

Suggestion:

                        text.regionMatches(position, negativeSuffix, 0, negativeSuffix.length());

src/java.base/share/classes/java/text/DecimalFormat.java line 2428:

> 2426:                         text.regionMatches(position, negativeSuffix,0, negativeSuffix.length());
> 2427:                 boolean endsWithNegSuffix =
> 2428:                         containsNegSuffix && text.length() == position  + negativeSuffix.length();

Suggestion:

                        containsNegSuffix && text.length() == position + negativeSuffix.length();

src/java.base/share/classes/java/text/DecimalFormat.java line 2482:

> 2480:         // process digits or Inf, find decimal position
> 2481:         status[STATUS_INFINITE] = false;
> 2482:         if (!isExponent && text.regionMatches(position, symbols.getInfinity(),0,

Suggestion:

        if (!isExponent && text.regionMatches(position, symbols.getInfinity(), 0,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529965478
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529965780
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529966184
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529966645

From sroy at openjdk.org  Tue Mar 19 10:00:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 19 Mar 2024 10:00:21 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
Message-ID: <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>

On Mon, 18 Mar 2024 17:40:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > In AIX, we have an usecase where shared libraries have certain member objects to be referred to. E.g libclang.a(shr_64.o) .
> 
> Would you happen to know any official documentation which explains that AIX syntax?
> 

https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command
Text : 

**autoload:?path/file(member) | Automatically load the archive member.
-- | --**
Autoload is a  flag used to load archive members. The format of the path is mentioned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1530054525

From sroy at openjdk.org  Tue Mar 19 10:04:25 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 19 Mar 2024 10:04:25 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
Message-ID: <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>

On Tue, 19 Mar 2024 09:58:04 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> In AIX, we have an usecase where shared libraries have certain member objects to be referred to. E.g libclang.a(shr_64.o) .
>> 
>> Would you happen to know any official documentation which explains that AIX syntax? 
>> 
>>> When we provide the path to loadLibrary()
>> 
>> Do you mean some application code is calling the `System.loadLibrary()` method with such values?
>
>> > In AIX, we have an usecase where shared libraries have certain member objects to be referred to. E.g libclang.a(shr_64.o) .
>> 
>> Would you happen to know any official documentation which explains that AIX syntax?
>> 
> 
> https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command
> Text : 
> 
> **autoload:?path/file(member) | Automatically load the archive member.
> -- | --**
> Autoload is a  flag used to load archive members. The format of the path is mentioned.

> Do you mean some application code is calling the `System.loadLibrary()` method with such values?

Yes we are trying to install liblcang and also jextract and it fails with errors.

Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
 
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
        at java.base/java.lang.System.loadLibrary(System.java:2063)
        at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
        at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
        at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
        at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
        at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
        at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
        at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))


The actual member is libclang.a(libclang.so.16)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1530059834

From sgehwolf at openjdk.org  Tue Mar 19 10:29:27 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Mar 2024 10:29:27 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v21]
In-Reply-To: <2Hq_LiXdJEZfVaOwfei9KUzX3hiqw-ocgszyC0R9iCo=.abdcb5bf-f1ac-438e-83cd-37408ee154c4@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <zLp_bBwO1X5tmnnKaLKzcZJ9KdlAo-11G7xXflih53k=.970ec66c-6ec4-4d74-85c5-b55cdb0e7e40@github.com>
 <2Hq_LiXdJEZfVaOwfei9KUzX3hiqw-ocgszyC0R9iCo=.abdcb5bf-f1ac-438e-83cd-37408ee154c4@github.com>
Message-ID: <RyrmC1THIeTiDuljoSqJ2Sl042TZNSVprvh1UmxE22I=.e47883aa-68ba-4827-8668-fdb787d109be@github.com>

On Mon, 18 Mar 2024 20:18:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This is what I understand from your implementation:
> 
>     1. create a regular JDK image under `support/images/runtime-link-initial-jdk` using jlink from the exploded JDK build
> 
>     2. create a linkable JDK image under `images/jdk` using jlink from the exploded JDK build with jlink command-line options used in step 1 plus
> 
> 
> ```
> -create-linkable-runtime jimage=support/images/runtime-link-initial-jdk/lib/modules:module-path=support/images/jmods
> ```
> 
> jlink in step 2 has to run through the plugin pipeline as in step 1 and also the `create-linkable-runtime` plugin to generate the diffs and record the metadata for reconstituting the modules from the images (without the packaged modules).
> 
> Step 2 re-creates a new jimage file from the input packaged modules while the diffs are generated from `runtime-link-initial-jdk/lib/modules`. In this approach, step 1 and step 2 assume that the same set of modules are linked and set set of plugin transformation is applied except `--create-linkable-runtime` as in step 1, i.e. it relies on the makefile to pass proper commands to step 1 and step 2 to result in the same `lib/modules` minus the new metadata and diffs added by `--create-linkable-runtime`.

That's correct.

> The original idea we discussed is that step 1 creates a normal JDK image (as step 1 above) and then step 2 solely creates a new JDK linkable image without involving plugin pipeline that would be a simpler model. The idea was something like this:
> 
> ```
> $ runtime-link-initial-jdk/bin/jlink -create-linkable-runtime support/images/jmods --output images/jdk
> ```
> 
> jlink `--create-linkable-runtime` will copy everything under `runtime-link-initial-jdk` (the runtime executing jlink) except `lib/modules` to `images/jdk` and create a new jimage `lib/modules` from `runtime-link-initial-jdk/lib/modules` (include diffs and metadata files).
> 
> Have you seen any issues with this approach over your current approach which involves the plugin transformation in both step 1 and 2?

Yes, a couple of issues. In no particular order:

- `jlink` is the only tool capable of generating the `jimage` file (`lib/modules`) as of yet. See class `ImageFileCreator`.
- `jlink` is currently designed in a way to work on a) some form of an `Archive` (packaged modules, really) and b) a plugin pipeline. a) changes with this patch due to introduction of `JRTArchive`, but this archive relies on the "diff parts" as well as the "non-class-resource" parts. So in order to "use" `lib/modules` from `runtime-link-initial-jdk` we have a chicken and egg problem: Use `JRTArchive` before it's ready to be used. Or we'd have to distinguish between `JRTArchive` usage at JDK build time and `JRTArchive` usage at jlink runtime (after the JDK build has completed).
- Let's assume the `JRTArchive` issue as described above is solved then we wouldn't have a way to **not** run any plugins at jlink time, unless we specify `--disable-plugin <name>` for each. Even if we had, then there is no guarantee to present the resources in the `jimage` file in the desired order.
- Let's assume we don't use `JRTArchive` and use an `Archive` implementation from packaged modules instead. We cannot use that approach either, since we'd miss generated resources from plugins (like `--system-modules`, `--release-info` and `--generate-jli-classes`) or change the order of the resources in the `jimage` (plugin `--order-resources`) or have a different compression level (plugin `--compress`). There is more, which affects generation of the actual `jimage` file.
- The way I understand the `jimage` [format](https://cr.openjdk.org/~sgehwolf/leyden/jimage_visualization_1.png) and how it's generated, it doesn't allow for post-factum addition of resources for a module. Those need to be known at jlink pipeline run time so that this information is available when the actual image format is being serialized.

So unless, I'm missing something, the approach that I've taken would be the one with less compatibility impact. Thoughts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2006724776

From duke at openjdk.org  Tue Mar 19 10:54:41 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 10:54:41 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v7]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  update the latter years for the Oracle copyrights

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/abc5a6ab..8bcc364f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=05-06

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032

PR: https://git.openjdk.org/jdk/pull/18032

From duke at openjdk.org  Tue Mar 19 10:54:41 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 10:54:41 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v6]
In-Reply-To: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
Message-ID: <AzDSHkHxsYiIZjvEbYs9mOtKyeitmU11N82MEW6miEg=.fc52ea51-7905-4cfd-a8e6-0e50e63493f2@github.com>

On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added terminal new line

I have updated them

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2006812767

From sgehwolf at openjdk.org  Tue Mar 19 11:17:39 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Mar 2024 11:17:39 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v22]
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: <EYeqyTMxTGgyBvii1AWjH0HLOJehhtBQZku5RjhOYNo=.cb818926-3aa5-441f-a0f5-9760856fe5fa@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 90 commits:

 - Fix race wrt. first and second image generation.
   
   The second, create-linkable-runtime enabled link, needs to depend
   on the first (default jdk link). Also fix an issue with respect to
   which support dir is being used for which link.
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Fix comment.
 - Review feedback and Windows build fix (FixPath)
 - Fix comment in autoconf file
 - Remove no longer needed plugin options
 - Restore GenerateJLIClassesPluginTest.java
 - Update some comments
 - Add copyright header/comments
 - Ensure build-only plugin isn't propagated to the final image
 - ... and 80 more: https://git.openjdk.org/jdk/compare/fc0472ba...e25dd440

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=21
  Stats: 3549 lines in 38 files changed: 3413 ins; 111 del; 25 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 dnsimon at openjdk.org  Tue Mar 19 11:18:28 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 19 Mar 2024 11:18:28 GMT
Subject: RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with
 -Xcomp
Message-ID: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>

The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in `-Xcomp` temporarily causes some extra memory pressure (probably due to [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause recoverable OOMEs to occur (memory is recovered when the relevant libgraal compilations complete). It also seems related to async threads used for cleaning weak references when using G1 or ZGC as I cannot reproduce the failure under `-XX:+UseSerialGC`.

Installing a global `Thread.UncaughtExceptionHandler` that ignores `OutOfMemoryError`s resolves the problem.

-------------

Commit messages:
 - ignore recoverable OOMEs

Changes: https://git.openjdk.org/jdk/pull/18098/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327176
  Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18098/head:pull/18098

PR: https://git.openjdk.org/jdk/pull/18098

From dnsimon at openjdk.org  Tue Mar 19 11:18:28 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 19 Mar 2024 11:18:28 GMT
Subject: RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with
 -Xcomp
In-Reply-To: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>
References: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>
Message-ID: <bGh50s0HYEvkcBqlR6T4LDqNybQ8B5Lqc_GJ_LriUmU=.7fb41ec3-6e0a-4aa7-85d4-8493e08e8eb5@github.com>

On Sun, 3 Mar 2024 17:01:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in `-Xcomp` temporarily causes some extra memory pressure (probably due to [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause recoverable OOMEs to occur (memory is recovered when the relevant libgraal compilations complete). It also seems related to async threads used for cleaning weak references when using G1 or ZGC as I cannot reproduce the failure under `-XX:+UseSerialGC`.
> 
> Installing a global `Thread.UncaughtExceptionHandler` that ignores `OutOfMemoryError`s resolves the problem.

I confirmed that `java/util/concurrent/Executors/UnreferencedExecutor.java` still fails if the [fix applied to ThreadContainers.java](https://github.com/openjdk/jdk/commit/ada416e66cbff6c8e631bf352acc0744c248740b#diff-1e347b9a95cc4fe81a01ca70e4122a73a65d99a69668c7567abb2a6067f8cc6dL68) is reverted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18098#issuecomment-1975231258

From duke at openjdk.org  Tue Mar 19 11:23:36 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 11:23:36 GMT
Subject: RFR: JDK-8326951 Missing @since Tags [v2]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@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).

Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision:

 - Revert "fix rest of private/public since tags"
   
   This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1.
 - Revert "removed unnecessary @ since tags"
   
   This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660.
 - removed unnecessary @ since tags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/2c04a9d8..ba97724d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=00-01

  Stats: 10 lines in 10 files changed: 8 ins; 0 del; 2 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 jpai at openjdk.org  Tue Mar 19 11:23:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Mar 2024 11:23:36 GMT
Subject: RFR: JDK-8326951 Missing @since Tags [v2]
In-Reply-To: <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
Message-ID: <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>

On Tue, 19 Mar 2024 11:21:14 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> 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).
>
> Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "fix rest of private/public since tags"
>    
>    This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1.
>  - Revert "removed unnecessary @ since tags"
>    
>    This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660.
>  - removed unnecessary @ since tags

src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68:

> 66:      *
> 67:      * @return {@inheritDoc java.security.AsymmetricKey}
> 68:      * @since 22

Hello Nizar, are the removal of `@since` in this PR intentional? I haven't checked all of them, but this specific removal appears incorrect, since this method was indeed introduced in Java 22 as part of https://bugs.openjdk.org/browse/JDK-8318096.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1526987579

From duke at openjdk.org  Tue Mar 19 11:23:36 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 11:23:36 GMT
Subject: RFR: JDK-8326951 Missing @since Tags [v2]
In-Reply-To: <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
 <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>
Message-ID: <K6SpdFx7vEtLn0ORV6AVig5Z-0g9-vDUGpL8xlMMxdI=.7f224f25-dd6b-4d00-9e0d-cf76cf6bb8fb@github.com>

On Sat, 16 Mar 2024 00:20:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Revert "fix rest of private/public since tags"
>>    
>>    This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1.
>>  - Revert "removed unnecessary @ since tags"
>>    
>>    This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660.
>>  - removed unnecessary @ since tags
>
> src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68:
> 
>> 66:      *
>> 67:      * @return {@inheritDoc java.security.AsymmetricKey}
>> 68:      * @since 22
> 
> Hello Nizar, are the removal of `@since` in this PR intentional? I haven't checked all of them, but this specific removal appears incorrect, since this method was indeed introduced in Java 22 as part of https://bugs.openjdk.org/browse/JDK-8318096.

Hello Jaikiran,
in jdk21 DHPPublicKey did have a [getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244) method, so it is not new in jdk 22. It also existed [before that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252)

If you haven't looked at the other cases, I was about to group the changes related to the Key interfaces in a separate PR if that's fine. let me know what you think

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1527393223

From jlahoda at openjdk.org  Tue Mar 19 11:23:36 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 19 Mar 2024 11:23:36 GMT
Subject: RFR: JDK-8326951 Missing @since Tags [v2]
In-Reply-To: <K6SpdFx7vEtLn0ORV6AVig5Z-0g9-vDUGpL8xlMMxdI=.7f224f25-dd6b-4d00-9e0d-cf76cf6bb8fb@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
 <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>
 <K6SpdFx7vEtLn0ORV6AVig5Z-0g9-vDUGpL8xlMMxdI=.7f224f25-dd6b-4d00-9e0d-cf76cf6bb8fb@github.com>
Message-ID: <HklJY0-bc9olSZa06HvI31hvTu-tSzDJq3851ndtq6k=.d8d874f5-f456-4a88-9e8b-9803b210a71a@github.com>

On Sun, 17 Mar 2024 01:20:17 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java line 68:
>> 
>>> 66:      *
>>> 67:      * @return {@inheritDoc java.security.AsymmetricKey}
>>> 68:      * @since 22
>> 
>> Hello Nizar, are the removal of `@since` in this PR intentional? I haven't checked all of them, but this specific removal appears incorrect, since this method was indeed introduced in Java 22 as part of https://bugs.openjdk.org/browse/JDK-8318096.
>
> Hello Jaikiran,
> in jdk21 DHPPublicKey did have a [getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244) method, so it is not new in jdk 22. It also existed [before that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252)
> 
> If you haven't looked at the other cases, I was about to group the changes related to the Key interfaces in a separate PR if that's fine. let me know what you think

Hello,

While the override of `getParams` in `DHPublicKey` was added, the `getParams` method has been inherited to `DHPublicKey` for a long time from `DHKey`. E.g., I can take this:

import javax.crypto.interfaces.DHPublicKey;

public class DhkeyTest {

    public static void main(DHPublicKey key) {
        System.err.println(key.getParams());
    }
    
}


and compile using JDK 8 without any compile-time errors. So, it would make more sense to me to not add the `@since` for it.

I believe Nizar will separate the changes to the Key interfaces into a separate PR, so we can discuss in more detail there.

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1528625403

From jpai at openjdk.org  Tue Mar 19 11:23:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Mar 2024 11:23:36 GMT
Subject: RFR: JDK-8326951 Missing @since Tags [v2]
In-Reply-To: <HklJY0-bc9olSZa06HvI31hvTu-tSzDJq3851ndtq6k=.d8d874f5-f456-4a88-9e8b-9803b210a71a@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <UDkEmHVP18ceH_Zc-W56n3MtJqvofrrMdHXR47S8xvE=.032b9f79-a4f8-4a90-a82f-4a804f33e3ae@github.com>
 <YuZPlDfp1kV-p6Egxo-3hVahmZEIXwEYtGhOyPKxmD8=.1e7d4118-b461-40e1-b3ed-10865e710dcf@github.com>
 <K6SpdFx7vEtLn0ORV6AVig5Z-0g9-vDUGpL8xlMMxdI=.7f224f25-dd6b-4d00-9e0d-cf76cf6bb8fb@github.com>
 <HklJY0-bc9olSZa06HvI31hvTu-tSzDJq3851ndtq6k=.d8d874f5-f456-4a88-9e8b-9803b210a71a@github.com>
Message-ID: <xTb03h9jOHl392fvK_Tu_3LyXqlMod3dSmd2uLzaJMg=.2fa387a2-6a47-4bd2-b882-ea74520d9896@github.com>

On Mon, 18 Mar 2024 14:02:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Hello Jaikiran,
>> in jdk21 DHPPublicKey did have a [getParams()](https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L244) method, so it is not new in jdk 22. It also existed [before that](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java#L252)
>> 
>> If you haven't looked at the other cases, I was about to group the changes related to the Key interfaces in a separate PR if that's fine. let me know what you think
>
> Hello,
> 
> While the override of `getParams` in `DHPublicKey` was added, the `getParams` method has been inherited to `DHPublicKey` for a long time from `DHKey`. E.g., I can take this:
> 
> import javax.crypto.interfaces.DHPublicKey;
> 
> public class DhkeyTest {
> 
>     public static void main(DHPublicKey key) {
>         System.err.println(key.getParams());
>     }
>     
> }
> 
> 
> and compile using JDK 8 without any compile-time errors. So, it would make more sense to me to not add the `@since` for it.
> 
> I believe Nizar will separate the changes to the Key interfaces into a separate PR, so we can discuss in more detail there.
> 
> Thanks!

Hello Jan, interesting. I hadn't noticed that `javax.crypto.interfaces.DHPublicKey` already was exposing `getParams()` in earlier versions because `javax.crypto.interfaces.DHPublicKey` extends from `javax.crypto.interfaces.DHKey` which has the `getParams()` method.

 > I believe Nizar will separate the changes to the Key interfaces into a separate PR, so we can discuss in more detail there.

That sounds fine to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1528641492

From duke at openjdk.org  Tue Mar 19 12:15:23 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 19 Mar 2024 12:15:23 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <UeTlF6XlFqMijlqRAt_EBrPYzMSOjLmvqPXej5m4Qz8=.c54e472c-1b98-4817-9c09-34b6188f7797@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>
Message-ID: <EmNY_uTyEOlQSXcmIIP_JdGUYEvrr25wSaHfdlnNwtQ=.e295a2fe-1c42-4f93-9b7f-acea254548af@github.com>

On Tue, 12 Mar 2024 14:03:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore comment
>
> 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?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2007020206

From goetz at openjdk.org  Tue Mar 19 15:04:34 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Tue, 19 Mar 2024 15:04:34 GMT
Subject: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could not
 reserve enough space for 2097152KB object heap
Message-ID: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>

?rve enough space for 2097152KB object heap

I would like to fix this as the two related issues mentioned in the JBS bug.
We see it currently in most GHA runs.

-------------

Commit messages:
 - 8328524: [x86] StringRepeat.java failure on linux-x86: Could not reserve enough space for 2097152KB object heap

Changes: https://git.openjdk.org/jdk/pull/18380/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18380&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328524
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18380/head:pull/18380

PR: https://git.openjdk.org/jdk/pull/18380

From rriggs at openjdk.org  Tue Mar 19 15:08:22 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Mar 2024 15:08:22 GMT
Subject: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could
 not reserve enough space for 2097152KB object heap
In-Reply-To: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
References: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
Message-ID: <V9BSC9VhGNMSbMCCTIF7-oRrTyH7rI-13xzBL178_H0=.c9c62e55-2e29-4139-8e96-3c42d6e9f7c3@github.com>

On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?rve enough space for 2097152KB object heap
> 
> I would like to fix this as the two related issues mentioned in the JBS bug.
> We see it currently in most GHA runs.

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18380#pullrequestreview-1946547791

From mdoerr at openjdk.org  Tue Mar 19 15:08:22 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 19 Mar 2024 15:08:22 GMT
Subject: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could
 not reserve enough space for 2097152KB object heap
In-Reply-To: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
References: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
Message-ID: <I6wXa9a0aF8uUrEoZ5C7e3IftXIxsEkeQtAWvym5tLU=.51e1c6e7-5dd8-4ea2-9201-2eb402f66ab7@github.com>

On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?rve enough space for 2097152KB object heap
> 
> I would like to fix this as the two related issues mentioned in the JBS bug.
> We see it currently in most GHA runs.

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18380#pullrequestreview-1946550205

From daniel.fuchs at oracle.com  Tue Mar 19 15:19:52 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 19 Mar 2024 15:19:52 +0000
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
Message-ID: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>

Hi,

I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the 
Core Libraries Group [4].

Per-Ake is an OpenJDK Reviewer, a committer in the
Leyden and Panama projects, and a member of Oracle?s
Java Core Libraries team.

Per-Ake has been actively participating in the development of
the JDK and Panama projects for several years, and is one of
the co-author of the Implementation of Foreign Function and
Memory API (Third Preview) [2].
His contributions include more than 80 commits in the JDK [3]


Votes are due by 16:00 UTC on April 2, 2024.

Only current Members of the Core Libraries Group [4] are eligible to 
vote on this nomination. Votes must be cast in the open by replying to 
this mailing list.

For Lazy Consensus voting instructions, see [5].

best regards,

-- daniel

[1] https://openjdk.org/census#pminborg
[2] 
https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
[3] 
https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg&type=commits
[4] https://openjdk.org/census#core-libs
[5] https://openjdk.org/groups/#member-vote


From lance.andersen at oracle.com  Tue Mar 19 15:22:49 2024
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 19 Mar 2024 15:22:49 +0000
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <26C02BCF-3735-488A-990C-2F78323E0D8D@oracle.com>

Vote: yes

On Mar 19, 2024, at 11:19?AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

Hi,

I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4].

Per-Ake is an OpenJDK Reviewer, a committer in the
Leyden and Panama projects, and a member of Oracle?s
Java Core Libraries team.

Per-Ake has been actively participating in the development of
the JDK and Panama projects for several years, and is one of
the co-author of the Implementation of Foreign Function and
Memory API (Third Preview) [2].
His contributions include more than 80 commits in the JDK [3]


Votes are due by 16:00 UTC on April 2, 2024.

Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

best regards,

-- daniel

[1] https://openjdk.org/census#pminborg
[2] https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
[3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg&type=commits
[4] https://openjdk.org/census#core-libs
[5] https://openjdk.org/groups/#member-vote


[oracle_sig_logo.gif]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240319/928a73a4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240319/928a73a4/oracle_sig_logo-0001.gif>

From prappo at openjdk.org  Tue Mar 19 15:25:26 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 19 Mar 2024 15:25:26 GMT
Subject: Integrated: 8297879: javadoc link to preview JEP 1000 has grouping
 character comma
In-Reply-To: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>
References: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com>
Message-ID: <7PArJXG1ZKRHbwf2SBnuB6z1YIOC9iYcMgHNX_MHmSI=.aa8998d0-08ec-44de-88e1-781df1a695ae@github.com>

On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple bugfix to properly construct links to preview JEPs.
> 
> The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`.
> 
> For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were:
> 
>  1. slap `noreg-hard` on the JBS bug and skip testing
>  2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base`
> 
> While (1) is insufficient, (2) seems overkill in this case.

This pull request has now been integrated.

Changeset: f140eb4c
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f140eb4c3a47e1479d62fe1eef16bbbea92892bc
Stats:     5 lines in 3 files changed: 0 ins; 0 del; 5 mod

8297879: javadoc link to preview JEP 1000 has grouping character comma

Reviewed-by: jjg, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/18350

From raffaello.giulietti at oracle.com  Tue Mar 19 15:39:27 2024
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Tue, 19 Mar 2024 16:39:27 +0100
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <0fcd36da-1795-4d65-bd20-eb61fad4244b@oracle.com>

Vote: yes

On 2024-03-19 16:19, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the 
> Core Libraries Group [4].
> 
> Per-Ake is an OpenJDK Reviewer, a committer in the
> Leyden and Panama projects, and a member of Oracle?s
> Java Core Libraries team.
> 
> Per-Ake has been actively participating in the development of
> the JDK and Panama projects for several years, and is one of
> the co-author of the Implementation of Foreign Function and
> Memory API (Third Preview) [2].
> His contributions include more than 80 commits in the JDK [3]
> 
> 
> Votes are due by 16:00 UTC on April 2, 2024.
> 
> Only current Members of the Core Libraries Group [4] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> best regards,
> 
> -- daniel
> 
> [1] https://openjdk.org/census#pminborg
> [2] 
> https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
> [3] 
> https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg&type=commits
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
> 

From sgehwolf at openjdk.org  Tue Mar 19 15:44:20 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Mar 2024 15:44:20 GMT
Subject: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could
 not reserve enough space for 2097152KB object heap
In-Reply-To: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
References: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
Message-ID: <G2r_CjBVYUwPI74YzTa6RhFio-x9cnq_gAdxYN_12Qc=.5127548d-5543-4c7d-b81d-bed2445a8941@github.com>

On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?rve enough space for 2097152KB object heap
> 
> I would like to fix this as the two related issues mentioned in the JBS bug.
> We see it currently in most GHA runs.

Marked as reviewed by sgehwolf (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18380#pullrequestreview-1946656126

From naoto.sato at oracle.com  Tue Mar 19 15:53:01 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 19 Mar 2024 08:53:01 -0700
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <ce89cb0d-8597-44d4-bc1f-fd5b4119c142@oracle.com>

Vote: yes

Naoto

On 3/19/24 8:19 AM, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the 
> Core Libraries Group [4].
> 
> Per-Ake is an OpenJDK Reviewer, a committer in the
> Leyden and Panama projects, and a member of Oracle?s
> Java Core Libraries team.
> 
> Per-Ake has been actively participating in the development of
> the JDK and Panama projects for several years, and is one of
> the co-author of the Implementation of Foreign Function and
> Memory API (Third Preview) [2].
> His contributions include more than 80 commits in the JDK [3]
> 
> 
> Votes are due by 16:00 UTC on April 2, 2024.
> 
> Only current Members of the Core Libraries Group [4] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> best regards,
> 
> -- daniel
> 
> [1] https://openjdk.org/census#pminborg
> [2] 
> https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
> [3] 
> https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg&type=commits
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
> 

From duke at openjdk.org  Tue Mar 19 15:54:34 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 15:54:34 GMT
Subject: RFR: JDK-8326951 Missing @since Tags [v3]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <7uRhl1-KqL4yOiC8H_8iDbliZlj9nB3I5oC6Kf9FeV8=.8bbf14de-6d8a-4ae9-b6bb-a964944396cc@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).

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  added since tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/ba97724d..3cec63e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=01-02

  Stats: 1 line in 1 file changed: 1 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 mchung at openjdk.org  Tue Mar 19 15:58:27 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 19 Mar 2024 15:58:27 GMT
Subject: Integrated: 8328261: public lookup fails with IllegalAccessException
 when used while module system is being initialized
In-Reply-To: <enxbcyBzvO7SqGaIlSU16gzQPfMvUY1vSaFkMT6_JJM=.0401f562-8ed9-4138-b7aa-4b3fd6bc2d47@github.com>
References: <enxbcyBzvO7SqGaIlSU16gzQPfMvUY1vSaFkMT6_JJM=.0401f562-8ed9-4138-b7aa-4b3fd6bc2d47@github.com>
Message-ID: <IosUkKxhb8GEX38y1JOydoAvCzrnsMQIiyTr4fpfzbo=.31e9a0fd-7c43-459e-9c98-d161ca9a1328@github.com>

On Mon, 18 Mar 2024 17:40:26 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A simple fix.   This is caused by a bug in `VerifyAccess::isClassAccessible` that checks if a class is exported from `java.base` before the exports are fully setup.    It should check if the module system is fully initialized before checking the module exports instead.

This pull request has now been integrated.

Changeset: 13292168
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/132921683bc9860ce2ba89729dcd989b10b89aa2
Stats:     9 lines in 1 file changed: 1 ins; 5 del; 3 mod

8328261: public lookup fails with IllegalAccessException when used while module system is being initialized

Reviewed-by: rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/18356

From brian.burkhalter at oracle.com  Tue Mar 19 16:01:15 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 19 Mar 2024 16:01:15 +0000
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <201791E5-E015-49C0-8047-8569810E5B6F@oracle.com>

Vote: yes

From mdoerr at openjdk.org  Tue Mar 19 16:12:22 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 19 Mar 2024 16:12:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
Message-ID: <hhdo2yVgNQ5cnBWuCeGky_v3ctBkhBUTzfZu1HJO1MU=.23a2a11a-607b-4e78-bca0-b6f24e8bce86@github.com>

On Tue, 19 Mar 2024 10:01:31 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> > In AIX, we have an usecase where shared libraries have certain member objects to be referred to. E.g libclang.a(shr_64.o) .
>>> 
>>> Would you happen to know any official documentation which explains that AIX syntax?
>>> 
>> 
>> https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command
>> Text : 
>> 
>> **autoload:?path/file(member) | Automatically load the archive member.
>> -- | --**
>> Autoload is a  flag used to load archive members. The format of the path is mentioned.
>
>> Do you mean some application code is calling the `System.loadLibrary()` method with such values?
> 
> Yes we are trying to install liblcang and also jextract and it fails with errors.
> 
> Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>  
>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>         at java.base/java.lang.System.loadLibrary(System.java:2063)
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
> 
> 
> The actual member is libclang.a(libclang.so.16)

Is this also needed for any other operating system? If not, I think the new code should only be used if `OperatingSystem.isAix()` (`import jdk.internal.util.OperatingSystem;`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1530686989

From jlu at openjdk.org  Tue Mar 19 16:16:24 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 16:16:24 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v7]
In-Reply-To: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
Message-ID: <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>

On Tue, 19 Mar 2024 10:54:41 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the latter years for the Oracle copyrights

src/java.base/share/classes/java/nio/channels/Channels.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved.

Thanks for updating, but needs a little adjustment.

Rather than adding a third year, the format should be: "original year, current year, Oracle ..."
So in this case ->  `2000, 2024,`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530694415

From aefimov at openjdk.org  Tue Mar 19 16:24:26 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 19 Mar 2024 16:24:26 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v8]
In-Reply-To: <IGkgkob8lvI2h642AnVStJOe_UU6SHNtlsdm2eZid4s=.08105a6e-e49a-4d1f-921e-f9fce3864a68@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <IGkgkob8lvI2h642AnVStJOe_UU6SHNtlsdm2eZid4s=.08105a6e-e49a-4d1f-921e-f9fce3864a68@github.com>
Message-ID: <n9IOkLBLSzms1pQIGfaBa-bjAiwlyORtnxA00XPTn5k=.64da35f4-0320-4fd1-b681-fd0fd35885ed@github.com>

On Thu, 14 Mar 2024 21:59:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer 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:
> 
>  - Update module-info text
>  - Merge branch 'master' into JDK-8325579
>  - Indentation
>  - Merge branch 'master' into JDK-8325579
>  - Review feedback
>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>  - Merge branch 'master' into JDK-8325579
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/bc0070cb...10271159

The latest version looks good to me with a couple minor comments and suggestions.

src/java.naming/share/classes/module-info.java line 42:

> 40:  *         <br>The value of this environment property specifies the fully
> 41:  *         qualified class name of the socket factory used by the LDAP provider.
> 42:  *         This class must implement the javax.net.SocketFactory abstract class

You could add a link to the `SocketFactory` class here: 
Suggestion:

 *         This class must implement the {@link javax.net.SocketFactory} abstract class

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 164:

> 162:                     if (CustomSocketFactory.customSocket.closeMethodCalledCount() <= 0) {
> 163:                         System.err.println("Custom Socket was not closed.");
> 164:                         System.exit(-1);

Can we update test not to use `System.exit` and replace it with throwing `new RuntimeException`, something like:
Suggestion:

                        throw new RuntimeException("Custom Socket was not closed");

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 177:

> 175:                     ctx.close();
> 176:                     if (!checkSocketClosed(sock)) {
> 177:                         System.exit(-1);

Can be replaced with:
Suggestion:

                        throw new RuntimeException("Socket isn't closed");

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 184:

> 182:             e.printStackTrace();
> 183:             System.exit(-1);
> 184:         }

For simplification and `System.exit` removal purposes this catch block can be removed with addition of `throws Exception` clause to the `main` method.
Suggestion:

        }

-------------

PR Review: https://git.openjdk.org/jdk/pull/17797#pullrequestreview-1946713010
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1530674406
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1530686689
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1530696579
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1530693641

From ysr at openjdk.org  Tue Mar 19 16:25:25 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 19 Mar 2024 16:25:25 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <H4pQc-SO2nGCdT2y8RyI3gUQu7rlBzLIat2cOMlcnfI=.7a4eb42e-2cc8-4c21-a1c2-6a1b54113187@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
 <H4pQc-SO2nGCdT2y8RyI3gUQu7rlBzLIat2cOMlcnfI=.7a4eb42e-2cc8-4c21-a1c2-6a1b54113187@github.com>
Message-ID: <isY_xkrTSpXvYHL0twZkKJu6hN4ci87qQ4XEMP19aHQ=.e325ebb1-3f42-45da-8283-e36dd28f7bb6@github.com>

On Tue, 19 Mar 2024 02:53:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/package-info.java line 137:
>> 
>>> 135:  *
>>> 136:  * A <em>reachable</em> object is any object that can be accessed in any potential
>>> 137:  * continuing computation from any live thread (as stated in {@jls 12.6.1}).
>> 
>> This seems like somewhat loose and sloppy wording to me. "Any potential continuing computation"? "Any live thread"? Could you share a pointer to JLS 12.6.1 being referenced here?
>
> https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.6.1
> 
>> A reachable object is any object that can be accessed in any potential continuing computation from any live thread. 
> 
> It may be "loose" because the devil is in the details when it comes to reachability, but I disagree that it is "sloppy". This expresses reachability in simple terms, as a "first-order" or "Newtonian" model. There are of course "Quantum" effects that need to be dealt with in practice. The JLS alludes to this with:
>> Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable.

Sorry, my use of words was sloppy here. I think I did mean loose or somewhat informal and therefore slippery.

What I was saying is that using terms such as "any continuing computation" doesn't make sense because this is referring to a current state of the computation. I'm not sure what "any continuing computation" from a state is because the concept of what constitutes the notion of "a continuing computation" has not been defined before. To me it sounds like a computation tree with nodes as state and transitions as edges and a continuing computation as a path through that tree into the future. The way it is written then, it sounds to the naive reader, or to me at least, as if the object is perpetually reachable by every thread always. I assume I am misinterpreting the intention of the writing, but it sounds too loose for a definition being invoked here in the javadoc. May be it can be tightened up a bit.

Could one state instead that "An object is reachable at a given state when some thread is able to access the object through a sequence of steps starting at that state without other threads taking any steps."  ? Or something along those lines? Or at least something tighter than the current wording that is somewhat too loose.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1530705355

From ysr at openjdk.org  Tue Mar 19 16:41:26 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 19 Mar 2024 16:41:26 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <isY_xkrTSpXvYHL0twZkKJu6hN4ci87qQ4XEMP19aHQ=.e325ebb1-3f42-45da-8283-e36dd28f7bb6@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
 <H4pQc-SO2nGCdT2y8RyI3gUQu7rlBzLIat2cOMlcnfI=.7a4eb42e-2cc8-4c21-a1c2-6a1b54113187@github.com>
 <isY_xkrTSpXvYHL0twZkKJu6hN4ci87qQ4XEMP19aHQ=.e325ebb1-3f42-45da-8283-e36dd28f7bb6@github.com>
Message-ID: <pDl9EZqWPejHCxx8BSHOdXu4z6tn4XQIBESRI9ro2SY=.2a605cec-df19-4941-ac19-a5086a560fff@github.com>

On Tue, 19 Mar 2024 16:20:55 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.6.1
>> 
>>> A reachable object is any object that can be accessed in any potential continuing computation from any live thread. 
>> 
>> It may be "loose" because the devil is in the details when it comes to reachability, but I disagree that it is "sloppy". This expresses reachability in simple terms, as a "first-order" or "Newtonian" model. There are of course "Quantum" effects that need to be dealt with in practice. The JLS alludes to this with:
>>> Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable.
>
> Sorry, my use of words was sloppy here. I think I did mean loose or somewhat informal and therefore slippery.
> 
> What I was saying is that using terms such as "any continuing computation" doesn't make sense because this is referring to a current state of the computation. I'm not sure what "any continuing computation" from a state is because the concept of what constitutes the notion of "a continuing computation" has not been defined before. To me it sounds like a computation tree with nodes as state and transitions as edges and a continuing computation as a path through that tree into the future. The way it is written then, it sounds to the naive reader, or to me at least, as if the object is perpetually reachable by every thread always. I assume I am misinterpreting the intention of the writing, but it sounds too loose for a definition being invoked here in the javadoc. May be it can be tightened up a bit.
> 
> Could one state instead that "An object is reachable at a given state when some thread is able to access the object through a sequence of steps starting at that state without other threads taking any steps."  ? Or something along those lines? Or at least something tighter than the current wording that is somewhat too loose.

In fact, it appears as if the problem is with the use of "any", which is universal in strength, whereas the intention here is existential in strength (as suggested by. my wording). Indeed, you might achieve the same effect by replacing "any" with "some" so that:

"An object is reachable if it can be accessed in some continuing computation from some live thread."

You needn't even say live because dead threads can neither take steps nor continue participating in the computation nor can they "access" objects for whatever informal notion of access. The "some continuing computation" subsumes "potential" (as in a possible future) so potential can be dropped.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1530731176

From joe.darcy at oracle.com  Tue Mar 19 16:49:40 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 19 Mar 2024 09:49:40 -0700
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <998c0ebe-a97a-48c0-b6ab-fae666e308df@oracle.com>

Vote: yes


On 3/19/2024 8:19 AM, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the 
> Core Libraries Group [4].
>
> Per-Ake is an OpenJDK Reviewer, a committer in the
> Leyden and Panama projects, and a member of Oracle?s
> Java Core Libraries team.
>
> Per-Ake has been actively participating in the development of
> the JDK and Panama projects for several years, and is one of
> the co-author of the Implementation of Foreign Function and
> Memory API (Third Preview) [2].
> His contributions include more than 80 commits in the JDK [3]
>
>
> Votes are due by 16:00 UTC on April 2, 2024.
>
> Only current Members of the Core Libraries Group [4] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
>
> For Lazy Consensus voting instructions, see [5].
>
> best regards,
>
> -- daniel
>
> [1] https://openjdk.org/census#pminborg
> [2] 
> https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
> [3] 
> https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg&type=commits
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
>

From sgehwolf at openjdk.org  Tue Mar 19 16:55:14 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Mar 2024 16:55:14 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
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: <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@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 one additional commit since the last revision:

  Move CreateLinkableRuntimePlugin to build folder
  
  Keep runtime link supporting classes in package
  jdk.tools.jlink.internal.runtimelink

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/e25dd440..5a6d2e4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=21-22

  Stats: 29 lines in 12 files changed: 14 ins; 1 del; 14 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 duke at openjdk.org  Tue Mar 19 17:02:36 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 17:02:36 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v8]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - update the copyright year to 2024
 - Revert "update the latter years for the Oracle copyrights"
   
   This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/8bcc364f..56968dcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=06-07

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032

PR: https://git.openjdk.org/jdk/pull/18032

From huizhe.wang at oracle.com  Tue Mar 19 17:04:39 2024
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 19 Mar 2024 10:04:39 -0700
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <04437f57-2676-4284-b9c4-2132f763279e@oracle.com>

Vote: yes

Joe (joehw)

On 3/19/24 8:19 AM, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the 
> Core Libraries Group [4]. 


From duke at openjdk.org  Tue Mar 19 17:08:23 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 17:08:23 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v7]
In-Reply-To: <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
 <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>
Message-ID: <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>

On Tue, 19 Mar 2024 16:13:49 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the latter years for the Oracle copyrights
>
> src/java.base/share/classes/java/nio/channels/Channels.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Thanks for updating, but needs a little adjustment.
> 
> Rather than adding a third year, the format should be: "original year, current year, Oracle ..."
> So in this case ->  `2000, 2024,`

Thanks for the explanation, I have fixed it.
I have a couple other similar PRs, is the policy to update the copyright year every time a file is changed? whether it's an addition or removal of code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530770401

From jlu at openjdk.org  Tue Mar 19 17:23:21 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 17:23:21 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v7]
In-Reply-To: <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
 <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>
 <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>
Message-ID: <Tquf1xKBVkshr66HGgVy9yVpl53oCjPH2KrSQYNq1VM=.e2fd363a-7bab-4f78-923a-6c1a153de746@github.com>

On Tue, 19 Mar 2024 17:05:50 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/channels/Channels.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved.
>> 
>> Thanks for updating, but needs a little adjustment.
>> 
>> Rather than adding a third year, the format should be: "original year, current year, Oracle ..."
>> So in this case ->  `2000, 2024,`
>
> Thanks for the explanation, I have fixed it.
> I have a couple other similar PRs, is the policy to update the copyright year every time a file is changed? whether it's an addition or removal of code?

Yes, you should update the copyright year to the current year if you make a change to the file, regardless if the change itself is "significant" or not.

Note that there are two formats: `Year1, Year2, Oracle` and `Year, Oracle`. The latter would be used if say you added a new file in 2024.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530792055

From jlu at openjdk.org  Tue Mar 19 17:32:21 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 17:32:21 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v8]
In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <GXW2-arZymX_4iLIBbcG608h4-QvxtH8P97lWY-hWeI=.6f57894b-aa5f-423e-b9a9-4f32da6a37a6@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the copyright year to 2024
>  - Revert "update the latter years for the Oracle copyrights"
>    
>    This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.

Change looks good to me, but you will need someone with reviewer status to sponsor your changes before you can integrate them.

BTW, I also added a `noreg-doc` label to your JBS issue, which just means that no tests are needed for this change as it is a documentation only change.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1946933024

From bhuang at openjdk.org  Tue Mar 19 17:58:46 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 19 Mar 2024 17:58:46 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
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: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@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/8472c31f..620f9259

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00-01

  Stats: 136 lines in 5 files changed: 36 ins; 13 del; 87 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 duke at openjdk.org  Tue Mar 19 18:02:21 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 18:02:21 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v8]
In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the copyright year to 2024
>  - Revert "update the latter years for the Oracle copyrights"
>    
>    This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.

Thank you justin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2007813492

From roger.riggs at oracle.com  Tue Mar 19 18:08:04 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 19 Mar 2024 14:08:04 -0400
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <59e9e162-bb93-4c9c-b244-3d3a7082243d@oracle.com>

Vote: Yes

On 3/19/24 11:19 AM, Daniel Fuchs wrote:
> I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the 
> Core Libraries Group [4]. 


From mchung at openjdk.org  Tue Mar 19 18:08:27 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 19 Mar 2024 18:08:27 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: <HEPQN2FO40L1Q4cnOvRawN65sDzQddC3WE3XYKPDrOw=.13735887-143a-409a-b533-48d7592907f5@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 details.    I feel the pain in extending jlink for this work as the current jlink implementation is not easily understandable and has been yearning for rewrite in my perspective (looking forward to Project Leyden's condenser model).   Really appreciate your effort for this.

IIUC, the main issue is regarding extending an jimage with additional entries in the same compression level.   The other option is to add the diffs as a separate file in the JDK image under `lib` instead of part of the jimage.   The per-module mapping metadata files can be generated as part of the normal linking as the footprint is small.  Would that simplify it?   I think the other issues may be solvable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2007823095

From mandy.chung at oracle.com  Tue Mar 19 19:04:21 2024
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 19 Mar 2024 12:04:21 -0700
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <bb9012aa-6202-4512-8b87-94aef7595e69@oracle.com>

Vote: yes

Mandy

On 3/19/24 8:19 AM, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the 
> Core Libraries Group [4].
>
> Per-Ake is an OpenJDK Reviewer, a committer in the
> Leyden and Panama projects, and a member of Oracle?s
> Java Core Libraries team.
>
> Per-Ake has been actively participating in the development of
> the JDK and Panama projects for several years, and is one of
> the co-author of the Implementation of Foreign Function and
> Memory API (Third Preview) [2].
> His contributions include more than 80 commits in the JDK [3]
>
>
> Votes are due by 16:00 UTC on April 2, 2024.
>
> Only current Members of the Core Libraries Group [4] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
>
> For Lazy Consensus voting instructions, see [5].
>
> best regards,
>
> -- daniel
>
> [1] https://openjdk.org/census#pminborg
> [2] 
> https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
> [3] 
> https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg&type=commits
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
>

From yzheng at openjdk.org  Tue Mar 19 19:06:36 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 19 Mar 2024 19:06:36 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]
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: <25CO5hMsh1UPgSEZNT3ywdBxRs7EHhYTiYxWDuakfKc=.35f7b465-36de-4152-abbe-397e92aba117@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/37232a5f..bfc323b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=00-01

  Stats: 70 lines in 11 files changed: 8 ins; 28 del; 34 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  Tue Mar 19 19:06:36 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 19 Mar 2024 19:06:36 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]
In-Reply-To: <XGgFKhPknDKGS7aGJ0DELlaueodnWAethcWem2y-5Kw=.8d88801f-6427-4504-8d5d-8d152fafd8a1@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <XGgFKhPknDKGS7aGJ0DELlaueodnWAethcWem2y-5Kw=.8d88801f-6427-4504-8d5d-8d152fafd8a1@github.com>
Message-ID: <lMmEUPIw41kfFBKuGXu2I1mb_u8vcC542FHkViKfN9A=.3a6273bd-3116-43a5-a4df-8438dbf2edac@github.com>

On Mon, 18 Mar 2024 16:55:28 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> Quite a simplification! Have you checked if there are any performance differences?

Ran https://github.com/oracle/graal/blob/master/compiler/src/org.graalvm.micro.benchmarks/src/micro/benchmarks/BigIntegerBenchmark.java
The results are

$ before change
Benchmark                                 Mode  Cnt    Score   Error  Units
BigIntegerBenchmark.bigIntMontgomeryMul  thrpt    5  122.488 ? 0.130  ops/s
BigIntegerBenchmark.bigIntMontgomerySqr  thrpt    5   76.023 ? 0.106  ops/s
BigIntegerBenchmark.bigIntMul            thrpt    5  330.130 ? 0.349  ops/s
BigIntegerBenchmark.bigIntMulAdd         thrpt    5  455.590 ? 0.663  ops/s

$ after change
Benchmark                                 Mode  Cnt    Score   Error  Units
BigIntegerBenchmark.bigIntMontgomeryMul  thrpt    5  124.407 ? 0.045  ops/s
BigIntegerBenchmark.bigIntMontgomerySqr  thrpt    5   76.036 ? 0.232  ops/s
BigIntegerBenchmark.bigIntMul            thrpt    5  329.836 ? 0.953  ops/s
BigIntegerBenchmark.bigIntMulAdd         thrpt    5  456.485 ? 0.766  ops/s

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2007922439

From darcy at openjdk.org  Tue Mar 19 19:34:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 19 Mar 2024 19:34:24 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <UeTlF6XlFqMijlqRAt_EBrPYzMSOjLmvqPXej5m4Qz8=.c54e472c-1b98-4817-9c09-34b6188f7797@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>
Message-ID: <3bVBncVGIg7Wh46TGgEevHt9AWqNvAcU2Cke8iQNn9A=.8d40431e-c578-4d5b-9dbd-c9e9fd55bb91@github.com>

On Tue, 12 Mar 2024 14:03:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore comment
>
> 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2007967764

From dlong at openjdk.org  Tue Mar 19 19:43:20 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 19 Mar 2024 19:43:20 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]
In-Reply-To: <25CO5hMsh1UPgSEZNT3ywdBxRs7EHhYTiYxWDuakfKc=.35f7b465-36de-4152-abbe-397e92aba117@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <25CO5hMsh1UPgSEZNT3ywdBxRs7EHhYTiYxWDuakfKc=.35f7b465-36de-4152-abbe-397e92aba117@github.com>
Message-ID: <beG2QY4aY0twk0VcxidSyu5JHP_t5k99Vm21lUtyaFA=.a5208549-acc0-4487-be9f-031e46971613@github.com>

On Tue, 19 Mar 2024 19:06:36 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/macroAssembler_aarch64.cpp line 3559:

> 3557:                                      Register tmp5, Register tmp6, Register product_hi, Register tmp8) {
> 3558: 
> 3559:   assert_different_registers(x, xlen, y, ylen, z, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp8);

Suggestion:

  assert_different_registers(x, xlen, y, ylen, z, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp8, product_hi);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1530980566

From dlong at openjdk.org  Tue Mar 19 19:46:20 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 19 Mar 2024 19:46:20 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]
In-Reply-To: <25CO5hMsh1UPgSEZNT3ywdBxRs7EHhYTiYxWDuakfKc=.35f7b465-36de-4152-abbe-397e92aba117@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <25CO5hMsh1UPgSEZNT3ywdBxRs7EHhYTiYxWDuakfKc=.35f7b465-36de-4152-abbe-397e92aba117@github.com>
Message-ID: <2zUQ2j5f9hwiK70250bR627K7vDslkAWA9pMzdXwqYI=.e2239329-eb87-4dd3-b70c-c928dd9b757c@github.com>

On Tue, 19 Mar 2024 19:06:36 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 tmp6  = r15;
> 4669:     const Register tmp7  = r16;
> 4670:     const Register tmp8  = r17;

It looks like tmp8 is never used.  The call to multiply_to_len() below needs to be adjusted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1530986811

From rgiulietti at openjdk.org  Tue Mar 19 19:54:23 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Mar 2024 19:54:23 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v10]
In-Reply-To: <EmNY_uTyEOlQSXcmIIP_JdGUYEvrr25wSaHfdlnNwtQ=.e295a2fe-1c42-4f93-9b7f-acea254548af@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>
 <EmNY_uTyEOlQSXcmIIP_JdGUYEvrr25wSaHfdlnNwtQ=.e295a2fe-1c42-4f93-9b7f-acea254548af@github.com>
Message-ID: <EjvGZqnaJjb5CSx8PjbBr_RutP5PEpFlZWFOGUHwmUo=.eae91fcd-f0b6-49e5-8b61-d90781598325@github.com>

On Tue, 19 Mar 2024 12:12:30 GMT, Shaojin Wen <duke 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?

@wenshao I'll take a look sometime this week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2007999908

From yzheng at openjdk.org  Tue Mar 19 21:09:31 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 19 Mar 2024 21:09:31 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v3]
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: <zMKT2cOKMHo76IFkz5uh8NOa07lp1NhleOJFKDi_v8c=.b5605b07-077e-4cf8-9014-f9a169b0af46@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/bfc323b7..870a6127

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=01-02

  Stats: 2 lines in 2 files 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 dholmes at openjdk.org  Tue Mar 19 22:22:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Mar 2024 22:22:26 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <pDl9EZqWPejHCxx8BSHOdXu4z6tn4XQIBESRI9ro2SY=.2a605cec-df19-4941-ac19-a5086a560fff@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
 <H4pQc-SO2nGCdT2y8RyI3gUQu7rlBzLIat2cOMlcnfI=.7a4eb42e-2cc8-4c21-a1c2-6a1b54113187@github.com>
 <isY_xkrTSpXvYHL0twZkKJu6hN4ci87qQ4XEMP19aHQ=.e325ebb1-3f42-45da-8283-e36dd28f7bb6@github.com>
 <pDl9EZqWPejHCxx8BSHOdXu4z6tn4XQIBESRI9ro2SY=.2a605cec-df19-4941-ac19-a5086a560fff@github.com>
Message-ID: <N7p2oiigvf5EZ0Gz8oj0pYkuON172yI7fMUaU9bEpSQ=.35033d49-d253-493a-8a9c-016d9b8d88b1@github.com>

On Tue, 19 Mar 2024 16:38:49 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Sorry, my use of words was sloppy here. I think I did mean loose or somewhat informal and therefore slippery.
>> 
>> What I was saying is that using terms such as "any continuing computation" doesn't make sense because this is referring to a current state of the computation. I'm not sure what "any continuing computation" from a state is because the concept of what constitutes the notion of "a continuing computation" has not been defined before. To me it sounds like a computation tree with nodes as state and transitions as edges and a continuing computation as a path through that tree into the future. The way it is written then, it sounds to the naive reader, or to me at least, as if the object is perpetually reachable by every thread always. I assume I am misinterpreting the intention of the writing, but it sounds too loose for a definition being invoked here in the javadoc. May be it can be tightened up a bit.
>> 
>> Could one state instead that "An object is reachable at a given state when some thread is able to access the object through a sequence of steps starting at that state without other threads taking any steps."  ? Or something along those lines? Or at least something tighter than the current wording that is somewhat too loose.
>
> In fact, it appears as if the problem is with the use of "any", which is universal in strength, whereas the intention here is existential in strength (as suggested by. my wording). Indeed, you might achieve the same effect by replacing "any" with "some" so that:
> 
> "An object is reachable if it can be accessed in some continuing computation from some live thread."
> 
> You needn't even say live because dead threads can neither take steps nor continue participating in the computation nor can they "access" objects for whatever informal notion of access. The "some continuing computation" subsumes "potential" (as in a possible future) so potential can be dropped.

I think you are overthinking this somewhat Ramki. I don't see a practical (non discrete-math) distinction between "some" and "any", so would not object to that single word change if it helps. But "potential" should remain as it covers branching in the program whereby if we proceed down one branch an object remains reachable, whereas if we precede down another then it may not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1531191269

From smarks at openjdk.org  Tue Mar 19 22:29:23 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 19 Mar 2024 22:29:23 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <N7p2oiigvf5EZ0Gz8oj0pYkuON172yI7fMUaU9bEpSQ=.35033d49-d253-493a-8a9c-016d9b8d88b1@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
 <H4pQc-SO2nGCdT2y8RyI3gUQu7rlBzLIat2cOMlcnfI=.7a4eb42e-2cc8-4c21-a1c2-6a1b54113187@github.com>
 <isY_xkrTSpXvYHL0twZkKJu6hN4ci87qQ4XEMP19aHQ=.e325ebb1-3f42-45da-8283-e36dd28f7bb6@github.com>
 <pDl9EZqWPejHCxx8BSHOdXu4z6tn4XQIBESRI9ro2SY=.2a605cec-df19-4941-ac19-a5086a560fff@github.com>
 <N7p2oiigvf5EZ0Gz8oj0pYkuON172yI7fMUaU9bEpSQ=.35033d49-d253-493a-8a9c-016d9b8d88b1@github.com>
Message-ID: <9uEUQhZ9TXKXIH89PHpcmS1DLq1iEH3apCwhoIdlAao=.ad01c39f-98af-47ae-a61b-4e8e241b112c@github.com>

On Tue, 19 Mar 2024 22:19:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In fact, it appears as if the problem is with the use of "any", which is universal in strength, whereas the intention here is existential in strength (as suggested by. my wording). Indeed, you might achieve the same effect by replacing "any" with "some" so that:
>> 
>> "An object is reachable if it can be accessed in some continuing computation from some live thread."
>> 
>> You needn't even say live because dead threads can neither take steps nor continue participating in the computation nor can they "access" objects for whatever informal notion of access. The "some continuing computation" subsumes "potential" (as in a possible future) so potential can be dropped.
>
> I think you are overthinking this somewhat Ramki. I don't see a practical (non discrete-math) distinction between "some" and "any", so would not object to that single word change if it helps. But "potential" should remain as it covers branching in the program whereby if we proceed down one branch an object remains reachable, whereas if we precede down another then it may not.

I don't think changing "any" to "some" is helpful. I think "any" is ambiguous regarding meaning universal or existential strength. The sense used here is, considering the possible future execution paths of a thread, if any of them accesses the object, that object is reachable. In other words, it means "any one" and not "all".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1531198317

From weijun at openjdk.org  Wed Mar 20 01:57:51 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 01:57:51 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v7]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <2WzsZtBsmeZkMUZKZS_4IGdfxGH19xrE88_uzSgRVLg=.1229163e-adb6-418e-be61-7eab69e1ed32@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang 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:

 - years and comments
 - Merge branch 'master' into 8296244
 - revert changes to MBeanServerFileAccessController.java
 - Merge branch 'master' into 8296244
 - revert some test changes, spec change for subject
 - fix MBeanServerFileAccessController, more test in SM
 - JMX needs SM
 - Resolve Alan's comments
 - remove exe bits
 - remove x bit
 - ... and 1 more: https://git.openjdk.org/jdk/compare/bb164794...dfa22af0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/80810b54..dfa22af0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=05-06

  Stats: 384142 lines in 1493 files changed: 18191 ins; 81433 del; 284518 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472

From duke at openjdk.org  Wed Mar 20 02:10:35 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Wed, 20 Mar 2024 02:10:35 GMT
Subject: RFR: JDK-8326836 Incorrect @since Tags for ClassSignature methods
 [v2]
In-Reply-To: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
Message-ID: <emnKMZ-WItnQQLRD83517Y-dqdN45CfEo9154kkWTfI=.d53f0fc6-8f34-4a27-9a51-f6a1b9ddb798@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.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  update the copyright year to 2024

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18030/files
  - new: https://git.openjdk.org/jdk/pull/18030/files/0d857db4..8c0c7122

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18030&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18030&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Wed Mar 20 02:17:36 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Wed, 20 Mar 2024 02:17:36 GMT
Subject: RFR: JDK-8326951 Missing @since Tags [v4]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <YOGk9cUYcFRYOZN1zhy49hIEjqhUfYP_VENHMr5YHLM=.ae609a72-e61a-4830-bcc5-7bf7fdc3c2f5@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).

Nizar Benalla has updated the pull request incrementally with three additional commits since the last revision:

 - update the copyright year to 2024
 - Revert "update the copyright year to 2024"
   
   This reverts commit 9ddd230dcf88bedade76a8e2804db6e120a200f8.
 - update the copyright year to 2024

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/3cec63e9..7d6e969e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=02-03

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 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 ysr at openjdk.org  Wed Mar 20 06:34:26 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 20 Mar 2024 06:34:26 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <9uEUQhZ9TXKXIH89PHpcmS1DLq1iEH3apCwhoIdlAao=.ad01c39f-98af-47ae-a61b-4e8e241b112c@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
 <H4pQc-SO2nGCdT2y8RyI3gUQu7rlBzLIat2cOMlcnfI=.7a4eb42e-2cc8-4c21-a1c2-6a1b54113187@github.com>
 <isY_xkrTSpXvYHL0twZkKJu6hN4ci87qQ4XEMP19aHQ=.e325ebb1-3f42-45da-8283-e36dd28f7bb6@github.com>
 <pDl9EZqWPejHCxx8BSHOdXu4z6tn4XQIBESRI9ro2SY=.2a605cec-df19-4941-ac19-a5086a560fff@github.com>
 <N7p2oiigvf5EZ0Gz8oj0pYkuON172yI7fMUaU9bEpSQ=.35033d49-d253-493a-8a9c-016d9b8d88b1@github.com>
 <9uEUQhZ9TXKXIH89PHpcmS1DLq1iEH3apCwhoIdlAao=.ad01c39f-98af-47ae-a61b-4e8e241b112c@github.com>
Message-ID: <i4jwKZgBDeU1CEfRy6l4JaPbuF5NgoOi9KI0wo5pCa0=.3e205cb9-3e6d-4d09-8435-01e40b5a816e@github.com>

On Tue, 19 Mar 2024 22:26:22 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I think you are overthinking this somewhat Ramki. I don't see a practical (non discrete-math) distinction between "some" and "any", so would not object to that single word change if it helps. But "potential" should remain as it covers branching in the program whereby if we proceed down one branch an object remains reachable, whereas if we precede down another then it may not.
>
> I don't think changing "any" to "some" is helpful. I think "any" is ambiguous regarding meaning universal or existential strength. The sense used here is, considering the possible future execution paths of a thread, if any of them accesses the object, that object is reachable. In other words, it means "any one" and not "all".

OK, no worries; will let you decide what makes sense. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1531559810

From goetz at openjdk.org  Wed Mar 20 07:24:23 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 20 Mar 2024 07:24:23 GMT
Subject: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could
 not reserve enough space for 2097152KB object heap
In-Reply-To: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
References: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
Message-ID: <IpntCaSsBrYQumyY3q1lWkXNgtFw74RpL0EDSyhGXBk=.07a1e44f-fde2-4d08-8e36-f0a650dfa51a@github.com>

On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?rve enough space for 2097152KB object heap
> 
> I would like to fix this as the two related issues mentioned in the JBS bug.
> We see it currently in most GHA runs.

GHA failure: known Risc-V build problem.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18380#issuecomment-2008933994
PR Comment: https://git.openjdk.org/jdk/pull/18380#issuecomment-2008934348

From goetz at openjdk.org  Wed Mar 20 07:24:24 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 20 Mar 2024 07:24:24 GMT
Subject: Integrated: 8328524: [x86] StringRepeat.java failure on linux-x86:
 Could not reserve enough space for 2097152KB object heap
In-Reply-To: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
References: <hl-E5A8XH2wBJhDb22IYZ1DvviuuctJiBs_uTIzl-2c=.27e6f036-c12c-4acc-a955-ce81f747c921@github.com>
Message-ID: <3qCm-Uz3StEY_aUsciKNiO6Wg0eiRGGZ3LbSigdYd8U=.fcf3e443-0315-4890-a35f-4d112b8d2a00@github.com>

On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?rve enough space for 2097152KB object heap
> 
> I would like to fix this as the two related issues mentioned in the JBS bug.
> We see it currently in most GHA runs.

This pull request has now been integrated.

Changeset: eebcc218
Author:    Goetz Lindenmaier <goetz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eebcc2181fe27f6aa10559233c7c58882a146f56
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8328524: [x86] StringRepeat.java failure on linux-x86: Could not reserve enough space for 2097152KB object heap

Reviewed-by: rriggs, mdoerr, sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/18380

From egahlin at openjdk.org  Wed Mar 20 10:27:22 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 20 Mar 2024 10:27:22 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <E9ekmv_5nb6r5rq1GBtSGAtKe8odMuOy153p42a3kzQ=.20d60bba-892c-4566-8323-8a25e10891d8@github.com>

On Tue, 19 Mar 2024 17:58:46 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

Speaking for JFR, we should probably just create a normal file, possibly with a filename to indicate subtest and iteration. That said, test changes for JFR looks fine, and fixing the filename is outside the scope of this bug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2009218768

From sgehwolf at openjdk.org  Wed Mar 20 10:27:29 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 20 Mar 2024 10:27:29 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <HEPQN2FO40L1Q4cnOvRawN65sDzQddC3WE3XYKPDrOw=.13735887-143a-409a-b533-48d7592907f5@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <HEPQN2FO40L1Q4cnOvRawN65sDzQddC3WE3XYKPDrOw=.13735887-143a-409a-b533-48d7592907f5@github.com>
Message-ID: <oIHBOdEGnOZV7GTMikznCN0HpX_WlrybRtqkNF6xB1Y=.8fbd6b11-a1e7-4158-b669-0c3ffec64943@github.com>

On Tue, 19 Mar 2024 18:05:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Thanks for the details. I feel the pain in extending jlink for this work as the current jlink implementation is not easily understandable and has been yearning for rewrite in my perspective (looking forward to Project Leyden's condenser model).

+1

> Really appreciate your effort for this.

Sure.

> IIUC, the main issue is regarding extending an jimage with additional entries.

Yes, it's really extending the jimage with additional entries which isn't supported currently (outside the jlink + archive + plugin pipeline).

> The other option is to add the diffs as a separate file in the JDK image under `lib` instead of part of the jimage.

Sure that would work. On the other hand, it's another additional artefact that downstream distributors need to account for. What's more, it seems almost too easy to change if it was a file outside the image. Thirdly, it would go against where the hermetic java work is going (one effort of this project is to try to include most of the conf/resource files outside the jimage inside the jimage, next to the classes that use them).

> The per-module mapping metadata files can be generated as part of the normal linking as the footprint is small.

Sure.

> Would that simplify it?

I'm not sure. What we really want is some form of API to extend/patch an existing jimage preserving everything else. Perhaps I should look into that. Would that be worth doing?

> I think the other issues may be solvable.

It's not a question of being solvable. All the issues are solvable in some way. Question is how exactly we want to address them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2009217508

From jpai at openjdk.org  Wed Mar 20 14:28:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Mar 2024 14:28:23 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: <-Wm5fMj3NQpjGPRxSFmOxLsyT1WV2UrExHyqRWf-gMc=.0a790a59-a4c6-45b0-8e37-fbf2c4117f74@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, tier1, tier2, tier3 completed without any related failures. I also ran JCK tests related to this class and those too passed. I've also taken Lance's inputs on this PR and he agrees that this look OK. I'll go ahead and approve this now. Thank you for fixing this, as well as your patience during the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-2009699729

From jpai at openjdk.org  Wed Mar 20 14:32:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Mar 2024 14:32:24 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: <gNTft4p6o7PPNanajZaP_J-uqrpMIPPmjsrevv4-VKo=.f7f68d90-c9aa-4ba7-9133-62500e38a82f@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.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17113#pullrequestreview-1949062346

From weijun at openjdk.org  Wed Mar 20 14:45:50 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 14:45:50 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more allow and years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/dfa22af0..1e6a7982

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=06-07

  Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

PR: https://git.openjdk.org/jdk/pull/17472

From weijun at openjdk.org  Wed Mar 20 15:02:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 15:02:25 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
Message-ID: <Lj2dIOon8EcxXTrhY7aevB-F-M6xQvnHHjezGoRkfBU=.c403d499-21ea-4256-a3bd-21f2d3f296f4@github.com>

On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more allow and years

There is no source code change to `java.management` anymore inside this PR. They will be resolved with new bugs at [JDK-8327618](https://bugs.openjdk.org/browse/JDK-8327618) and [JDK-8328263](https://bugs.openjdk.org/browse/JDK-8328263). There are test changes in these areas in this PR to force them running with SM allowed. Ideally, these changes can be reverted when the 2 new bugs are resolved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17472#issuecomment-2009779837

From acobbs at openjdk.org  Wed Mar 20 15:04:31 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 20 Mar 2024 15:04:31 GMT
Subject: Integrated: 7036144: GZIPInputStream readTrailer uses faulty
 available() test for end-of-stream
In-Reply-To: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
References: <vTqcdBsdNKsBdz1LiPWqpjuUAC8CpmXYf1HKar08hrg=.41f4b2b6-d670-48e4-a25e-531664731bc5@github.com>
Message-ID: <tlmiCrgchRWGc1fNvZTXbps26ubXe_xS3lS_LGPN2VI=.de4de8f7-213a-4a10-8f4c-62f9254a8b84@github.com>

On Thu, 14 Dec 2023 20:15:39 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.

This pull request has now been integrated.

Changeset: d3f3011d
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3f3011d56267360d65841da3550eca79cf1575b
Stats:     111 lines in 2 files changed: 96 ins; 9 del; 6 mod

7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/17113

From vklang at openjdk.org  Wed Mar 20 16:31:28 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 16:31:28 GMT
Subject: RFR: 8328366: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501
Message-ID: <aIPWtgpa0WM0FW7FCuIMaDXlXianE_T4TC_P6nUwUJQ=.452698e7-84a6-4e40-9b10-676bbec859d3@github.com>

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?

-------------

Commit messages:
 - Adding test case to verify that it is possible to change the CCL of the common pool
 - Restore setContextClassLoader functionality without breaking JDK-8327501

Changes: https://git.openjdk.org/jdk/pull/18374/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18374&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328366
  Stats: 14 lines in 2 files changed: 8 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18374/head:pull/18374

PR: https://git.openjdk.org/jdk/pull/18374

From vklang at openjdk.org  Wed Mar 20 16:31:28 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 16:31:28 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: <ubn7fTUYS-KCiZxPKMn9Wsk-jDxP0NM9EB-5NvQ8bZ0=.d4f0d567-ce1f-4e33-b4f6-b2915028e4c4@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?

@DougLea @AlanBateman Added a regression test to ForkJoinPool9Test. I think this is the fix we need. Please review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18374#issuecomment-2009993580

From mchung at openjdk.org  Wed Mar 20 17:18:21 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 20 Mar 2024 17:18:21 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: <JOs0zlC7sN6d9F5q0VezSJL9Jtt8ZJn4mxbyGNy6i5c=.e91745c0-4568-43cd-9dd8-bab71fc1b804@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?

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?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18374#discussion_r1532497712

From naoto at openjdk.org  Wed Mar 20 17:46:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Mar 2024 17:46:24 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v8]
In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <pjgeEs6MaHAk8pv0ZGE9VNEZ1XAm0hVfSUb9WcEilFk=.33042064-905e-4e73-b05b-a246fc581908@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the copyright year to 2024
>  - Revert "update the latter years for the Oracle copyrights"
>    
>    This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1949627443

From mcimadamore at openjdk.org  Wed Mar 20 17:52:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 20 Mar 2024 17:52:19 GMT
Subject: RFR: 8327994: Update code gen in CallGeneratorHelper [v2]
In-Reply-To: <S2ts94OiirHtbF5rOdowjMRmotVq9whFzIS0K4cfR8A=.397cbf63-9991-442b-9745-5c638a7e79ef@github.com>
References: <zFBzrJ8FEI7yrwITdz5YCmwL2cm2W100I4enNOW-mwo=.ca09bbf3-0caa-46f4-8553-143630d39dd2@github.com>
 <S2ts94OiirHtbF5rOdowjMRmotVq9whFzIS0K4cfR8A=.397cbf63-9991-442b-9745-5c638a7e79ef@github.com>
Message-ID: <V9gfr48GXru-4tU2FS8x7HChdUqIAhYFhmXVwAJPeFc=.7e6754c7-9df0-4617-a3ab-eeab3c4ed130@github.com>

On Sat, 16 Mar 2024 22:34:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Update the code gen code in CallGeneratorHelper to reflect the latest state of the libTest(Downcall/Upcall)(Stack).c and shared.h files.
>> 
>> - The previous code wanted users to pipe stdout into a file. But, since we have 5 files that need to be created, and the names of those files is important too, I've changed the script to write to those files directly instead.
>> - I moved the definition of `S_FFFF` to libVarArgs.c where it's used, as it's not actually generated by CallGeneratorHelper.
>> - GitHub doesn't render the changes to some of the files, but those files only contain either white space changes (some missing spaces after `,`), and copyright header updates.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete extra space
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Nice cleanup. No changes in libTestDowncallStack.c (not even minor ones) ?

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18269#pullrequestreview-1949642772

From duke at openjdk.org  Wed Mar 20 18:04:50 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Wed, 20 Mar 2024 18:04:50 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v9]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com>

> # Issue
> - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10
> 
> I changed the `@since` tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - Update full name
 - Update full name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/56968dcd..99f54fe2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=07-08

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18032/head:pull/18032

PR: https://git.openjdk.org/jdk/pull/18032

From mchung at openjdk.org  Wed Mar 20 18:48:26 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 20 Mar 2024 18:48:26 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <oIHBOdEGnOZV7GTMikznCN0HpX_WlrybRtqkNF6xB1Y=.8fbd6b11-a1e7-4158-b669-0c3ffec64943@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <HEPQN2FO40L1Q4cnOvRawN65sDzQddC3WE3XYKPDrOw=.13735887-143a-409a-b533-48d7592907f5@github.com>
 <oIHBOdEGnOZV7GTMikznCN0HpX_WlrybRtqkNF6xB1Y=.8fbd6b11-a1e7-4158-b669-0c3ffec64943@github.com>
Message-ID: <6Cy6p2gJMKyDpYF841Yi_8mK_P3LLQhPwreMLV9UDp4=.c94ebff1-6bb3-437a-afd0-af3ef10aecf5@github.com>

On Wed, 20 Mar 2024 10:24:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> What we really want is some form of API to extend/patch an existing jimage preserving everything else. Perhaps I should look into that. Would that be worth doing?

I think avoiding the plugin pipeline in creating a linkable image is simpler and more reliable design.   I think it's worth understanding how big effort to support that.

The reason why I proposed the alternative putting the diffs data as a side file under `lib` is an interim solution that would allow this work to continue while the API for extending jimage can be done as a follow up.   

> it seems almost too easy to change if it was a file outside the image. 

Only a few files in the `lib` directory such as libjvm.so or libjvm.dylib, src.zip and a few other files are intended for external use.   All other files and directories under it must be treated are private implementation details and their names, format, and content are subject to change without notice. See JEP 220 for details.

> Thirdly, it would go against where the hermetic java work is going (one effort of this project is to try to include most of the conf/resource files outside the jimage inside the jimage, next to the classes that use them).

I agree that putting the diffs file in the jimage is a good direction.   I am also ok with the interim solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2010349483

From stuart.marks at oracle.com  Wed Mar 20 19:48:08 2024
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 20 Mar 2024 12:48:08 -0700
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <82b9b0b4-ae71-f6fa-2c89-15b3a3a42aea@oracle.com>

Vote: yes

On 3/19/24 8:19 AM, Daniel Fuchs wrote:
> Hi,
> 
> I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries 
> Group [4].
> 
> Per-Ake is an OpenJDK Reviewer, a committer in the
> Leyden and Panama projects, and a member of Oracle?s
> Java Core Libraries team.
> 
> Per-Ake has been actively participating in the development of
> the JDK and Panama projects for several years, and is one of
> the co-author of the Implementation of Foreign Function and
> Memory API (Third Preview) [2].
> His contributions include more than 80 commits in the JDK [3]
> 
> 
> Votes are due by 16:00 UTC on April 2, 2024.
> 
> Only current Members of the Core Libraries Group [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> best regards,
> 
> -- daniel
> 
> [1] https://openjdk.org/census#pminborg
> [2] https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
> [3] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg&type=commits
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
> 

From vklang at openjdk.org  Wed Mar 20 20:08:21 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 20:08:21 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: <exlyX14M__eStKJK8dcLZ_8SXfCFMYIrVuA3aF4t4b8=.d6b16425-83f4-499a-bc99-aa162f56a5e1@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 Yeah, @DougLea perhaps want to weigh in on that. I wonder if this should be addressed as this PR or if it should be handled separately?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18374#discussion_r1532781080

From vklang at openjdk.org  Wed Mar 20 20:24:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 20:24:31 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false
Message-ID: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>

Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.

Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

-------------

Commit messages:
 - Adds differentiation between direct and transitive short circutiting for Gatherers

Changes: https://git.openjdk.org/jdk/pull/18351/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18351&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328316
  Stats: 70 lines in 2 files changed: 66 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18351/head:pull/18351

PR: https://git.openjdk.org/jdk/pull/18351

From vklang at openjdk.org  Wed Mar 20 20:24:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 20:24:32 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false
In-Reply-To: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
Message-ID: <hXZ-RGqpw_V3OHnQ_CMkxhJzJqxYzCBdDLWhHxf2cpU=.cc5f1ba4-91ed-4bff-a0a9-2b3c2eb096ee@github.com>

On Mon, 18 Mar 2024 16:27:13 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
> 
> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

Just a note to self, consider if this should get backported to 22 or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18351#issuecomment-2004384537

From mullan at openjdk.org  Wed Mar 20 20:45:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 20 Mar 2024 20:45:21 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
Message-ID: <6q9lWdNP10bPYE7_UAGZmKwOGgA4UqHwcZmh4jTsjRI=.7ebc2d0d-a7c3-4f89-948e-bdacaec5f355@github.com>

On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more allow and years

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17472#pullrequestreview-1950109209

From redestad at openjdk.org  Wed Mar 20 21:01:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 20 Mar 2024 21:01:24 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v14]
In-Reply-To: <G8nOGcGdQnJMQuDH1Pf1Dt4519wf1V-Ze2WfkiAAuJU=.34b745d2-a080-45f8-a05c-7e4eca0e1ba3@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <G8nOGcGdQnJMQuDH1Pf1Dt4519wf1V-Ze2WfkiAAuJU=.34b745d2-a080-45f8-a05c-7e4eca0e1ba3@github.com>
Message-ID: <wm1xDNrXWvjFBTUTDL411o4adX5DR3SCTHRpeLd_JPY=.cb3cd8a8-123f-44cb-9d42-3511a1964a98@github.com>

On Thu, 14 Mar 2024 00:00:53 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 incrementally with one additional commit since the last revision:
> 
>   bug fix for CharArraySequence#charAt

src/java.base/share/classes/java/math/BigDecimal.java line 576:

> 574:         long rs = 0;                  // the compact value in long
> 575:         BigInteger rb = null;         // the inflated value in BigInteger
> 576:         // use String bounds checking to handle too-long, len == 0,

Suggestion:

        // use CharSequence bounds checking to handle too-long, len == 0,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1532860171

From redestad at openjdk.org  Wed Mar 20 21:04:27 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 20 Mar 2024 21:04:27 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v14]
In-Reply-To: <G8nOGcGdQnJMQuDH1Pf1Dt4519wf1V-Ze2WfkiAAuJU=.34b745d2-a080-45f8-a05c-7e4eca0e1ba3@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <G8nOGcGdQnJMQuDH1Pf1Dt4519wf1V-Ze2WfkiAAuJU=.34b745d2-a080-45f8-a05c-7e4eca0e1ba3@github.com>
Message-ID: <F6kLa-G8ndcgQ7ai1K45ZVIa60NEWPHnM2gJR6T3oqY=.f7acdfc7-5985-4561-aada-341d63d18026@github.com>

On Thu, 14 Mar 2024 00:00:53 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 incrementally with one additional commit since the last revision:
> 
>   bug fix for CharArraySequence#charAt

src/java.base/share/classes/java/math/BigDecimal.java line 598:

> 596:                 // First compact case, we need not to preserve the character
> 597:                 // and we can just compute the value in place.
> 598:                 for (; ; c = val.charAt(++offset)) {

This needs to be simplified. Let's at least do this, which is more honest: 

                while (true) {
                    ...
                    c = val.charAt(++offset);
                }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18177#discussion_r1532864646

From clanger at openjdk.org  Wed Mar 20 21:11:23 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 20 Mar 2024 21:11:23 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v8]
In-Reply-To: <n9IOkLBLSzms1pQIGfaBa-bjAiwlyORtnxA00XPTn5k=.64da35f4-0320-4fd1-b681-fd0fd35885ed@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <IGkgkob8lvI2h642AnVStJOe_UU6SHNtlsdm2eZid4s=.08105a6e-e49a-4d1f-921e-f9fce3864a68@github.com>
 <n9IOkLBLSzms1pQIGfaBa-bjAiwlyORtnxA00XPTn5k=.64da35f4-0320-4fd1-b681-fd0fd35885ed@github.com>
Message-ID: <vHJ7zBNp1pqQKw109F75FNYCgwjpu5zKDsvAq_BnrLw=.349fa6a7-81c5-44f6-8fd0-6bf5d14e2161@github.com>

On Tue, 19 Mar 2024 16:01:34 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Christoph Langer 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:
>> 
>>  - Update module-info text
>>  - Merge branch 'master' into JDK-8325579
>>  - Indentation
>>  - Merge branch 'master' into JDK-8325579
>>  - Review feedback
>>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>>  - Merge branch 'master' into JDK-8325579
>>  - Typo
>>  - Merge branch 'master' into JDK-8325579
>>  - Rename test and refine comment
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b172eb4c...10271159
>
> src/java.naming/share/classes/module-info.java line 42:
> 
>> 40:  *         <br>The value of this environment property specifies the fully
>> 41:  *         qualified class name of the socket factory used by the LDAP provider.
>> 42:  *         This class must implement the javax.net.SocketFactory abstract class
> 
> You could add a link to the `SocketFactory` class here: 
> Suggestion:
> 
>  *         This class must implement the {@link javax.net.SocketFactory} abstract class

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1532877183

From clanger at openjdk.org  Wed Mar 20 21:19:40 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 20 Mar 2024 21:19:40 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v8]
In-Reply-To: <n9IOkLBLSzms1pQIGfaBa-bjAiwlyORtnxA00XPTn5k=.64da35f4-0320-4fd1-b681-fd0fd35885ed@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <IGkgkob8lvI2h642AnVStJOe_UU6SHNtlsdm2eZid4s=.08105a6e-e49a-4d1f-921e-f9fce3864a68@github.com>
 <n9IOkLBLSzms1pQIGfaBa-bjAiwlyORtnxA00XPTn5k=.64da35f4-0320-4fd1-b681-fd0fd35885ed@github.com>
Message-ID: <GN7kq22yAk0R8cfctz5DSOI4VdoV8G7JV6yVFPQChB0=.ce82389b-82d9-4da2-9deb-89bb64f0c328@github.com>

On Tue, 19 Mar 2024 16:09:18 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Christoph Langer 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:
>> 
>>  - Update module-info text
>>  - Merge branch 'master' into JDK-8325579
>>  - Indentation
>>  - Merge branch 'master' into JDK-8325579
>>  - Review feedback
>>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>>  - Merge branch 'master' into JDK-8325579
>>  - Typo
>>  - Merge branch 'master' into JDK-8325579
>>  - Rename test and refine comment
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/ffdffc5b...10271159
>
> test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 164:
> 
>> 162:                     if (CustomSocketFactory.customSocket.closeMethodCalledCount() <= 0) {
>> 163:                         System.err.println("Custom Socket was not closed.");
>> 164:                         System.exit(-1);
> 
> Can we update test not to use `System.exit` and replace it with throwing `new RuntimeException`, something like:
> Suggestion:
> 
>                         throw new RuntimeException("Custom Socket was not closed");

Done.

> test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 177:
> 
>> 175:                     ctx.close();
>> 176:                     if (!checkSocketClosed(sock)) {
>> 177:                         System.exit(-1);
> 
> Can be replaced with:
> Suggestion:
> 
>                         throw new RuntimeException("Socket isn't closed");

I simplified this, removing checkSocketClosed() method

> test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 184:
> 
>> 182:             e.printStackTrace();
>> 183:             System.exit(-1);
>> 184:         }
> 
> For simplification and `System.exit` removal purposes this catch block can be removed with addition of `throws Exception` clause to the `main` method.
> Suggestion:
> 
>         }

I chose to throw a new RuntimeException(e)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1532883964
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1532885041
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1532884603

From clanger at openjdk.org  Wed Mar 20 21:19:38 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 20 Mar 2024 21:19:38 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v9]
In-Reply-To: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
Message-ID: <X-55Tn0ivPbmqrBWus1iStnLF63u0xdSsDZiJ0wbdyQ=.d93798d4-6d78-46a6-8bf2-7a7ca950eb97@github.com>

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

Christoph Langer 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:

 - Review suggestions Aleksei
 - Merge branch 'master' into JDK-8325579
 - Update module-info text
 - Merge branch 'master' into JDK-8325579
 - Indentation
 - Merge branch 'master' into JDK-8325579
 - Review feedback
 - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
 - Merge branch 'master' into JDK-8325579
 - Typo
 - ... and 4 more: https://git.openjdk.org/jdk/compare/7b45211e...8fdc039c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17797/files
  - new: https://git.openjdk.org/jdk/pull/17797/files/10271159..8fdc039c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17797&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17797&range=07-08

  Stats: 292653 lines in 398 files changed: 5187 ins; 5644 del; 281822 mod
  Patch: https://git.openjdk.org/jdk/pull/17797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17797/head:pull/17797

PR: https://git.openjdk.org/jdk/pull/17797

From weijun at openjdk.org  Wed Mar 20 21:28:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 21:28:29 GMT
Subject: Integrated: 8296244: Alternate implementation of user-based
 authorization Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security
 Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <sVQNg8PJbPuUovgGQYsvAzGqhH0l7cSKf6bJcrEuN60=.67048ca0-828e-49ce-9deb-d06b727ecc60@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

This pull request has now been integrated.

Changeset: d32746ef
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d32746ef4a0ce6fec558274244321991be141698
Stats:     622 lines in 17 files changed: 477 ins; 27 del; 118 mod

8296244: Alternate implementation of user-based authorization Subject APIs that doesn?t depend on Security Manager APIs

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/17472

From Alan.Bateman at oracle.com  Wed Mar 20 21:37:47 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Mar 2024 06:37:47 +0900
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <41b4db8f-62cb-4712-a83d-9a99b962d0da@oracle.com>

Vote: yes

From vklang at openjdk.org  Wed Mar 20 22:51:22 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 22:51:22 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false
In-Reply-To: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
Message-ID: <nhq3jVOBD0JFE803jSi6CfZovlrPJq-5uoUy7_gnppM=.579b07d6-19cc-41e3-87ec-d7b812ef6aaa@github.com>

On Mon, 18 Mar 2024 16:27:13 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
> 
> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

@PaulSandoz Would you mind reviewing this PR, Paul?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18351#issuecomment-2010809413

From duke at openjdk.org  Wed Mar 20 22:51:36 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 20 Mar 2024 22:51:36 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v15]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <eVrYcad_GBTzsbU3XB0hiGbfb5VL8PRiD8vIhxJOohY=.f4c69f36-20d9-44c1-9bc6-bf81083b8993@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 incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/math/BigDecimal.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/69be44db..3ec5eac6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 jvernee at openjdk.org  Wed Mar 20 22:56:22 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 20 Mar 2024 22:56:22 GMT
Subject: RFR: 8327994: Update code gen in CallGeneratorHelper [v2]
In-Reply-To: <V9gfr48GXru-4tU2FS8x7HChdUqIAhYFhmXVwAJPeFc=.7e6754c7-9df0-4617-a3ab-eeab3c4ed130@github.com>
References: <zFBzrJ8FEI7yrwITdz5YCmwL2cm2W100I4enNOW-mwo=.ca09bbf3-0caa-46f4-8553-143630d39dd2@github.com>
 <S2ts94OiirHtbF5rOdowjMRmotVq9whFzIS0K4cfR8A=.397cbf63-9991-442b-9745-5c638a7e79ef@github.com>
 <V9gfr48GXru-4tU2FS8x7HChdUqIAhYFhmXVwAJPeFc=.7e6754c7-9df0-4617-a3ab-eeab3c4ed130@github.com>
Message-ID: <WV3Yf81fONN6PMBJpmnNtI2NHLv9DOUdBeb_EUlWlWY=.f7125ff4-7f38-4d50-a2ca-76b13e886485@github.com>

On Wed, 20 Mar 2024 17:49:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> No changes in libTestDowncallStack.c (not even minor ones) ?

No, there was a 'missing' space between the prefix parameters and the actual parameters of the stack variants, and between the arguments passed when that callback was called in the upcall lib (So, white space only). libTestDowncall.c didn't have any changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18269#issuecomment-2010825750

From duke at openjdk.org  Wed Mar 20 22:56:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 20 Mar 2024 22:56:38 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v16]
In-Reply-To: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
Message-ID: <x9SnGx9TpR0wlNOAtbgSR5cK5yQO7RywpQvCXe7fzwE=.72d80ce0-23c3-4036-9eae-641c9cf3d530@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 incrementally with one additional commit since the last revision:

  use while instead for

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18177/files
  - new: https://git.openjdk.org/jdk/pull/18177/files/3ec5eac6..17f0a736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18177&range=14-15

  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 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 psandoz at openjdk.org  Wed Mar 20 23:14:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 20 Mar 2024 23:14:20 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false
In-Reply-To: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
Message-ID: <y5JFFHKbiO1gGYTG4w1iySy2EUL8ElRcKhMZcKo43wE=.7050d8ed-e832-4533-b4a3-afea959da2ca@github.com>

On Mon, 18 Mar 2024 16:27:13 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
> 
> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

Looks good, just a minor suggestion.

test/jdk/java/util/stream/GathererShortCircuitTest.java line 48:

> 46:                 Gatherer.of(
> 47:                     (unused, element, downstream) -> false,
> 48:                     (unused, downstream) -> downstream.push(expected)

Suggestion:

                    (_, element, downstream) -> false,
                    (_ downstream) -> downstream.push(expected)

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18351#pullrequestreview-1950412052
PR Review Comment: https://git.openjdk.org/jdk/pull/18351#discussion_r1533025318

From vklang at openjdk.org  Wed Mar 20 23:22:35 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 23:22:35 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false [v2]
In-Reply-To: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
Message-ID: <vFQGhvAogbKuG3LY4wf_YVHYzKa8S5YlXrz-H6HaytA=.aaefbf30-be59-4fbb-8556-35c0c4c34bb5@github.com>

> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
> 
> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/util/stream/GathererShortCircuitTest.java
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18351/files
  - new: https://git.openjdk.org/jdk/pull/18351/files/fe867a15..f32b1c5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18351&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18351&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18351/head:pull/18351

PR: https://git.openjdk.org/jdk/pull/18351

From vklang at openjdk.org  Wed Mar 20 23:31:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 23:31:31 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false [v3]
In-Reply-To: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
Message-ID: <yep8QoPmlCA4aRGL3LCJc8RTrcT_K999Ja6JHB1jFRc=.75ef35da-af95-4b07-8ebb-c17ebb508c7a@github.com>

> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
> 
> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

Viktor Klang has updated the pull request incrementally with 236 additional commits since the last revision:

 - Adding a comma
 - Updating copyright year on GathererOp
 - 8289822: G1: Make concurrent mark code owner of TAMSes
   
   Reviewed-by: ayang, iwalulya
 - 8325362: Allow to create a simple in-memory input JavaFileObject
   
   Reviewed-by: jlaskey, darcy
 - 8326941: Remove StringUTF16::isBigEndian
   
   Reviewed-by: rriggs
 - 8325187: JVMTI GetThreadState says virtual thread is JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
   
   Reviewed-by: dholmes, alanb
 - 8308660: C2 compilation hits 'node must be dead' assert
   
   Reviewed-by: chagedorn, kvn
 - 8323972: C2 compilation fails with assert(!x->as_Loop()->is_loop_nest_inner_loop()) failed: loop was transformed
   
   Reviewed-by: chagedorn, epeter
 - 8328275: CodeCache::print_internals should not be called in PRODUCT code
   
   Reviewed-by: ihse, jwaters, dholmes
 - 8326964: Remove Eclipse Shared Workspaces
   
   Reviewed-by: erikj, ihse
 - ... and 226 more: https://git.openjdk.org/jdk/compare/f32b1c5f...189ffaa3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18351/files
  - new: https://git.openjdk.org/jdk/pull/18351/files/f32b1c5f..189ffaa3

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: Webrev is not available because diff is too large

  Stats: 384826 lines in 1503 files changed: 18739 ins; 81305 del; 284782 mod
  Patch: https://git.openjdk.org/jdk/pull/18351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18351/head:pull/18351

PR: https://git.openjdk.org/jdk/pull/18351

From vklang at openjdk.org  Wed Mar 20 23:58:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Mar 2024 23:58:32 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false [v4]
In-Reply-To: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
Message-ID: <8i5GewezI8x7UvxpD6annahxVLdDIp2_ye2L2C11UgM=.4ca682e8-a763-49db-ab3d-89b10df646a6@github.com>

> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
> 
> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Updating copyright year and switching to use underscores in GathererShortCircuitTest
 - Adds differentiation between direct and transitive short circutiting for Gatherers

-------------

Changes: https://git.openjdk.org/jdk/pull/18351/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18351&range=03
  Stats: 71 lines in 2 files changed: 66 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18351/head:pull/18351

PR: https://git.openjdk.org/jdk/pull/18351

From duke at openjdk.org  Thu Mar 21 00:43:24 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 21 Mar 2024 00:43:24 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v16]
In-Reply-To: <x9SnGx9TpR0wlNOAtbgSR5cK5yQO7RywpQvCXe7fzwE=.72d80ce0-23c3-4036-9eae-641c9cf3d530@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <x9SnGx9TpR0wlNOAtbgSR5cK5yQO7RywpQvCXe7fzwE=.72d80ce0-23c3-4036-9eae-641c9cf3d530@github.com>
Message-ID: <1C_4Va_V906s63KZWzauFvVPUokOp2vk9bqFY0Intgo=.8cb5bae0-6184-4182-89d9-f9b62063b7ea@github.com>

On Wed, 20 Mar 2024 22:56:38 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 incrementally with one additional commit since the last revision:
> 
>   use while instead for

Should we declare the BigDecimal(CharSequence,MathContext) method as public? Scenarios like [MysqlBinaryValueDecoder#decodeDecimal](https://github.com/mysql/mysql-connector-j/blob/release/8.x/src/main/protocol-impl/java/com/mysql/cj/protocol/a/MysqlBinaryValueDecoder.java#L275) can be used to avoid a memory allocation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2010977844

From liach at openjdk.org  Thu Mar 21 02:16:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Mar 2024 02:16:27 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v16]
In-Reply-To: <1C_4Va_V906s63KZWzauFvVPUokOp2vk9bqFY0Intgo=.8cb5bae0-6184-4182-89d9-f9b62063b7ea@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <x9SnGx9TpR0wlNOAtbgSR5cK5yQO7RywpQvCXe7fzwE=.72d80ce0-23c3-4036-9eae-641c9cf3d530@github.com>
 <1C_4Va_V906s63KZWzauFvVPUokOp2vk9bqFY0Intgo=.8cb5bae0-6184-4182-89d9-f9b62063b7ea@github.com>
Message-ID: <p2ElAtjdmcdeGMNct9YZwluqq6y8cworIiT53hMs7EY=.03ab7ca6-ac80-4dcc-b453-f69fd27dc630@github.com>

On Thu, 21 Mar 2024 00:40:45 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Should we declare the BigDecimal(CharSequence,MathContext) method as public? Scenarios like [MysqlBinaryValueDecoder#decodeDecimal](https://github.com/mysql/mysql-connector-j/blob/release/8.x/src/main/protocol-impl/java/com/mysql/cj/protocol/a/MysqlBinaryValueDecoder.java#L275) can be used to avoid a memory allocation.

Good idea, but since this involves a change in the public APIs and needs extra care with API specification, you should do this in a dependent PR (target the pr/18177 branch of jdk repo) that focus specifically on the addition. A new API is out of scope for this current PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2011064004

From smarks at openjdk.org  Thu Mar 21 05:24:21 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 21 Mar 2024 05:24:21 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v3]
In-Reply-To: <2MuoCDS5QNXFwMb8hrVZ7IS2Vomgm8Z8SQVyOWN2us4=.ac233527-0bba-41ea-929a-36955f05861b@github.com>
References: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>
 <2MuoCDS5QNXFwMb8hrVZ7IS2Vomgm8Z8SQVyOWN2us4=.ac233527-0bba-41ea-929a-36955f05861b@github.com>
Message-ID: <HnAFXoRuBDgvMRPe-ARc4UdyAKL-4QlyedY06Q6Ugvg=.d873ff34-878c-47e8-bb4f-bed01b6c2077@github.com>

On Wed, 14 Feb 2024 20:46:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use new suggestion and remove original clarification

Sorry for the delay.

The current wording looks fine.

I've changed the summary of the bug report to "clarify specification of Map::putIfAbsent return value" which I think is a better description. @hjohn please change the PR title to match.

I've taken the liberty of updating the CSR. While this is sort-of a borderline case for a CSR, it is a bit more than fixing a typo; it's rewording a bit of normative specification. The CSR doesn't need to say too much beyond documenting the change and the reason for it (which I've done, based on @hjohn's original draft). The CSR should be approved without difficulty. Please review it. (@pavelrappo please mark as reviewed if you get a chance, thanks.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17438#issuecomment-2011242189

From dholmes at openjdk.org  Thu Mar 21 05:40:20 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Mar 2024 05:40:20 GMT
Subject: RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with
 -Xcomp
In-Reply-To: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>
References: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>
Message-ID: <oQvBOK62oRISpP7n3ZPhhnauEAEBSglkZ65A2Myxt4Y=.653e0405-498a-42c4-9d5a-d7eaed738116@github.com>

On Sun, 3 Mar 2024 17:01:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in `-Xcomp` temporarily causes some extra memory pressure (probably due to [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause recoverable OOMEs to occur (memory is recovered when the relevant libgraal compilations complete). It also seems related to async threads used for cleaning weak references when using G1 or ZGC as I cannot reproduce the failure under `-XX:+UseSerialGC`.
> 
> Installing a global `Thread.UncaughtExceptionHandler` that ignores `OutOfMemoryError`s resolves the problem.

Changes requested by dholmes (Reviewer).

test/jdk/java/util/concurrent/Executors/UnreferencedExecutor.java line 58:

> 56:                 throw new RuntimeException(e);
> 57:             }
> 58:         }

I'm not clear exactly what you are trying to achieve with this - is it just to not print the stacktrace when OOME occurs?

A UEH should not rethrow exceptions as they are effectively ignored as we are already at the final level of handling exceptions (the VM will print a one line warning if a UEH itself throws). If I understand what you want then I think the following would be more correct:

// Ignore OOME but do default handling for any other uncaught exception.
public void uncaughtException(Thread t, Throwable e) {
    if ( ! e instanceof OutOfMemoryError) {
        System.err.print("Exception in thread "" + t.getName() + "" ");
        e.printStackTrace(System.err);
    }
}


This doesn't stop the thread from terminating of course - the OOME already caused it to unwind its stack if we get this far.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18098#pullrequestreview-1950797938
PR Review Comment: https://git.openjdk.org/jdk/pull/18098#discussion_r1533273137

From alanb at openjdk.org  Thu Mar 21 07:43:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Mar 2024 07:43:21 GMT
Subject: RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with
 -Xcomp
In-Reply-To: <bGh50s0HYEvkcBqlR6T4LDqNybQ8B5Lqc_GJ_LriUmU=.7fb41ec3-6e0a-4aa7-85d4-8493e08e8eb5@github.com>
References: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>
 <bGh50s0HYEvkcBqlR6T4LDqNybQ8B5Lqc_GJ_LriUmU=.7fb41ec3-6e0a-4aa7-85d4-8493e08e8eb5@github.com>
Message-ID: <q4iWZHR3fIj-8xyWV5XGCYmx6dE9O3-Y5WLbctmJVug=.efdbd802-ce92-47e9-bd84-3f240a16de53@github.com>

On Sun, 3 Mar 2024 17:03:51 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in `-Xcomp` temporarily causes some extra memory pressure (probably due to [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause recoverable OOMEs to occur (memory is recovered when the relevant libgraal compilations complete). It also seems related to async threads used for cleaning weak references when using G1 or ZGC as I cannot reproduce the failure under `-XX:+UseSerialGC`.
>> 
>> Installing a global `Thread.UncaughtExceptionHandler` that ignores `OutOfMemoryError`s resolves the problem.
>
> I confirmed that `java/util/concurrent/Executors/UnreferencedExecutor.java` still fails if the [fix applied to ThreadContainers.java](https://github.com/openjdk/jdk/commit/ada416e66cbff6c8e631bf352acc0744c248740b#diff-1e347b9a95cc4fe81a01ca70e4122a73a65d99a69668c7567abb2a6067f8cc6dL68) is reverted.

@dougxc I added this test when fixing JDK-8308235. The point of the test is that OOME is not thrown so adding a default UEH to ignore OOME is changing the test. I wonder if this is a test that just needed to be skipped with libgraal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18098#issuecomment-2011390893

From dnsimon at openjdk.org  Thu Mar 21 09:14:26 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 21 Mar 2024 09:14:26 GMT
Subject: RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with
 -Xcomp
In-Reply-To: <bGh50s0HYEvkcBqlR6T4LDqNybQ8B5Lqc_GJ_LriUmU=.7fb41ec3-6e0a-4aa7-85d4-8493e08e8eb5@github.com>
References: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>
 <bGh50s0HYEvkcBqlR6T4LDqNybQ8B5Lqc_GJ_LriUmU=.7fb41ec3-6e0a-4aa7-85d4-8493e08e8eb5@github.com>
Message-ID: <8x1fXu9oWIXN9ULzgPC8TrJClXaU3wCA6-PHNCcMEA8=.bb9e0c88-0457-4b67-9e1c-c3397a8a81b5@github.com>

On Sun, 3 Mar 2024 17:03:51 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in `-Xcomp` temporarily causes some extra memory pressure (probably due to [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause recoverable OOMEs to occur (memory is recovered when the relevant libgraal compilations complete). It also seems related to async threads used for cleaning weak references when using G1 or ZGC as I cannot reproduce the failure under `-XX:+UseSerialGC`.
>> 
>> Installing a global `Thread.UncaughtExceptionHandler` that ignores `OutOfMemoryError`s resolves the problem.
>
> I confirmed that `java/util/concurrent/Executors/UnreferencedExecutor.java` still fails if the [fix applied to ThreadContainers.java](https://github.com/openjdk/jdk/commit/ada416e66cbff6c8e631bf352acc0744c248740b#diff-1e347b9a95cc4fe81a01ca70e4122a73a65d99a69668c7567abb2a6067f8cc6dL68) is reverted.

> @dougxc I added this test when fixing JDK-8308235. The point of the test is that OOME is not thrown so adding a default UEH to ignore OOME is changing the test. I wonder if this is a test that just needed to be skipped with libgraal.

I understood the point of that test to be that an OOME does not cause the VM to exit. As i mentioned (https://github.com/openjdk/jdk/pull/18098#issuecomment-1975231258), the test still detects the memory leak plugged by JDK-8308235.

That said, I have tried to reproduce the failure on a more recent libgraal and JDK build and am having no luck. I'll close this PR and come up with alternative solutions if the failure starts reappearing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18098#issuecomment-2011700020

From dnsimon at openjdk.org  Thu Mar 21 09:14:27 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 21 Mar 2024 09:14:27 GMT
Subject: Withdrawn: 8327176: UnreferencedExecutor.java can fail on libgraal
 with -Xcomp
In-Reply-To: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>
References: <YawRFPxXqqwZ0hqKFi2LyfvEQUEApoeY4ZXSHHDdx8g=.1a01e4be-a281-48b3-9adb-b4cbdd54757a@github.com>
Message-ID: <Ok-osmLzNnhk2vy0l7j2Bh8_WvXjMmi76oYzksC8-8M=.8fb9f6aa-cfb3-4608-a04d-d91b763cb119@github.com>

On Sun, 3 Mar 2024 17:01:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in `-Xcomp` temporarily causes some extra memory pressure (probably due to [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause recoverable OOMEs to occur (memory is recovered when the relevant libgraal compilations complete). It also seems related to async threads used for cleaning weak references when using G1 or ZGC as I cannot reproduce the failure under `-XX:+UseSerialGC`.
> 
> Installing a global `Thread.UncaughtExceptionHandler` that ignores `OutOfMemoryError`s resolves the problem.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18098

From pminborg at openjdk.org  Thu Mar 21 09:28:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Mar 2024 09:28:30 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment
Message-ID: <yGUDL9KFPQOLTviQ8LjiRU5towjC77FWmkH256hIVKs=.207a6854-31ce-4385-a81e-1fdcec59cedd@github.com>

This PR proposes to remove an old optimization check that was incorrect making `AbstractMemorySegmentImpl::mismatch` always return `-1` if the source and destination segment are the same (disregarding offsets).

-------------

Commit messages:
 - Remove comment out markings
 - Remove erroneous check

Changes: https://git.openjdk.org/jdk/pull/18426/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323552
  Stats: 34 lines in 2 files changed: 27 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18426.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18426/head:pull/18426

PR: https://git.openjdk.org/jdk/pull/18426

From dfuchs at openjdk.org  Thu Mar 21 09:30:26 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Mar 2024 09:30:26 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v9]
In-Reply-To: <X-55Tn0ivPbmqrBWus1iStnLF63u0xdSsDZiJ0wbdyQ=.d93798d4-6d78-46a6-8bf2-7a7ca950eb97@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <X-55Tn0ivPbmqrBWus1iStnLF63u0xdSsDZiJ0wbdyQ=.d93798d4-6d78-46a6-8bf2-7a7ca950eb97@github.com>
Message-ID: <bRxmtYOmF2RrOKS0rQ_PDhdKbqawc_9b_cHNsivEHJ4=.17f8049f-5b9a-4f2f-b81f-1e0649b6e9a1@github.com>

On Wed, 20 Mar 2024 21:19:38 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer 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:
> 
>  - Review suggestions Aleksei
>  - Merge branch 'master' into JDK-8325579
>  - Update module-info text
>  - Merge branch 'master' into JDK-8325579
>  - Indentation
>  - Merge branch 'master' into JDK-8325579
>  - Review feedback
>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>  - Merge branch 'master' into JDK-8325579
>  - Typo
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/b817e52b...8fdc039c

Latest changes LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17797#pullrequestreview-1951411585

From mcimadamore at openjdk.org  Thu Mar 21 10:14:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 21 Mar 2024 10:14:20 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment
In-Reply-To: <yGUDL9KFPQOLTviQ8LjiRU5towjC77FWmkH256hIVKs=.207a6854-31ce-4385-a81e-1fdcec59cedd@github.com>
References: <yGUDL9KFPQOLTviQ8LjiRU5towjC77FWmkH256hIVKs=.207a6854-31ce-4385-a81e-1fdcec59cedd@github.com>
Message-ID: <Wd9fmw03R8QqwQFZOEREHe9ecSEZ2f7J3onVKoTwA2w=.37845c5b-46bf-420e-a871-261333055a87@github.com>

On Thu, 21 Mar 2024 09:23:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove an old optimization check that was incorrect making `AbstractMemorySegmentImpl::mismatch` always return `-1` if the source and destination segment are the same (disregarding offsets).

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18426#pullrequestreview-1951602572

From jvernee at openjdk.org  Thu Mar 21 12:37:24 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 21 Mar 2024 12:37:24 GMT
Subject: Integrated: 8327994: Update code gen in CallGeneratorHelper
In-Reply-To: <zFBzrJ8FEI7yrwITdz5YCmwL2cm2W100I4enNOW-mwo=.ca09bbf3-0caa-46f4-8553-143630d39dd2@github.com>
References: <zFBzrJ8FEI7yrwITdz5YCmwL2cm2W100I4enNOW-mwo=.ca09bbf3-0caa-46f4-8553-143630d39dd2@github.com>
Message-ID: <VCxXVIEfpaynCH6gStwbBNLBpJMdx3ie00OK2nybe5I=.8ddf1952-3dc6-4569-898a-60ba366d1d40@github.com>

On Wed, 13 Mar 2024 11:28:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Update the code gen code in CallGeneratorHelper to reflect the latest state of the libTest(Downcall/Upcall)(Stack).c and shared.h files.
> 
> - The previous code wanted users to pipe stdout into a file. But, since we have 5 files that need to be created, and the names of those files is important too, I've changed the script to write to those files directly instead.
> - I moved the definition of `S_FFFF` to libVarArgs.c where it's used, as it's not actually generated by CallGeneratorHelper.
> - GitHub doesn't render the changes to some of the files, but those files only contain either white space changes (some missing spaces after `,`), and copyright header updates.

This pull request has now been integrated.

Changeset: ac2f8e5a
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac2f8e5af8c88cd13038b113f82bb7c17a38aa40
Stats:     36078 lines in 6 files changed: 62 ins; 40 del; 35976 mod

8327994: Update code gen in CallGeneratorHelper

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/18269

From asotona at openjdk.org  Thu Mar 21 12:57:28 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Mar 2024 12:57:28 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include checks
 from hotspot/share/classfile/classFileParser.cpp
Message-ID: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>

ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.

Also new `VerifierSelfTest::testParserVerifier` has been added.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - work in progress
 - work in progress
 - work in progress
 - work in progress
 - work in progress
 - removed string templates from test
 - work in progress
 - work in progress
 - work in progress
 - work in progress
 - ... and 15 more: https://git.openjdk.org/jdk/compare/784f11c3...b3c34820

Changes: https://git.openjdk.org/jdk/pull/16809/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320396
  Stats: 706 lines in 6 files changed: 672 ins; 8 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/16809.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809

PR: https://git.openjdk.org/jdk/pull/16809

From asotona at openjdk.org  Thu Mar 21 14:40:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Mar 2024 14:40:37 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v2]
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> 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 26 commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
 - work in progress
 - work in progress
 - work in progress
 - work in progress
 - work in progress
 - removed string templates from test
 - work in progress
 - work in progress
 - work in progress
 - ... and 16 more: https://git.openjdk.org/jdk/compare/e41bc42d...54c4e9b9

-------------

Changes: https://git.openjdk.org/jdk/pull/16809/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=01
  Stats: 706 lines in 6 files changed: 672 ins; 8 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/16809.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809

PR: https://git.openjdk.org/jdk/pull/16809

From jpai at openjdk.org  Thu Mar 21 14:44:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 14:44:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>

On Tue, 19 Mar 2024 17:58:46 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

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57:

> 55: 
> 56:             File flagsFile = File.createTempFile("CheckOriginFlags", null);
> 57:             flagsFile.deleteOnExit();

Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary).
Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do:


File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile();

and don't need any explicit deletions?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534054951

From ihse at openjdk.org  Thu Mar 21 14:57:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Mar 2024 14:57:29 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: <VxmGlRYbm6YgNfgGegfXfu-iHQjJkJs5B3zPCQfSYqE=.8515aa64-efd0-4aad-a4bc-5cd830491ead@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

make/Images.gmk line 124:

> 122: 
> 123: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
> 124: 

Please avoid newlines after if statements.

Suggestion:

make/Images.gmk line 131:

> 129:   # in FixPath call in order to avoid needing to use strip.
> 130:   RL_JIMAGE_PATH_ARG := $(call FixPath,$(JDK_LINK_OUTPUT_DIR)/lib/modules)
> 131:   RL_MOD_PATH_ARG := $(call FixPath,$(IMAGES_OUTPUTDIR)/jmods)

I'd much rather prefer to use strip and have proper space after commas. This is the approach taken elsewhere in the build system.

Suggestion:

  RL_JIMAGE_PATH_ARG := $(strip $(call FixPath, $(JDK_LINK_OUTPUT_DIR)/lib/modules))
  RL_MOD_PATH_ARG := $(strip $(call FixPath, $(IMAGES_OUTPUTDIR)/jmods))

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?

make/Images.gmk line 171:

> 169: 
> 170:   JLINK_JDK_TARGETS += $(jlink_runtime_jdk)
> 171: 

Please avoid newlines before endif statements.

Suggestion:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534080047
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534079021
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534082359
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534080744

From ihse at openjdk.org  Thu Mar 21 15:04:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Mar 2024 15:04:32 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: <dAlJmW3cp8iTHu3hHREuQiK19yltm6TZnfPvFEcPi4I=.79c9ef33-dd43-48d2-bbbc-8d6a714b7923@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

make/jdk/src/jdk.unsupported_jlink_runtime/share/classes/build/tools/runtimelink/CreateLinkableRuntimePlugin.java line 1:

> 1: /*

This file does not at all fit in with the pattern of other build tools, which are not module-based but instead live in packages `build.tools.*` in the `make/jdk/src/classes` directory. We will need to find a better arrangement for this.

First question, do this class really need to be in a separate module? (I'm afraid the answer is "yes" but I need to ask it anyway).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534094775

From jpai at openjdk.org  Thu Mar 21 15:05:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:05:26 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <-LZotlcsvx3EbHNNn0DO-u7HsWB302dYqZ33vFTf0UA=.9728ca78-a90f-4705-8b81-de5c61d342ca@github.com>

On Tue, 19 Mar 2024 17:58:46 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

test/jdk/java/nio/channels/unixdomain/Bind.java line 201:

> 199:                 System.out.println("Null server address: " + server.getLocalAddress());
> 200:             } finally {
> 201:                 Files.deleteIfExists(usa.getPath());

`usa` can be `null` here, if it never got assigned due to some exception in the prior lines, which can lead to a `NullPointerException` here.

test/jdk/java/nio/channels/unixdomain/Bind.java line 341:

> 339:                 assertAddress(client.getRemoteAddress(), usa, "server");
> 340:             } finally {
> 341:                 Files.deleteIfExists(usa.getPath());

Same applies here about potential NullPointerException and some other places in other files as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534092806
PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534095046

From ihse at openjdk.org  Thu Mar 21 15:08:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Mar 2024 15:08:30 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: <7xzEVrU4b4lQ_XHrVxJI3jaYeUfNS8Pq45wgvabaO64=.be88e5ff-9bcb-4e4a-925c-867d94b7b386@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

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 36:

> 34: 
> 35: /**
> 36:  * Used by the build-only jlink plugin CreateLinkableRuntimePlugin.

Why does this file not live next to the jlink plugin then? Does it have to be part of the jdk.jlink module?

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534102351
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534103809

From jpai at openjdk.org  Thu Mar 21 15:09:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:09:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>

On Tue, 19 Mar 2024 17:58:46 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

test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95:

> 93: 
> 94:         // ensure that the archive is still readable, and the date is 1979-11-30
> 95:         Path path = Utils.createTempFile("out", ".zip");

So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534105420

From jpai at openjdk.org  Thu Mar 21 15:21:22 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:21:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
Message-ID: <X0IV-EGzKzXEU8x5unjACl1wpmuxiX_AlZ4nzNTqQdY=.080e0617-6ea3-4e3a-ad1e-7b063482f20f@github.com>

On Tue, 19 Mar 2024 10:01:31 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> > In AIX, we have an usecase where shared libraries have certain member objects to be referred to. E.g libclang.a(shr_64.o) .
>>> 
>>> Would you happen to know any official documentation which explains that AIX syntax?
>>> 
>> 
>> https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command
>> Text : 
>> 
>> **autoload:?path/file(member) | Automatically load the archive member.
>> -- | --**
>> Autoload is a  flag used to load archive members. The format of the path is mentioned.
>
>> Do you mean some application code is calling the `System.loadLibrary()` method with such values?
> 
> Yes we are trying to install liblcang and also jextract and it fails with errors.
> 
> Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>  
>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>         at java.base/java.lang.System.loadLibrary(System.java:2063)
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
> 
> 
> The actual member is libclang.a(libclang.so.16)

Hello @suchismith1993, I haven't fully caught up on the necessity of this change. The current proposed change, renames files in the underlying filesystem in the code flow of `System.loadLibrary()` and I don't think is the right thing to do irrespective of whether we do it in AIX specific code or common code.

Could you update the JBS issue description to clearly explain what (application?) code is causing what issue? I know you mentioned about jextract here, but it's not clear whether this is some issue in jextract or something else. Having all those details in the JBS issue will be helpful to decide what changes should be pursued.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534124561

From jpai at openjdk.org  Thu Mar 21 15:25:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:25:21 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <X0IV-EGzKzXEU8x5unjACl1wpmuxiX_AlZ4nzNTqQdY=.080e0617-6ea3-4e3a-ad1e-7b063482f20f@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
 <X0IV-EGzKzXEU8x5unjACl1wpmuxiX_AlZ4nzNTqQdY=.080e0617-6ea3-4e3a-ad1e-7b063482f20f@github.com>
Message-ID: <OITNnRh5XI8_jpUrAZ-3dairZE1IkSBte_IgYcsbiVo=.5b4ba626-598b-4448-b83e-3470e3120c1c@github.com>

On Thu, 21 Mar 2024 15:18:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Do you mean some application code is calling the `System.loadLibrary()` method with such values?
>> 
>> Yes we are trying to install liblcang and also jextract and it fails with errors.
>> 
>> Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>>  
>>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
>>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>>         at java.base/java.lang.System.loadLibrary(System.java:2063)
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
>> 
>> 
>> The actual member is libclang.a(libclang.so.16)
>
> Hello @suchismith1993, I haven't fully caught up on the necessity of this change. The current proposed change, renames files in the underlying filesystem in the code flow of `System.loadLibrary()` and I don't think is the right thing to do irrespective of whether we do it in AIX specific code or common code.
> 
> Could you update the JBS issue description to clearly explain what (application?) code is causing what issue? I know you mentioned about jextract here, but it's not clear whether this is some issue in jextract or something else. Having all those details in the JBS issue will be helpful to decide what changes should be pursued.

As for this:

> Yes we are trying to install liblcang and also jextract and it fails with errors.

> Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>
    at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
    at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
    at java.base/java.lang.System.loadLibrary(System.java:2063)
    at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
    at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
    at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
    at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
    at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
    at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
    at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))


I had a quick look at the latest jextract code and I don't see some of the classes that are reported in that stacktrace. Which exact version of jextract is this? If jextract is what motivated this change, then I would recommend checking on jextract-dev mailing list first https://mail.openjdk.org/mailman/listinfo/jextract-dev to understand if this is an issue in jextract itself.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534132674

From sgehwolf at openjdk.org  Thu Mar 21 15:37:34 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 21 Mar 2024 15:37:34 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <VxmGlRYbm6YgNfgGegfXfu-iHQjJkJs5B3zPCQfSYqE=.8515aa64-efd0-4aad-a4bc-5cd830491ead@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>
Message-ID: <2vB9N80N5vzYIQiyt9yb2bufOR-l_mH4g5C4qZ9_Jm0=.57d0cc34-50b5-4965-8229-2c046014088d@github.com>

On Thu, 21 Mar 2024 14:54:15 GMT, Magnus Ihse Bursie <ihse 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
>
> make/Images.gmk line 124:
> 
>> 122: 
>> 123: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
>> 124: 
> 
> Please avoid newlines after if statements.
> 
> Suggestion:

OK.

> make/Images.gmk line 131:
> 
>> 129:   # in FixPath call in order to avoid needing to use strip.
>> 130:   RL_JIMAGE_PATH_ARG := $(call FixPath,$(JDK_LINK_OUTPUT_DIR)/lib/modules)
>> 131:   RL_MOD_PATH_ARG := $(call FixPath,$(IMAGES_OUTPUTDIR)/jmods)
> 
> I'd much rather prefer to use strip and have proper space after commas. This is the approach taken elsewhere in the build system.
> 
> Suggestion:
> 
>   RL_JIMAGE_PATH_ARG := $(strip $(call FixPath, $(JDK_LINK_OUTPUT_DIR)/lib/modules))
>   RL_MOD_PATH_ARG := $(strip $(call FixPath, $(IMAGES_OUTPUTDIR)/jmods))

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.

> 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...

> make/Images.gmk line 171:
> 
>> 169: 
>> 170:   JLINK_JDK_TARGETS += $(jlink_runtime_jdk)
>> 171: 
> 
> Please avoid newlines before endif statements.
> 
> Suggestion:

OK. Will fix.

> First question, do this class really need to be in a separate module? (I'm afraid the answer is "yes" but I need to ask it anyway).

Yes, because it uses the `Plugin` ServiceLoader extension using the boot ModuleLayer. But it's going to be a moot point because this'll get reworked due to concerns raised by @mlchung (having the plugin pipeline running when producing a linkable runtime jimage).

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 36:
> 
>> 34: 
>> 35: /**
>> 36:  * Used by the build-only jlink plugin CreateLinkableRuntimePlugin.
> 
> Why does this file not live next to the jlink plugin then? Does it have to be part of the jdk.jlink module?

The idea was to have the "supporting" classes inside jdk.jlink to keep code-bases in sync. But the actual invocation of them should be in the build code. This will likely change again.

> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534137541
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534141577
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534148956
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534137294
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534136264
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534154082
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534151066

From ihse at openjdk.org  Thu Mar 21 15:37:35 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Mar 2024 15:37:35 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: <nPDJ7Lc3TWtM3A6hE5SEvHOGFD23WtBiHvTBuVwALLY=.8a444e4c-4fde-4046-be06-2d3fc7f09bfc@github.com>

On Thu, 21 Mar 2024 15:27:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> make/Images.gmk line 131:
>> 
>>> 129:   # in FixPath call in order to avoid needing to use strip.
>>> 130:   RL_JIMAGE_PATH_ARG := $(call FixPath,$(JDK_LINK_OUTPUT_DIR)/lib/modules)
>>> 131:   RL_MOD_PATH_ARG := $(call FixPath,$(IMAGES_OUTPUTDIR)/jmods)
>> 
>> I'd much rather prefer to use strip and have proper space after commas. This is the approach taken elsewhere in the build system.
>> 
>> Suggestion:
>> 
>>   RL_JIMAGE_PATH_ARG := $(strip $(call FixPath, $(JDK_LINK_OUTPUT_DIR)/lib/modules))
>>   RL_MOD_PATH_ARG := $(strip $(call FixPath, $(IMAGES_OUTPUTDIR)/jmods))
>
> 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?

>> make/jdk/src/jdk.unsupported_jlink_runtime/share/classes/build/tools/runtimelink/CreateLinkableRuntimePlugin.java line 1:
>> 
>>> 1: /*
>> 
>> This file does not at all fit in with the pattern of other build tools, which are not module-based but instead live in packages `build.tools.*` in the `make/jdk/src/classes` directory. We will need to find a better arrangement for this.
>> 
>> First question, do this class really need to be in a separate module? (I'm afraid the answer is "yes" but I need to ask it anyway).
>
>> First question, do this class really need to be in a separate module? (I'm afraid the answer is "yes" but I need to ask it anyway).
> 
> Yes, because it uses the `Plugin` ServiceLoader extension using the boot ModuleLayer. But it's going to be a moot point because this'll get reworked due to concerns raised by @mlchung (having the plugin pipeline running when producing a linkable runtime jimage).

Ok, fine. Will the new solution still include a build-time only tool?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534149409
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534146496

From sgehwolf at openjdk.org  Thu Mar 21 15:37:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 21 Mar 2024 15:37:35 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: <vmuux88zamMVuqmXJ9MJFRoOuwTAzTSpx5rYTVS-SzI=.b3c15c0d-a926-468f-8ad4-e4d96d0e1ee1@github.com>

On Thu, 21 Mar 2024 15:28:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> First question, do this class really need to be in a separate module? (I'm afraid the answer is "yes" but I need to ask it anyway).
>> 
>> Yes, because it uses the `Plugin` ServiceLoader extension using the boot ModuleLayer. But it's going to be a moot point because this'll get reworked due to concerns raised by @mlchung (having the plugin pipeline running when producing a linkable runtime jimage).
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1534158026

From mdoerr at openjdk.org  Thu Mar 21 15:46:23 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 21 Mar 2024 15:46:23 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <OITNnRh5XI8_jpUrAZ-3dairZE1IkSBte_IgYcsbiVo=.5b4ba626-598b-4448-b83e-3470e3120c1c@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
 <X0IV-EGzKzXEU8x5unjACl1wpmuxiX_AlZ4nzNTqQdY=.080e0617-6ea3-4e3a-ad1e-7b063482f20f@github.com>
 <OITNnRh5XI8_jpUrAZ-3dairZE1IkSBte_IgYcsbiVo=.5b4ba626-598b-4448-b83e-3470e3120c1c@github.com>
Message-ID: <d5IuO_08XPIXSvSG6_tH3r7DRON45ucP8IwNR11OXdE=.167a0f62-c23c-43be-ba97-d4b3109b1fcc@github.com>

On Thu, 21 Mar 2024 15:22:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello @suchismith1993, I haven't fully caught up on the necessity of this change. The current proposed change, renames files in the underlying filesystem in the code flow of `System.loadLibrary()` and I don't think is the right thing to do irrespective of whether we do it in AIX specific code or common code.
>> 
>> Could you update the JBS issue description to clearly explain what (application?) code is causing what issue? I know you mentioned about jextract here, but it's not clear whether this is some issue in jextract or something else. Having all those details in the JBS issue will be helpful to decide what changes should be pursued.
>
> As for this:
> 
>> Yes we are trying to install liblcang and also jextract and it fails with errors.
> 
>> Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>>
>     at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
>     at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>     at java.base/java.lang.System.loadLibrary(System.java:2063)
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
> 
> 
> I had a quick look at the latest jextract code and I don't see some of the classes that are reported in that stacktrace. Which exact version of jextract is this? If jextract is what motivated this change, then I would recommend checking on jextract-dev mailing list first https://mail.openjdk.org/mailman/listinfo/jextract-dev to understand if this is an issue in jextract itself.

I had experimented with the jdk22 branch of jextract. AIX is currently not supported. `libclang.a(libclang.so.16)` only severs as an example use case. However, archives which require a member specification seem to be quite common on AIX. So, not supporting them is a major limitation for the foreign function interface. We need to discuss which formats should be supported by `System.loadLibrary`:

- `System.loadLibrary("clang(libclang.so.16)")`
- `System.loadLibrary("clang.a(libclang.so.16)")`
- `System.loadLibrary("libclang.a(libclang.so.16)")`

I think the first variant should be supported. Maybe not the others?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534172694

From sroy at openjdk.org  Thu Mar 21 15:54:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 21 Mar 2024 15:54:21 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
Message-ID: <k4a2O7QCOkiNlQ34v7J32vA2Soz15iHK6iO2b25jTzY=.ce61d16d-a974-45c2-8d31-044b750bd0dc@github.com>

On Tue, 19 Mar 2024 10:01:31 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> > In AIX, we have an usecase where shared libraries have certain member objects to be referred to. E.g libclang.a(shr_64.o) .
>>> 
>>> Would you happen to know any official documentation which explains that AIX syntax?
>>> 
>> 
>> https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command
>> Text : 
>> 
>> **autoload:?path/file(member) | Automatically load the archive member.
>> -- | --**
>> Autoload is a  flag used to load archive members. The format of the path is mentioned.
>
>> Do you mean some application code is calling the `System.loadLibrary()` method with such values?
> 
> Yes we are trying to install liblcang and also jextract and it fails with errors.
> 
> Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>  
>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>         at java.base/java.lang.System.loadLibrary(System.java:2063)
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
> 
> 
> The actual member is libclang.a(libclang.so.16)

> Hello @suchismith1993, I haven't fully caught up on the necessity of this change. The current proposed change, renames files in the underlying filesystem in the code flow of `System.loadLibrary()` and I don't think is the right thing to do irrespective of whether we do it in AIX specific code or common code.
> 
> Could you update the JBS issue description to clearly explain what (application?) code is causing what issue? I know you mentioned about jextract here, but it's not clear whether this is some issue in jextract or something else. Having all those details in the JBS issue will be helpful to decide what changes should be pursued.

This is not specific to an application. We are looking to support member objects of AIX shared libraries in the Java ClassLoader. 
As for the renaming, the renaming is necessary because the member object is not part of the actual filename. 
Example : libclang.a(libclang.so.16) 
This member object, is identified only by the dlopen() in the hotspot code. But there is no actual file named libclang.a(libclang.so.16) in the filesystem. 
So when the check is done if file exists, it fails,i.e it checks for libclang.a(libclang.so.16).So i remove the braces and member name to extract the actual name of the file in the filesystem, which is libclang.a. But when welibclang.a and the dlopen ,it will fail to open it. 
Hence i need to rename the file to the name with braces before it passes to dlopen.So i reconstruct it to libclang.a(libclang.so.16)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534186639

From sroy at openjdk.org  Thu Mar 21 16:14:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 21 Mar 2024 16:14:21 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <k4a2O7QCOkiNlQ34v7J32vA2Soz15iHK6iO2b25jTzY=.ce61d16d-a974-45c2-8d31-044b750bd0dc@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
 <k4a2O7QCOkiNlQ34v7J32vA2Soz15iHK6iO2b25jTzY=.ce61d16d-a974-45c2-8d31-044b750bd0dc@github.com>
Message-ID: <jYgkrmEP9p7XlZe4eGRSYm_gERv8HYBDZLkL_rQ7oXI=.1cd46276-4959-45cb-b183-7c6cc4099b0d@github.com>

On Thu, 21 Mar 2024 15:51:59 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> Do you mean some application code is calling the `System.loadLibrary()` method with such values?
>> 
>> Yes we are trying to install liblcang and also jextract and it fails with errors.
>> 
>> Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>>  
>>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
>>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>>         at java.base/java.lang.System.loadLibrary(System.java:2063)
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
>>         at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
>> 
>> 
>> The actual member is libclang.a(libclang.so.16)
>
>> Hello @suchismith1993, I haven't fully caught up on the necessity of this change. The current proposed change, renames files in the underlying filesystem in the code flow of `System.loadLibrary()` and I don't think is the right thing to do irrespective of whether we do it in AIX specific code or common code.
>> 
>> Could you update the JBS issue description to clearly explain what (application?) code is causing what issue? I know you mentioned about jextract here, but it's not clear whether this is some issue in jextract or something else. Having all those details in the JBS issue will be helpful to decide what changes should be pursued.
> 
> This is not specific to an application. We are looking to support member objects of AIX shared libraries in the Java ClassLoader. 
> As for the renaming, the renaming is necessary because the member object is not part of the actual filename. 
> Example : libclang.a(libclang.so.16) 
> This member object, is identified only by the dlopen() in the hotspot code. But there is no actual file named libclang.a(libclang.so.16) in the filesystem. 
> So when the check is done if file exists, it fails,i.e it checks for libclang.a(libclang.so.16).So i remove the braces and member name to extract the actual name of the file in the filesystem, which is libclang.a. But when we pass libclang.a to the dlopen ,it will fail to open it. 
> Hence i need to rename the file to the name with braces before it passes to dlopen.So i reconstruct it to libclang.a(libclang.so.16)

> As for this:
> 
> > Yes we are trying to install liblcang and also jextract and it fails with errors.
> 
> > Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
> 
> ```
> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
> at java.base/java.lang.System.loadLibrary(System.java:2063)
> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
> at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
> at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
> ```
> 
> I had a quick look at the latest jextract code and I don't see some of the classes that are reported in that stacktrace. Which exact version of jextract is this? If jextract is what motivated this change, then I would recommend checking on jextract-dev mailing list first https://mail.openjdk.org/mailman/listinfo/jextract-dev to understand if this is an issue in jextract itself.

Jextract is one use case that prompted to make this change. There is no issue with the Jextract in particular. We probably might need a small change in the Index java file. But there are use cases where we need to support AIX dynamic archives to be able to load using Java ClassLoader,which is more like a front end to the hotspot code.
This support got recently added to hotspot code too. It is important to have it at the classloader level too.
@JoKern65  Could you add in more on the importance of this and provide your inputs ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534221275

From psandoz at openjdk.org  Thu Mar 21 16:52:24 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 21 Mar 2024 16:52:24 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false [v4]
In-Reply-To: <8i5GewezI8x7UvxpD6annahxVLdDIp2_ye2L2C11UgM=.4ca682e8-a763-49db-ab3d-89b10df646a6@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
 <8i5GewezI8x7UvxpD6annahxVLdDIp2_ye2L2C11UgM=.4ca682e8-a763-49db-ab3d-89b10df646a6@github.com>
Message-ID: <KMlTgyy2qLJ2iticmhuRuG9l8R0e-6bG808cmmVX8-c=.7585127e-5b5c-46ed-96ce-9c7f19e63cab@github.com>

On Wed, 20 Mar 2024 23:58:32 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
>> 
>> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.
>
> Viktor Klang 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:
> 
>  - Updating copyright year and switching to use underscores in GathererShortCircuitTest
>  - Adds differentiation between direct and transitive short circutiting for Gatherers

Marked as reviewed by psandoz (Reviewer).

src/java.base/share/classes/java/util/stream/GathererOp.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18351#pullrequestreview-1952810339
PR Review Comment: https://git.openjdk.org/jdk/pull/18351#discussion_r1534280411

From jlu at openjdk.org  Thu Mar 21 16:53:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Mar 2024 16:53:23 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v8]
In-Reply-To: <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
 <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
Message-ID: <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>

On Tue, 19 Mar 2024 17:59:48 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update the copyright year to 2024
>>  - Revert "update the latter years for the Oracle copyrights"
>>    
>>    This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.
>
> Thank you justin

Hi @nizarbenalla , you can comment `/integrate` whenever you're ready, and we can sponsor the change to have it integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2012982347

From bhuang at openjdk.org  Thu Mar 21 16:54:21 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 16:54:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
Message-ID: <AW72Q2T6TyFJRUkyTjV-eZJdV0KUGZ-YFQa_ZatithQ=.bfd1c59b-1823-4c87-aa5f-5473959f4278@github.com>

On Thu, 21 Mar 2024 14:41:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57:
> 
>> 55: 
>> 56:             File flagsFile = File.createTempFile("CheckOriginFlags", null);
>> 57:             flagsFile.deleteOnExit();
> 
> Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary).
> Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do:
> 
> 
> File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile();
> 
> and don't need any explicit deletions?

Hi Jaikiran, I think both solutions work for this bug. I personally prefer to place the files in the scratch directory for the ease of debugging. 
In addition, for this specific test, I am considering using File.createTempFile("CheckOriginaFlags", null, Path.of(".").toFile) instead of Files.createTempFile for consistency purposes, as Files.createTempFile may have more restrictive access permissions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534283105

From bhuang at openjdk.org  Thu Mar 21 16:59:20 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 16:59:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
Message-ID: <5fp1NwbiBibdMUnZA8mIj76MLVvTxdA2m_z9IM8dUEc=.28d46052-8e8d-4ede-96ac-5da5d7a568a9@github.com>

On Thu, 21 Mar 2024 15:06:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments
>
> test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95:
> 
>> 93: 
>> 94:         // ensure that the archive is still readable, and the date is 1979-11-30
>> 95:         Path path = Utils.createTempFile("out", ".zip");
> 
> So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`?

Yes, you are right. We don't need explicit deletion for these files by using this util method, Utils.createTempFile.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534290137

From jpai at openjdk.org  Thu Mar 21 17:00:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 17:00:21 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <jYgkrmEP9p7XlZe4eGRSYm_gERv8HYBDZLkL_rQ7oXI=.1cd46276-4959-45cb-b183-7c6cc4099b0d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
 <k4a2O7QCOkiNlQ34v7J32vA2Soz15iHK6iO2b25jTzY=.ce61d16d-a974-45c2-8d31-044b750bd0dc@github.com>
 <jYgkrmEP9p7XlZe4eGRSYm_gERv8HYBDZLkL_rQ7oXI=.1cd46276-4959-45cb-b183-7c6cc4099b0d@github.com>
Message-ID: <gxoQU62rGdxFq62YkyovjCpxuFaB_4NzhzbKTIijYP0=.fc6dd27b-d880-46e8-ab13-937e1588f57d@github.com>

On Thu, 21 Mar 2024 16:11:16 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> Hello @suchismith1993, I haven't fully caught up on the necessity of this change. The current proposed change, renames files in the underlying filesystem in the code flow of `System.loadLibrary()` and I don't think is the right thing to do irrespective of whether we do it in AIX specific code or common code.
>>> 
>>> Could you update the JBS issue description to clearly explain what (application?) code is causing what issue? I know you mentioned about jextract here, but it's not clear whether this is some issue in jextract or something else. Having all those details in the JBS issue will be helpful to decide what changes should be pursued.
>> 
>> This is not specific to an application. We are looking to support member objects of AIX shared libraries in the Java ClassLoader. 
>> As for the renaming, the renaming is necessary because the member object is not part of the actual filename. 
>> Example : libclang.a(libclang.so.16) 
>> This member object, is identified only by the dlopen() in the hotspot code. But there is no actual file named libclang.a(libclang.so.16) in the filesystem. 
>> So when the check is done if file exists, it fails,i.e it checks for libclang.a(libclang.so.16).So i remove the braces and member name to extract the actual name of the file in the filesystem, which is libclang.a. But when we pass libclang.a to the dlopen ,it will fail to open it. 
>> Hence i need to rename the file to the name with braces before it passes to dlopen.So i reconstruct it to libclang.a(libclang.so.16)
>
>> As for this:
>> 
>> > Yes we are trying to install liblcang and also jextract and it fails with errors.
>> 
>> > Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>> 
>> ```
>> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>> at java.base/java.lang.System.loadLibrary(System.java:2063)
>> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
>> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
>> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
>> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
>> at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
>> at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
>> at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
>> ```
>> 
>> I had a quick look at the latest jextract code and I don't see some of the classes that are reported in that stacktrace. Which exact version of jextract is this? If jextract is what motivated this change, then I would recommend checking on jextract-dev mailing list first https://mail.openjdk.org/mailman/listinfo/jextract-dev to understand if this is an issue in jextract itself.
> 
> Jextract is one use case that prompted to make this change. There is no issue with the Jextract in particular. We probably might need a small change in the Index java file. But there are use cases where we need ...

> But there is no actual file named libclang.a(libclang.so.16) in the filesystem.
So when the check is done if file exists, it fails,i.e it checks for libclang.a(libclang.so.16).

I'll let Mandy and others more knowledgable of this area to correct me. From what I know, there was a change done a few releases back in the JDK (https://bugs.openjdk.org/browse/JDK-8275703) which accomodated macos platform where it too doesn't actually have the file on the filesystem in recent versions of macos. That change allowed platform specific code to dictate whether the file existence check needs to be done here in this loadLibrary code. That's done through the call to `jdk.internal.loader.ClassLoaderHelper.loadLibraryOnlyIfPresent()`. For macos, that implementation of that method resides in macos specific class here https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java#L41. For AIX too then, perhaps you could add an implementation which returns `false` (either always or in specific cases) and experiment with that to see if that's enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534292292

From vklang at openjdk.org  Thu Mar 21 17:04:53 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 21 Mar 2024 17:04:53 GMT
Subject: RFR: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false [v5]
In-Reply-To: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
Message-ID: <OeDGSCKJMHU6HeNDTlwUAoaHXx0Iq69Sox_SVjMiY4I=.9b8e16d3-cf00-4308-b606-8b81d37f086a@github.com>

> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
> 
> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/stream/GathererOp.java
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18351/files
  - new: https://git.openjdk.org/jdk/pull/18351/files/8974d9f9..763366c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18351&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18351&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18351/head:pull/18351

PR: https://git.openjdk.org/jdk/pull/18351

From jpai at openjdk.org  Thu Mar 21 17:09:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 17:09:19 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <gxoQU62rGdxFq62YkyovjCpxuFaB_4NzhzbKTIijYP0=.fc6dd27b-d880-46e8-ab13-937e1588f57d@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
 <k4a2O7QCOkiNlQ34v7J32vA2Soz15iHK6iO2b25jTzY=.ce61d16d-a974-45c2-8d31-044b750bd0dc@github.com>
 <jYgkrmEP9p7XlZe4eGRSYm_gERv8HYBDZLkL_rQ7oXI=.1cd46276-4959-45cb-b183-7c6cc4099b0d@github.com>
 <gxoQU62rGdxFq62YkyovjCpxuFaB_4NzhzbKTIijYP0=.fc6dd27b-d880-46e8-ab13-937e1588f57d@github.com>
Message-ID: <BBLcz8MarNdkPxOOPcxsCejmCi1pzowrcKGfr1nlozQ=.13ee9664-999e-478b-bd9a-127f1c9fc4a2@github.com>

On Thu, 21 Mar 2024 16:57:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> For AIX too then, perhaps you could add an implementation which returns false (either always or in specific cases) and experiment with that to see if that's enough?

I see that you actually have a ClassLoaderHelper in this PR for AIX, but that implementation in `loadLibraryOnlyIfPresent()` is currently returning `true` and thus enforcing the file existence check. Was it intentional to have it to `true`? Given the context of this change, shouldn't it be returning `false`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534306257

From bhuang at openjdk.org  Thu Mar 21 17:13:46 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 17:13:46 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
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: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@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:

  Fixed potential NPE issues.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/620f9259..2517f756

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=01-02

  Stats: 11 lines in 4 files changed: 5 ins; 1 del; 5 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 aefimov at openjdk.org  Thu Mar 21 17:21:24 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 21 Mar 2024 17:21:24 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v9]
In-Reply-To: <X-55Tn0ivPbmqrBWus1iStnLF63u0xdSsDZiJ0wbdyQ=.d93798d4-6d78-46a6-8bf2-7a7ca950eb97@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <X-55Tn0ivPbmqrBWus1iStnLF63u0xdSsDZiJ0wbdyQ=.d93798d4-6d78-46a6-8bf2-7a7ca950eb97@github.com>
Message-ID: <DEDobPNSes1ghWywjOdzx-1f5dFr1lZqmBZsvmkYpdo=.f3d9bf6b-f3c5-44ee-8c95-ebee736a6300@github.com>

On Wed, 20 Mar 2024 21:19:38 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer 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:
> 
>  - Review suggestions Aleksei
>  - Merge branch 'master' into JDK-8325579
>  - Update module-info text
>  - Merge branch 'master' into JDK-8325579
>  - Indentation
>  - Merge branch 'master' into JDK-8325579
>  - Review feedback
>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>  - Merge branch 'master' into JDK-8325579
>  - Typo
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/02859d70...8fdc039c

The latest changes look good to me. Thank you for addressing all the comments. 
I've tested the proposed change with JNDI regression tests, including the modified one, and there are no new issues discovered.

-------------

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17797#pullrequestreview-1952901178

From mullan at openjdk.org  Thu Mar 21 17:46:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 17:46:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <H3UoDTth09CIdHaBVX8occDp0THRZY-SI9UrWHnTN0c=.c3e8aaf5-0e94-4599-9862-5a8cdc09f3be@github.com>

On Thu, 21 Mar 2024 17:13:46 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:
> 
>   Fixed potential NPE issues.

The bug should have a `noreg-self` label.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2013158192

From liach at openjdk.org  Thu Mar 21 18:01:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Mar 2024 18:01:38 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
Message-ID: <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@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 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

-------------

Changes: https://git.openjdk.org/jdk/pull/15834/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15834&range=01
  Stats: 89 lines in 2 files changed: 87 ins; 0 del; 2 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 jlu at openjdk.org  Thu Mar 21 18:12:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Mar 2024 18:12:52 GMT
Subject: RFR: JDK-8327640: Allow NumberFormat strict parsing [v3]
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: <7_mpxWeNVmfq7TzzANs25293m8lD0cmUkT1595MFT1I=.344529c9-6ce2-4ef3-a8aa-d5f6de2131fd@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 three additional commits since the last revision:

 - Re-work specification wording from Format down to subclasses
 - implement white space suggestions
 - remove unsupported methods header, should go in JDK-8327875 instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/c3a32500..c09a34dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=01-02

  Stats: 128 lines in 4 files changed: 21 ins; 64 del; 43 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  Thu Mar 21 18:12:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Mar 2024 18:12:52 GMT
Subject: RFR: JDK-8327640: Allow NumberFormat strict parsing [v2]
In-Reply-To: <EvPX2cY93CUliSON9s06Ecx0oqLAidIj1R60PORW5ig=.b58a7655-e11d-4a02-a831-cb85ee8dbaf6@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
 <rl0Y0vv1IjraFLkn_iIpCIFgk9X4qE08snhdc3AP55s=.d7cf85ca-0b90-4145-9c5b-86dac3bed664@github.com>
 <EvPX2cY93CUliSON9s06Ecx0oqLAidIj1R60PORW5ig=.b58a7655-e11d-4a02-a831-cb85ee8dbaf6@github.com>
Message-ID: <yDGG6eJVLsqQBE9cMZRRWqw-qmlbsRpyBfzXEPvY3mQ=.1f8ba92d-0a4d-41bf-b13b-9238cc8b2800@github.com>

On Tue, 19 Mar 2024 08:56:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace protected field with a public getter -> isStrict().
>>   Replace setLenient() with setStrict() to avoid messy inversion of boolean.
>>   Add a leniency section to NumberFormat.
>>   Overhaul of NumberFormat class specification to be much more organized/readable.
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 2482:
> 
>> 2480:         // process digits or Inf, find decimal position
>> 2481:         status[STATUS_INFINITE] = false;
>> 2482:         if (!isExponent && text.regionMatches(position, symbols.getInfinity(),0,
> 
> Suggestion:
> 
>         if (!isExponent && text.regionMatches(position, symbols.getInfinity(), 0,

Thanks, this and the other suggestions you provided should be fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1534407476

From vklang at openjdk.org  Thu Mar 21 19:22:26 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 21 Mar 2024 19:22:26 GMT
Subject: Integrated: 8328316: Finisher cannot emit if stream is sequential and
 integrator returned false
In-Reply-To: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
References: <QC02LzQND22M89-ylXbhoGMlrYYC2R0VUVPx4XKzrGI=.89fc2818-8d47-45fe-bc4f-567b03241117@github.com>
Message-ID: <ptDZcLlRuRgV0ry54YF7sLBXokXgM6HouFriJE-SsFE=.49f0af60-61e6-4889-99ac-f00b2e534f68@github.com>

On Mon, 18 Mar 2024 16:27:13 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Adds differentiation between direct and transitive short circuiting which could prevent pushing downstream in the finisher for built-ins that were not `collect()`.
> 
> Creating this as a draft PR for now, just need to run some benchmarks to validate no significant regressions first.

This pull request has now been integrated.

Changeset: ab28045d
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab28045d7785d948b2bce685f06043e8217961f4
Stats:     71 lines in 2 files changed: 66 ins; 0 del; 5 mod

8328316: Finisher cannot emit if stream is sequential and integrator returned false

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/18351

From jvernee at openjdk.org  Thu Mar 21 19:27:21 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 21 Mar 2024 19:27:21 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <yiOoDg6WmDVpoKakwzF-h4Zn7O0t5Dh8n1AzsFjK6dY=.731ec816-6802-46e1-9b23-1dc3b8a21afb@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

I think ideally the member suffix should be added by `System.mapLibraryName` since that takes care of mapping the platform agnostic library name to a platform specific string that identifies a library. Is it possible to infer the member name from the library name? (e.g. from `clang` infer `clang(libclang.so.16)`).

FWIW, there exists an API that is a more direct proxy for dlopen, which is `SymbolLookup.libaryLookup`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013435496

From liach at openjdk.org  Thu Mar 21 19:28:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Mar 2024 19:28:22 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <sMItJ-gYuIR9cHM5VvGvtXnAFn3dCMFEw2B3EQhiaG8=.a3f7ca24-61c7-400a-ae15-b4bcb9d92bbd@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <sMItJ-gYuIR9cHM5VvGvtXnAFn3dCMFEw2B3EQhiaG8=.a3f7ca24-61c7-400a-ae15-b4bcb9d92bbd@github.com>
Message-ID: <3yJVMA7zZBO0S5nY1UTC07zS34sf3WdPpIA0dX7HSbc=.d1cf1a61-1497-4fbd-b0ed-0f7e39542b9d@github.com>

On Tue, 12 Mar 2024 10:12:18 GMT, Viktor Klang <vklang 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
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 926:
> 
>> 924:             if (!REVERSE && e1 != EMPTY) {
>> 925:                 action.accept((E) e1);
>> 926:             }
> 
> I'm curious to know how the following alternative would fare:
> 
> Suggestion:
> 
>             if (e1 != EMPTY) {
>                 action.accept(REVERSE ? (E)e1 : (E)e0); // implicit null check
>                 action.accept(REVERSE ? (E)e0 : (E)e1);
>             } else {
>                 action.accept(e0); // Implicit null check
>             }

@viktorklang-ora I've updated this piece of code, does it look better now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1534539452

From vklang at openjdk.org  Thu Mar 21 20:12:22 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 21 Mar 2024 20:12:22 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: <8I6TzPUv9WRYWHnCz6NZI9y9Zo5Lgoy-WRjqeLtUOuw=.31bd7d2a-4104-480d-bf22-ae395f80222e@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

src/java.base/share/classes/java/util/ImmutableCollections.java line 924:

> 922:                 action.accept(REVERSE ? (E)e1 : e0); // implicit null check
> 923:                 action.accept(REVERSE ? e0 : (E)e1);
> 924:             }

Out of curiosity, how does the following fare performance-wise?

Suggestion:

                action.accept((!REVERSE || e1 == EMPTY) ? e0 : (E)e1); // implicit null check
                if (e1 != EMPTY)
                    action.accept(!REVERSE ? (E)e1 : e0);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1534612528

From mchung at openjdk.org  Thu Mar 21 20:32:22 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Mar 2024 20:32:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <g7hSyNo0NSeoH6LS0il8Ax8J1rg0T83S_9WnEYUFFII=.62b5034b-2c29-4c82-b80c-dedbd63b4ef0@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

JDK-8313616 added the support of loading library members on AIX in os::dll_load in JDK 22.   On AIX, is a shared object a member object loaded from `libname.a(libname.so)`?   If so, changing `mapLibraryName` implementation seems to be a proper fix.   If you want to load a specific version, it should call `loadLibrary("libclang.a(libclang.so.16)")` instead.

As @jaikiran suggests, `loadLibraryOnlyIfPresent()` should return false for AIX as the file does not exist.   The library implementation may need to adjust as the current implementation uses a file path name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013669909

From mchung at openjdk.org  Thu Mar 21 21:37:23 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Mar 2024 21:37:23 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <A-0NBzZ-OD9e5UJpv1BFiBgiPL5AbnzvFjYpne2PhjU=.f9b432a8-2665-4476-812c-3bf04916eee2@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

`os::dll_load` already handles loading from .a on AIX when attempting loading .so (see JDK-8320005).   For example, if loading `libclang.so` fails, it attempts to load from `libclang.a`.    This issue is essentially revisiting the fix for JDK-8320005 and needs to understand the right mapping.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013811988

From mcimadamore at openjdk.org  Thu Mar 21 22:09:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 21 Mar 2024 22:09:25 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <cDGA4Rx3V9uBXMWyFjYV70coe6j9ESiVhqJ-PzTcCyk=.3ea98661-9114-4e07-955a-a1d1ad6bcb32@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

This problem seems relatively similar to what happens for versioned library names on e.g. linux distributions - e.g. "libclang.so.2". In such cases users are stuck between a rock and a hard place: using `System.loadLibrary("libclang")` is too little: it will be expanded to `libclang.so`, and will not be found. But there's no way to pass the version name to `loadLibrary`, as, to do that, you have to also pass the `.so` extension, and that doesn't work. So the only option is to use the _full_ absolute name with `System::load` (not `loadLibrary`).

My feeling is that it is not possible to "infer" the desired member name (because we don't know which version the member library has), in the same way as, in my system, it is not possible to infer "libc.so.6" from just the library name "c". As @JornVernee  mentioned, this is why `SymbolLookup::libraryLookup` exists, so that library names can be passed straight to dlopen, w/o further interpretation from the JDK. It seems that at least part of the issue here is that the `jextract` code loads its own library (libclang) using `System::loadLibrary`, which doesn't do the right thing on AIX when only given "clang" as the library name. But I'm not exactly sure there's a fix for that at the `System::loadLibrary` level if `dlopen` really expects `clang.a(libclang.so.16)` to be passed as parameter.

In other words, a fix to `mapLibraryName` only works as long as `dlopen` on AIX is able to do something with a name that is mechanically inferred, such as `clang.a(libclang.so)`. Is that the case? (I'm pessimistic)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013909303

From mcimadamore at openjdk.org  Thu Mar 21 22:25:26 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 21 Mar 2024 22:25:26 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <cDGA4Rx3V9uBXMWyFjYV70coe6j9ESiVhqJ-PzTcCyk=.3ea98661-9114-4e07-955a-a1d1ad6bcb32@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <cDGA4Rx3V9uBXMWyFjYV70coe6j9ESiVhqJ-PzTcCyk=.3ea98661-9114-4e07-955a-a1d1ad6bcb32@github.com>
Message-ID: <eTjV8iH98pUrJkbnqc2vN6RuysN2M-4wtdM6M5OiIqs=.c49d3393-48ef-47bf-b8f6-ca89b89b338b@github.com>

On Thu, 21 Mar 2024 22:04:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> (I'm pessimistic)

To summarize: I think that allowing version-specific names (even if surrounded by parenthesis) in `System::loadLibrary` would be very odd. After all, `System::loadLibrary` doesn't support versioned names, even on other systems (and adding support for versioned library names across different platforms is a much bigger effort).

For this reason, the only thing that would make sense for `loadLibrary` to support is `clang` which will be expanded (by `mapLibraryName`) to `clang(libclang.so)`. But, even assuming this works: wouldn't we still have an issue? As far as I understand (and given the code in this patch), we don't really know (before calling `dlopen`) whether the suffix is needed or not: whether it's an archive with an `.so` inside, or whether it's a plain `.so`. So how can the behavior of `mapLibraryName` be deterministic?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013954504

From bchristi at openjdk.org  Thu Mar 21 23:38:30 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 21 Mar 2024 23:38:30 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v15]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <sMUQGOMmhqooALZvfLJIVjAp40MY_ub6-EBBZhbmx10=.bb8e4835-d4c2-4c91-8ede-61f22a015eea@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:

  Elaborate on 'surprising and undesirable effects' in reachabilityFence()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/80a3973a..3df288a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=13-14

  Stats: 29 lines in 1 file changed: 11 ins; 0 del; 18 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 liach at openjdk.org  Fri Mar 22 00:25:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Mar 2024 00:25:25 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <8I6TzPUv9WRYWHnCz6NZI9y9Zo5Lgoy-WRjqeLtUOuw=.31bd7d2a-4104-480d-bf22-ae395f80222e@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
 <8I6TzPUv9WRYWHnCz6NZI9y9Zo5Lgoy-WRjqeLtUOuw=.31bd7d2a-4104-480d-bf22-ae395f80222e@github.com>
Message-ID: <F-fcyYin-zakkqs4sn2Jdr0RyTzf_JSKNT6jSbEqNxo=.c40bf9c6-aba7-4766-a17a-cf203feaeb68@github.com>

On Thu, 21 Mar 2024 20:09:23 GMT, Viktor Klang <vklang 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
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 924:
> 
>> 922:                 action.accept(REVERSE ? (E)e1 : e0); // implicit null check
>> 923:                 action.accept(REVERSE ? e0 : (E)e1);
>> 924:             }
> 
> Out of curiosity, how does the following fare performance-wise?
> 
> Suggestion:
> 
>                 action.accept((!REVERSE || e1 == EMPTY) ? e0 : (E)e1); // implicit null check
>                 if (e1 != EMPTY)
>                     action.accept(!REVERSE ? (E)e1 : e0);

Benchmark                        Mode  Cnt    Score   Error   Units
ImmutableColls.forEachOverList  thrpt   15  361.423 ? 8.751  ops/us
ImmutableColls.forEachOverSet   thrpt   15   79.158 ? 5.064  ops/us
ImmutableColls.getOrDefault     thrpt   15  244.012 ? 0.943  ops/us
ImmutableColls.iterateOverList  thrpt   15  152.598 ? 3.687  ops/us
ImmutableColls.iterateOverSet   thrpt   15   61.969 ? 4.453  ops/us

The 3 results are also available at https://gist.github.com/f0b4336e5b1cf9c5299ebdbcd82232bf, where baseline is the master this patch currently is based on (which has WhiteBoxResizeTest failures), patch-0 being the current code, and patch-1 being your proposal (uncommited patch below).

diff --git a/src/java.base/share/classes/java/util/ImmutableCollections.java b/src/java.base/share/classes/java/util/ImmutableCollections.java
index fc232a521fb..f38b093cf60 100644
--- a/src/java.base/share/classes/java/util/ImmutableCollections.java
+++ b/src/java.base/share/classes/java/util/ImmutableCollections.java
@@ -916,12 +916,9 @@ public <T> T[] toArray(T[] a) {
         @Override
         @SuppressWarnings("unchecked")
         public void forEach(Consumer<? super E> action) {
-            if (e1 == EMPTY) {
-                action.accept(e0); // implicit null check
-            } else {
-                action.accept(REVERSE ? (E)e1 : e0); // implicit null check
-                action.accept(REVERSE ? e0 : (E)e1);
-            }
+            action.accept((!REVERSE || e1 == EMPTY) ? e0 : (E) e1); // implicit null check
+            if (e1 != EMPTY)
+                action.accept(!REVERSE ? (E) e1 : e0);
         }
 
         @Override



My testing shows that the existing version I have is most likely faster than your proposed version.

Also note that the test failures are from WhiteBoxResizeTest that's fixed in latest master; I decide not to pull as not to invalidate the existing benchmark baselines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1534886983

From dholmes at openjdk.org  Fri Mar 22 02:11:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Mar 2024 02:11:26 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v15]
In-Reply-To: <sMUQGOMmhqooALZvfLJIVjAp40MY_ub6-EBBZhbmx10=.bb8e4835-d4c2-4c91-8ede-61f22a015eea@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <sMUQGOMmhqooALZvfLJIVjAp40MY_ub6-EBBZhbmx10=.bb8e4835-d4c2-4c91-8ede-61f22a015eea@github.com>
Message-ID: <poqkSu0jK-tTRsxWJCz8K83QiFOLxUbUPJcBY5O9d70=.30a840e0-e480-43b4-a020-9804f71b4224@github.com>

On Thu, 21 Mar 2024 23:38:30 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:
> 
>   Elaborate on 'surprising and undesirable effects' in reachabilityFence()

src/java.base/share/classes/java/lang/ref/Reference.java line 576:

> 574:      * detects that there is no further need for an object. The garbage collector
> 575:      * may reclaim an object even if values from that object's fields are still
> 576:      * in use, or while a method on the object is still running, so long as the

Suggestion: method _of_ the object

src/java.base/share/classes/java/lang/ref/Reference.java line 579:

> 577:      * object has otherwise become unreachable.
> 578:      * <p>
> 579:      * This may have surprising and undesirable effects, in particular when using

Nit: I don't think a new paragraph is appropriate here as "This may ..." refers back to the subject of the preceding lines.

src/java.base/share/classes/java/lang/ref/Reference.java line 581:

> 579:      * This may have surprising and undesirable effects, in particular when using
> 580:      * a Cleaner or finalizer for cleanup. If an object becomes unreachable while
> 581:      * a method on the object is running, it can lead to a race between the

Again suggest: method _of_ the object

src/java.base/share/classes/java/lang/ref/Reference.java line 585:

> 583:      * Cleaner or finalizer. For instance, the cleanup thread could cleanup the
> 584:      * resource, followed by the program thread (still running the method)
> 585:      * attempting to access the now-already-freed resource.

suggestion: s/cleanup/free/ to match the `now-already-freed` part.

src/java.base/share/classes/java/lang/ref/Reference.java line 586:

> 584:      * resource, followed by the program thread (still running the method)
> 585:      * attempting to access the now-already-freed resource.
> 586:      * {@code reachabilityFence} can prevent this race by ensuring that the

Suggestion: `Use of {@code reachabilityFence ...`

This avoids starting a sentence with a code font word that starts with a lower-case letter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1534946886
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1534947996
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1534948233
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1534948894
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1534949965

From dholmes at openjdk.org  Fri Mar 22 02:16:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Mar 2024 02:16:29 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v2]
In-Reply-To: <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
Message-ID: <6a4jwXlBCyCxpLkKT-CMX1XOUcEb040gP9_CR6SugQA=.442b2fcb-75f1-419b-9816-a1c63b2db260@github.com>

On Thu, 21 Mar 2024 14:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> 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 26 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - removed string templates from test
>  - work in progress
>  - work in progress
>  - work in progress
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/e41bc42d...54c4e9b9

> class checks inspired by hotspot/share/classfile/classFileParser.cpp

Just to be clear any such checks are mandated by the JVMS

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16809#issuecomment-2014188184

From dholmes at openjdk.org  Fri Mar 22 02:20:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Mar 2024 02:20:24 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v2]
In-Reply-To: <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
Message-ID: <3HOtO-xeJ7UUIBp04qgyxn-ohvkW-c8P5edKMtIZvTU=.ac812eaa-46a8-4a45-95d1-f4fa99edbb5c@github.com>

On Thu, 21 Mar 2024 14:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> 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 26 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - removed string templates from test
>  - work in progress
>  - work in progress
>  - work in progress
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/e41bc42d...54c4e9b9

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 56:

> 54: 
> 55: /**
> 56:  * @see <a href="https://raw.githubusercontent.com/openjdk/jdk/master/src/hotspot/share/classfile/classFileParser.cpp">hotspot/share/classfile/classFileParser.cpp</a>

A reference to JVMS Ch4(?) would be appropriate here as that is what any checks should be compliant with.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1534955072

From dholmes at openjdk.org  Fri Mar 22 02:26:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Mar 2024 02:26:23 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v2]
In-Reply-To: <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
Message-ID: <-_rXcY01yNU57Pk_sIkn4x8vjMKcjUsZDo7ll0kY9To=.1551b82a-9939-4947-8771-e38a207c9144@github.com>

On Thu, 21 Mar 2024 14:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> 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 26 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - removed string templates from test
>  - work in progress
>  - work in progress
>  - work in progress
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/e41bc42d...54c4e9b9

@asotona  pardon my ignorance of the Classfile API usage, but I had thought that the API could be used to either write the bytecode representation of class, or else introspect on an existing class that has already been loaded. So I'm not clear at what point you would run these JVMS defined structural verification checks that you are adding?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16809#issuecomment-2014195638

From liach at openjdk.org  Fri Mar 22 03:45:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Mar 2024 03:45:22 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v2]
In-Reply-To: <-_rXcY01yNU57Pk_sIkn4x8vjMKcjUsZDo7ll0kY9To=.1551b82a-9939-4947-8771-e38a207c9144@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
 <-_rXcY01yNU57Pk_sIkn4x8vjMKcjUsZDo7ll0kY9To=.1551b82a-9939-4947-8771-e38a207c9144@github.com>
Message-ID: <QhvGKlR7xJTOdyVSp3swuFwUdgT7acp8Vs7t-T8SihA=.3a906a2c-1b0e-478e-aa3a-0a0793133edd@github.com>

On Fri, 22 Mar 2024 02:23:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So I'm not clear at what point you would run these JVMS defined structural verification checks that you are adding?

This is more like an addon module to Class-File API; it is only run when users call `ClassFile::verify`. Otherwise, Class-File API performs minimal validation that's required to generate or parse class files.
The verification can be performed on both arbitrary byte array (may be built by Class-File API) or a ClassModel (always loaded from a byte array)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16809#issuecomment-2014295404

From hboehm at google.com  Fri Mar 22 03:47:00 2024
From: hboehm at google.com (Hans Boehm)
Date: Thu, 21 Mar 2024 20:47:00 -0700
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v15]
In-Reply-To: <poqkSu0jK-tTRsxWJCz8K83QiFOLxUbUPJcBY5O9d70=.30a840e0-e480-43b4-a020-9804f71b4224@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <sMUQGOMmhqooALZvfLJIVjAp40MY_ub6-EBBZhbmx10=.bb8e4835-d4c2-4c91-8ede-61f22a015eea@github.com>
 <poqkSu0jK-tTRsxWJCz8K83QiFOLxUbUPJcBY5O9d70=.30a840e0-e480-43b4-a020-9804f71b4224@github.com>
Message-ID: <CAMOCf+im2ZBk+YTv6um+H-jH7fU42wnVpy0ah0VVboZk4pnj5w@mail.gmail.com>

Is it worth keeping the discussion starting with "It is sometimes possible
to better encapsulate ..." and the associated example code? I find this
example extremely unconvincing. It's very hard to construct a case in which
you can safely use the result of getExternalResource(). And I don't want to
encourage writing getters for things like this; if you use them from a
static method, or somebody decides to make it public, things get really
messy really quickly.

This example kind of gives the impression that we have a solution to
reachabilityFence() proliferation. I don't think we do. There may be a
difference of opinion about whether it's worth fixing, but I don't think we
should deny the existence of the problem.

On Thu, Mar 21, 2024 at 7:11?PM David Holmes <dholmes at openjdk.org> wrote:

> On Thu, 21 Mar 2024 23:38:30 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:
> >
> >   Elaborate on 'surprising and undesirable effects' in
> reachabilityFence()
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 576:
>
> > 574:      * detects that there is no further need for an object. The
> garbage collector
> > 575:      * may reclaim an object even if values from that object's
> fields are still
> > 576:      * in use, or while a method on the object is still running, so
> long as the
>
> Suggestion: method _of_ the object
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 579:
>
> > 577:      * object has otherwise become unreachable.
> > 578:      * <p>
> > 579:      * This may have surprising and undesirable effects, in
> particular when using
>
> Nit: I don't think a new paragraph is appropriate here as "This may ..."
> refers back to the subject of the preceding lines.
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 581:
>
> > 579:      * This may have surprising and undesirable effects, in
> particular when using
> > 580:      * a Cleaner or finalizer for cleanup. If an object becomes
> unreachable while
> > 581:      * a method on the object is running, it can lead to a race
> between the
>
> Again suggest: method _of_ the object
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 585:
>
> > 583:      * Cleaner or finalizer. For instance, the cleanup thread could
> cleanup the
> > 584:      * resource, followed by the program thread (still running the
> method)
> > 585:      * attempting to access the now-already-freed resource.
>
> suggestion: s/cleanup/free/ to match the `now-already-freed` part.
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 586:
>
> > 584:      * resource, followed by the program thread (still running the
> method)
> > 585:      * attempting to access the now-already-freed resource.
> > 586:      * {@code reachabilityFence} can prevent this race by ensuring
> that the
>
> Suggestion: `Use of {@code reachabilityFence ...`
>
> This avoids starting a sentence with a code font word that starts with a
> lower-case letter.
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/16644#discussion_r1534946886
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/16644#discussion_r1534947996
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/16644#discussion_r1534948233
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/16644#discussion_r1534948894
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/16644#discussion_r1534949965
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240321/c956dca0/attachment-0001.htm>

From asotona at openjdk.org  Fri Mar 22 08:29:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 22 Mar 2024 08:29:24 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v2]
In-Reply-To: <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
Message-ID: <9DouAROvyejesdiHkOJOIsvwRgtbIJfCnJglQA8McRw=.6be5fb29-7817-4124-8f89-02eecbaa6b94@github.com>

On Thu, 21 Mar 2024 14:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> 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 26 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - removed string templates from test
>  - work in progress
>  - work in progress
>  - work in progress
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/e41bc42d...54c4e9b9

Verification is an optional feature of Class-File API, however it is critical for development and testing of the Class-File API itself and all frameworks and libraries built on top of it.
`ClassFile::verify` is now focused on JVMS chapter 6 only, however the goal is to give user a bit more confidence that any class file passing the `ClassFile::verify` is correct.
Loading of the generated or transformed classes to verify them is not feasible in many situations and `ClassFile::verify` tries to give user at least some information, similar to ASM `CheckClassAdapter`or BCEL `Verifier`.

The work is also related to [JDK-8182774 Verify code in javap](https://bugs.openjdk.org/browse/JDK-8182774).

I'll add references to the relevant JVMS chapters.
Thank you for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16809#issuecomment-2014600028

From asotona at openjdk.org  Fri Mar 22 09:08:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 22 Mar 2024 09:08:38 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v3]
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <OECaqMfBpG_bgoHdDFu79YBjnGUTyX6je1Pj56o56yg=.1c9a1add-0c70-4364-9c82-e5a24406024c@github.com>

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added references to jvms

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16809/files
  - new: https://git.openjdk.org/jdk/pull/16809/files/54c4e9b9..61a9d748

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=01-02

  Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16809.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809

PR: https://git.openjdk.org/jdk/pull/16809

From asotona at openjdk.org  Fri Mar 22 09:10:25 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 22 Mar 2024 09:10:25 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v2]
In-Reply-To: <3HOtO-xeJ7UUIBp04qgyxn-ohvkW-c8P5edKMtIZvTU=.ac812eaa-46a8-4a45-95d1-f4fa99edbb5c@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <cVmsuFdQct4zBig1XQkAJLa25Pq-vRHSsxZC4FgT2bM=.5ef84449-5fe3-4279-bc4a-00fd45decacd@github.com>
 <3HOtO-xeJ7UUIBp04qgyxn-ohvkW-c8P5edKMtIZvTU=.ac812eaa-46a8-4a45-95d1-f4fa99edbb5c@github.com>
Message-ID: <KXlaexsz6_lD6brUaKCM1R5SEHInHMQAoD3exliv_bw=.591cace6-30e1-4404-8db0-cf9509ccffa7@github.com>

On Fri, 22 Mar 2024 02:17:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - removed string templates from test
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/e41bc42d...54c4e9b9
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 56:
> 
>> 54: 
>> 55: /**
>> 56:  * @see <a href="https://raw.githubusercontent.com/openjdk/jdk/master/src/hotspot/share/classfile/classFileParser.cpp">hotspot/share/classfile/classFileParser.cpp</a>
> 
> A reference to JVMS Ch4(?) would be appropriate here as that is what any checks should be compliant with.

Thank you for the review, I've added references to JVMS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1535265201

From vklang at openjdk.org  Fri Mar 22 09:27:23 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 22 Mar 2024 09:27:23 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v2]
In-Reply-To: <F-fcyYin-zakkqs4sn2Jdr0RyTzf_JSKNT6jSbEqNxo=.c40bf9c6-aba7-4766-a17a-cf203feaeb68@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <0nlmIMh17vSEO1fE0FLevpVEr4t6oQ5mvM5L_hlM0eI=.7269ee58-0473-4270-9e13-9ca83a351bc9@github.com>
 <8I6TzPUv9WRYWHnCz6NZI9y9Zo5Lgoy-WRjqeLtUOuw=.31bd7d2a-4104-480d-bf22-ae395f80222e@github.com>
 <F-fcyYin-zakkqs4sn2Jdr0RyTzf_JSKNT6jSbEqNxo=.c40bf9c6-aba7-4766-a17a-cf203feaeb68@github.com>
Message-ID: <sVy1U9oiZedcVVRg1-NMlkNZbo92lnhybYy3DORfrKI=.5549b0fe-7119-4dc9-b46b-d118c3af48db@github.com>

On Fri, 22 Mar 2024 00:21:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 924:
>> 
>>> 922:                 action.accept(REVERSE ? (E)e1 : e0); // implicit null check
>>> 923:                 action.accept(REVERSE ? e0 : (E)e1);
>>> 924:             }
>> 
>> Out of curiosity, how does the following fare performance-wise?
>> 
>> Suggestion:
>> 
>>                 action.accept((!REVERSE || e1 == EMPTY) ? e0 : (E)e1); // implicit null check
>>                 if (e1 != EMPTY)
>>                     action.accept(!REVERSE ? (E)e1 : e0);
>
> Benchmark                        Mode  Cnt    Score   Error   Units
> ImmutableColls.forEachOverList  thrpt   15  361.423 ? 8.751  ops/us
> ImmutableColls.forEachOverSet   thrpt   15   79.158 ? 5.064  ops/us
> ImmutableColls.getOrDefault     thrpt   15  244.012 ? 0.943  ops/us
> ImmutableColls.iterateOverList  thrpt   15  152.598 ? 3.687  ops/us
> ImmutableColls.iterateOverSet   thrpt   15   61.969 ? 4.453  ops/us
> 
> The 3 results are also available at https://gist.github.com/f0b4336e5b1cf9c5299ebdbcd82232bf, where baseline is the master this patch currently is based on (which has WhiteBoxResizeTest failures), patch-0 being the current code, and patch-1 being your proposal (uncommited patch below).
> 
> diff --git a/src/java.base/share/classes/java/util/ImmutableCollections.java b/src/java.base/share/classes/java/util/ImmutableCollections.java
> index fc232a521fb..f38b093cf60 100644
> --- a/src/java.base/share/classes/java/util/ImmutableCollections.java
> +++ b/src/java.base/share/classes/java/util/ImmutableCollections.java
> @@ -916,12 +916,9 @@ public <T> T[] toArray(T[] a) {
>          @Override
>          @SuppressWarnings("unchecked")
>          public void forEach(Consumer<? super E> action) {
> -            if (e1 == EMPTY) {
> -                action.accept(e0); // implicit null check
> -            } else {
> -                action.accept(REVERSE ? (E)e1 : e0); // implicit null check
> -                action.accept(REVERSE ? e0 : (E)e1);
> -            }
> +            action.accept((!REVERSE || e1 == EMPTY) ? e0 : (E) e1); // implicit null check
> +            if (e1 != EMPTY)
> +                action.accept(!REVERSE ? (E) e1 : e0);
>          }
>  
>          @Override
> 
> 
> 
> My testing shows that the existing version I have is most likely faster than your proposed version.
> 
> Also note that the test failures are from WhiteBoxResizeTest that's fixed in latest master; I decide not to pull as not to invalidate the existing benchmark baselines.

Thanks. I was mostly trying to gauge what the bottleneck might be.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1535286326

From vklang at openjdk.org  Fri Mar 22 09:30:28 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 22 Mar 2024 09:30:28 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v15]
In-Reply-To: <sMUQGOMmhqooALZvfLJIVjAp40MY_ub6-EBBZhbmx10=.bb8e4835-d4c2-4c91-8ede-61f22a015eea@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <sMUQGOMmhqooALZvfLJIVjAp40MY_ub6-EBBZhbmx10=.bb8e4835-d4c2-4c91-8ede-61f22a015eea@github.com>
Message-ID: <I6SxU3TlD1SU8Za1StZ4_YEEF8cJG6xielhOmGc4Upg=.c41442ff-53ef-45c1-bd1c-d0294f4c1567@github.com>

On Thu, 21 Mar 2024 23:38:30 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:
> 
>   Elaborate on 'surprising and undesirable effects' in reachabilityFence()

src/java.base/share/classes/java/lang/ref/Reference.java line 632:

> 630:      * object.  This might be the case if, for example, a usage in a user program
> 631:      * had the form {@code new Resource().action();} which retains no other
> 632:      * reference to this {@code Resource}.  The

Reformat this line?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1535291214

From sroy at openjdk.org  Fri Mar 22 09:53:23 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 22 Mar 2024 09:53:23 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <g7hSyNo0NSeoH6LS0il8Ax8J1rg0T83S_9WnEYUFFII=.62b5034b-2c29-4c82-b80c-dedbd63b4ef0@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <g7hSyNo0NSeoH6LS0il8Ax8J1rg0T83S_9WnEYUFFII=.62b5034b-2c29-4c82-b80c-dedbd63b4ef0@github.com>
Message-ID: <ieO0drJ-fxcZqi-PpQploiB8Qp5ec1yAgU31jUC8WhE=.cdf4629c-8def-4287-a54c-13e9471642a5@github.com>

On Thu, 21 Mar 2024 20:29:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> As @jaikiran suggests, `loadLibraryOnlyIfPresent()` should return false for AIX as the file does not exist. The library implementation may need to adjust as the current implementation uses a file path name.

Had kept it as true, as it was in J9. but changing it to false works.
So that would mean we are letting the java Runtime to handle paths that don't exist ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014728820

From sroy at openjdk.org  Fri Mar 22 09:53:24 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 22 Mar 2024 09:53:24 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v2]
In-Reply-To: <BBLcz8MarNdkPxOOPcxsCejmCi1pzowrcKGfr1nlozQ=.13ee9664-999e-478b-bd9a-127f1c9fc4a2@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <8BEYFpVxjtVz2uZVNKeCu9DqLGSe5VotCL7oy-SUS7c=.718c1bda-80b2-4836-bce4-dbaac888eadf@github.com>
 <7lNrnbxNhpSSQ0NIhIMs_EiQt4GaiMseyoL8DcOVENA=.bd7b6fbe-aa9c-4070-bff3-a5d3e8225bf9@github.com>
 <5lBF2UoSs-wSy9sC-LUNpItjxatWk7kII8-xzV56Fd4=.86ead6a9-2820-4b48-b278-411b0f6e6738@github.com>
 <cvJHnyi368CCGV3DsT2BKeAMo7n4pAsrUb9gaoacXo8=.1a159a51-80a3-463e-97b6-54bfd88d5e0f@github.com>
 <aCn8jAjpnLImOVtD74jzI84cN2hD6qbO6_RR2dn23Cc=.4ff39100-1b1e-4583-98af-952184d0e090@github.com>
 <90by4pj9HzxPHW6dGHhCCvRQ9mT1nBajy-Mtk6OC8P8=.c62eb23e-6f3f-4321-ba4b-5287218b6882@github.com>
 <k4a2O7QCOkiNlQ34v7J32vA2Soz15iHK6iO2b25jTzY=.ce61d16d-a974-45c2-8d31-044b750bd0dc@github.com>
 <jYgkrmEP9p7XlZe4eGRSYm_gERv8HYBDZLkL_rQ7oXI=.1cd46276-4959-45cb-b183-7c6cc4099b0d@github.com>
 <gxoQU62rGdxFq62YkyovjCpxuFaB_4NzhzbKTIijYP0=.fc6dd27b-d880-46e8-ab13-937e1588f57d@github.com>
 <BBLcz8MarNdkPxOOPcxsCejmCi1pzowrcKG
 fr1nlozQ=.13ee9664-999e-478b-bd9a-127f1c9fc4a2@github.com>
Message-ID: <wvhmNozpk0tsszbxP2Tq4wJPf-G-OfpVEUnz9YufjKs=.d069914f-988d-4144-b78c-81190a3a96fa@github.com>

On Thu, 21 Mar 2024 17:06:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> But there is no actual file named libclang.a(libclang.so.16) in the filesystem.
>> So when the check is done if file exists, it fails,i.e it checks for libclang.a(libclang.so.16).
>> 
>> I'll let Mandy and others more knowledgable of this area to correct me. From what I know, there was a change done a few releases back in the JDK (https://bugs.openjdk.org/browse/JDK-8275703) which accomodated macos platform where it too doesn't actually have the file on the filesystem in recent versions of macos. That change allowed platform specific code to dictate whether the file existence check needs to be done here in this loadLibrary code. That's done through the call to `jdk.internal.loader.ClassLoaderHelper.loadLibraryOnlyIfPresent()`. For macos, that implementation of that method resides in macos specific class here https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java#L41. For AIX too then, perhaps you could add an implementation which returns `false` (either always or in specific cases) and experiment with that to see if that's enough?
>
>> For AIX too then, perhaps you could add an implementation which returns false (either always or in specific cases) and experiment with that to see if that's enough?
> 
> I see that you actually have a ClassLoaderHelper in this PR for AIX, but that implementation in `loadLibraryOnlyIfPresent()` is currently returning `true` and thus enforcing the file existence check. Was it intentional to have it to `true`? Given the context of this change, shouldn't it be returning `false`?

Correct. Had kept it as true, as it was in J9. but changing it to false works. 
So that would mean we are letting the java Runtime to handle paths that don't exist ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1535320320

From sroy at openjdk.org  Fri Mar 22 10:02:23 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 22 Mar 2024 10:02:23 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <eTjV8iH98pUrJkbnqc2vN6RuysN2M-4wtdM6M5OiIqs=.c49d3393-48ef-47bf-b8f6-ca89b89b338b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <cDGA4Rx3V9uBXMWyFjYV70coe6j9ESiVhqJ-PzTcCyk=.3ea98661-9114-4e07-955a-a1d1ad6bcb32@github.com>
 <eTjV8iH98pUrJkbnqc2vN6RuysN2M-4wtdM6M5OiIqs=.c49d3393-48ef-47bf-b8f6-ca89b89b338b@github.com>
Message-ID: <FXgsBF2jab-XW1ZuKoN7VXXePVs-lmkj6px6254q4vg=.9f3db582-4fe2-46a0-b73c-51f2309d9fda@github.com>

On Thu, 21 Mar 2024 22:23:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > (I'm pessimistic)
> 
> To summarize: I think that allowing version-specific names (even if surrounded by parenthesis) in `System::loadLibrary` would be very odd. After all, `System::loadLibrary` doesn't support versioned names, even on other systems (and adding support for versioned library names across different platforms is a much bigger effort).
> 
> For this reason, the only thing that would make sense for `loadLibrary` to support is `clang` which will be expanded (by `mapLibraryName`) to `clang(libclang.so)`. But, even assuming this works: wouldn't we still have an issue? As far as I understand (and given the code in this patch), we don't really know (before calling `dlopen`) whether the suffix is needed or not: whether it's an archive with an `.so` inside, or whether it's a plain `.so`. So how can the behavior of `mapLibraryName` be deterministic?

yes, i think the member needs to be specified in full. AIX archives can be both static and shared, so to mention the shared object member, we need to put the braces. 
But we also have cases, where a .so file when it doesn't exists will map deterministically to .a file , in which we use the loadlibrary. 
Specifying member objects is in addition to it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014741652

From sroy at openjdk.org  Fri Mar 22 10:19:22 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 22 Mar 2024 10:19:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <eTjV8iH98pUrJkbnqc2vN6RuysN2M-4wtdM6M5OiIqs=.c49d3393-48ef-47bf-b8f6-ca89b89b338b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <cDGA4Rx3V9uBXMWyFjYV70coe6j9ESiVhqJ-PzTcCyk=.3ea98661-9114-4e07-955a-a1d1ad6bcb32@github.com>
 <eTjV8iH98pUrJkbnqc2vN6RuysN2M-4wtdM6M5OiIqs=.c49d3393-48ef-47bf-b8f6-ca89b89b338b@github.com>
Message-ID: <NgOMHp-SjMMZlXRTe1M3qPghJ8GO4uTSCXuxC2KJm3k=.60bfae2b-3371-49f6-9a2b-0efd4d3a4903@github.com>

On Thu, 21 Mar 2024 22:23:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> For this reason, the only thing that would make sense for `loadLibrary` to support is `clang` which will be expanded (by `mapLibraryName`) to `clang(libclang.so)`. But, even assuming this works: wouldn't we still have an issue? As far as I understand (and given the code in this patch), we don't really know (before calling `dlopen`) whether the suffix is needed or not: whether it's an archive with an `.so` inside, or whether it's a plain `.so`. So how can the behavior of `mapLibraryName` be deterministic?

The behaviour is deterministic when we have a case where, a .so file maps to .a file without specifying any members. This was the original intention for mapAlternateName so that we can use loadLibrary to load shared objects with .so format, and on failure we fallback and check if .a exists.

But to mention the member object, it looks to me that we must specify the full name and there is no direct mapping. So then we restrict that to only System.load and not System.loadLibrary ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014770717

From michael.x.mcmahon at oracle.com  Fri Mar 22 10:19:54 2024
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 22 Mar 2024 10:19:54 +0000
Subject: CFV: New Core Libraries Group Member: Per-Ake Minborg
In-Reply-To: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
References: <a4ff0bce-bec7-4957-b91f-750eb58a5c13@oracle.com>
Message-ID: <77af5211-78d5-4aa4-acba-f3d45d8b60fd@oracle.com>

Vote: Yes

On 19/03/2024 16:19, Daniel Fuchs wrote:
> Hi,
>
> I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the 
> Core Libraries Group [4].
>
> Per-Ake is an OpenJDK Reviewer, a committer in the
> Leyden and Panama projects, and a member of Oracle?s
> Java Core Libraries team.
>
> Per-Ake has been actively participating in the development of
> the JDK and Panama projects for several years, and is one of
> the co-author of the Implementation of Foreign Function and
> Memory API (Third Preview) [2].
> His contributions include more than 80 commits in the JDK [3]
>
>
> Votes are due by 16:00 UTC on April 2, 2024.
>
> Only current Members of the Core Libraries Group [4] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
>
> For Lazy Consensus voting instructions, see [5].
>
> best regards,
>
> -- daniel
>
> [1] https://openjdk.org/census#pminborg
> [2] 
> https://github.com/openjdk/jdk/commit/cbccc4c8172797ea2f1b7c301d00add3f517546d
> [3] 
> https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author%3Aminborg&type=commits
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240322/48c39dd1/attachment.htm>

From sroy at openjdk.org  Fri Mar 22 10:24:24 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 22 Mar 2024 10:24:24 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <cDGA4Rx3V9uBXMWyFjYV70coe6j9ESiVhqJ-PzTcCyk=.3ea98661-9114-4e07-955a-a1d1ad6bcb32@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <cDGA4Rx3V9uBXMWyFjYV70coe6j9ESiVhqJ-PzTcCyk=.3ea98661-9114-4e07-955a-a1d1ad6bcb32@github.com>
Message-ID: <XhQl9ctElMAAuLkgS8lKcFSeRfKZVVY2Df8mIkdvG50=.bcbfdb81-f630-4700-ae84-4ffaf2679c8b@github.com>

On Thu, 21 Mar 2024 22:04:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This problem seems relatively similar to what happens for versioned library names on e.g. linux distributions - e.g. `libclang.so.2`. In such cases users are stuck between a rock and a hard place: using `System.loadLibrary("libclang")` is too little: it will be expanded to `libclang.so`, and will not be found. But there's no way to pass the version name to `loadLibrary`, as, to do that, you have to also pass the `.so` extension, and that doesn't work. So the only option is to use the _full_ absolute name with `System::load` (not `loadLibrary`).
> 
> My feeling is that it is not possible to "infer" the desired member name (because we don't know which version the member library has), in the same way as, in my system, it is not possible to infer `libc.so.6` from just the library name `c`. As @JornVernee mentioned, this is why `SymbolLookup::libraryLookup` exists, so that library names can be passed straight to dlopen, w/o further interpretation from the JDK. It seems that at least part of the issue here is that the `jextract` code loads its own library (libclang) using `System::loadLibrary`, which doesn't do the right thing on AIX when only given "clang" as the library name. But I'm not exactly sure there's a fix for that at the `System::loadLibrary` level if `dlopen` really expects `clang.a(libclang.so.16)` to be passed as parameter.
> 
> In other words, a fix to `mapLibraryName` only works as long as `dlopen` on AIX is able to do something with a name that is mechanically inferred, such as `clang.a(libclang.so)`. Is that the case? (I'm pessimistic)

Yes, dlopen expects the full name. 
If i just pass clang in loadLibrary() and not the member i get exec error. 
System error: Exec format error

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014780371

From duke at openjdk.org  Fri Mar 22 10:28:24 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 22 Mar 2024 10:28:24 GMT
Subject: RFR: JDK-8326853 Missing @since tags for Charset related methods
 added in Java 10 [v9]
In-Reply-To: <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com>
Message-ID: <OrMrE0Qq8TigtKpb2SMcyaZ2CXZqfGmpHIW61GkpXOo=.90051740-7358-4dd6-a844-8e375d930d37@github.com>

On Wed, 20 Mar 2024 18:04:50 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the `@since` tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update full name
>  - Update full name

I spent some time running some tests to learn the process.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2014786660

From sgehwolf at openjdk.org  Fri Mar 22 12:56:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 22 Mar 2024 12:56:21 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: <4igI0UicqIV8pAhAFkxreyNnV9rZiaZZ98JI5TZWpEo=.3a2747f4-bfc2-4e09-9172-2b2f6d9bc2d6@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?

Anyone willing to review this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2015043712

From mdoerr at openjdk.org  Fri Mar 22 14:56:23 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 22 Mar 2024 14:56:23 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <j9i0yqE1ejUyy-op0BD_apzD5uZIi3VcrdOFMIzjhdY=.4453e189-2dc5-4105-bade-1fe776e66b22@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

`dlopen` really expects `libclang.a(libclang.so.16)`. I don't think this can currently be passed by any of the functions `System.loadLibrary`, `System.load` or `SymbolLookup.libraryLookup`. The `.16` suffix is only for clang 16. Clang 15 uses `.15`.
Note that AIX uses archive members quite often. E.g. `libc.a(shr_64.o)`, `libpthreads.a(shr_xpg5_64.o)`, `libz.a(libz.so.1)`, ...
Only the Java developer can select the right member.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015274997

From mcimadamore at openjdk.org  Fri Mar 22 15:08:23 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Mar 2024 15:08:23 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <j9i0yqE1ejUyy-op0BD_apzD5uZIi3VcrdOFMIzjhdY=.4453e189-2dc5-4105-bade-1fe776e66b22@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <j9i0yqE1ejUyy-op0BD_apzD5uZIi3VcrdOFMIzjhdY=.4453e189-2dc5-4105-bade-1fe776e66b22@github.com>
Message-ID: <zMdgUjs_XK0_T-rUtVF_y1_ixKOkBcfJ92lbUsQMOnI=.549603e5-6038-44eb-91ae-9fc8429eec59@github.com>

On Fri, 22 Mar 2024 14:53:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Only the Java developer can select the right member.

Right, and I think this problem is isomporphic to the problem we have in Linux distros of selecting between libclang.so.1 and libclang.so.2. `System::loadLibrary` cannot do it. So, I think it would feel odd if, say AIX was able to load precise version of a library using the member syntax, but in all other platforms that would not be possible. For better or worse, the story for now is: if you want version, use `System::load`.

In this case, the problem might be that `System::load` doesn't work out of the box, as the path doesn't really exist. But this doesn't seem different to loading non-existing framework paths in MacOS - e.g. it is a special case that can be added for AIX (when using `System::load`).

All that said, if one is doing `System::load/loadLibrary` just because they want to use FFM and `Linker`, a better way to do that is to just use `SymbolLookup::libraryLookup` directly, which gives you direct access to whatever string `dlopen` accepts in your system. Now, I realize that `jextract` is currently using `SymbolLookup::loaderLookup`, but I believe we can change that, which in turn will make adding support for AIX a bit easier.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015299960

From jwilhelm at openjdk.org  Fri Mar 22 15:23:49 2024
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 22 Mar 2024 15:23:49 GMT
Subject: RFR: 8328812: Update and move siphash license
Message-ID: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>

Updated and moved the license file.

-------------

Commit messages:
 - 8328812: Update and move siphash license

Changes: https://git.openjdk.org/jdk/pull/18455/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18455&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328812
  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18455/head:pull/18455

PR: https://git.openjdk.org/jdk/pull/18455

From duke at openjdk.org  Fri Mar 22 15:52:28 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 22 Mar 2024 15:52:28 GMT
Subject: RFR: JDK-8326853 Missing @ since tags for Charset related methods
 added in Java 10 [v8]
In-Reply-To: <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
 <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
 <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>
Message-ID: <ybe6vfwdT6TWJEIUIvx7aJrcFaEKGNKuoQZZ05Q6k90=.b3b2a78f-80f4-4a4a-9321-42ca44a9eaf2@github.com>

On Thu, 21 Mar 2024 16:50:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Thank you justin
>
> Hi @nizarbenalla , you can comment `/integrate` whenever you're ready, and we can sponsor the change to have it integrated.

@justin-curtis-lu I realized there is a small issue with the commit message

8326853: Missing @since tags for Charset related methods added in Java 10

Reviewed-by: jlu, naoto

there is a github user with the username `@since` and he will be tagged in the commit message, so there should be a space here. I added a space in the PR title

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2015380584

From lfoltan at openjdk.org  Fri Mar 22 16:00:25 2024
From: lfoltan at openjdk.org (Lois Foltan)
Date: Fri, 22 Mar 2024 16:00:25 GMT
Subject: RFR: 8328812: Update and move siphash license
In-Reply-To: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
Message-ID: <IDWN-4p2_DwjyoTRopdqXv_bfaw8-Y5ccZghimniKRM=.77106e37-627d-4970-9951-07475eb897b8@github.com>

On Fri, 22 Mar 2024 15:18:29 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Updated and moved the license file.

Looks good.
Lois

-------------

Marked as reviewed by lfoltan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18455#pullrequestreview-1955180960

From jwilhelm at openjdk.org  Fri Mar 22 16:07:30 2024
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 22 Mar 2024 16:07:30 GMT
Subject: Integrated: 8328812: Update and move siphash license
In-Reply-To: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
Message-ID: <l4n5y5OiVgFDL12yPF2TfGhJfTjnzVAPnctWzhappxI=.73a7b87c-513e-4eca-a203-c4f55c56b6a6@github.com>

On Fri, 22 Mar 2024 15:18:29 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Updated and moved the license file.

This pull request has now been integrated.

Changeset: ce7ebaa6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce7ebaa606f96fdfee66d300b56022d9903b5ae3
Stats:     4 lines in 1 file changed: 1 ins; 1 del; 2 mod

8328812: Update and move siphash license

Reviewed-by: lfoltan

-------------

PR: https://git.openjdk.org/jdk/pull/18455

From duke at openjdk.org  Fri Mar 22 16:14:26 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 22 Mar 2024 16:14:26 GMT
Subject: Integrated: JDK-8326853 Missing `@since` tags for Charset related
 methods added in Java 10
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <4cUvcPClyJ-k2flHg2HTAheLLeCUKQsee04x-gQ9B5M=.6eefac93-ca3d-435a-990b-27de51410e3c@github.com>

On Tue, 27 Feb 2024 16:28:26 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> # Issue
> - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10
> 
> I changed the `@since` tags to better accurately show when the methods and constructors were introduced.

This pull request has now been integrated.

Changeset: 4d932d61
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d932d615c78f45516a4f136398e7610546065a6
Stats:     12 lines in 2 files changed: 10 ins; 0 del; 2 mod

8326853: Missing `@since` tags for Charset related methods added in Java 10

Reviewed-by: jlu, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18032

From mdoerr at openjdk.org  Fri Mar 22 16:56:29 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 22 Mar 2024 16:56:29 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <kFsmNVGNDfvlOLEXfiPkFSm-2FTvUE_V6sqymNzOUaw=.629131db-6ddd-46c9-9cf1-1e4538b96708@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

In case of jextract (jdk22 branch), we would then need something like the following if we want AIX to behave like the other platforms?

diff --git a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
index 14eba30..c069c3b 100644
--- a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
+++ b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
@@ -27,11 +27,13 @@
 
 package org.openjdk.jextract.clang.libclang;
 
+import java.io.File;
 import java.lang.invoke.*;
 import java.lang.foreign.*;
 import java.nio.ByteOrder;
 import java.util.*;
 import java.util.function.*;
+import java.util.StringTokenizer;
 import java.util.stream.*;
 
 import static java.lang.foreign.ValueLayout.*;
@@ -101,8 +103,21 @@ public class Index_h {
     }
 
     static {
-        String libName = System.getProperty("os.name").startsWith("Windows") ? "libclang" : "clang";
-        System.loadLibrary(libName);
+        String osName = System.getProperty("os.name");
+        String libName = "";
+        if (osName.startsWith("AIX")) {
+            String libPath = System.getProperty("java.library.path");
+            StringTokenizer parser = new StringTokenizer(libPath, ":");
+            while (parser.hasMoreTokens()) {
+                libName = parser.nextToken() + "/libclang.a";
+                File f = new File(libName);
+                if (f.exists() && !f.isDirectory()) break;
+            }
+            SymbolLookup.libraryLookup(libName + "(libclang.so.16)", Arena.global());
+        } else {
+            libName = osName.startsWith("Windows") ? "libclang" : "clang";
+            System.loadLibrary(libName);
+        }
     }
 
     static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.loaderLookup()

If I try this, I get "UnsatisfiedLinkError: unresolved symbol: clang_createIndex". So, seems like the lib gets found, but symbols not loaded. Seems like there are more changes needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015506765

From rgiulietti at openjdk.org  Fri Mar 22 18:03:35 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 22 Mar 2024 18:03:35 GMT
Subject: RFR: 8328700: Unused import and variable should be deleted in regex
 package
Message-ID: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>

Make use of an unused local variable probably intended to replace later casts.

-------------

Commit messages:
 - 8328700: Unused import and variable should be deleted in regex package

Changes: https://git.openjdk.org/jdk/pull/18460/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328700
  Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18460/head:pull/18460

PR: https://git.openjdk.org/jdk/pull/18460

From redestad at openjdk.org  Fri Mar 22 18:38:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 22 Mar 2024 18:38:22 GMT
Subject: RFR: 8328700: Unused import and variable should be deleted in
 regex package
In-Reply-To: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
References: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
Message-ID: <aM8PRz28ss2O2vg8Qmc5Z7UdOBPnklHIt-RyOKGBpcM=.080d285d-3b74-4cad-ba4a-92a9bf7f9a0b@github.com>

On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of an unused local variable probably intended to replace later casts.

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18460#pullrequestreview-1955510870

From rriggs at openjdk.org  Fri Mar 22 18:43:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 22 Mar 2024 18:43:27 GMT
Subject: RFR: 8328700: Unused import and variable should be deleted in
 regex package
In-Reply-To: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
References: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
Message-ID: <FYIK7aHqU26Gqlh3Ht1GqwY5VqRsInd_4ThddfHNEuE=.17532b1e-98bf-42fa-bc55-581e529fd53b@github.com>

On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of an unused local variable probably intended to replace later casts.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18460#pullrequestreview-1955516666

From bpb at openjdk.org  Fri Mar 22 18:43:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 22 Mar 2024 18:43:28 GMT
Subject: RFR: 8328700: Unused import and variable should be deleted in
 regex package
In-Reply-To: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
References: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
Message-ID: <-LXPiFQJUcMLws6v2amuK3irvbCJyqBhLmQ862BUHCE=.4f511fe6-2796-4bc4-a5e0-825473b6894f@github.com>

On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of an unused local variable probably intended to replace later casts.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18460#pullrequestreview-1955519288

From iris at openjdk.org  Fri Mar 22 18:50:22 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 22 Mar 2024 18:50:22 GMT
Subject: RFR: 8328700: Unused import and variable should be deleted in
 regex package
In-Reply-To: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
References: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
Message-ID: <bsZkDnpP133QpAOI0e0oCOyjjl_aKQk8cfeubGkMtEE=.85c26e98-59c4-4530-a979-fee8fd99ed3b@github.com>

On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of an unused local variable probably intended to replace later casts.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18460#pullrequestreview-1955535154

From naoto at openjdk.org  Fri Mar 22 18:50:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Mar 2024 18:50:22 GMT
Subject: RFR: 8328700: Unused import and variable should be deleted in
 regex package
In-Reply-To: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
References: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
Message-ID: <ENzKwV0ZiXgkSzkyYhlbym7lHTV4-ZcpZhTzkGSboe0=.03caa3bb-e6d1-457e-91b6-d6beec1c0893@github.com>

On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of an unused local variable probably intended to replace later casts.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18460#pullrequestreview-1955528280

From mcimadamore at openjdk.org  Fri Mar 22 19:32:22 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Mar 2024 19:32:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <kFsmNVGNDfvlOLEXfiPkFSm-2FTvUE_V6sqymNzOUaw=.629131db-6ddd-46c9-9cf1-1e4538b96708@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <kFsmNVGNDfvlOLEXfiPkFSm-2FTvUE_V6sqymNzOUaw=.629131db-6ddd-46c9-9cf1-1e4538b96708@github.com>
Message-ID: <yMJzj8LurIx1aQRsdJscOwy2UmYWksQ6wQLou7vDxYY=.582ba852-9618-4964-b47f-994ec3fbf099@github.com>

On Fri, 22 Mar 2024 16:53:58 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> In case of jextract (jdk22 branch), we would then need something like the following if we want AIX to behave like the other platforms?
> 
> ```
> diff --git a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
> index 14eba30..c069c3b 100644
> --- a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
> +++ b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
> @@ -27,11 +27,13 @@
>  
>  package org.openjdk.jextract.clang.libclang;
>  
> +import java.io.File;
>  import java.lang.invoke.*;
>  import java.lang.foreign.*;
>  import java.nio.ByteOrder;
>  import java.util.*;
>  import java.util.function.*;
> +import java.util.StringTokenizer;
>  import java.util.stream.*;
>  
>  import static java.lang.foreign.ValueLayout.*;
> @@ -101,8 +103,21 @@ public class Index_h {
>      }
>  
>      static {
> -        String libName = System.getProperty("os.name").startsWith("Windows") ? "libclang" : "clang";
> -        System.loadLibrary(libName);
> +        String osName = System.getProperty("os.name");
> +        String libName = "";
> +        if (osName.startsWith("AIX")) {
> +            String libPath = System.getProperty("java.library.path");
> +            StringTokenizer parser = new StringTokenizer(libPath, ":");
> +            while (parser.hasMoreTokens()) {
> +                libName = parser.nextToken() + "/libclang.a";
> +                File f = new File(libName);
> +                if (f.exists() && !f.isDirectory()) break;
> +            }
> +            SymbolLookup.libraryLookup(libName + "(libclang.so.16)", Arena.global());
> +        } else {
> +            libName = osName.startsWith("Windows") ? "libclang" : "clang";
> +            System.loadLibrary(libName);
> +        }
>      }
>  
>      static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.loaderLookup()
> ```
> 
> If I try this, I get "UnsatisfiedLinkError: unresolved symbol: clang_createIndex". So, seems like the lib gets found, but symbols not loaded. Seems like there are more changes needed.

Something like that seems good. When you call "find" on that lookup, it should just forward to dlsym... I suggest you try first to simply use the lookup in a standalone file (w/o jextract) and try to lookup a symbol in clang (e.g. `clang_getClangVersion`), and see what happens.

If that doesn't work (likely), I'd suggest to write the equivalent C program with dlopen/dlsym, and make sure that works, and also note which DLOPEN/DLSYM parameters are used (maybe those are different from the ones used by the JDK?).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015773691

From mdoerr at openjdk.org  Fri Mar 22 19:59:22 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 22 Mar 2024 19:59:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <tfloXrK_yv33mOlhUflkGpAJwe8f_ZAhImGSluVzhPk=.b679f0cb-7ab3-431f-b04c-e0b21a3fe0cf@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

Ah, right. Thanks! I should use that `SymbolLookup`:

diff --git a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
index 14eba30..4f92f43 100644
--- a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
+++ b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
@@ -27,11 +27,13 @@
 
 package org.openjdk.jextract.clang.libclang;
 
+import java.io.File;
 import java.lang.invoke.*;
 import java.lang.foreign.*;
 import java.nio.ByteOrder;
 import java.util.*;
 import java.util.function.*;
+import java.util.StringTokenizer;
 import java.util.stream.*;
 
 import static java.lang.foreign.ValueLayout.*;
@@ -100,14 +102,27 @@ public class Index_h {
         throw new IllegalArgumentException("Invalid type for ABI: " + c.getTypeName());
     }
 
+    static SymbolLookup SYMBOL_LOOKUP;
+
     static {
-        String libName = System.getProperty("os.name").startsWith("Windows") ? "libclang" : "clang";
-        System.loadLibrary(libName);
+        String osName = System.getProperty("os.name");
+        String libName = "";
+        if (osName.startsWith("AIX")) {
+            String libPath = System.getProperty("java.library.path");
+            StringTokenizer parser = new StringTokenizer(libPath, ":");
+            while (parser.hasMoreTokens()) {
+                libName = parser.nextToken() + "/libclang.a";
+                File f = new File(libName);
+                if (f.exists() && !f.isDirectory()) break;
+            }
+            SYMBOL_LOOKUP = SymbolLookup.libraryLookup(libName + "(libclang.so.16)", Arena.global());
+        } else {
+            libName = osName.startsWith("Windows") ? "libclang" : "clang";
+            System.loadLibrary(libName);
+            SYMBOL_LOOKUP = SymbolLookup.loaderLookup().or(Linker.nativeLinker().defaultLookup());
+        }
     }
 
-    static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.loaderLookup()
-            .or(Linker.nativeLinker().defaultLookup());
-
     public static final ValueLayout.OfBoolean C_BOOL = ValueLayout.JAVA_BOOLEAN;
     public static final ValueLayout.OfByte C_CHAR = ValueLayout.JAVA_BYTE;
     public static final ValueLayout.OfShort C_SHORT = ValueLayout.JAVA_SHORT;

The symbols get found and the JVM can really call into the `libclang.a(libclang.so.16)`. Impressive! (That doesn't mean that jextract is working. clang crashes the way we are calling it. Maybe because of a thread stack size or other memory management problem.) So, there is basically a valid solution for loading such libraries. Only not very smooth for Java programmers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015811096

From jlu at openjdk.org  Fri Mar 22 21:09:38 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Mar 2024 21:09:38 GMT
Subject: RFR: JDK-8327640: Allow NumberFormat strict parsing [v4]
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: <GVu3-2eQOKxA9-HVDYBCj8dV9_3N7xIt0WqYRN8t8U4=.1ca00df7-0437-44fe-9677-7e65684a73cd@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 three additional commits since the last revision:

 - 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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/c09a34dd..4edb4802

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=02-03

  Stats: 148 lines in 4 files changed: 87 ins; 24 del; 37 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 mcimadamore at openjdk.org  Sat Mar 23 00:40:33 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Sat, 23 Mar 2024 00:40:33 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <tfloXrK_yv33mOlhUflkGpAJwe8f_ZAhImGSluVzhPk=.b679f0cb-7ab3-431f-b04c-e0b21a3fe0cf@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <tfloXrK_yv33mOlhUflkGpAJwe8f_ZAhImGSluVzhPk=.b679f0cb-7ab3-431f-b04c-e0b21a3fe0cf@github.com>
Message-ID: <hIqUkduaIdxLA6JyCeSH_MB0ZJoV9I7mfrygy-0N6M8=.96b927c2-fc78-4efa-b947-50cfadd40c1a@github.com>

On Fri, 22 Mar 2024 19:56:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The symbols get found and the JVM can really call into the `libclang.a(libclang.so.16)`. Impressive! (That doesn't mean that jextract is working. clang crashes the way we are calling it. Maybe because of a thread stack size or other memory management problem.) So, there is basically a valid solution for loading such libraries. Only not very smooth for Java programmers.

Note that the jextract code itself depends on bindings generated via jextract (!!). So, I wonder if there might be some incompatibility in the generated layouts/descriptors, which is then causing the crash.The generated bindings are here:

https://github.com/openjdk/jextract/tree/master/src/main/java/org/openjdk/jextract/clang/libclang

These bindings are effectively shared across Linux/x64, Macos/x64, Macos/arm64 and Win/x64 - that is, all the layouts in there are valid and portable on these platforms (except for `C_LONG` on Windows, but libclang is quite disciplined and only uses `long long`).

I'd try few steps:

1. check that your libclang.so is not broken, by calling `clang_version` in a C program and making sure that works w/o crashing
2. then try to do the same (w/o jextract) using FFM, from Java, and see if that still works

If even (1) fails, you might just have a bad libclang, or one that is not for your system (not all the binary downloads in the LLVM website worked on my machine, even if they were supposedly compatible).

If (1) succeds, but (2) fails, that would indicate some general issue with libclang and the JVM. There is an issue that we currently have to workaround, where libclang tries to install its own signal handlers, which mess up the JVM's signal handler to deal with NPEs (and that causes a random JVM crash). This is documented here:

https://reviews.llvm.org/D23662

We try to call "setenv" to disable that logic, but that might fail or not be supported on your platform, so worth checking that.

Finally, if (1) and (2) both succeed, but you get spurious JVM crashes with jextract, then I'd start looking at jextract's bindings (the ones in the folder above), pick a struct (e.g. CXCursor, or CXString) and then inspect the layout and make sure that corresponds to what the layout should be in AIX - it is possible that the AIX compiler inserts some extra padding, and then passing structs with the wrong size in and out of libclang would explain the issues.

Hope this helps!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2016231211

From mcimadamore at openjdk.org  Sat Mar 23 00:49:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Sat, 23 Mar 2024 00:49:32 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <LX6-Fw0W9n7A-lmeI49yO6cDqXSbKPH7-sO2Fv4UjZo=.80b7cf79-1f29-4189-bccf-ece474ca4f59@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

I'd like to uplevel the discussion a bit. This PR started off to tweak the way in which `System::load` worked in AIX. We then discussed a bunch of options, talked about `Symbol::libraryLookup` and verified that this lookup allows to load libraries as expected in AIX. There's some jextract issues which need to be worked out, but that's outside the scope of this PR.

That said, is there anything that we feel could be improved in terms of library loading support with `System::load` ? My conclusion was that, given that in this case we needed a fully versioned archive member, it is hard to implement and/or to expose as a simple `mapLibraryName` add-on. Is that correct?

If you feel that there's not much that `System::load` can do for these cases, then I'd suggest we close this PR, and perhaps move the discussion about jextract either on `jextract-dev` or on `panama-dev`. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2016237758

From sgibbons at openjdk.org  Sat Mar 23 02:16:57 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 23 Mar 2024 02:16:57 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v14]
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: <GUD4T-ob6T65iNHEN4-Nhy0ntHz-283coZ7H5kYuHJg=.d5eaac76-a93f-4cb4-add6-0b1d5a0fcd23@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 46 commits:

 - 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
 - Works - needs cleanup
 - Passes tests.
 - ... and 36 more: https://git.openjdk.org/jdk/compare/bc739639...e079fc12

-------------

Changes: https://git.openjdk.org/jdk/pull/16753/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=13
  Stats: 4905 lines in 19 files changed: 4551 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 sgibbons at openjdk.org  Sat Mar 23 02:16:58 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 23 Mar 2024 02:16:58 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v13]
In-Reply-To: <MZj_08eJiTVFJyis-u7V8SBGal_cJ-6tIYr0oFseVpY=.329ca24b-48e3-4c3d-80ec-a395d9d8a4d5@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <MZj_08eJiTVFJyis-u7V8SBGal_cJ-6tIYr0oFseVpY=.329ca24b-48e3-4c3d-80ec-a395d9d8a4d5@github.com>
Message-ID: <FSAbopPjHJdiPqBuTGeGec5wflrC5fCChvEIyKEzpqg=.1d509261-23ea-4711-80ad-38ff741f06e7@github.com>

On Thu, 22 Feb 2024 03:15:10 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> 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:
> 
>   Addressed some review coments; replaced hard-coded registers with descriptive names.

Re-opening this PR after some insightful comments, which resulted in a re-design.  Now ready for review.

Now showing ~1.6x performance gain on original StringIndexOf benchmark.  I added a benchmark (StringIndexOfHuge) that measures performance on large-ish strings (e.g., 34-byte substring within a 2052-byte string).  This benchmark performed on average ~14x original.

Sorry for the large change, but it couldn't be done piecemeal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2016308399

From duke at openjdk.org  Sat Mar 23 10:01:32 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Sat, 23 Mar 2024 10:01:32 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v14]
In-Reply-To: <GUD4T-ob6T65iNHEN4-Nhy0ntHz-283coZ7H5kYuHJg=.d5eaac76-a93f-4cb4-add6-0b1d5a0fcd23@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <GUD4T-ob6T65iNHEN4-Nhy0ntHz-283coZ7H5kYuHJg=.d5eaac76-a93f-4cb4-add6-0b1d5a0fcd23@github.com>
Message-ID: <ogK1sC24QmAn9Hlu4MkCMiyu2EuZ3sD_ouVwly4qDR4=.9cec734f-e2c9-4956-9aec-d3da570dd3bc@github.com>

On Sat, 23 Mar 2024 02:16:57 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> 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 46 commits:
> 
>  - 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
>  - Works - needs cleanup
>  - Passes tests.
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/bc739639...e079fc12

Hi, in Netty, we have our own AsciiString::indexOf based on SWAR techniques, which is manually loop unrolling the head processing (first < 8 bytes) to artificially make sure the branch predictor got different branches to care AND JIT won't make it wrong. We have measured (I can provide a link of the benchmark and results, If you are interested) that it delivers a much better performance on tiny strings and makes a smoother  degradation vs perfectly aligned string length as well. Clearly this tends to be much visible if the input strings have shuffled delimiter positions, to make the branch prediction misses more relevant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2016432345

From mdoerr at openjdk.org  Sat Mar 23 12:03:24 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 23 Mar 2024 12:03:24 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
Message-ID: <EOeIFclHv2zgVTT9p5-SvwxtcSolTFLF361a9ljscZ4=.f3a73ad2-941f-474f-921b-074e1256bbfd@github.com>

On Mon, 18 Mar 2024 17:43:45 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:
> 
>   trraling spaces

Thanks! Agreed. jextract is crashing in libclang.a::llvm::MemoryBuffer::getMemBufferRef() in a new llvm thread (could be related to the signal handler issue). That seems to be unrelated to this issue and shouldn't be discussed here.
It would be nice if loading such libraries could be made easier for Java developers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2016470368

From sroy at openjdk.org  Sat Mar 23 12:17:30 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Sat, 23 Mar 2024 12:17:30 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v4]
In-Reply-To: <LX6-Fw0W9n7A-lmeI49yO6cDqXSbKPH7-sO2Fv4UjZo=.80b7cf79-1f29-4189-bccf-ece474ca4f59@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <UV83nYNSHL2-9w7p7rOMfL5DuGk5Ly97_bfJry9lgbU=.fb5b2551-3477-49d8-8f26-151e08ce4b0b@github.com>
 <LX6-Fw0W9n7A-lmeI49yO6cDqXSbKPH7-sO2Fv4UjZo=.80b7cf79-1f29-4189-bccf-ece474ca4f59@github.com>
Message-ID: <aleYqLzpTM9qz7O4Fr4EOUQk0C3cZCjoU2xuYubimPU=.46059fac-0c83-477e-ab8d-f42d00795a8b@github.com>

On Sat, 23 Mar 2024 00:46:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I'd like to uplevel the discussion a bit. This PR started off to tweak the way in which `System::load` worked in AIX. We then discussed a bunch of options, talked about `Symbol::libraryLookup` and verified that this lookup allows to load libraries as expected in AIX. There's some jextract issues which need to be worked out, but that's outside the scope of this PR.
> 
> That said, is there anything that we feel could be improved in terms of library loading support with `System::load` ? My conclusion was that, given that in this case we needed a fully versioned archive member, it is hard to implement and/or to expose as a simple `mapLibraryName` add-on. Is that correct?
> 
> If you feel that there's not much that `System::load` can do for these cases, then I'd suggest we close this PR, and perhaps move the discussion about jextract either on `jextract-dev` or on `panama-dev`. Thanks!

I Feel it is good to at least keep the option for Java developers to use system.load for member objects. 
Also , the original intention of the PR was to allow .so to .a mapping if .so is not there. This fix had gone into J9 and I think it would be good to keep this support in OpenJDK too. 
In summary, the functionality to parse members can be kept limited to System.load and the deterministic .so to .a mapping as part of System.loadLibrary().

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2016475083

From sgibbons at openjdk.org  Sat Mar 23 16:50:28 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 23 Mar 2024 16:50:28 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v14]
In-Reply-To: <ogK1sC24QmAn9Hlu4MkCMiyu2EuZ3sD_ouVwly4qDR4=.9cec734f-e2c9-4956-9aec-d3da570dd3bc@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <GUD4T-ob6T65iNHEN4-Nhy0ntHz-283coZ7H5kYuHJg=.d5eaac76-a93f-4cb4-add6-0b1d5a0fcd23@github.com>
 <ogK1sC24QmAn9Hlu4MkCMiyu2EuZ3sD_ouVwly4qDR4=.9cec734f-e2c9-4956-9aec-d3da570dd3bc@github.com>
Message-ID: <PKDQCr51MzSMn4FQcbYzu1_ZlTRjO5vOaSO7I9ILfKs=.62e9d160-6c15-47c0-97d5-0818db26de67@github.com>

On Sat, 23 Mar 2024 09:57:49 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - 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
>>  - Works - needs cleanup
>>  - Passes tests.
>>  - ... and 36 more: https://git.openjdk.org/jdk/compare/bc739639...e079fc12
>
> Hi, in Netty, we have our own AsciiString::indexOf based on SWAR techniques, which is manually loop unrolling the head processing (first < 8 bytes) to artificially make sure the branch predictor got different branches to care AND JIT won't make it wrong. We have measured (I can provide a link of the benchmark and results, If you are interested) that it delivers a much better performance on tiny strings and makes a smoother  degradation vs perfectly aligned string length as well. Clearly this tends to be much visible if the input strings have shuffled delimiter positions, to make the branch prediction misses more relevant.

Hi @franz1981.  I'd be interested in seeing the code.  I looked [here](https://github.com/netty/netty/blob/3a3f9d13b129555802de5652667ca0af662f554e/common/src/main/java/io/netty/util/AsciiString.java#L696), but that just looks like a na?ve implementation, so I must be missing something.

This code uses vector compares to search for the first byte of the substring (needle) in 32-byte chunks of the input string (haystack).  However, once a character is found, it also checks for a match corresponding to the last byte of the needle within the haystack before doing the full needle comparison.  This is also in 32-byte chunks.  That is, we load a vector register with 32 (or 16 for wide chars) copies of the first byte of the needle, and another with copies of the last byte of the needle.  The first comparison is done at the start of the haystack, giving us indication of the presence and index of the first byte.  We then compare the last byte of the needle at the haystack indexed at needle length - 1 (i.e., the last byte).  This tells us if the last byte of the needle appears in the correct relative position within the haystack.  ANDing these results tells us whether or not we have a candidate needle within the haystack, as well as the position of the needle.  Only then do we
  do a full char-by-char comparison of the needle to the haystack (this is also done with vector instructions when possible).

A lot of this code is there to handle the cases of small-ish needles within small-ish haystacks, where 32-byte reads are not possible (due to reading past the end of the strings, possibly generating a page fault).  I handle less than 32-byte haystacks by copying the haystack to the stack, where I can be assured that 32-byte reads will be possible.  So there are special cases for haystack < 32 bytes with needle sizes <= 10 (arbitrary) and one for haystacks > 32 bytes and needle size <= 10.  I also added a section for haystacks <= 32 bytes and needle sizes < 5, which seem to be the most common cases.  This path copies the haystack to the stack (a single vector read & write) and up to 5 vector comparisons, one for each byte of the needle, with no branching or looping.

I'd be very interested in seeing the Netty SWAR implementation.  Thanks for the comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2016544706

From duke at openjdk.org  Sat Mar 23 19:02:28 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Sat, 23 Mar 2024 19:02:28 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v14]
In-Reply-To: <GUD4T-ob6T65iNHEN4-Nhy0ntHz-283coZ7H5kYuHJg=.d5eaac76-a93f-4cb4-add6-0b1d5a0fcd23@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <GUD4T-ob6T65iNHEN4-Nhy0ntHz-283coZ7H5kYuHJg=.d5eaac76-a93f-4cb4-add6-0b1d5a0fcd23@github.com>
Message-ID: <mPSvYQslZuAi93-4onfZALPb6yekQuO2F4ma8NgN89s=.1481c1dd-215a-4c47-8a4f-28d1edda873d@github.com>

On Sat, 23 Mar 2024 02:16:57 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> 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 46 commits:
> 
>  - 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
>  - Works - needs cleanup
>  - Passes tests.
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/bc739639...e079fc12

Sure thing: https://github.com/netty/netty/pull/13534#issuecomment-1685247165

It's the comparison with String::indexOf while the impl is: https://github.com/netty/netty/blob/3a3f9d13b129555802de5652667ca0af662f554e/buffer/src/main/java/io/netty/buffer/ByteBufUtil.java#L590

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2016576139

From duke at openjdk.org  Sun Mar 24 17:27:27 2024
From: duke at openjdk.org (Bernd)
Date: Sun, 24 Mar 2024 17:27:27 GMT
Subject: RFR: 8328812: Update and move siphash license
In-Reply-To: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
Message-ID: <Nc-eP-b6MGpTLHJuTR4H5N_5lC-TJG-xtdpnHIkT7pQ=.cb26ec2e-1d4e-4c4e-b8ef-db0bb219703c@github.com>

On Fri, 22 Mar 2024 15:18:29 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Updated and moved the license file.

src/hotspot/share/legal/siphash.md line 9:

> 7:    Copyright (c) 2012-2021 Jean-Philippe Aumasson
> 8:    <jeanphilippe.aumasson at gmail.com>
> 9:    Copyright (c) 2012-2014 Daniel J. Bernstein <djb at cr.yp.to>

Why would you remove a author or year range?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18455#discussion_r1536867069

From rgiulietti at openjdk.org  Mon Mar 25 08:50:30 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 25 Mar 2024 08:50:30 GMT
Subject: Integrated: 8328700: Unused import and variable should be deleted in
 regex package
In-Reply-To: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
References: <9hX5Er6rESxtPnFeIupv5q2jWid6brk4HqtoeZWiuz4=.447f5f04-f36d-43b7-af17-1add17180516@github.com>
Message-ID: <01VYAXuyIgsC0RNhyyTPpoLKPknjYzRDtAQIM5qzpsE=.b2d6b342-e806-42f4-96c3-e1778e44b0e3@github.com>

On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of an unused local variable probably intended to replace later casts.

This pull request has now been integrated.

Changeset: 19a0151a
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19a0151a529ca69b3bef1ca821d9292018efbb7c
Stats:     7 lines in 2 files changed: 0 ins; 1 del; 6 mod

8328700: Unused import and variable should be deleted in regex package

Reviewed-by: redestad, rriggs, bpb, naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/18460

From pminborg at openjdk.org  Mon Mar 25 09:40:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 25 Mar 2024 09:40:25 GMT
Subject: Integrated: 8323552: AbstractMemorySegmentImpl#mismatch returns -1
 when comparing distinct areas of the same instance of MemorySegment
In-Reply-To: <yGUDL9KFPQOLTviQ8LjiRU5towjC77FWmkH256hIVKs=.207a6854-31ce-4385-a81e-1fdcec59cedd@github.com>
References: <yGUDL9KFPQOLTviQ8LjiRU5towjC77FWmkH256hIVKs=.207a6854-31ce-4385-a81e-1fdcec59cedd@github.com>
Message-ID: <EYAYfM28oU9UhQ205wsPRDPVl37MTCPgY5juWcfoge8=.9000c6a1-f43c-4d91-9f5f-afaa106d104c@github.com>

On Thu, 21 Mar 2024 09:23:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove an old optimization check that was incorrect making `AbstractMemorySegmentImpl::mismatch` always return `-1` if the source and destination segment are the same (disregarding offsets).

This pull request has now been integrated.

Changeset: 93579c29
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93579c29e3ba60a8bc16d712e7ffc733f324a223
Stats:     34 lines in 2 files changed: 27 ins; 4 del; 3 mod

8323552: AbstractMemorySegmentImpl#mismatch returns -1 when comparing distinct areas of the same instance of MemorySegment

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/18426

From sroy at openjdk.org  Mon Mar 25 09:46:50 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 25 Mar 2024 09:46:50 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
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: <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@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 four additional commits since the last revision:

 - coding style
 - set false
 - restore fil
 -  remove member check code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17945/files
  - new: https://git.openjdk.org/jdk/pull/17945/files/d361656c..212a8cf9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=03-04

  Stats: 16 lines in 2 files changed: 1 ins; 13 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 pminborg at openjdk.org  Mon Mar 25 10:39:23 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 25 Mar 2024 10:39:23 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment [v3]
In-Reply-To: <GX3AHG5TyzYjqOMIDu54uAQlFN4DEL67L1GVcraOMhM=.6246b527-d3da-4783-8e53-5ff6cd921443@github.com>
References: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
 <GX3AHG5TyzYjqOMIDu54uAQlFN4DEL67L1GVcraOMhM=.6246b527-d3da-4783-8e53-5ff6cd921443@github.com>
Message-ID: <rh5yKoHIMpgpkyXPIZ-UuzXhzkJ5w4gJznKxOcl3wvs=.dca8d3de-aefa-47e7-8772-81282979dc26@github.com>

On Thu, 11 Jan 2024 16:21:38 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It returns `-1` (meaning that regions are equal) when passing the same instance of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of whether `srcFromOffset` and `dstFromOffset` as well as `srcToOffset` and `dstToOffset` are also equal.
>> 
>> Am I right?
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove special-case check from instance method - test pending

This PR can be closed @plevart as the issue has been fixed via https://github.com/openjdk/jdk/pull/18426

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17354#issuecomment-2017693081

From sgibbons at openjdk.org  Mon Mar 25 14:39:59 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Mon, 25 Mar 2024 14:39:59 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v15]
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: <WTUkWyZvpP2wTIxoAYdZZduq-uDvxpiouVRPAlIcGTA=.aea48904-829d-4008-887a-db9891505345@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:

  Remove infinite loop (used for debugging)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/e079fc12..1cd1b501

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=13-14

  Stats: 12 lines in 1 file changed: 0 ins; 2 del; 10 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 clanger at openjdk.org  Mon Mar 25 16:34:31 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 25 Mar 2024 16:34:31 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: <36-uLVrsexBrgtOwUkfGEY9DYq7kVtZG58b_bQoBe0s=.49a0d4b1-e141-4863-bc9f-80a8bd7b8196@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
 <Gfc5nSHywS0SkSv33Bgu9htQapPQgbH1SAXmjtU6UIA=.82fe269b-3a6a-40cb-b77d-c878b4d12210@github.com>
 <rNceCTggSqL-bJVTTj4X4HEzVsmanlKNIhrbrPCf-g0=.395f0162-d5d9-4840-98dd-199def542269@github.com>
 <RaKJiTLW6li4_S5-HsffyRqDNOwd-vFCkLH8b0_dD1k=.4bff88c5-04f4-498d-af4d-14c437bb369a@github.com>
 <QZU5goh25uLufkMD76XbPw1yrRDok-cl995sUZ602pI=.536873ab-d1bb-457e-88a9-d180f3720f8b@github.com>
 <ysYpm97ehjB1vmPga-F6V81vmdDwbQ_s-67oNUKbmrQ=.601fadce-df07-4a25-8559-819025c1a7ce@github.com>
 <rxsscNAo3wJCLQ-Zr3HSAN2PdTNdwMe9fIOiYNUzrSg=.9cde53d2-43f0-4b35-93d2-52e7f0820683@github.com>
 <36-uLVrsexBrgtOwUkfGEY9DYq7kVtZG58b_bQoBe0s=.49a0d4b1-e141-4863-bc9f-80a8bd7b8196@github.com>
Message-ID: <p6_cxWr46qYUJ6Jzr06Yg4FQIO0hDuAxc5O8TMzZFD8=.240164a8-7695-4af1-9382-0cb2872de3d0@github.com>

On Mon, 4 Mar 2024 15:02:45 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>>> As for the test, I had a closer look now and I find it hard to separate testing of [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) from [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). Furthermore, most of the entries test things that hadn't been addressed by any of these two bugs at all.
>>>
>>> So, [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) is only tested in lines 72, 73, 76 and 77 The original problem of this issue [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) is touched in line 71 and 73.
>>> 
>>> That means, most of the other test invocations test some generic behavior which was never erroneous so far.
>> 
>> Thanks for exploring the possibility of improving tracebility of test invocations to reported bugs.  
>> 
>>> I could, however, give each line its own test id and annotate the bugs accordingly. Do you think that makes sense?
>> 
>> It does make sense, but I'm not sure how such annotations will look like and if it will be easy to use them for debugging failures. I will leave the final decision to you here.  Your last message with linkage of test invocations to bug id is already a good information to have. 
>> 
>>> I drafted a CSR. @AlekseiEfimov, would be nice if you could review it.
>> 
>> Thanks for drafting a CSR. I will review it in comming days.
>
>> Thanks for exploring the possibility of improving tracebility of test invocations to reported bugs.
>> 
>> >
> 
> I've given this test change a second thought, maybe you can try to separate the test into two separate test classes? One possibility to avoid duplicating code and have a separate test for each bug is to introduce a base test class that will contain the common functionality for [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) and [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) tests.

Thanks @AlekseiEfimov and @dfuch for the reviews. Submitting this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-2018412400

From clanger at openjdk.org  Mon Mar 25 16:34:32 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 25 Mar 2024 16:34:32 GMT
Subject: Integrated: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket
In-Reply-To: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
References: <S2A0y4PUrORBoRbdEV-us3ONq0etIaZy4_er6zcbOrI=.37dd6c05-97b0-4c85-b356-b9cf15b27a69@github.com>
Message-ID: <LHz3rMRHwRfSLKgq9MISfEEVMQAiv6Svf7TnwCSjNRw=.cd6a2edd-035e-4702-a686-0cedf7250e87@github.com>

On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

This pull request has now been integrated.

Changeset: 907e30ff
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/907e30ff00abd6cd4935987810d282f46ec07704
Stats:     245 lines in 3 files changed: 130 ins; 35 del; 80 mod

8325579: Inconsistent behavior in com.sun.jndi.ldap.Connection::createSocket

Reviewed-by: dfuchs, aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/17797

From mchung at openjdk.org  Mon Mar 25 18:46:30 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 25 Mar 2024 18:46:30 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
Message-ID: <HgLsgTS3mdrdd9G2ZVxDcunYz0evzm4D2AUL2ZS9FdA=.969a9e5f-2506-4cba-85ba-ba1c64a51526@github.com>

On Mon, 25 Mar 2024 09:46:50 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 four additional commits since the last revision:
> 
>  - coding style
>  - set false
>  - restore fil
>  -  remove member check code

JDK-8313616 changes HotSpot VM to support loading member objects from .a on AIX dlopen.   That RFE was a reasonable change as AIX JDK may load native libraries from an archive file of a named member object e.g. `/usr/lib/libperfstat.a(shr_64.o)`

JDK-8320005 was the first attempt to fix `dcstartup` and second attempt by this issue in JDK 23.   This changes HotSpot VM to load from an alternate path if `os::dll_load(lib_path)`, which in turn calls dlopen` on AIX,  fails to load `lib_path` with `.so` suffix, it tries to load with an alternatve path by replacing `.so` with `.a`.

This issue (JDK-8319516) attempts to change the library implementation as follows:
1. `System::loadLibrary("foo")` to call `dlopen("/usr/lib/libfoo.so")` first; if fails, `dlopen("/usr/lib/libfoo.a")`
2. `System::load("/usr/lib/libfoo.so(libfoo.so.1)"` that will call (1) `dlopen("/usr/lib/libfoo.so((libfoo.so.1)")`, if fails (2) `dlopen("/usr/lib/libfoo.a((libfoo.so.1)")`.

On AIX, loading shared objects from an archive object via `System::loadLibrary` and `System::load` never work before.

Do you expect if developers start to package shared objects in the format of archive objects?  If so, it would be reasonable to support #1 for compatibility.

For #2,  `System::loadLibrary("foo(libfoo.so.1)"`,  `System::load("/usr/lib/libfoo.so((libfoo.so.1)")` and `System::load("/usr/lib/libfoo.a((libfoo.so.1)")` are never supported.   I think applications should use `SymbolLookup::libraryLookup` instead on Java 22 and later.   I don't use `libclang` as the example here because that's related to jextract and has nothing to do with `System::load` as Maurizio said.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2018669567

From sroy at openjdk.org  Mon Mar 25 19:00:30 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 25 Mar 2024 19:00:30 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <HgLsgTS3mdrdd9G2ZVxDcunYz0evzm4D2AUL2ZS9FdA=.969a9e5f-2506-4cba-85ba-ba1c64a51526@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <HgLsgTS3mdrdd9G2ZVxDcunYz0evzm4D2AUL2ZS9FdA=.969a9e5f-2506-4cba-85ba-ba1c64a51526@github.com>
Message-ID: <g4Ve0apXBwEEmXxf2ZnTMW22aSU2mq7qr1c8xIRIZvQ=.54d1ec6e-31e5-4e9e-91cc-d4a8f752ecc5@github.com>

On Mon, 25 Mar 2024 18:43:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Do you expect if developers start to package shared objects in the format of archive objects? If so, it would be reasonable to support #1 for compatibility.

Yes. I agree. We should keep this compatibility for entire flow from classloader to the hotspot code. And it has been in J9 for long time for the exact same reason, which actually brought out the issue for dcstartup in OpenJDK.

> For #2, `System::loadLibrary("foo(libfoo.so.1)"`, `System::load("/usr/lib/libfoo.so((libfoo.so.1)")` and `System::load("/usr/lib/libfoo.a((libfoo.so.1)")` are never supported. I think applications should use `SymbolLookup::libraryLookup` instead on Java 22 and later. I don't use `libclang` as the example here because that's related to jextract and has nothing to do with `System::load` as Maurizio said.

I just feel keeping load functionality is still applicable, which does not expect a deterministic mapping (or does it ? ). if loadLibrary expects this to be deterministic, then i agree, we should drop that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2018690683
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2018693188

From bchristi at openjdk.org  Mon Mar 25 19:26:41 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 25 Mar 2024 19:26:41 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v16]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <1UvLALeMWw_K4XiqxSr_Nj-_sUTxN8iFuIEOmiXez1k=.1159d190-1aab-45fd-8000-b713eb0a156a@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 updates to reachabilityFence, per review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/3df288a5..15ae0f25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=14-15

  Stats: 5 lines in 1 file changed: 0 ins; 1 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 bchristi at openjdk.org  Mon Mar 25 19:26:42 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 25 Mar 2024 19:26:42 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v15]
In-Reply-To: <I6SxU3TlD1SU8Za1StZ4_YEEF8cJG6xielhOmGc4Upg=.c41442ff-53ef-45c1-bd1c-d0294f4c1567@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <sMUQGOMmhqooALZvfLJIVjAp40MY_ub6-EBBZhbmx10=.bb8e4835-d4c2-4c91-8ede-61f22a015eea@github.com>
 <I6SxU3TlD1SU8Za1StZ4_YEEF8cJG6xielhOmGc4Upg=.c41442ff-53ef-45c1-bd1c-d0294f4c1567@github.com>
Message-ID: <IRZQRHhHicV5QqCZoKkTOyjuHImmBXd0sPlUvu3T6HM=.1273baec-f0cc-4b9f-bff6-264a1eca8031@github.com>

On Fri, 22 Mar 2024 09:28:02 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Elaborate on 'surprising and undesirable effects' in reachabilityFence()
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 632:
> 
>> 630:      * object.  This might be the case if, for example, a usage in a user program
>> 631:      * had the form {@code new Resource().action();} which retains no other
>> 632:      * reference to this {@code Resource}.  The
> 
> Reformat this line?

Suggestions?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1538120558

From mchung at openjdk.org  Mon Mar 25 20:05:23 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 25 Mar 2024 20:05:23 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <g4Ve0apXBwEEmXxf2ZnTMW22aSU2mq7qr1c8xIRIZvQ=.54d1ec6e-31e5-4e9e-91cc-d4a8f752ecc5@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <HgLsgTS3mdrdd9G2ZVxDcunYz0evzm4D2AUL2ZS9FdA=.969a9e5f-2506-4cba-85ba-ba1c64a51526@github.com>
 <g4Ve0apXBwEEmXxf2ZnTMW22aSU2mq7qr1c8xIRIZvQ=.54d1ec6e-31e5-4e9e-91cc-d4a8f752ecc5@github.com>
Message-ID: <Vgr72T5zlpw_6nsSVjs4FghRpC1dZcjpR2HZwjkiQQM=.ac199a36-b8ea-4838-8925-d0eb1158cbdd@github.com>

On Mon, 25 Mar 2024 18:56:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>  And it has been in J9 for long time for the exact same reason, which actually brought out the issue for dcstartup in OpenJDK.

dcstartup fails because it fails to load an agent library specified via `-agentlib:am_ibm_16` that was fixed by JDK-8320005.   I assume that's what you referred to "J9 had for a long time".   This does not use `System::loadLibrary`.    It's unclear if any JNI native library is changed to load from an archive object.   Any customer reporting this issue?

> I just feel keeping load functionality is still applicable, which does not expect a deterministic mapping (or does it ? ). if loadLibrary expects this to be deterministic, then i agree, we should drop that.

It's not about deterministic mapping or not.   `System::load` is intended for loading JNI native libraries but not for providing equivalent functionality to `dlopen`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2018810383

From kbarrett at openjdk.org  Mon Mar 25 20:09:28 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 25 Mar 2024 20:09:28 GMT
Subject: RFR: 8328812: Update and move siphash license
In-Reply-To: <Nc-eP-b6MGpTLHJuTR4H5N_5lC-TJG-xtdpnHIkT7pQ=.cb26ec2e-1d4e-4c4e-b8ef-db0bb219703c@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
 <Nc-eP-b6MGpTLHJuTR4H5N_5lC-TJG-xtdpnHIkT7pQ=.cb26ec2e-1d4e-4c4e-b8ef-db0bb219703c@github.com>
Message-ID: <dT9cJed-6fM1rnTfHzyz0m319lZWx5mvCPIvabkTSEE=.91496bdf-734a-4779-a142-24fe2378529f@github.com>

On Sun, 24 Mar 2024 17:24:49 GMT, Bernd <duke at openjdk.org> wrote:

>> Updated and moved the license file.
>
> src/hotspot/share/legal/siphash.md line 9:
> 
>> 7:    Copyright (c) 2012-2021 Jean-Philippe Aumasson
>> 8:    <jeanphilippe.aumasson at gmail.com>
>> 9:    Copyright (c) 2012-2014 Daniel J. Bernstein <djb at cr.yp.to>
> 
> Why would you remove a author or year range?

To match the license claim in the code we are using:
https://github.com/openjdk/jdk/blob/fb8f2a0a929ebe7f65c69741712b89bbb403ade9/src/hotspot/share/classfile/altHashing.cpp#L32-L43

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18455#discussion_r1538171151

From duke at openjdk.org  Mon Mar 25 20:13:35 2024
From: duke at openjdk.org (Bernd)
Date: Mon, 25 Mar 2024 20:13:35 GMT
Subject: RFR: 8328812: Update and move siphash license
In-Reply-To: <dT9cJed-6fM1rnTfHzyz0m319lZWx5mvCPIvabkTSEE=.91496bdf-734a-4779-a142-24fe2378529f@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
 <Nc-eP-b6MGpTLHJuTR4H5N_5lC-TJG-xtdpnHIkT7pQ=.cb26ec2e-1d4e-4c4e-b8ef-db0bb219703c@github.com>
 <dT9cJed-6fM1rnTfHzyz0m319lZWx5mvCPIvabkTSEE=.91496bdf-734a-4779-a142-24fe2378529f@github.com>
Message-ID: <WtpNA_q8MuE7HDZe_ub1ZKHY4uJ00xapVW2Y9bBQqJM=.aa3fe25d-f2a5-466c-a7a3-ead1e1ab0392@github.com>

On Mon, 25 Mar 2024 20:07:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/legal/siphash.md line 9:
>> 
>>> 7:    Copyright (c) 2012-2021 Jean-Philippe Aumasson
>>> 8:    <jeanphilippe.aumasson at gmail.com>
>>> 9:    Copyright (c) 2012-2014 Daniel J. Bernstein <djb at cr.yp.to>
>> 
>> Why would you remove a author or year range?
>
> To match the license claim in the code we are using:
> https://github.com/openjdk/jdk/blob/fb8f2a0a929ebe7f65c69741712b89bbb403ade9/src/hotspot/share/classfile/altHashing.cpp#L32-L43

The header file contains more claims https://github.com/veorq/SipHash/blob/master/halfsiphash.h

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18455#discussion_r1538174915

From bchristi at openjdk.org  Mon Mar 25 20:20:29 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 25 Mar 2024 20:20:29 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v16]
In-Reply-To: <1UvLALeMWw_K4XiqxSr_Nj-_sUTxN8iFuIEOmiXez1k=.1159d190-1aab-45fd-8000-b713eb0a156a@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <1UvLALeMWw_K4XiqxSr_Nj-_sUTxN8iFuIEOmiXez1k=.1159d190-1aab-45fd-8000-b713eb0a156a@github.com>
Message-ID: <yy2GXkNHNWpNgmZi4JJqqQxe-8YGWW4HV1n0reA3Cnk=.e29e80cf-0698-4c71-9c12-a150953c8527@github.com>

On Mon, 25 Mar 2024 19:26:41 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:
> 
>   Small updates to reachabilityFence, per review

src/java.base/share/classes/java/lang/ref/Reference.java line 638:

> 636:      *
> 637:      * <p> It is sometimes possible to better encapsulate use of
> 638:      * {@code reachabilityFence}.  Continuing the above example, if it were

[Per Hans in email,](https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/120747.html) I agree that this is not a good example, and is misleading.

Even if `update()` could be called without harm if the finalizer has already executed:
the user has called `action()` expecting some action (involving the `externalResource`) to take place. With the `reachabilityFence()` call "refactored" in this way, it is unclear whether that action actually takes place.

Better to stick with the try/finally/reachabilityFence() pattern, and have `action()` behave consistently.

This passage/example should be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1538183404

From kbarrett at openjdk.org  Mon Mar 25 20:36:27 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 25 Mar 2024 20:36:27 GMT
Subject: RFR: 8328812: Update and move siphash license
In-Reply-To: <WtpNA_q8MuE7HDZe_ub1ZKHY4uJ00xapVW2Y9bBQqJM=.aa3fe25d-f2a5-466c-a7a3-ead1e1ab0392@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
 <Nc-eP-b6MGpTLHJuTR4H5N_5lC-TJG-xtdpnHIkT7pQ=.cb26ec2e-1d4e-4c4e-b8ef-db0bb219703c@github.com>
 <dT9cJed-6fM1rnTfHzyz0m319lZWx5mvCPIvabkTSEE=.91496bdf-734a-4779-a142-24fe2378529f@github.com>
 <WtpNA_q8MuE7HDZe_ub1ZKHY4uJ00xapVW2Y9bBQqJM=.aa3fe25d-f2a5-466c-a7a3-ead1e1ab0392@github.com>
Message-ID: <2zN0sRhgR3Q7CtlruyOXYR3BN7VbOb6mGz55CWAonqM=.d7e02724-fa9f-4440-8c46-1fc473327c5c@github.com>

On Mon, 25 Mar 2024 20:10:45 GMT, Bernd <duke at openjdk.org> wrote:

>> To match the license claim in the code we are using:
>> https://github.com/openjdk/jdk/blob/fb8f2a0a929ebe7f65c69741712b89bbb403ade9/src/hotspot/share/classfile/altHashing.cpp#L32-L43
>
> The header file contains more claims https://github.com/veorq/SipHash/blob/master/halfsiphash.h

That header only contains a single function declaration for an entry point into the implementation.
HotSpot doesn't use that function, and doesn't have anything with a corresponding signature.  So it's
not in any way derived from that header.  The HotSpot code is derived from the .c file only, so that's
the license we should be referencing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18455#discussion_r1538202785

From duke at openjdk.org  Mon Mar 25 20:43:27 2024
From: duke at openjdk.org (Bernd)
Date: Mon, 25 Mar 2024 20:43:27 GMT
Subject: RFR: 8328812: Update and move siphash license
In-Reply-To: <2zN0sRhgR3Q7CtlruyOXYR3BN7VbOb6mGz55CWAonqM=.d7e02724-fa9f-4440-8c46-1fc473327c5c@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
 <Nc-eP-b6MGpTLHJuTR4H5N_5lC-TJG-xtdpnHIkT7pQ=.cb26ec2e-1d4e-4c4e-b8ef-db0bb219703c@github.com>
 <dT9cJed-6fM1rnTfHzyz0m319lZWx5mvCPIvabkTSEE=.91496bdf-734a-4779-a142-24fe2378529f@github.com>
 <WtpNA_q8MuE7HDZe_ub1ZKHY4uJ00xapVW2Y9bBQqJM=.aa3fe25d-f2a5-466c-a7a3-ead1e1ab0392@github.com>
 <2zN0sRhgR3Q7CtlruyOXYR3BN7VbOb6mGz55CWAonqM=.d7e02724-fa9f-4440-8c46-1fc473327c5c@github.com>
Message-ID: <CBEEUV2VwBFcdNsgSDPoFuVf4lDbAWbYWPGNZ6u6AeA=.ff1b0f69-9afc-4dc6-b232-8ec7511d26cf@github.com>

On Mon, 25 Mar 2024 20:34:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> The header file contains more claims https://github.com/veorq/SipHash/blob/master/halfsiphash.h
>
> That header only contains a single function declaration for an entry point into the implementation.
> HotSpot doesn't use that function, and doesn't have anything with a corresponding signature.  So it's
> not in any way derived from that header.  The HotSpot code is derived from the .c file only, so that's
> the license we should be referencing.

The problem is that the project is a joined work and has multiple variants of copyrights (see the readme). I don?t think it?s on the safe side to pick a single (non recent) copyright - especially if you change attribution after the fact. But that?s just me

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18455#discussion_r1538209271

From openjdk.ruwen.reddig at mailbox.org  Mon Mar 25 20:50:26 2024
From: openjdk.ruwen.reddig at mailbox.org (openjdk.ruwen.reddig at mailbox.org)
Date: Mon, 25 Mar 2024 21:50:26 +0100 (CET)
Subject: Overload window methods in Gatherers with step size
Message-ID: <1631445894.203837.1711399826471@office.mailbox.org>

Hello,

thanks for the amazing presentations during the Java 22 release stream.

I highly appreciated the new JEP 461 (https://openjdk.org/jeps/461), especially the windowing functions windowFixed and windowSliding.
I would like to propose to overload both methods, so they accept the step size as an additional parameter:

- windowFixed(int windowSize, int stepSize)
- windowSliding(int windowSize, int stepSize)

This would make the existing functionality more flexible without introducing much additional concepts to learn/understand.

That being said, I read https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117718.html and agree that the initial set of functions should be kept small. So looking forward how more experienced developers are gauging the trade-offs.
Best reagards
Ruwen Reddig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240325/e9ac5de4/attachment.htm>

From jwilhelm at openjdk.org  Mon Mar 25 22:25:30 2024
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 25 Mar 2024 22:25:30 GMT
Subject: RFR: 8328812: Update and move siphash license
In-Reply-To: <CBEEUV2VwBFcdNsgSDPoFuVf4lDbAWbYWPGNZ6u6AeA=.ff1b0f69-9afc-4dc6-b232-8ec7511d26cf@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
 <Nc-eP-b6MGpTLHJuTR4H5N_5lC-TJG-xtdpnHIkT7pQ=.cb26ec2e-1d4e-4c4e-b8ef-db0bb219703c@github.com>
 <dT9cJed-6fM1rnTfHzyz0m319lZWx5mvCPIvabkTSEE=.91496bdf-734a-4779-a142-24fe2378529f@github.com>
 <WtpNA_q8MuE7HDZe_ub1ZKHY4uJ00xapVW2Y9bBQqJM=.aa3fe25d-f2a5-466c-a7a3-ead1e1ab0392@github.com>
 <2zN0sRhgR3Q7CtlruyOXYR3BN7VbOb6mGz55CWAonqM=.d7e02724-fa9f-4440-8c46-1fc473327c5c@github.com>
 <CBEEUV2VwBFcdNsgSDPoFuVf4lDbAWbYWPGNZ6u6AeA=.ff1b0f69-9afc-4dc6-b232-8ec7511d26cf@github.com>
Message-ID: <lyFE8Fff5dRs-gacDUdpjnfptVWj3IjGJgYPQVu1jwA=.204689b5-f7d3-4b72-8985-7aec74c6f5a8@github.com>

On Mon, 25 Mar 2024 20:40:50 GMT, Bernd <duke at openjdk.org> wrote:

>> That header only contains a single function declaration for an entry point into the implementation.
>> HotSpot doesn't use that function, and doesn't have anything with a corresponding signature.  So it's
>> not in any way derived from that header.  The HotSpot code is derived from the .c file only, so that's
>> the license we should be referencing.
>
> The problem is that the project is a joined work and has multiple variants of copyrights (see the readme). I don?t think it?s on the safe side to pick a single (non recent) copyright - especially if you change attribution after the fact. But that?s just me. This is especially a problem because the file does NOT contain a dual license claim - the claim is in the readme with this text:
> 
>> Intellectual property
> 
>> This code is copyright (c) 2014-2023 Jean-Philippe Aumasson, Daniel J. Bernstein. It is dual-licensed [CC0](https://github.com/veorq/SipHash/blob/master/LICENCE_CC0) and [MIT](https://github.com/veorq/SipHash/blob/master/LICENSE_MIT).

Copyright and license are two different things. The project has a dual license which we attribute. Code in different files can have different copyrights (as is the case in e.g. our own OpenJDK code). We copied the copyright from the file that we looked at. If you feel it has the wrong copyright please contact the authors of that file and ask them to update their code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18455#discussion_r1538303713

From duke at openjdk.org  Mon Mar 25 23:42:33 2024
From: duke at openjdk.org (Bernd)
Date: Mon, 25 Mar 2024 23:42:33 GMT
Subject: RFR: 8328812: Update and move siphash license
In-Reply-To: <lyFE8Fff5dRs-gacDUdpjnfptVWj3IjGJgYPQVu1jwA=.204689b5-f7d3-4b72-8985-7aec74c6f5a8@github.com>
References: <Lq4Dw9EkYfI2paoEQ6LJGY2QZ0wbD-VO1JXrhUgbBjI=.2fac1555-bc2e-491a-8036-ffcab20f5f0c@github.com>
 <Nc-eP-b6MGpTLHJuTR4H5N_5lC-TJG-xtdpnHIkT7pQ=.cb26ec2e-1d4e-4c4e-b8ef-db0bb219703c@github.com>
 <dT9cJed-6fM1rnTfHzyz0m319lZWx5mvCPIvabkTSEE=.91496bdf-734a-4779-a142-24fe2378529f@github.com>
 <WtpNA_q8MuE7HDZe_ub1ZKHY4uJ00xapVW2Y9bBQqJM=.aa3fe25d-f2a5-466c-a7a3-ead1e1ab0392@github.com>
 <2zN0sRhgR3Q7CtlruyOXYR3BN7VbOb6mGz55CWAonqM=.d7e02724-fa9f-4440-8c46-1fc473327c5c@github.com>
 <CBEEUV2VwBFcdNsgSDPoFuVf4lDbAWbYWPGNZ6u6AeA=.ff1b0f69-9afc-4dc6-b232-8ec7511d26cf@github.com>
 <lyFE8Fff5dRs-gacDUdpjnfptVWj3IjGJgYPQVu1jwA=.204689b5-f7d3-4b72-8985-7aec74c6f5a8@github.com>
Message-ID: <nc9J1h1SyYkmiNv-rww-sw5o_CEslikCFB_TTeElPfM=.eb643356-a11c-4102-a417-a8c333a7ed6b@github.com>

On Mon, 25 Mar 2024 22:23:03 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> The problem is that the project is a joined work and has multiple variants of copyrights (see the readme). I don?t think it?s on the safe side to pick a single (non recent) copyright - especially if you change attribution after the fact. But that?s just me. This is especially a problem because the file does NOT contain a dual license claim - the claim is in the readme with this text:
>> 
>>> Intellectual property
>> 
>>> This code is copyright (c) 2014-2023 Jean-Philippe Aumasson, Daniel J. Bernstein. It is dual-licensed [CC0](https://github.com/veorq/SipHash/blob/master/LICENCE_CC0) and [MIT](https://github.com/veorq/SipHash/blob/master/LICENSE_MIT).
>
> Copyright and license are two different things. The project has a dual license which we attribute. Code in different files can have different copyrights (as is the case in e.g. our own OpenJDK code). We copied the copyright from the file that we looked at. If you feel it has the wrong copyright please contact the authors of that file and ask them to update their code.

The file has a different license also. Either you use the joined copyright and dual license or only the single copyright and cc0 license which is in the file. But I asked DJB to clarify.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18455#discussion_r1538369236

From davidalayachew at gmail.com  Tue Mar 26 02:37:57 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 25 Mar 2024 22:37:57 -0400
Subject: Overload window methods in Gatherers with step size
In-Reply-To: <1631445894.203837.1711399826471@office.mailbox.org>
References: <1631445894.203837.1711399826471@office.mailbox.org>
Message-ID: <CAA9v-_N_t-dB-M1D2R9Gzup63T6LuRkjjkLQgOjak9JZf9NEwQ@mail.gmail.com>

I actually plan to follow through on that email. I just can't right now
because of work emergencies. Literally as soon as those calm down, top of
my list is to give Viktor the lost of code examples where I am using the
windowBy Gatherer he gave me.

On Mon, Mar 25, 2024, 6:24?PM <openjdk.ruwen.reddig at mailbox.org> wrote:

> Hello,
>
> thanks for the amazing presentations during the Java 22 release stream.
>
> I highly appreciated the new JEP 461 (https://openjdk.org/jeps/461),
> especially the windowing functions windowFixed and windowSliding.
> I would like to propose to overload both methods, so they accept the step
> size as an additional parameter:
>
> - windowFixed(int windowSize, int stepSize)
> - windowSliding(int windowSize, int stepSize)
>
> This would make the existing functionality more flexible without
> introducing much additional concepts to learn/understand.
>
> That being said, I read
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117718.html and
> agree that the initial set of functions should be kept small. So looking
> forward how more experienced developers are gauging the trade-offs.
> Best reagards
> Ruwen Reddig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240325/e9627797/attachment.htm>

From aturbanov at openjdk.org  Tue Mar 26 07:30:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 26 Mar 2024 07:30:23 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dnzll7uMjmAmGD_8ZaudJH1Kw90Dqq-j3TEiABaWSu4=.560e44c6-d426-4799-9fe6-fc04b338ef38@github.com>

On Thu, 21 Mar 2024 17:13:46 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:
> 
>   Fixed potential NPE issues.

test/jdk/java/nio/channels/unixdomain/Bind.java line 162:

> 160:         // address with space should work
> 161:         checkNormal(() -> {
> 162:             UnixDomainSocketAddress usa =  UnixDomainSocketAddress.of("with space");

Suggestion:

            UnixDomainSocketAddress usa = UnixDomainSocketAddress.of("with space");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1538701870

From mbaesken at openjdk.org  Tue Mar 26 09:26:32 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 09:26:32 GMT
Subject: RFR: JDK-8329074: AIX build fails after JDK-8328824
Message-ID: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>

After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the AIX build into this failure :

/opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
gmake[3]: *** [lib/CoreLibraries.gmk:194: /openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o] Error 2
gmake[3]: *** Waiting for unfinished jobs....

Looks like an addprefix usage is wrong, a '$' is missing.

-------------

Commit messages:
 - JDK-8329074

Changes: https://git.openjdk.org/jdk/pull/18484/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18484&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329074
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18484/head:pull/18484

PR: https://git.openjdk.org/jdk/pull/18484

From clanger at openjdk.org  Tue Mar 26 09:38:22 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 26 Mar 2024 09:38:22 GMT
Subject: RFR: JDK-8329074: AIX build fails after JDK-8328824
In-Reply-To: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
References: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
Message-ID: <eLaC6iMM0y9lTzO0CDDXu7cDFlXFBxrGBaXJJhohmVQ=.2d341820-e81e-4c6f-9c45-4b17f5a7915e@github.com>

On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the AIX build into this failure :
> 
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194: /openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o] Error 2
> gmake[3]: *** Waiting for unfinished jobs....
> 
> Looks like an addprefix usage is wrong, a '$' is missing.

Obvious typo that broke the AIX build. Thanks for fixing.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18484#pullrequestreview-1959820693

From sroy at openjdk.org  Tue Mar 26 09:49:27 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 26 Mar 2024 09:49:27 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <Vgr72T5zlpw_6nsSVjs4FghRpC1dZcjpR2HZwjkiQQM=.ac199a36-b8ea-4838-8925-d0eb1158cbdd@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <HgLsgTS3mdrdd9G2ZVxDcunYz0evzm4D2AUL2ZS9FdA=.969a9e5f-2506-4cba-85ba-ba1c64a51526@github.com>
 <g4Ve0apXBwEEmXxf2ZnTMW22aSU2mq7qr1c8xIRIZvQ=.54d1ec6e-31e5-4e9e-91cc-d4a8f752ecc5@github.com>
 <Vgr72T5zlpw_6nsSVjs4FghRpC1dZcjpR2HZwjkiQQM=.ac199a36-b8ea-4838-8925-d0eb1158cbdd@github.com>
Message-ID: <ua4W_DqvkDrf53vSrxMyLb28W9Ail5bYGjv7ob_G8II=.c97d1187-5eb3-4254-a293-ec2bdefc01c4@github.com>

On Mon, 25 Mar 2024 20:02:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> dcstartup fails because it fails to load an agent library specified via `-agentlib:am_ibm_16` that was fixed by JDK-8320005. I assume that's what you referred to "J9 had for a long time". This does not use `System::loadLibrary`. It's unclear if any JNI native library is changed to load from an archive object. Any customer reporting this issue?

So when this was reported in J9, the fix was made at the classloader level. Thats when i replicated this change to OpenJDK. 
But on further debug i saw that in this case, directly the hotspot code was called and the classloader was not in picture. 

I need to confirm about customer issue again. I will do that in a few days. 
But is there any particular reason why we don't support loading shared archives via loadLibrary() ? It can be an insurance against future issues too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2019965401

From goetz at openjdk.org  Tue Mar 26 10:03:26 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Tue, 26 Mar 2024 10:03:26 GMT
Subject: RFR: JDK-8329074: AIX build fails after JDK-8328824
In-Reply-To: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
References: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
Message-ID: <8z1E9WZ_QGGrouf1Lqz_ZRlB2bVMwyWF8YejyLrueHQ=.75da96fd-69f4-4d52-ad56-e28d2d19b561@github.com>

On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the AIX build into this failure :
> 
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194: /openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o] Error 2
> gmake[3]: *** Waiting for unfinished jobs....
> 
> Looks like an addprefix usage is wrong, a '$' is missing.

LGTM

-------------

Marked as reviewed by goetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18484#pullrequestreview-1959873067

From mbaesken at openjdk.org  Tue Mar 26 10:03:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 10:03:26 GMT
Subject: RFR: JDK-8329074: AIX build fails after JDK-8328824
In-Reply-To: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
References: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
Message-ID: <bjVAvwa6gIqUGN2-UGvUCkM-refMfO2KmLbxHMPQ1Q8=.d5d99df7-bd58-4cb6-8e2c-e61490ebb6bb@github.com>

On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the AIX build into this failure :
> 
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194: /openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o] Error 2
> gmake[3]: *** Waiting for unfinished jobs....
> 
> Looks like an addprefix usage is wrong, a '$' is missing.

windows aarch64 failure is unrelated, fails with some download
[build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /d/a/jdk/jdk/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
Error: sh][ERROR] wget exited with exit code 4

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18484#issuecomment-2019994055
PR Comment: https://git.openjdk.org/jdk/pull/18484#issuecomment-2019997165

From mbaesken at openjdk.org  Tue Mar 26 10:03:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 10:03:26 GMT
Subject: Integrated: JDK-8329074: AIX build fails after JDK-8328824
In-Reply-To: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
References: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
Message-ID: <niBylIJuOTesIhDxIHcxfanThIXlxcun1qDautoYyJs=.234eec14-429b-4685-a1be-33e2316577e5@github.com>

On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the AIX build into this failure :
> 
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194: /openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o] Error 2
> gmake[3]: *** Waiting for unfinished jobs....
> 
> Looks like an addprefix usage is wrong, a '$' is missing.

This pull request has now been integrated.

Changeset: b9c76ded
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9c76dedf4aa2248a5e561a535c9e3e181f7836a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8329074: AIX build fails after JDK-8328824

Reviewed-by: clanger, goetz

-------------

PR: https://git.openjdk.org/jdk/pull/18484

From redestad at openjdk.org  Tue Mar 26 11:20:31 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 26 Mar 2024 11:20:31 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v16]
In-Reply-To: <x9SnGx9TpR0wlNOAtbgSR5cK5yQO7RywpQvCXe7fzwE=.72d80ce0-23c3-4036-9eae-641c9cf3d530@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <x9SnGx9TpR0wlNOAtbgSR5cK5yQO7RywpQvCXe7fzwE=.72d80ce0-23c3-4036-9eae-641c9cf3d530@github.com>
Message-ID: <6OG2QsGKo-Yu6pG_S85fkVpsWfQi40e2Cuw4g38lM6c=.8c153eb9-51d6-4216-a7f5-4a643b27bd52@github.com>

On Wed, 20 Mar 2024 22:56:38 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 incrementally with one additional commit since the last revision:
> 
>   use while instead for

I agree that a public `BigDecimal(CharSequence, ...)` constructor (or set of constructors) should be considered out of scope here. I think the bar is higher on such a change, too, but I'm not ruling out that such an addition would make the cut.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2020156038

From duke at openjdk.org  Tue Mar 26 11:50:25 2024
From: duke at openjdk.org (Elif Aslan)
Date: Tue, 26 Mar 2024 11:50:25 GMT
Subject: Integrated: 8327998: Enable
 java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac
In-Reply-To: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>
References: <ePYgMLShxu2inE8uKJ1WvDh_IBIqDV1tcLrkmyJpzkw=.94abc390-cd32-4418-80e8-8d92a5ee7b57@github.com>
Message-ID: <_qi91Jr6kjMgFU_U4ouF27HlgsWwB7305eJnOjENjFM=.7e49e3ef-67ab-47c4-849e-fb8c5620bed9@github.com>

On Tue, 12 Mar 2024 21:52:31 GMT, Elif Aslan <duke at openjdk.org> wrote:

> This change enables to run JspawnhelperProtocol.java on MacOS.
> 
> In addition to GHA , the test has been run on macos and linux.
> 
> 
> Test report is stored in build/macosx-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'macosx-x86_64-server-fastdebug'
> 
> 
> 
> 
> 
> Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_ProcessBuilder_JspawnhelperProtocol_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> Stopping javac server
> [ec2-user at ip-172-16-0-10 jdk]$ make test CONF=linux-x86_64-server-fastdebug TEST=test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java

This pull request has now been integrated.

Changeset: cc1800fa
Author:    Elif Aslan <elifasln at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc1800fa4de3c1369efd46f5ca967ea82763f5d5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8327998: Enable java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac

Reviewed-by: gli, shade, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/18253

From michaelm at openjdk.org  Tue Mar 26 15:56:23 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 26 Mar 2024 15:56:23 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dDrW4l3mQ8774vjN_VH6nQ94gMJSKK5xcEzMpxy_EPU=.8d557a74-6ad1-44ae-ba35-cab23db68f39@github.com>

On Thu, 21 Mar 2024 17:13:46 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:
> 
>   Fixed potential NPE issues.

unixdomain NIO test changes look fine to me

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1960889711

From dfenacci at openjdk.org  Tue Mar 26 16:02:23 2024
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 26 Mar 2024 16:02:23 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v3]
In-Reply-To: <zMKT2cOKMHo76IFkz5uh8NOa07lp1NhleOJFKDi_v8c=.b5605b07-077e-4cf8-9014-f9a169b0af46@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <zMKT2cOKMHo76IFkz5uh8NOa07lp1NhleOJFKDi_v8c=.b5605b07-077e-4cf8-9014-f9a169b0af46@github.com>
Message-ID: <IEbiW8OAUyzLJ9NWnSZEI_iOYBfJrsIy-wc8KF-R92I=.72f6c6e6-af4f-495e-8612-f1bb6318ec67@github.com>

On Tue, 19 Mar 2024 21:09:31 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.

`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.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18226#pullrequestreview-1960906919

From serge.chernyshev at bell-sw.com  Tue Mar 26 16:51:53 2024
From: serge.chernyshev at bell-sw.com (Sergey Chernyshev)
Date: Tue, 26 Mar 2024 17:51:53 +0100
Subject: InetAddress API extension proposal
Message-ID: <b25b9ced-3d1e-4067-bb91-77bd17844611@bell-sw.com>

Hello Core Libs Dev team,

I would like to propose a PR to extend the InetAddress API in JDK 23, 
namely to provide interface to constructing InetAddress objects from 
literal addresses in POSIX/BSD form (please see the discussion [1]), to 
the Apps that need to mimic the behavior of POSIX network APIs 
(|inet_addr|) used by standard network utilities such as 
netcat/curl/wget and the majority of web browsers. At present time, 
there's no way to construct |InetAddress| object from such literal 
addresses because the new API |InetAddress.ofLiteral()| and 
|Inet4Address.ofLiteral()| will consume an address and successfully 
parse it as decimal, ignoring the octal prefix. Hence, the resulting 
object will point to a different IP address than it is expected to point to.

Historically |InetAddress.getByName()/.getAllByName()| were the only way 
to convert a literal address into an InetAddress object. 
|getAllByName()| API relies on POSIX |getaddrinfo| / |inet_aton| which 
parses IP address segments with |strtoul| (accepts octal and hexadecimal 
bases). The fallback to |getaddrinfo| is undesirable as it may end up 
with network queries (blocking mode), if |inet_aton| rejects the input 
literal address. The Java standard explicitly says that

|"If a literal IP address is supplied, only the validity of the address 
format is checked." |

Aleksei Efimov contributed JDK-8272215 [2] that adds new factory methods 
|.ofLiteral()| to |InetAddress| classes. Although the new API is not 
affected by the |getaddrinfo| fallback issue, it is not sufficient for 
an app that wants to mimic the behavior of BSD/POSIX network utlilities.

It is suggested to add a new factory method such as |.ofPosixLiteral()| 
to |Inet4Address| class to fill this gap. This won't introduce ambiguity 
into the API and won't break the long standing behavior. I am not sure 
if the superclass |InetAddress| needs the new method too because the 
change is only related to IPv4 addressing, also the chance that client 
code will call the wrong factory method is reduced when it knows exactly 
what it does.

Please share your thoughts on whether such a change might be desirable 
in JDK 23.

Thank you for your help!

Best regards
Sergey Chernyshev

[1] https://bugs.openjdk.org/browse/JDK-8315767
[2] https://bugs.openjdk.org/browse/JDK-8272215
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240326/4aedad99/attachment.htm>

From cushon at openjdk.org  Tue Mar 26 16:57:39 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 26 Mar 2024 16:57:39 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of the
 manifest is >4GB
Message-ID: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@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'.

-------------

Commit messages:
 - Improvements
 - 8328995: launcher can't open jar files where the offset of the manifest is >4GB

Changes: https://git.openjdk.org/jdk/pull/18479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328995
  Stats: 223 lines in 3 files changed: 215 ins; 3 del; 5 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 bhuang at openjdk.org  Tue Mar 26 18:18:39 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 26 Mar 2024 18:18:39 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
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: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@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:

  Update test/jdk/java/nio/channels/unixdomain/Bind.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/2517f756..0f4130a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 ecki at zusammenkunft.net  Tue Mar 26 19:10:31 2024
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 26 Mar 2024 20:10:31 +0100 (CET)
Subject: InetAddress API extension proposal
In-Reply-To: <b25b9ced-3d1e-4067-bb91-77bd17844611@bell-sw.com>
References: <b25b9ced-3d1e-4067-bb91-77bd17844611@bell-sw.com>
Message-ID: <20240326191031.A4185661192@dd33810.kasserver.com>

Would be helpful to point to the posix standard/requirement which mandates this. Do you mean a single Unix api description or a posix command spec? I don?t think I know of any such things.

Wikipedia claims A POSIX-conforming variant of inet_aton, the inet_pton() function, supports only the four-decimal variant of IP addresses.[10]

And can you also justify a bit more who needs that octal compatibility? Over the years a lot of confusion (zero padding) and security issues (csrf filters not catching all formats) have been found, so it?s really not a good idea to implement it for no good reason. I think this was also the conclusion for the ofLiteral() api. 

Sergey Chernyshev wrote on 26. Mar 2024 17:51 (GMT +01:00):

> Hello Core Libs Dev team,
> 
> I would like to propose a PR to extend the InetAddress API in JDK 23, 

From bchristi at openjdk.org  Tue Mar 26 20:22:48 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 26 Mar 2024 20:22:48 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v17]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <n9qhzVS_iDQD48xpjKqsVYt2yp9_7H8VnRwcjM4L5dI=.acef8759-513b-4efb-8b2e-fd0237fdd5e1@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 section about 'encapsulating' reachabilityFence()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/15ae0f25..54a44414

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=15-16

  Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 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 jlu at openjdk.org  Tue Mar 26 20:53:31 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 20:53:31 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern tests
 under en_US locale
Message-ID: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>

Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.

There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.

As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

-------------

Commit messages:
 - run in othervm
 - init

Changes: https://git.openjdk.org/jdk/pull/18498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329118
  Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18498/head:pull/18498

PR: https://git.openjdk.org/jdk/pull/18498

From jlu at openjdk.org  Tue Mar 26 20:55:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 20:55:35 GMT
Subject: RFR: JDK-8327875: ChoiceFormat should advise throwing
 UnsupportedOperationException for unused methods
Message-ID: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>

Please review this PR which advises ChoiceFormat subclasses throw `UnsupportedOperationException` for unused inherited methods.

The CSR covers the proposed wording, and the reasons as to why this is a specification and not an implementation update. In addition, the `api/implNote` tags have been moved to the bottom of the class description, as they are no longer only relevant to the pattern section, (where they were previously located).

-------------

Commit messages:
 - remove contract wording
 - move and clarify api/impl note
 - init

Changes: https://git.openjdk.org/jdk/pull/18499/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18499&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327875
  Stats: 25 lines in 1 file changed: 15 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18499/head:pull/18499

PR: https://git.openjdk.org/jdk/pull/18499

From mdoerr at openjdk.org  Tue Mar 26 21:05:25 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 26 Mar 2024 21:05:25 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
Message-ID: <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>

On Mon, 25 Mar 2024 09:46:50 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 four additional commits since the last revision:
> 
>  - coding style
>  - set false
>  - restore fil
>  -  remove member check code

I think your new version makes sense in general. MacOS also uses `mapAlternativeName` to support different endings. And your current version still allows using a member for `System.load` which is helpful.

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved.

Copyright outdated.

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 43:

> 41:       static boolean loadLibraryOnlyIfPresent() {
> 42:           return false;
> 43:       }

Indentation is odd.

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 61:

> 59:             long openBracketCount = name.chars().filter(ch -> ch == '(').count();
> 60:             long closeBracketCount = name.chars().filter(ch -> ch == ')').count();
> 61:             //Checking if the format is correct.

Space after //.

src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 68:

> 66:             int dotIndex = name.lastIndexOf('.');
> 67:             String memberName = name.substring(openBracketIndex,dotIndex);
> 68:             //Reconstruct <libname>.so(<member_name>) as <libname>.a(<member_name>)

Do we really need to support libname.so(member)? Isn't it always libname.a(member)?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17945#pullrequestreview-1961722255
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540103849
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540104059
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540104421
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540105840

From mchung at openjdk.org  Tue Mar 26 21:13:24 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 26 Mar 2024 21:13:24 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
Message-ID: <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>

On Tue, 26 Mar 2024 20:59:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - coding style
>>  - set false
>>  - restore fil
>>  -  remove member check code
>
> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 68:
> 
>> 66:             int dotIndex = name.lastIndexOf('.');
>> 67:             String memberName = name.substring(openBracketIndex,dotIndex);
>> 68:             //Reconstruct <libname>.so(<member_name>) as <libname>.a(<member_name>)
> 
> Do we really need to support libname.so(member)? Isn't it always libname.a(member)?

I think `mapAlternativeName` isn't needed at all.   If `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")` should be passed to dlopen directly.   @suchismith1993 can verify it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540117924

From mchung at openjdk.org  Tue Mar 26 21:19:24 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 26 Mar 2024 21:19:24 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
Message-ID: <Mp9oIgdf7duMX4kpEzsr2IHgFquaO0t2MXHeimzzwg8=.f6abbbf9-3e2c-47db-ae7e-021bb729a633@github.com>

On Mon, 25 Mar 2024 09:46:50 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 four additional commits since the last revision:
> 
>  - coding style
>  - set false
>  - restore fil
>  -  remove member check code

I think just changing `loadLibraryOnlyIfPresent` to return false should be sufficient to make `System.loadLibrary("foo")` loading from "libfoo.a" and `System.load("/usr/lib/libfoo.a(libfoo.so)")` to work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2021488820

From naoto at openjdk.org  Tue Mar 26 21:56:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 21:56:22 GMT
Subject: RFR: JDK-8327875: ChoiceFormat should advise throwing
 UnsupportedOperationException for unused methods
In-Reply-To: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>
References: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>
Message-ID: <m4o61XoB3mrrZRABF3wohKzCv2NrhTJX8lWneYvkn6s=.e089bd72-d788-49fd-a657-fe3b1cac671f@github.com>

On Tue, 26 Mar 2024 20:50:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which advises ChoiceFormat subclasses throw `UnsupportedOperationException` for unused inherited methods.
> 
> The CSR covers the proposed wording, and the reasons as to why this is a specification and not an implementation update. In addition, the `api/implNote` tags have been moved to the bottom of the class description, as they are no longer only relevant to the pattern section, (where they were previously located).

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18499#pullrequestreview-1961808439

From naoto at openjdk.org  Tue Mar 26 22:00:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 22:00:25 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>

On Tue, 26 Mar 2024 20:49:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 29:

> 27:  * @summary Test MessageFormatPattern ability to recognize and produce
> 28:  *          appropriate FormatType and FormatStyle for CompactNumberFormat.
> 29:  * @run junit/othervm -Duser.language=en -Duser.country=US CompactSubFormats

I would instantiate MessageFormat explicitly with the `US` locale (using the 2-arg constructor), instead of implicitly specifying it with the system property.

test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 43:

> 41: import static org.junit.jupiter.api.Assertions.assertEquals;
> 42: 
> 43: // This tests expects an en_US locale, as this locale provides distinct instances

Nit: typo tests -> test

test/jdk/java/text/Format/MessageFormat/ListSubFormats.java line 31:

> 29:  *          STANDARD, OR, and UNIT types are supported as built-in patterns for
> 30:  *          MessageFormat. All types use the FULL style.
> 31:  * @run junit/othervm -Duser.language=en -Duser.country=US ListSubFormats

Same as above

test/jdk/java/text/Format/MessageFormat/ListSubFormats.java line 42:

> 40: import static org.junit.jupiter.api.Assertions.assertThrows;
> 41: 
> 42: // This tests expects an en_US locale, as this locale provides distinct instances

ditto

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540157210
PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540157737
PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540157897
PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540157979

From Alan.Bateman at oracle.com  Tue Mar 26 22:05:46 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 27 Mar 2024 07:05:46 +0900
Subject: InetAddress API extension proposal
In-Reply-To: <b25b9ced-3d1e-4067-bb91-77bd17844611@bell-sw.com>
References: <b25b9ced-3d1e-4067-bb91-77bd17844611@bell-sw.com>
Message-ID: <6807e24e-1cea-460a-8c8a-919db281b730@oracle.com>

On 27/03/2024 01:51, Sergey Chernyshev wrote:
>
> Hello Core Libs Dev team,
>
> I would like to propose a PR to extend the InetAddress API in JDK 23, 
> namely to provide interface to constructing InetAddress objects from 
> literal addresses in POSIX/BSD form (please see the discussion [1]), 
> to the Apps that need to mimic the behavior of POSIX network APIs 
> (|inet_addr|) used by standard network utilities such as 
> netcat/curl/wget and the majority of web browsers. At present time, 
> there's no way to construct |InetAddress| object from such literal 
> addresses because the new API |InetAddress.ofLiteral()| and 
> |Inet4Address.ofLiteral()| will consume an address and successfully 
> parse it as decimal, ignoring the octal prefix. Hence, the resulting 
> object will point to a different IP address than it is expected to 
> point to.
>
Better to start the discussion on net-dev as that is where the 
InetAddress API is maintained. Make sure to go through the recent 
discussions there on ofLiteral(String), particularly security concerns 
which is partly why the method is not specified to allow octal values.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240327/da8c69e4/attachment.htm>

From jlu at openjdk.org  Tue Mar 26 22:26:49 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 22:26:49 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v2]
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <K4JdqqjPrQ2u33__VOHzYQt2P0aZfPnk4kNla7tVJzo=.42f1524a-67c8-44ae-8b1c-c0f576561588@github.com>

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  implement suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18498/files
  - new: https://git.openjdk.org/jdk/pull/18498/files/1ea2cd4e..33dc70ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18498&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18498&range=00-01

  Stats: 26 lines in 2 files changed: 9 ins; 4 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18498/head:pull/18498

PR: https://git.openjdk.org/jdk/pull/18498

From jlu at openjdk.org  Tue Mar 26 22:26:49 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 22:26:49 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v2]
In-Reply-To: <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>
Message-ID: <W54BKumgdPRjShLWOLSqvViJrHtYoe0kfXRNZSZ2n78=.c0cbf6a1-d104-4eba-94a8-147800160f3e@github.com>

On Tue, 26 Mar 2024 21:56:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   implement suggestions
>
> test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 29:
> 
>> 27:  * @summary Test MessageFormatPattern ability to recognize and produce
>> 28:  *          appropriate FormatType and FormatStyle for CompactNumberFormat.
>> 29:  * @run junit/othervm -Duser.language=en -Duser.country=US CompactSubFormats
> 
> I would instantiate MessageFormat explicitly with the `US` locale (using the 2-arg constructor), instead of implicitly specifying it with the system property.

Thanks for the review and suggestions, PR should be updated. (I presume you meant the 2-arg Locale.of() method, not the constructor)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540182774

From naoto at openjdk.org  Tue Mar 26 22:34:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 22:34:23 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v2]
In-Reply-To: <W54BKumgdPRjShLWOLSqvViJrHtYoe0kfXRNZSZ2n78=.c0cbf6a1-d104-4eba-94a8-147800160f3e@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>
 <W54BKumgdPRjShLWOLSqvViJrHtYoe0kfXRNZSZ2n78=.c0cbf6a1-d104-4eba-94a8-147800160f3e@github.com>
Message-ID: <UmF-W2RBFVrF51fR36XpkyXXaf0EgXkIyzqWZL86EOo=.2d5fdc2e-7ad0-47ce-b44e-d9be84a18ec2@github.com>

On Tue, 26 Mar 2024 22:23:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 29:
>> 
>>> 27:  * @summary Test MessageFormatPattern ability to recognize and produce
>>> 28:  *          appropriate FormatType and FormatStyle for CompactNumberFormat.
>>> 29:  * @run junit/othervm -Duser.language=en -Duser.country=US CompactSubFormats
>> 
>> I would instantiate MessageFormat explicitly with the `US` locale (using the 2-arg constructor), instead of implicitly specifying it with the system property.
>
> Thanks for the review and suggestions, PR should be updated. (I presume you meant the 2-arg Locale.of() method, not the constructor)

I meant using `new MessageFormat(String, Locale.US)`, instead of `new MessageFormat(String)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540192178

From jlu at openjdk.org  Tue Mar 26 23:02:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 23:02:34 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v3]
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <0ExY69tWdqSeR8NMpuQ8Ep8MnyFJMqL2AEKQnHrQeSY=.82568e42-e8ee-4c7b-b2db-38cedff0e85a@github.com>

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  correct update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18498/files
  - new: https://git.openjdk.org/jdk/pull/18498/files/33dc70ab..bf99aa92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18498&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18498&range=01-02

  Stats: 21 lines in 2 files changed: 1 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/18498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18498/head:pull/18498

PR: https://git.openjdk.org/jdk/pull/18498

From jlu at openjdk.org  Tue Mar 26 23:02:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 23:02:34 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v3]
In-Reply-To: <UmF-W2RBFVrF51fR36XpkyXXaf0EgXkIyzqWZL86EOo=.2d5fdc2e-7ad0-47ce-b44e-d9be84a18ec2@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>
 <W54BKumgdPRjShLWOLSqvViJrHtYoe0kfXRNZSZ2n78=.c0cbf6a1-d104-4eba-94a8-147800160f3e@github.com>
 <UmF-W2RBFVrF51fR36XpkyXXaf0EgXkIyzqWZL86EOo=.2d5fdc2e-7ad0-47ce-b44e-d9be84a18ec2@github.com>
Message-ID: <L71qIrJHyr73mDlLV3Fml50yZJti4h3brSYcF7juzgw=.07dd725d-1ec6-4e6e-bb76-9855d42caf4d@github.com>

On Tue, 26 Mar 2024 22:32:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Thanks for the review and suggestions, PR should be updated. (I presume you meant the 2-arg Locale.of() method, not the constructor)
>
> I meant using `new MessageFormat(String, Locale.US)`, instead of `new MessageFormat(String)`.

Ah, gotchu. Updated with the two arg `MessageFormat` constructor, although I think it would have been fine previously as well just passing the locale in directly to the subformat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540210872

From naoto at openjdk.org  Tue Mar 26 23:12:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 23:12:21 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v3]
In-Reply-To: <0ExY69tWdqSeR8NMpuQ8Ep8MnyFJMqL2AEKQnHrQeSY=.82568e42-e8ee-4c7b-b2db-38cedff0e85a@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <0ExY69tWdqSeR8NMpuQ8Ep8MnyFJMqL2AEKQnHrQeSY=.82568e42-e8ee-4c7b-b2db-38cedff0e85a@github.com>
Message-ID: <QAb8yaJz4OiKGhD52j1jzg69XqEAZ7UDKq45xeYXIqE=.9e2a56f4-9023-48af-a191-d0eb26c26547@github.com>

On Tue, 26 Mar 2024 23:02:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
>> 
>> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
>> 
>> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct update

test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 47:

> 45:     // This test expects an en_US locale, as this locale provides distinct instances
> 46:     // for different styles.
> 47:     private static final Locale loc = Locale.of("en", "US");

No need to define this field. You can directly use the `Locale.US` constant in the constructor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540220164

From ihse at openjdk.org  Tue Mar 26 23:26:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 26 Mar 2024 23:26:24 GMT
Subject: RFR: JDK-8329074: AIX build fails after JDK-8328824
In-Reply-To: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
References: <kQJMvwrDNc1p49hs3p_H46L9v95DBnRnYfk2tL_spHM=.64b8b0ea-8324-4701-8303-a3d6f1d100b5@github.com>
Message-ID: <PeZNkCx0kOfL4av7d1SBm2PtCTjgCItf4H5bXFYgj68=.9f89616c-b93a-4f29-bc02-d3e8aaba5a68@github.com>

On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the AIX build into this failure :
> 
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194: /openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o] Error 2
> gmake[3]: *** Waiting for unfinished jobs....
> 
> Looks like an addprefix usage is wrong, a '$' is missing.

I apologize for missing this typo. :-( Thanks for fixing it for me, and so quickly!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18484#issuecomment-2021631327

From jlu at openjdk.org  Tue Mar 26 23:32:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 23:32:34 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v4]
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  drop loc field for US constant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18498/files
  - new: https://git.openjdk.org/jdk/pull/18498/files/bf99aa92..5e797fe4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18498&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18498&range=02-03

  Stats: 21 lines in 2 files changed: 4 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18498/head:pull/18498

PR: https://git.openjdk.org/jdk/pull/18498

From naoto at openjdk.org  Tue Mar 26 23:44:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 23:44:21 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v4]
In-Reply-To: <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>
Message-ID: <RqztHsFJs6juuGLsOyyhIjvEWhS4pMvaLRDPFMnuz-k=.83fc9ab4-0551-411f-a439-69cae3aababd@github.com>

On Tue, 26 Mar 2024 23:32:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
>> 
>> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
>> 
>> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop loc field for US constant

LGTM. Thanks for fixing it

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18498#pullrequestreview-1961949433

From smarks at openjdk.org  Wed Mar 27 02:06:30 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 27 Mar 2024 02:06:30 GMT
Subject: RFR: JDK-8323760 clarify specification of Map::putIfAbsent return
 value [v3]
In-Reply-To: <2MuoCDS5QNXFwMb8hrVZ7IS2Vomgm8Z8SQVyOWN2us4=.ac233527-0bba-41ea-929a-36955f05861b@github.com>
References: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>
 <2MuoCDS5QNXFwMb8hrVZ7IS2Vomgm8Z8SQVyOWN2us4=.ac233527-0bba-41ea-929a-36955f05861b@github.com>
Message-ID: <z8sbGwpgJyKu-lLAcbYuDPTxQbfyr_y7-PUlEItK8ws=.027b7726-ad92-4286-a821-cba4c357991b@github.com>

On Wed, 14 Feb 2024 20:46:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use new suggestion and remove original clarification

See CSR comments from Martin Buchholz:

https://bugs.openjdk.org/browse/JDK-8325811?focusedId=14659527&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14659527

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17438#issuecomment-2021785703

From jiangli at openjdk.org  Wed Mar 27 03:22:22 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 27 Mar 2024 03:22:22 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB
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: <9wbFYwittlKo6Dn_PmaTcPCXhQBgl9XM9H5X7lCoYRA=.59096284-3c2e-4ef8-94ec-ed9469d6c037@github.com>

On Mon, 25 Mar 2024 21:37:03 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'.

src/java.base/share/native/libjli/manifest_info.h line 59:

> 57: #define ZIP64_EXTID   1       // Extra field Zip64 header ID
> 58: 
> 59: #define ZIP64_EXTMAXLEN 36 // Maximum Zip64 extra field length

The fields described in APPNOTE-6.3.9.TXT 4.5.3 are total 32 bytes. Any other additional fields in the Zip64 extended information?


        Value      Size       Description
        -----      ----       -----------
(ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
        Size       2 bytes    Size of this "extra" block
        Original 
        Size       8 bytes    Original uncompressed file size
        Compressed
        Size       8 bytes    Size of compressed data
        Relative Header
        Offset     8 bytes    Offset of local header record
        Disk Start
        Number     4 bytes    Number of the disk on which
                              this file starts

src/java.base/share/native/libjli/manifest_info.h line 146:

> 144:  * Macros for getting Extensible Data Fields
> 145:  */
> 146: #define ZIPEXT_HDR(b) SH(b, 0)      /* Header ID */

How about naming the macros as ZIP64EXT_HDR and ZIP64EXT_SIZ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1540404585
PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1540405121

From sroy at openjdk.org  Wed Mar 27 07:59:23 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 27 Mar 2024 07:59:23 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
Message-ID: <PmTux1JW-6THqEE9Q4CFWT5JoNoD2sIuJ_KH6Vd_wTo=.08346b44-58ba-4123-9625-6c3d59bccb74@github.com>

On Tue, 26 Mar 2024 21:11:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 68:
>> 
>>> 66:             int dotIndex = name.lastIndexOf('.');
>>> 67:             String memberName = name.substring(openBracketIndex,dotIndex);
>>> 68:             //Reconstruct <libname>.so(<member_name>) as <libname>.a(<member_name>)
>> 
>> Do we really need to support libname.so(member)? Isn't it always libname.a(member)?
>
> I think `mapAlternativeName` isn't needed at all.   If `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")` should be passed to dlopen directly.   @suchismith1993 can verify it.

@mlchung Correct. But, if .so file is given and it is not present , it will throw exception. So we should keep the mapAlternativeName for atleast .so to .a mapping(without any members  mentioned).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540621304

From serge.chernyshev at bell-sw.com  Wed Mar 27 08:05:25 2024
From: serge.chernyshev at bell-sw.com (Sergey Chernyshev)
Date: Wed, 27 Mar 2024 09:05:25 +0100
Subject: InetAddress API extension proposal
In-Reply-To: <20240326191031.A4185661192@dd33810.kasserver.com>
References: <b25b9ced-3d1e-4067-bb91-77bd17844611@bell-sw.com>
 <20240326191031.A4185661192@dd33810.kasserver.com>
Message-ID: <97a6d5e7-2c58-4fc4-867d-f5951d0d2e8f@bell-sw.com>

Hi Bernd,

Thank you for your comments! inet_addr() is POSIX.1, please see 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html

In its common implementation inet_addr() is just

u_long
inet_addr(cp)
	register  const  char  *cp;
{
	struct  in_addr val;

	if  (inet_aton(cp, &val))
		return  (val.s_addr);
	return  (INADDR_NONE);
}

In turn, inet_aton() is what's described - it either recognizes the 
hex/octal bases or relies on strtoul().

RFC 3493 section 6.1 specifies a protocol-independent node name and 
service name translation:

   "If the specified address family is AF_INET or AF_UNSPEC,
    address strings using Internet standard dot notation as specified in
    inet_addr() are valid."

In the discussion of .ofLiteral() it was not concluded that 
.ofPosixLiteral() would be insecure or undesirable. From the 'security 
issues' point of view, it is a new method, it won't change the behavior 
of old apps. If any code (a csrf filter) written in Java recognized 
(knowing what it does) additional literal address formats, it would only 
be an improvement (in detection). The good reason is bringing 
compatibility with standard tools relying on inet_addr() into Java, that 
would actually help overcoming the confusion between the standards. A 
real world example could be a Java program parsing HOSTS file (it allows 
hexadecimal address segments).


Am 26.03.24 um 20:10 schrieb Bernd Eckenfels:
> Would be helpful to point to the posix standard/requirement which mandates this. Do you mean a single Unix api description or a posix command spec? I don?t think I know of any such things.
>
> Wikipedia claims A POSIX-conforming variant of inet_aton, the inet_pton() function, supports only the four-decimal variant of IP addresses.[10]
>
> And can you also justify a bit more who needs that octal compatibility? Over the years a lot of confusion (zero padding) and security issues (csrf filters not catching all formats) have been found, so it?s really not a good idea to implement it for no good reason. I think this was also the conclusion for the ofLiteral() api.
>
> Sergey Chernyshev wrote on 26. Mar 2024 17:51 (GMT +01:00):
>
>> Hello Core Libs Dev team,
>>
>> I would like to propose a PR to extend the InetAddress API in JDK 23,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240327/eb7ed0f1/attachment-0001.htm>

From sroy at openjdk.org  Wed Mar 27 08:26:25 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 27 Mar 2024 08:26:25 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
Message-ID: <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>

On Tue, 26 Mar 2024 21:11:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 68:
>> 
>>> 66:             int dotIndex = name.lastIndexOf('.');
>>> 67:             String memberName = name.substring(openBracketIndex,dotIndex);
>>> 68:             //Reconstruct <libname>.so(<member_name>) as <libname>.a(<member_name>)
>> 
>> Do we really need to support libname.so(member)? Isn't it always libname.a(member)?
>
> I think `mapAlternativeName` isn't needed at all.   If `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")` should be passed to dlopen directly.   @suchismith1993 can verify it.

@mlchung The first name constructed by Classloader is always lib<name>.so. So we need a way to map it to lib<name>.a . Else it will search for .so and fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540650937

From mdoerr at openjdk.org  Wed Mar 27 08:49:26 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 27 Mar 2024 08:49:26 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
Message-ID: <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>

On Wed, 27 Mar 2024 08:23:53 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> I think `mapAlternativeName` isn't needed at all.   If `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")` should be passed to dlopen directly.   @suchismith1993 can verify it.
>
> @mlchung The first name constructed by Classloader is always lib<name>.so. So we need a way to map it to lib<name>.a . Else it will search for .so and fail.

Right, the `loadLibraryOnlyIfPresent` change is sufficient for `System.load("libname.a(member)")` support. I don't know how common ".a" without member specification ist, but that may make sense. It sounds similar to what was done for MacOS with https://github.com/openjdk/jdk/commit/1e4dfcfbf00a9b17418bccc0dc746fd9a71f3a06.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540686268

From duke at openjdk.org  Wed Mar 27 11:23:24 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 27 Mar 2024 11:23:24 GMT
Subject: RFR: 8327791: Optimization for new BigDecimal(String) [v16]
In-Reply-To: <x9SnGx9TpR0wlNOAtbgSR5cK5yQO7RywpQvCXe7fzwE=.72d80ce0-23c3-4036-9eae-641c9cf3d530@github.com>
References: <dUUnH0fYwQJEfKGBghPvfTxXlr--4KhhzCD17jaBXbs=.7e6560c8-a056-4e46-8114-2600f3abbd3f@github.com>
 <x9SnGx9TpR0wlNOAtbgSR5cK5yQO7RywpQvCXe7fzwE=.72d80ce0-23c3-4036-9eae-641c9cf3d530@github.com>
Message-ID: <FD9d-X3WeOln3IuiDd4SDiMT99YltJ1JZrNetIlKFoA=.31d25163-f34f-44dc-b842-10500d82daae@github.com>

On Wed, 20 Mar 2024 22:56:38 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 incrementally with one additional commit since the last revision:
> 
>   use while instead for

I also agree that public constructors should be a new PR. I'm waiting for this PR to be merged and then submit a new PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2022525905

From cushon at openjdk.org  Wed Mar 27 15:43:23 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 27 Mar 2024 15:43:23 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB
In-Reply-To: <9wbFYwittlKo6Dn_PmaTcPCXhQBgl9XM9H5X7lCoYRA=.59096284-3c2e-4ef8-94ec-ed9469d6c037@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <9wbFYwittlKo6Dn_PmaTcPCXhQBgl9XM9H5X7lCoYRA=.59096284-3c2e-4ef8-94ec-ed9469d6c037@github.com>
Message-ID: <Crr9nkXtwYAmPsZTX32WDY8Xfh4Y6iJ0rSVFhyxRaDc=.b1b10be3-bf94-4fde-a213-e2a0c05e9a5a@github.com>

On Wed, 27 Mar 2024 03:19:47 GMT, Jiangli Zhou <jiangli 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'.
>
> src/java.base/share/native/libjli/manifest_info.h line 146:
> 
>> 144:  * Macros for getting Extensible Data Fields
>> 145:  */
>> 146: #define ZIPEXT_HDR(b) SH(b, 0)      /* Header ID */
> 
> How about naming the macros as ZIP64EXT_HDR and ZIP64EXT_SIZ?

My thinking was that all extensible data fields start with a header with an id and a length, and these macros are used to iterate through the extra fields to find the zip64 extended information extra field, so these macros aren't zip64-specific.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1541364405

From jlahoda at openjdk.org  Wed Mar 27 15:47:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 27 Mar 2024 15:47:35 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview)
Message-ID: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@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.

-------------

Commit messages:
 - Removing whitespace
 - Cleanup.
 - Cleanup, bugfixes.
 - Adding tests.
 - Adding examples.
 - More correct handling of exceptions in derived record creation expression; optimizing the resulting bytecode.
 - Javadoc cleanup.
 - Merge branch 'master' into wthexp
 - Adding missing file.
 - Cleanup.
 - ... and 11 more: https://git.openjdk.org/jdk/compare/0c1b254b...a61682ff

Changes: https://git.openjdk.org/jdk/pull/18509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324651
  Stats: 1551 lines in 41 files changed: 1481 ins; 20 del; 50 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 cushon at openjdk.org  Wed Mar 27 16:05:43 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 27 Mar 2024 16:05:43 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v2]
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: <C_Q_uwpXHoyUsO7VGwjgwp9JgkBS8JTJTuqiiCHXezU=.2b05a4ee-b31c-4bf0-81fa-79a5f6c41548@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:

  Fix disk number size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18479/files
  - new: https://git.openjdk.org/jdk/pull/18479/files/8f908a0e..6b13ecc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=00-01

  Stats: 19 lines in 1 file changed: 8 ins; 7 del; 4 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  Wed Mar 27 16:05:44 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 27 Mar 2024 16:05:44 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v2]
In-Reply-To: <9wbFYwittlKo6Dn_PmaTcPCXhQBgl9XM9H5X7lCoYRA=.59096284-3c2e-4ef8-94ec-ed9469d6c037@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <9wbFYwittlKo6Dn_PmaTcPCXhQBgl9XM9H5X7lCoYRA=.59096284-3c2e-4ef8-94ec-ed9469d6c037@github.com>
Message-ID: <MquPFfjD6z0KGbtmOhgvBDGWPs3nPneA9wglEag4Otw=.2337026b-bff1-4a77-bd57-69b36e1a758c@github.com>

On Wed, 27 Mar 2024 03:18:42 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:
>> 
>>   Fix disk number size
>
> src/java.base/share/native/libjli/manifest_info.h line 59:
> 
>> 57: #define ZIP64_EXTID   1       // Extra field Zip64 header ID
>> 58: 
>> 59: #define ZIP64_EXTMAXLEN 36 // Maximum Zip64 extra field length
> 
> The fields described in APPNOTE-6.3.9.TXT 4.5.3 are total 32 bytes. Any other additional fields in the Zip64 extended information?
> 
> 
>         Value      Size       Description
>         -----      ----       -----------
> (ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
>         Size       2 bytes    Size of this "extra" block
>         Original 
>         Size       8 bytes    Original uncompressed file size
>         Compressed
>         Size       8 bytes    Size of compressed data
>         Relative Header
>         Offset     8 bytes    Offset of local header record
>         Disk Start
>         Number     4 bytes    Number of the disk on which
>                               this file starts

Thanks for the catch, I had missed that the disk start number is 4 bytes and not 8. I pushed a commit. I also removed some unused references to the disk number, which is only being used to validate the size of the zip64 extended info.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1541404663

From mchung at openjdk.org  Wed Mar 27 16:47:24 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 16:47:24 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
Message-ID: <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>

On Wed, 27 Mar 2024 08:47:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> @mlchung The first name constructed by Classloader is always lib<name>.so. So we need a way to map it to lib<name>.a . Else it will search for .so and fail.
>
> Right, the `loadLibraryOnlyIfPresent` change is sufficient for `System.load("libname.a(member)")` support. I don't know how common ".a" without member specification ist, but that may make sense. It sounds similar to what was done for MacOS with https://github.com/openjdk/jdk/commit/1e4dfcfbf00a9b17418bccc0dc746fd9a71f3a06.

> So we should keep the mapAlternativeName for atleast .so to .a mapping(without any members mentioned).

"libname.so(member_name)" is not a valid library name.   No reason why `System.load` has to support it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541477181

From sroy at openjdk.org  Wed Mar 27 17:04:28 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 27 Mar 2024 17:04:28 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
Message-ID: <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>

On Wed, 27 Mar 2024 16:44:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > So we should keep the mapAlternativeName for atleast .so to .a mapping(without any members mentioned).
> 
> "libname.so(member_name)" is not a valid library name. No reason why `System.load` has to support it.

We are not supporting that. Are you referring to the comment in the code ? Yeah it should be resconstruction of libname(member_name).so , which is the first filename the classLoader constructs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541502377

From mdoerr at openjdk.org  Wed Mar 27 17:09:25 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 27 Mar 2024 17:09:25 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
Message-ID: <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>

On Wed, 27 Mar 2024 17:01:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> So we should keep the mapAlternativeName for atleast .so to .a mapping(without any members mentioned).
>> 
>> "libname.so(member_name)" is not a valid library name.   No reason why `System.load` has to support it.
>
>> > So we should keep the mapAlternativeName for atleast .so to .a mapping(without any members mentioned).
>> 
>> "libname.so(member_name)" is not a valid library name. No reason why `System.load` has to support it.
> 
> We are not supporting that. Are you referring to the comment in the code ? Yeah it should be resconstruction of libname(member_name).so , which is the first filename the classLoader constructs.

I think we both mean that the `if (name.contains("("))` block should get removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541509898

From sroy at openjdk.org  Wed Mar 27 17:23:50 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 27 Mar 2024 17:23:50 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v6]
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: <g-HvEzEqrWTaXItMHcUAXO2HF9BB-ivlOK-oCJI022I=.c2adf1d4-f67f-4cc5-a406-2843b08963d0@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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - remove member check
 - update comment
 - coding style
 - set false
 - restore fil
 -  remove member check code
 - trraling spaces
 - trailing spaces
 - remove space
 - remove debug print lines
 - ... and 6 more: https://git.openjdk.org/jdk/compare/d0a26503...4c068e78

-------------

Changes: https://git.openjdk.org/jdk/pull/17945/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=05
  Stats: 82 lines in 1 file changed: 82 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 mchung at openjdk.org  Wed Mar 27 17:23:50 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 17:23:50 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
 <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
Message-ID: <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>

On Wed, 27 Mar 2024 17:06:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> > So we should keep the mapAlternativeName for atleast .so to .a mapping(without any members mentioned).
>>> 
>>> "libname.so(member_name)" is not a valid library name. No reason why `System.load` has to support it.
>> 
>> We are not supporting that. Are you referring to the comment in the code ? Yeah it should be resconstruction of libname(member_name).so , which is the first filename the classLoader constructs.
>
> I think we both mean that the `if (name.contains("("))` block should get removed.

> We are not supporting that. Are you referring to the comment in the code ? Yeah it should be resconstruction of libname(member_name).so , which is the first filename the classLoader constructs.

Note that `System.mapLibraryName` and `mapAlternativeName` are called for `System.loadLibrary`  (i.e. prepending `lib` and appending `.so`).    "libname(member_name)" is not a valid name and no reason for `System.loadLibrary`  to support it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541525247

From mchung at openjdk.org  Wed Mar 27 17:23:50 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 17:23:50 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
 <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
 <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>
Message-ID: <vXlLxJMSoD4TkP0DFdBqsujyVLXR8Wt6U7__qqlKWAc=.b04c2c67-910f-4570-a232-d233772157ff@github.com>

On Wed, 27 Mar 2024 17:18:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I think we both mean that the `if (name.contains("("))` block should get removed.
>
>> We are not supporting that. Are you referring to the comment in the code ? Yeah it should be resconstruction of libname(member_name).so , which is the first filename the classLoader constructs.
> 
> Note that `System.mapLibraryName` and `mapAlternativeName` are called for `System.loadLibrary`  (i.e. prepending `lib` and appending `.so`).    "libname(member_name)" is not a valid name and no reason for `System.loadLibrary`  to support it.

> I think we both mean that the if (name.contains("(")) block should get removed.

Because of the VM support, we can remove `mapAlternativeName` completely.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541531589

From sroy at openjdk.org  Wed Mar 27 17:23:50 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 27 Mar 2024 17:23:50 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <vXlLxJMSoD4TkP0DFdBqsujyVLXR8Wt6U7__qqlKWAc=.b04c2c67-910f-4570-a232-d233772157ff@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
 <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
 <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>
 <vXlLxJMSoD4TkP0DFdBqsujyVLXR8Wt6U7_
 _qqlKWAc=.b04c2c67-910f-4570-a232-d233772157ff@github.com>
Message-ID: <R0mOjcbiVZ-iiw2bD8S6BX2Xz8IAMdBsNU5VgD35KMM=.fb0091b3-f3b1-4854-8827-03223106dc03@github.com>

On Wed, 27 Mar 2024 17:19:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> We are not supporting that. Are you referring to the comment in the code ? Yeah it should be resconstruction of libname(member_name).so , which is the first filename the classLoader constructs.
>> 
>> Note that `System.mapLibraryName` and `mapAlternativeName` are called for `System.loadLibrary`  (i.e. prepending `lib` and appending `.so`).    "libname(member_name)" is not a valid name and no reason for `System.loadLibrary`  to support it.
>
>> I think we both mean that the if (name.contains("(")) block should get removed.
> 
> Because of the VM support, we can remove `mapAlternativeName` completely.

Oh ok.Yes i have removed that now. You mean ,load library wont support it, but load will be able to support it since the loadLibraryIfPresent is returned false now. 

Now the loadLibrary can only handle .so to .a mapping due to mapAlternativeName

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541534243

From sroy at openjdk.org  Wed Mar 27 17:32:24 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 27 Mar 2024 17:32:24 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <R0mOjcbiVZ-iiw2bD8S6BX2Xz8IAMdBsNU5VgD35KMM=.fb0091b3-f3b1-4854-8827-03223106dc03@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
 <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
 <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>
 <vXlLxJMSoD4TkP0DFdBqsujyVLXR8Wt6U7_
 _qqlKWAc=.b04c2c67-910f-4570-a232-d233772157ff@github.com>
 <R0mOjcbiVZ-iiw2bD8S6BX2Xz8IAMdBsNU5VgD35KMM=.fb0091b3-f3b1-4854-8827-03223106dc03@github.com>
Message-ID: <1qyiq1zDZi-yXSCRomK2XaREn50YeuuCXHn-V2GlWxs=.cafbbc4a-32da-42ff-b04a-917caaf74c8e@github.com>

On Wed, 27 Mar 2024 17:20:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> I think we both mean that the if (name.contains("(")) block should get removed.
>> 
>> Because of the VM support, we can remove `mapAlternativeName` completely.
>
> Oh ok.Yes i have removed that now. You mean ,load library wont support it, but load will be able to support it since the loadLibraryIfPresent is returned false now. 
> 
> Now the loadLibrary can only handle .so to .a mapping due to mapAlternativeName

> Because of the VM support, we can remove `mapAlternativeName` completely.

Does VM provide support for mapping .so to .a files ? We still have cases where the entire .a file is shared and don't need to mention the member.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541544958

From sroy at openjdk.org  Wed Mar 27 17:32:24 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 27 Mar 2024 17:32:24 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <1qyiq1zDZi-yXSCRomK2XaREn50YeuuCXHn-V2GlWxs=.cafbbc4a-32da-42ff-b04a-917caaf74c8e@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
 <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
 <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>
 <vXlLxJMSoD4TkP0DFdBqsujyVLXR8Wt6U7_
 _qqlKWAc=.b04c2c67-910f-4570-a232-d233772157ff@github.com>
 <R0mOjcbiVZ-iiw2bD8S6BX2Xz8IAMdBsNU5VgD35KMM=.fb0091b3-f3b1-4854-8827-03223106dc03@github.com>
 <1qyiq1zDZi-yXSCRomK2XaREn50YeuuCXHn-V2GlWxs=.cafbbc4a-32da-42ff-b04a-917caaf74c8e@github.com>
Message-ID: <Xyjlp9aFxioDemHLeoEi2UmOs_3BnGIiuQ00lqiwSsE=.38ee3ca6-e92f-42ef-ad95-e274f8940921@github.com>

On Wed, 27 Mar 2024 17:27:43 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Oh ok.Yes i have removed that now. You mean ,load library wont support it, but load will be able to support it since the loadLibraryIfPresent is returned false now. 
>> 
>> Now the loadLibrary can only handle .so to .a mapping due to mapAlternativeName
>
>> Because of the VM support, we can remove `mapAlternativeName` completely.
> 
> Does VM provide support for mapping .so to .a files ? We still have cases where the entire .a file is shared and don't need to mention the member.

libsystemInfo.a is one use case ,i got after discussion with our teams, which actually raised this issue in J9. So there are cases where pure .a files exist.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541548250

From mchung at openjdk.org  Wed Mar 27 17:37:25 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 17:37:25 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <Xyjlp9aFxioDemHLeoEi2UmOs_3BnGIiuQ00lqiwSsE=.38ee3ca6-e92f-42ef-ad95-e274f8940921@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
 <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
 <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>
 <vXlLxJMSoD4TkP0DFdBqsujyVLXR8Wt6U7_
 _qqlKWAc=.b04c2c67-910f-4570-a232-d233772157ff@github.com>
 <R0mOjcbiVZ-iiw2bD8S6BX2Xz8IAMdBsNU5VgD35KMM=.fb0091b3-f3b1-4854-8827-03223106dc03@github.com>
 <1qyiq1zDZi-yXSCRomK2XaREn50YeuuCXHn-V2GlWxs=.cafbbc4a-32da-42ff-b04a-917caaf74c8e@github.com>
 <Xyjlp9aFxioDemHLeoEi2UmOs_3BnGIiuQ00lqiwSsE=.38ee3ca6-e92f-42ef-ad95-e274f8940921@github.com>
Message-ID: <PllCiLHDxdRuIrH_2pJtTpcBeGPqmT4YBklbhDrQKB8=.b91c3305-1139-43e3-870f-48d41f9b16df@github.com>

On Wed, 27 Mar 2024 17:30:13 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>>> Because of the VM support, we can remove `mapAlternativeName` completely.
>> 
>> Does VM provide support for mapping .so to .a files ? We still have cases where the entire .a file is shared and don't need to mention the member.
>
> libsystemInfo.a is one use case ,i got after discussion with our teams, which actually raised this issue in J9. So there are cases where pure .a files exist.

AFAICT from your fix for [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) commit [e85355ad](https://github.com/openjdk/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab).

But it needs verification as I suggest (see https://github.com/openjdk/jdk/pull/17945#issuecomment-2019965401).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541555855

From sroy at openjdk.org  Wed Mar 27 17:42:25 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 27 Mar 2024 17:42:25 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <PllCiLHDxdRuIrH_2pJtTpcBeGPqmT4YBklbhDrQKB8=.b91c3305-1139-43e3-870f-48d41f9b16df@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
 <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
 <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>
 <vXlLxJMSoD4TkP0DFdBqsujyVLXR8Wt6U7_
 _qqlKWAc=.b04c2c67-910f-4570-a232-d233772157ff@github.com>
 <R0mOjcbiVZ-iiw2bD8S6BX2Xz8IAMdBsNU5VgD35KMM=.fb0091b3-f3b1-4854-8827-03223106dc03@github.com>
 <1qyiq1zDZi-yXSCRomK2XaREn50YeuuCXHn-V2GlWxs=.cafbbc4a-32da-42ff-b04a-917caaf74c8e@github.com>
 <Xyjlp9aFxioDemHLeoEi2UmOs_3BnGIiuQ00lqiwSsE=.38ee3ca6-e92f-42ef-ad95-e274f8940921@github.com>
 <PllCiLHDxdRuIrH_2pJtTpcBeGPqmT4YBklbhDrQKB8=.b91c3305-1139-43e3-870f-48d41f9b16df@github.com>
Message-ID: <fFpxdQnt6X0mqnelCFJdArR0YLhfmmFmq9uVcdxJd9I=.7a2f8e9d-1ef5-4919-b5b8-4114d2971afe@github.com>

On Wed, 27 Mar 2024 17:34:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> libsystemInfo.a is one use case ,i got after discussion with our teams, which actually raised this issue in J9. So there are cases where pure .a files exist.
>
> AFAICT from your fix for [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) commit [e85355ad](https://github.com/openjdk/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab).
> 
> But it needs verification as I suggest (see https://github.com/openjdk/jdk/pull/17945#issuecomment-2019965401).

@mlchung  [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) is solving the .so to .a mapping at hotspot level. But if we still call loadLibrary() , with a .so, which has an equivalent .a file, it will fail. 

What kind of verification are you mentioning ? We do have use cases where we have pure .a files. libsystemInfo.a  being one of them, as i confirmed from our teams.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541566885

From cushon at openjdk.org  Wed Mar 27 17:43:41 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 27 Mar 2024 17:43:41 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
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: <blggcSb-HpSewfmO6nB5JZQL0m8PR4IfxFLO1VV6Xeo=.cd6807c8-efd1-4758-aec9-7920d7c5e180@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:

  Make cendsk an unsigned short

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18479/files
  - new: https://git.openjdk.org/jdk/pull/18479/files/6b13ecc2..7b599c9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 mchung at openjdk.org  Wed Mar 27 17:45:22 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 17:45:22 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v5]
In-Reply-To: <fFpxdQnt6X0mqnelCFJdArR0YLhfmmFmq9uVcdxJd9I=.7a2f8e9d-1ef5-4919-b5b8-4114d2971afe@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <ux5bgBAaN1J8udAOI7mw_dI6S60oLcWY8c3u1Dz8HaI=.5ca063f8-e083-4688-bb7e-3e34547f25ac@github.com>
 <l75_gnMeazGWR5CBedHw2g0l8TUpP_hCcPkA-h_yys4=.fc5feb8b-f643-4a16-899d-5ef860430924@github.com>
 <XLCpMw-xjOmIlYmI3m6a1djave7Bu__wTQDi4lyISz8=.7e552ba9-7d69-4e05-975e-4cefb1112afa@github.com>
 <4lzT9fi5RCsUcx7w5MQF6uHEpz4859hOW32ZqfD79mc=.98db0a18-9e8c-496d-8bec-242f1c8da1e4@github.com>
 <EB6DRVr9IUZmstEPXXTBKNtpA2APGbeYpgIKsemp7Go=.55c4601d-a1ed-48ab-b2aa-611532f175f3@github.com>
 <68L4VVEn39h6a2c2ePlLw-qfjx1OYVPykLquIpesfJA=.2a96cc5c-36ff-4bc4-9ffa-e3bed7ee1f05@github.com>
 <4Z7yIbHKGgajI4j0PxTR5DG3aHNjMnXGl02Rj9FckQA=.c158a3a2-fa45-4a4c-a877-3d9544de4ef3@github.com>
 <_-gjxIEIqeXZHmB9NyZMyUD243KRDTBgwLMxE-k-8XQ=.13075d45-cafa-4706-87fe-a4840102b72b@github.com>
 <yURMTmpNJQywxxu6b2P42Cdz1kWPFdhKtApDwETLUko=.d29142e0-5682-400e-b9d7-0a077e865275@github.com>
 <vXlLxJMSoD4TkP0DFdBqsujyVLXR8Wt6U7_
 _qqlKWAc=.b04c2c67-910f-4570-a232-d233772157ff@github.com>
 <R0mOjcbiVZ-iiw2bD8S6BX2Xz8IAMdBsNU5VgD35KMM=.fb0091b3-f3b1-4854-8827-03223106dc03@github.com>
 <1qyiq1zDZi-yXSCRomK2XaREn50YeuuCXHn-V2GlWxs=.cafbbc4a-32da-42ff-b04a-917caaf74c8e@github.com>
 <Xyjlp9aFxioDemHLeoEi2UmOs_3BnGIiuQ00lqiwSsE=.38ee3ca6-e92f-42ef-ad95-e274f8940921@github.com>
 <PllCiLHDxdRuIrH_2pJtTpcBeGPqmT4YBklbhDrQKB8=.b91c3305-1139-43e3-870f-48d41f9b16df@github.com>
 <fFpxdQnt6X0mqnelCFJdArR0YLhfmmFmq9uVcdxJd9I=.7a2f8e9d-1ef5-4919-b5b8-4114d2971afe@github.com>
Message-ID: <yoDHftLHFYbG67XdDdwo42dXd-KmO5oHIbVQl0RYCdM=.139365b9-b808-4de0-ab42-c50be2fe21b6@github.com>

On Wed, 27 Mar 2024 17:40:09 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> AFAICT from your fix for [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) commit [e85355ad](https://github.com/openjdk/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab).
>> 
>> But it needs verification as I suggest (see https://github.com/openjdk/jdk/pull/17945#issuecomment-2019965401).
>
> @mlchung  [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) is solving the .so to .a mapping at hotspot level. But if we still call loadLibrary() , with a .so, which has an equivalent .a file, it will fail. 
> 
> What kind of verification are you mentioning ? We do have use cases where we have pure .a files. libsystemInfo.a  being one of them, as i confirmed from our teams.

You can try with a simple program calling `System.loadLibrary("systeminfo")` with just `loadLibraryOnlyIfPresent` change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541570578

From prappo at openjdk.org  Wed Mar 27 18:06:54 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 27 Mar 2024 18:06:54 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue) [v5]
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <ozznqzxZSIOGUMKtkoNvYqh4wjWiOEUpjckTyOuvimg=.7a5cdf85-cb58-410c-9c52-beac93d81c9f@github.com>

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

Pavel Rappo 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 branch 'master' into 8311864
 - Merge branch 'master' into 8311864
 - Merge remote-tracking branch 'jdk/master' into 8311864
 - Merge branch 'master' into 8311864
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14831/files
  - new: https://git.openjdk.org/jdk/pull/14831/files/e55dc5c1..2d06e03a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=03-04

  Stats: 582641 lines in 7412 files changed: 101141 ins; 127425 del; 354075 mod
  Patch: https://git.openjdk.org/jdk/pull/14831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14831/head:pull/14831

PR: https://git.openjdk.org/jdk/pull/14831

From naoto at openjdk.org  Wed Mar 27 20:23:38 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 27 Mar 2024 20:23:38 GMT
Subject: RFR: 8326627: Document Double/Float.valueOf(String) behaviour for
 numeric strings with non-ASCII digits
Message-ID: <szsDszk5wdBua45d65v2U7iOhdwPuYn-xExt3147chU=.c0634493-09b6-4491-b9fc-ce4983a6681d@github.com>

Clarifying the behavior for non-ASCII digits in Double/Float.valueOf(String) method descriptions. A draft CSR has also been created.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/18526/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326627
  Stats: 33 lines in 4 files changed: 22 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18526/head:pull/18526

PR: https://git.openjdk.org/jdk/pull/18526

From jlu at openjdk.org  Wed Mar 27 21:00:58 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 27 Mar 2024 21:00:58 GMT
Subject: RFR: JDK-8327640: Allow NumberFormat strict parsing [v5]
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: <HiouyCW1mXtZpMp7hyAKhuuZesxtu5BeFrQDJZ68fvo=.2903f485-499e-4af5-87a7-ca5c503d7fef@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 13 additional commits since the last revision:

 - 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
 - implement white space suggestions
 - ... and 3 more: https://git.openjdk.org/jdk/compare/c8a9b97f...3f2b097a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/4edb4802..3f2b097a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=03-04

  Stats: 349232 lines in 2746 files changed: 15275 ins; 10415 del; 323542 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 Mar 27 21:16:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 27 Mar 2024 21:16:34 GMT
Subject: Integrated: JDK-8327875: ChoiceFormat should advise throwing
 UnsupportedOperationException for unused methods
In-Reply-To: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>
References: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>
Message-ID: <NXhPvCzD8HkOtZut27PIv4xa5kaVzZVMZj-lPkQBgCg=.0ca657c9-c6b6-40ee-9e81-dc84e64de214@github.com>

On Tue, 26 Mar 2024 20:50:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which advises ChoiceFormat subclasses throw `UnsupportedOperationException` for unused inherited methods.
> 
> The CSR covers the proposed wording, and the reasons as to why this is a specification and not an implementation update. In addition, the `api/implNote` tags have been moved to the bottom of the class description, as they are no longer only relevant to the pattern section, (where they were previously located).

This pull request has now been integrated.

Changeset: 0cb0b5db
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cb0b5db2ac0f9b5a8fe40c5be5f7b12124fe402
Stats:     25 lines in 1 file changed: 15 ins; 10 del; 0 mod

8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18499

From iris at openjdk.org  Wed Mar 27 22:08:31 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 27 Mar 2024 22:08:31 GMT
Subject: RFR: 8326627: Document Double/Float.valueOf(String) behaviour for
 numeric strings with non-ASCII digits
In-Reply-To: <szsDszk5wdBua45d65v2U7iOhdwPuYn-xExt3147chU=.c0634493-09b6-4491-b9fc-ce4983a6681d@github.com>
References: <szsDszk5wdBua45d65v2U7iOhdwPuYn-xExt3147chU=.c0634493-09b6-4491-b9fc-ce4983a6681d@github.com>
Message-ID: <oZxJm7S8Jwh14jCqxT1K2bXrrqo4H23VychayX3e5To=.71a701ab-7d8a-4d7c-a84b-c4a15e59feea@github.com>

On Wed, 27 Mar 2024 19:58:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Clarifying the behavior for non-ASCII digits in Double/Float.valueOf(String) method descriptions. A draft CSR has also been created.

Associated CSR also Reviewed.  I like the relocation of existing text to the more appropriate `@apiNote`.  The example provides additional clarity.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18526#pullrequestreview-1964850180

From jjg at openjdk.org  Wed Mar 27 22:08:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 27 Mar 2024 22:08:57 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc
 comments
Message-ID: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@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.

-------------

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303689
  Stats: 477 lines in 60 files changed: 368 ins; 5 del; 104 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 prappo at openjdk.org  Wed Mar 27 22:44:31 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 27 Mar 2024 22:44:31 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: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@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.

Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024106466

From prappo at openjdk.org  Wed Mar 27 22:55:32 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 27 Mar 2024 22:55:32 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: <WsC10GQD9Q9xTXY9eY2_v5C91f8J5WKuRlRwmP4jElw=.b13568b0-44c3-470e-a8e4-aa27833ecd28@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.

Javadoc changes look trivially good. I only note that the javadoc man page diff contains some unrelated changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024116236

From prappo at openjdk.org  Wed Mar 27 22:59:34 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 27 Mar 2024 22:59:34 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: <CR1gXDa9g51mJiCtmPnP6-P-eT_71xIppMf2ND8axQ0=.bc1e2507-9973-498a-b6c4-159732c2e406@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.

src/jdk.javadoc/share/man/javadoc.1 line 111:

> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more
> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R].
> 111: Within a source file, you may use suppress any warnings generated by

Typo?
Suggestion:

Within a source file, you may suppress any warnings generated by

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542131487

From Alan.Bateman at oracle.com  Wed Mar 27 23:23:16 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 28 Mar 2024 08:23:16 +0900
Subject: InetAddress API extension proposal
In-Reply-To: <97a6d5e7-2c58-4fc4-867d-f5951d0d2e8f@bell-sw.com>
References: <b25b9ced-3d1e-4067-bb91-77bd17844611@bell-sw.com>
 <20240326191031.A4185661192@dd33810.kasserver.com>
 <97a6d5e7-2c58-4fc4-867d-f5951d0d2e8f@bell-sw.com>
Message-ID: <6208a924-dfaf-4c30-825f-af1b4664bc7d@oracle.com>



On 27/03/2024 17:05, Sergey Chernyshev wrote:
>
> In the discussion of .ofLiteral() it was not concluded that 
> .ofPosixLiteral() would be insecure or undesirable. From the 'security 
> issues' point of view, it is a new method, it won't change the 
> behavior of old apps. If any code (a csrf filter) written in Java 
> recognized (knowing what it does) additional literal address formats, 
> it would only be an improvement (in detection). The good reason is 
> bringing compatibility with standard tools relying on inet_addr() into 
> Java, that would actually help overcoming the confusion between the 
> standards. A real world example could be a Java program parsing HOSTS 
> file (it allows hexadecimal address segments).
>
Again, please start a new discussion on net-dev. It would be helpful to 
include a summary on the behavior between different operating system as 
it's that difference, and the parsing of ambiguous corner cases, where 
the security researchers will focus on.

-Alan

From jjg at openjdk.org  Wed Mar 27 23:47:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 27 Mar 2024 23:47:32 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com>
Message-ID: <VBk0641TIJuEE_Ez3MN1g9kd8v7zpjiBY4wdBvzaQP8=.9e11bd0d-14e8-4c9f-ac2c-72d0b77daeae@github.com>

On Wed, 27 Mar 2024 22:41:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments?

No. `-Xlint:dep-ann` correlates `@Deprecated` annotations with `@deprecated` tags in doc comments.

> src/jdk.javadoc/share/man/javadoc.1 line 111:
> 
>> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more
>> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R].
>> 111: Within a source file, you may use suppress any warnings generated by
> 
> Typo?
> Suggestion:
> 
> Within a source file, you may suppress any warnings generated by

Thanks; I'll check the underlying original.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024162355
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542157047

From mdoerr at openjdk.org  Thu Mar 28 08:42:38 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 28 Mar 2024 08:42:38 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v6]
In-Reply-To: <g-HvEzEqrWTaXItMHcUAXO2HF9BB-ivlOK-oCJI022I=.c2adf1d4-f67f-4cc5-a406-2843b08963d0@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <g-HvEzEqrWTaXItMHcUAXO2HF9BB-ivlOK-oCJI022I=.c2adf1d4-f67f-4cc5-a406-2843b08963d0@github.com>
Message-ID: <UYQK3bxgOTxyCEViinAB06PbSQZXUAK3WSvGbYoYwY0=.26c7bd99-d5a2-45c4-bb0a-960938bbdcb1@github.com>

On Wed, 27 Mar 2024 17:23:50 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 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:
> 
>  - remove member check
>  - update comment
>  - coding style
>  - set false
>  - restore fil
>  -  remove member check code
>  - trraling spaces
>  - trailing spaces
>  - remove space
>  - remove debug print lines
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6291ccd0...4c068e78

`mapAlternativeName` seems to be needed. I couldn't load a .a lib without it. So, this PR looks good to me, now. Please only fix the indentation as mentioned in the comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2024676628

From abimpoudis at openjdk.org  Thu Mar 28 11:31:34 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 28 Mar 2024 11:31:34 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview)
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <OelSYwifNXh3_MExb7lOLOj0OxcxqwxhkKSvFIQ0kog=.4f6c606f-65fb-47ad-bc44-d7f31e543721@github.com>

On Wed, 27 Mar 2024 10:24:51 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.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2228:

> 2226:          *  index into the vars array.
> 2227:          */
> 2228:         void newVar(JCTree pos,VarSymbol sym) {

This is used only twice. One from `void newVar(JCVariableDecl varDecl)` which is very intuitive and one with `newVar(null, component);` which I understand. But, is there any reason to create a `var` in the future with something else than `null` (unrelated to `sym`?). Maybe the comment needs to be updated to document what should be the relation (if any) between `pos` and `sym`.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3259:

> 3257:                 startPos = tree.pos().getStartPosition();
> 3258: 
> 3259:                 if (vars == null)

Curly braces here?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 3607:

> 3605:         public void visitLambda(JCLambda that)               { visitTree(that); }
> 3606:         public void visitParens(JCParens that)               { visitTree(that); }
> 3607:         public void visitReconstruction(JCDerivedInstance that) { visitTree(that); }

Maybe `visitDerivedInstance` to be in sync with the `JCDerivedInstance` world?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1542712222
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1542713984
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1542746919

From jlahoda at openjdk.org  Thu Mar 28 13:24:48 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Mar 2024 13:24:48 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v2]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <b8n6-CJFREBAYrMBLDhWJoTGLrEBi9wvyM0XtpQsGx8=.a21983a5-3109-4961-82e4-6993c03edb7a@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:

  Fixing support for derived record creation expression in JShell.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/a61682ff..e1a61833

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=00-01

  Stats: 61 lines in 11 files changed: 57 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 jlahoda at openjdk.org  Thu Mar 28 13:45:58 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Mar 2024 13:45:58 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v3]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <Flr3WDNN3sIOsSXrxLMd-euWdFBmJVKilGjYZLJm-10=.1aa4221b-4db0-41e2-974b-b2e5ccf5f1aa@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:

  Renaming visitReconstruction to visitDerivedInstance as suggested.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/e1a61833..73752b90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=01-02

  Stats: 15 lines in 10 files changed: 0 ins; 0 del; 15 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  Thu Mar 28 13:45:59 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Mar 2024 13:45:59 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v3]
In-Reply-To: <OelSYwifNXh3_MExb7lOLOj0OxcxqwxhkKSvFIQ0kog=.4f6c606f-65fb-47ad-bc44-d7f31e543721@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <OelSYwifNXh3_MExb7lOLOj0OxcxqwxhkKSvFIQ0kog=.4f6c606f-65fb-47ad-bc44-d7f31e543721@github.com>
Message-ID: <gbpY-IUw_erVal3X055uDbRKe3UeeCY8rVAel90VBm0=.24807fb1-2233-4309-9c66-114f2613539c@github.com>

On Thu, 28 Mar 2024 11:00:42 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renaming visitReconstruction to visitDerivedInstance as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2228:
> 
>> 2226:          *  index into the vars array.
>> 2227:          */
>> 2228:         void newVar(JCTree pos,VarSymbol sym) {
> 
> This is used only twice. One from `void newVar(JCVariableDecl varDecl)` which is very intuitive and one with `newVar(null, component);` which I understand. But, is there any reason to create a `var` in the future with something else than `null` (unrelated to `sym`?). Maybe the comment needs to be updated to document what should be the relation (if any) between `pos` and `sym`.

Oops, that's actually an oversight - there should be a pos specified in all cases. Should be fixed now.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3259:
> 
>> 3257:                 startPos = tree.pos().getStartPosition();
>> 3258: 
>> 3259:                 if (vars == null)
> 
> Curly braces here?

This is a copy of the similar code for `vardecls`. I was thinking if I could unify the codepaths, but does not seem to be so simple, so I created a duplicate. So, it might be better to keep the code the same/similar as it was before, to minimize disruptions.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 3607:
> 
>> 3605:         public void visitLambda(JCLambda that)               { visitTree(that); }
>> 3606:         public void visitParens(JCParens that)               { visitTree(that); }
>> 3607:         public void visitReconstruction(JCDerivedInstance that) { visitTree(that); }
> 
> Maybe `visitDerivedInstance` to be in sync with the `JCDerivedInstance` world?

Done. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1543004274
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1543006459
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1543006600

From jlahoda at openjdk.org  Thu Mar 28 14:01:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Mar 2024 14:01:07 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v4]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <XaWvCZ0KiDHAlslNon9DsJNdTtFAtuEakxFkaSi_MMs=.39ca75d2-663c-4c52-9085-1f74b449887a@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 two additional commits since the last revision:

 - Adding tests.
 - The var declaration can be any JCTree.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/73752b90..7b706eeb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=02-03

  Stats: 170 lines in 3 files changed: 169 ins; 0 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  Thu Mar 28 14:08:44 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Mar 2024 14:08:44 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@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:

  Fixing tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/7b706eeb..f89501ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=03-04

  Stats: 79 lines in 4 files changed: 0 ins; 46 del; 33 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 coffeys at openjdk.org  Thu Mar 28 15:59:47 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 28 Mar 2024 15:59:47 GMT
Subject: RFR: 8329013: StackOverflowError when starting Apache Tomcat with
 signed jar
Message-ID: <WwgqCS-193xahqRkHfUjMVufSU3oXkRyrT37m3u38b8=.671740e5-9468-4670-ab05-b020024cc982@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.

-------------

Commit messages:
 - 8329013

Changes: https://git.openjdk.org/jdk/pull/18534/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18534&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329013
  Stats: 87 lines in 2 files changed: 79 ins; 1 del; 7 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 cushon at openjdk.org  Thu Mar 28 16:28:54 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 28 Mar 2024 16:28:54 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException
Message-ID: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>

This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

-------------

Commit messages:
 - Use AbstractImmutableSet
 - Throw UOE for all Map.of().entrySet() mutator methods
 - 8328821: Make the ImmutableCollections clear() call consistent

Changes: https://git.openjdk.org/jdk/pull/18522/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328821
  Stats: 36 lines in 2 files changed: 35 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522

PR: https://git.openjdk.org/jdk/pull/18522

From liach at openjdk.org  Thu Mar 28 16:28:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Mar 2024 16:28: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: <Y2mGcjDmSSvUvfHXVUwOkllBh9U4boZtbNN0xmarNWk=.2c755e0a-f8f2-4ef1-bfb9-4878be93423f@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`.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1321:

> 1319:                 }
> 1320: 
> 1321:                 // all mutating methods throw UnsupportedOperationException

Can we change this anonymous class to `return new AbstractImmutableSet<>` and override `hashCode` with `MapN.this.hashCode()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1542086980

From cushon at openjdk.org  Thu Mar 28 16:28:54 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 28 Mar 2024 16:28:54 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException
In-Reply-To: <Y2mGcjDmSSvUvfHXVUwOkllBh9U4boZtbNN0xmarNWk=.2c755e0a-f8f2-4ef1-bfb9-4878be93423f@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <Y2mGcjDmSSvUvfHXVUwOkllBh9U4boZtbNN0xmarNWk=.2c755e0a-f8f2-4ef1-bfb9-4878be93423f@github.com>
Message-ID: <5DLIZGA6Pz-NuJWAdG3X7fYIWZeSDabo-YtkZP2QjIE=.f8f87349-7387-4101-a952-1abd01e2e3c2@github.com>

On Wed, 27 Mar 2024 21:49:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1321:
> 
>> 1319:                 }
>> 1320: 
>> 1321:                 // all mutating methods throw UnsupportedOperationException
> 
> Can we change this anonymous class to `return new AbstractImmutableSet<>` and override `hashCode` with `MapN.this.hashCode()`?

Thanks, I tried that out and it looks good based on the test coverage. I have tentatively updated the PR to use that approach.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1542163440

From mchung at openjdk.org  Thu Mar 28 17:00:37 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 28 Mar 2024 17:00:37 GMT
Subject: RFR: JDK-8319516 - Native library suffix impact on the library
 loading in AIX- Java Class Loader [v6]
In-Reply-To: <g-HvEzEqrWTaXItMHcUAXO2HF9BB-ivlOK-oCJI022I=.c2adf1d4-f67f-4cc5-a406-2843b08963d0@github.com>
References: <G0iuqkggeSbJKC2V5HtY1-emBNNxGyXA_EYw19acHTQ=.47025b24-6c42-4895-b651-27b9b6747b6d@github.com>
 <g-HvEzEqrWTaXItMHcUAXO2HF9BB-ivlOK-oCJI022I=.c2adf1d4-f67f-4cc5-a406-2843b08963d0@github.com>
Message-ID: <W1SnnV44hPNw3e68q02PdHyBBuDUiUZaq3llF0oEso8=.9979f6bd-33d4-47bc-be80-0643c9448c14@github.com>

On Wed, 27 Mar 2024 17:23:50 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 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:
> 
>  - remove member check
>  - update comment
>  - coding style
>  - set false
>  - restore fil
>  -  remove member check code
>  - trraling spaces
>  - trailing spaces
>  - remove space
>  - remove debug print lines
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4434d52f...4c068e78

`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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2025690507

From serge.chernyshev at bell-sw.com  Thu Mar 28 19:01:09 2024
From: serge.chernyshev at bell-sw.com (Sergey Chernyshev)
Date: Thu, 28 Mar 2024 20:01:09 +0100
Subject: InetAddress API extension proposal
In-Reply-To: <6208a924-dfaf-4c30-825f-af1b4664bc7d@oracle.com>
References: <b25b9ced-3d1e-4067-bb91-77bd17844611@bell-sw.com>
 <20240326191031.A4185661192@dd33810.kasserver.com>
 <97a6d5e7-2c58-4fc4-867d-f5951d0d2e8f@bell-sw.com>
 <6208a924-dfaf-4c30-825f-af1b4664bc7d@oracle.com>
Message-ID: <6b15929e-1861-40b5-ac38-ac890d7bc3b6@bell-sw.com>

Hi Alan,

Thank you for your comments! I will post this to net-nev too as you 
suggested.


Am 28.03.24 um 00:23 schrieb Alan Bateman:
>
>
> On 27/03/2024 17:05, Sergey Chernyshev wrote:
>>
>> In the discussion of .ofLiteral() it was not concluded that 
>> .ofPosixLiteral() would be insecure or undesirable. From the 
>> 'security issues' point of view, it is a new method, it won't change 
>> the behavior of old apps. If any code (a csrf filter) written in Java 
>> recognized (knowing what it does) additional literal address formats, 
>> it would only be an improvement (in detection). The good reason is 
>> bringing compatibility with standard tools relying on inet_addr() 
>> into Java, that would actually help overcoming the confusion between 
>> the standards. A real world example could be a Java program parsing 
>> HOSTS file (it allows hexadecimal address segments).
>>
> Again, please start a new discussion on net-dev. It would be helpful 
> to include a summary on the behavior between different operating 
> system as it's that difference, and the parsing of ambiguous corner 
> cases, where the security researchers will focus on.
>
> -Alan

From jlu at openjdk.org  Thu Mar 28 20:10:31 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Mar 2024 20:10:31 GMT
Subject: RFR: 8326627: Document Double/Float.valueOf(String) behavior for
 numeric strings with non-ASCII digits
In-Reply-To: <szsDszk5wdBua45d65v2U7iOhdwPuYn-xExt3147chU=.c0634493-09b6-4491-b9fc-ce4983a6681d@github.com>
References: <szsDszk5wdBua45d65v2U7iOhdwPuYn-xExt3147chU=.c0634493-09b6-4491-b9fc-ce4983a6681d@github.com>
Message-ID: <Pd0SYet6f5ey3kvzwChH0N4Oc32CvXElIz7MtxzwhAQ=.ce54e738-11f1-4cba-bc33-39687a1a7ebd@github.com>

On Wed, 27 Mar 2024 19:58:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Clarifying the behavior for non-ASCII digits in Double/Float.valueOf(String) method descriptions. A draft CSR has also been created.

New wording LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18526#pullrequestreview-1967172723

From science2000 at ya.ru  Thu Mar 28 20:43:26 2024
From: science2000 at ya.ru (science2000)
Date: Thu, 28 Mar 2024 23:43:26 +0300
Subject: Pattern matching refactoring proposal
Message-ID: <967231711658439@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240328/94e55151/attachment.htm>

From bchristi at openjdk.org  Thu Mar 28 21:46:48 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 28 Mar 2024 21:46:48 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v18]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <0GcDDQv5x4c9rgfAVs9vsRMQ-RVzzGCUkDt4y5Sevps=.85ea08b8-4857-4352-ae90-4f0715d78ff2@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:

  elaborate on VM optimizations, field values outliving their object, etc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/54a44414..0748ed04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=16-17

  Stats: 14 lines in 1 file changed: 10 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 jlu at openjdk.org  Thu Mar 28 22:47:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Mar 2024 22:47:35 GMT
Subject: Integrated: JDK-8329118: Run MessageFormat additional subformat
 pattern tests under en_US locale
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <n8_EAOJGS30upo8VDp_vWEgXU1uVAqAZjQ-8MrA3Nlc=.bb837a5d-4aa4-4d5f-8f95-f0dc858f45e9@github.com>

On Tue, 26 Mar 2024 20:49:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

This pull request has now been integrated.

Changeset: bf93e77e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf93e77e72ccce56685fd10dde83587c703a37b3
Stats:     18 lines in 2 files changed: 6 ins; 0 del; 12 mod

8329118: Run MessageFormat additional subformat pattern tests under en_US locale

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18498

From tprinzing at openjdk.org  Fri Mar 29 00:56:46 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Fri, 29 Mar 2024 00:56:46 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
Message-ID: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@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.

-------------

Commit messages:
 - javadoc fixup
 - remove mirrors from JDKEvents
 - 8329138: Convert JFR FileForceEvent to static mirror event

Changes: https://git.openjdk.org/jdk/pull/18542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329138
  Stats: 159 lines in 7 files changed: 123 ins; 30 del; 6 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 Alan.Bateman at oracle.com  Fri Mar 29 01:45:29 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 29 Mar 2024 10:45:29 +0900
Subject: Pattern matching refactoring proposal
In-Reply-To: <967231711658439@mail.yandex.ru>
References: <967231711658439@mail.yandex.ru>
Message-ID: <3a7220b2-a58b-4374-a633-89fb3f8dc0f0@oracle.com>



On 29/03/2024 05:43, science2000 wrote:
> Hello Core Libs Dev team,
>
> I would like to propose a patch [1] that applies pattern matching for 
> 'instanceof' (JEP-394) and 'switch-case' (JEP-433) on java.base. I 
> suppose this enchantment will improve readability and reduce the code 
> redundancy in cases of casts after 'inctanceof' checking.
> For better reviewing this improvement can be split into 4 tasks 1 for 
> each package: java [2], javax [3], sun [4] and com.sun.crypto [5].
>
> Please share your thoughts on whether such an improvement might be 
> applied.

 From a quick scan, you'll probably be asked to rename a lot of the 
variables as they very inconsistent with the naming in the changed 
source file, otherwise they should be safe and I assume you'll run at 
least tier1+tier2 at least.

-Alan

From alanb at openjdk.org  Fri Mar 29 01:52:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 29 Mar 2024 01:52:35 GMT
Subject: RFR: 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: <EfqP82wv46tkL-lb7QhMgC748W7wJ0dV5KWNWNHaCNg=.a2b9453a-1d9b-41f5-ac0e-b5bf54d77c48@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.

The other two places that should probably emit this event are FileDescriptor.sync and AsynchonrousFileChannel.force.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2026460366

From vromero at openjdk.org  Fri Mar 29 03:07:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Mar 2024 03:07:32 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: <GAZpxf-ZJzNHTZxqSFBUfMxBextCyxBNuNrINXTddyw=.8d42905b-1d96-49d8-992b-8edd48ae8a9b@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.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1967750057

From jiangli at openjdk.org  Fri Mar 29 17:34:31 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 29 Mar 2024 17:34:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <MquPFfjD6z0KGbtmOhgvBDGWPs3nPneA9wglEag4Otw=.2337026b-bff1-4a77-bd57-69b36e1a758c@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <9wbFYwittlKo6Dn_PmaTcPCXhQBgl9XM9H5X7lCoYRA=.59096284-3c2e-4ef8-94ec-ed9469d6c037@github.com>
 <MquPFfjD6z0KGbtmOhgvBDGWPs3nPneA9wglEag4Otw=.2337026b-bff1-4a77-bd57-69b36e1a758c@github.com>
Message-ID: <bWiKLM9NopgHwjWl8bzlGbOtHF41Gg4ejsHahZqkCuc=.d77555b3-296d-44ad-a1c8-4262196882ce@github.com>

On Wed, 27 Mar 2024 16:03:09 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/java.base/share/native/libjli/manifest_info.h line 59:
>> 
>>> 57: #define ZIP64_EXTID   1       // Extra field Zip64 header ID
>>> 58: 
>>> 59: #define ZIP64_EXTMAXLEN 36 // Maximum Zip64 extra field length
>> 
>> The fields described in APPNOTE-6.3.9.TXT 4.5.3 are total 32 bytes. Any other additional fields in the Zip64 extended information?
>> 
>> 
>>         Value      Size       Description
>>         -----      ----       -----------
>> (ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
>>         Size       2 bytes    Size of this "extra" block
>>         Original 
>>         Size       8 bytes    Original uncompressed file size
>>         Compressed
>>         Size       8 bytes    Size of compressed data
>>         Relative Header
>>         Offset     8 bytes    Offset of local header record
>>         Disk Start
>>         Number     4 bytes    Number of the disk on which
>>                               this file starts
>
> Thanks for the catch, I had missed that the disk start number is 4 bytes and not 8. I pushed a commit. I also removed some unused references to the disk number, which is only being used to validate the size of the zip64 extended info.

Ok. Could you please also fix the above `36`? Please change the start of `//` (comment) to be aligned with the earlier comment lines.

>> src/java.base/share/native/libjli/manifest_info.h line 146:
>> 
>>> 144:  * Macros for getting Extensible Data Fields
>>> 145:  */
>>> 146: #define ZIPEXT_HDR(b) SH(b, 0)      /* Header ID */
>> 
>> How about naming the macros as ZIP64EXT_HDR and ZIP64EXT_SIZ?
>
> My thinking was that all extensible data fields start with a header with an id and a length, and these macros are used to iterate through the extra fields to find the zip64 extended information extra field, so these macros aren't zip64-specific.

Seem reasonable, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544719690
PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544718064

From cushon at openjdk.org  Fri Mar 29 17:38:47 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 29 Mar 2024 17:38:47 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
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: <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@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:

  Maximum Zip64 extra field length is 32

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18479/files
  - new: https://git.openjdk.org/jdk/pull/18479/files/7b599c9c..d475de76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Fri Mar 29 17:38:47 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 29 Mar 2024 17:38:47 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <bWiKLM9NopgHwjWl8bzlGbOtHF41Gg4ejsHahZqkCuc=.d77555b3-296d-44ad-a1c8-4262196882ce@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <9wbFYwittlKo6Dn_PmaTcPCXhQBgl9XM9H5X7lCoYRA=.59096284-3c2e-4ef8-94ec-ed9469d6c037@github.com>
 <MquPFfjD6z0KGbtmOhgvBDGWPs3nPneA9wglEag4Otw=.2337026b-bff1-4a77-bd57-69b36e1a758c@github.com>
 <bWiKLM9NopgHwjWl8bzlGbOtHF41Gg4ejsHahZqkCuc=.d77555b3-296d-44ad-a1c8-4262196882ce@github.com>
Message-ID: <wnlg_q8YcTB6c4CaQwaLhA1lugzqA_ljv2DCS-UrAow=.d7859027-6374-4172-a907-2c191a6d5b8c@github.com>

On Fri, 29 Mar 2024 17:32:11 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Thanks for the catch, I had missed that the disk start number is 4 bytes and not 8. I pushed a commit. I also removed some unused references to the disk number, which is only being used to validate the size of the zip64 extended info.
>
> Ok. Could you please also fix the above `36`? Please change the start of `//` (comment) to be aligned with the earlier comment lines.

Done, thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544722502

From jiangli at openjdk.org  Fri Mar 29 17:43:31 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 29 Mar 2024 17:43:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <blggcSb-HpSewfmO6nB5JZQL0m8PR4IfxFLO1VV6Xeo=.cd6807c8-efd1-4758-aec9-7920d7c5e180@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <blggcSb-HpSewfmO6nB5JZQL0m8PR4IfxFLO1VV6Xeo=.cd6807c8-efd1-4758-aec9-7920d7c5e180@github.com>
Message-ID: <ePAi2R36NWMQgnISXwJIT-Z2bdqOOtNlC2TZue59gEA=.24c4b498-1002-4399-b79b-e5b6378be258@github.com>

On Wed, 27 Mar 2024 17:43:41 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:
> 
>   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

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544725300

From jiangli at openjdk.org  Fri Mar 29 17:46:32 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 29 Mar 2024 17:46:32 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <blggcSb-HpSewfmO6nB5JZQL0m8PR4IfxFLO1VV6Xeo=.cd6807c8-efd1-4758-aec9-7920d7c5e180@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <blggcSb-HpSewfmO6nB5JZQL0m8PR4IfxFLO1VV6Xeo=.cd6807c8-efd1-4758-aec9-7920d7c5e180@github.com>
Message-ID: <eLlN9xKKhG3Md5AMkeDNeZdQcOSGAZp04H3Y2yBg5NY=.6706b887-df23-4370-8f6b-7a40d753afe4@github.com>

On Wed, 27 Mar 2024 17:43:41 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:
> 
>   Make cendsk an unsigned short

src/java.base/share/native/libjli/parse_manifest.c line 505:

> 503:               Byte *base = p + CENHDR + CENNAM(p);
> 504:               jlong offset = 0;
> 505:               while (offset < cenext) {

Any reason why a loop is need here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544726976

From cushon at openjdk.org  Fri Mar 29 17:52:31 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 29 Mar 2024 17:52:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <eLlN9xKKhG3Md5AMkeDNeZdQcOSGAZp04H3Y2yBg5NY=.6706b887-df23-4370-8f6b-7a40d753afe4@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>
Message-ID: <z4JT0QIuvUJIgVz_aAl5WI2z9gPBDODSZfFW_dGgJnw=.eb26c9e8-2a71-4eff-b24b-e5896b73c56c@github.com>

On Fri, 29 Mar 2024 17:43:36 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 505:
> 
>> 503:               Byte *base = p + CENHDR + CENNAM(p);
>> 504:               jlong offset = 0;
>> 505:               while (offset < cenext) {
> 
> Any reason why a loop is need here?

There can be multiple extra fields, and the zip64 extended information may not be the first one

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544730915

From naoto at openjdk.org  Fri Mar 29 17:58:38 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 29 Mar 2024 17:58:38 GMT
Subject: Integrated: 8326627: Document Double/Float.valueOf(String) behavior
 for numeric strings with non-ASCII digits
In-Reply-To: <szsDszk5wdBua45d65v2U7iOhdwPuYn-xExt3147chU=.c0634493-09b6-4491-b9fc-ce4983a6681d@github.com>
References: <szsDszk5wdBua45d65v2U7iOhdwPuYn-xExt3147chU=.c0634493-09b6-4491-b9fc-ce4983a6681d@github.com>
Message-ID: <qhmbDjq6PXTeqCzSG1ZV0KFF3_YtlwhiHiJKYJS0vv4=.61d52c2b-c61d-486d-b3a1-2ac117a55b41@github.com>

On Wed, 27 Mar 2024 19:58:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Clarifying the behavior for non-ASCII digits in Double/Float.valueOf(String) method descriptions. A draft CSR has also been created.

This pull request has now been integrated.

Changeset: 8a0ef811
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a0ef811ed4daaa611c9578db0b7fcbcfb57643d
Stats:     33 lines in 4 files changed: 22 ins; 8 del; 3 mod

8326627: Document Double/Float.valueOf(String) behavior for numeric strings with non-ASCII digits

Reviewed-by: iris, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/18526

From jiangli at openjdk.org  Fri Mar 29 18:05:33 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 29 Mar 2024 18:05:33 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <z4JT0QIuvUJIgVz_aAl5WI2z9gPBDODSZfFW_dGgJnw=.eb26c9e8-2a71-4eff-b24b-e5896b73c56c@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>
Message-ID: <lK1mFZnmip-6IIjs_pM5VGLWwjD0QKPaBHkIB1sUf68=.79fbc369-36e0-4a82-8db1-0a7d829029bc@github.com>

On Fri, 29 Mar 2024 17:50:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/java.base/share/native/libjli/parse_manifest.c line 505:
>> 
>>> 503:               Byte *base = p + CENHDR + CENNAM(p);
>>> 504:               jlong offset = 0;
>>> 505:               while (offset < cenext) {
>> 
>> Any reason why a loop is need here?
>
> There can be multiple extra fields, and the zip64 extended information may not be the first one

Could you please point to the related spec for the other `extra field`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544739399

From cushon at openjdk.org  Fri Mar 29 18:11:32 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 29 Mar 2024 18:11:32 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <lK1mFZnmip-6IIjs_pM5VGLWwjD0QKPaBHkIB1sUf68=.79fbc369-36e0-4a82-8db1-0a7d829029bc@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>
Message-ID: <wCTC6i8z29iUpV_UoHdDvN5yLycOsMm3tMhleFQPnhE=.a9e54535-1749-4de2-bda6-fdb67f37bb83@github.com>

On Fri, 29 Mar 2024 18:03:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> There can be multiple extra fields, and the zip64 extended information may not be the first one
>
> Could you please point to the related spec for the other `extra field`?

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

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544742897

From jiangli at openjdk.org  Fri Mar 29 18:27:31 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 29 Mar 2024 18:27:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
Message-ID: <xG1cGAbW9_N7rp3sc5O4_Ph0MdGcuGzWDn2_w8TdJJs=.19418892-e737-4f5f-8b80-3aebcbb09270@github.com>

On Fri, 29 Mar 2024 17:38:47 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:
> 
>   Maximum Zip64 extra field length is 32

src/java.base/share/native/libjli/parse_manifest.c line 197:

> 195:   jlong cenoff = CENOFF(cenhdr);
> 196:   jlong cenext = CENEXT(cenhdr);
> 197:   if (cenoff == ZIP64_MAGICVAL && cenext > 0) {

Probably also need to check if `cenlen` or `censiz` is ZIP64_MAGICVAL?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544752292

From jiangli at openjdk.org  Fri Mar 29 18:27:32 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 29 Mar 2024 18:27:32 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v3]
In-Reply-To: <wCTC6i8z29iUpV_UoHdDvN5yLycOsMm3tMhleFQPnhE=.a9e54535-1749-4de2-bda6-fdb67f37bb83@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>
Message-ID: <OKE0ysEr8Br1-Ak6EXkkYySwyQOS-O8D1ErKl_eIPQM=.7e7e4414-4b11-44aa-9000-00f76bf345ed@github.com>

On Fri, 29 Mar 2024 18:08:56 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Could you please point to the related spec for the other `extra field`?
>
> 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)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544752797

From jiangli at openjdk.org  Fri Mar 29 18:31:31 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 29 Mar 2024 18:31:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
Message-ID: <VjU5pqgy901DyvRdYqIUPVqgV6ueuiBjRTMZ88DVWME=.e336162b-c009-48cc-90cd-a7d58c87e6b4@github.com>

On Fri, 29 Mar 2024 17:38:47 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:
> 
>   Maximum Zip64 extra field length is 32

src/java.base/share/native/libjli/parse_manifest.c line 506:

> 504:               jlong offset = 0;
> 505:               while (offset < cenext) {
> 506:                 short headerId = ZIPEXT_HDR(base + offset);

This block of code is very similar to the corresponding part (reading the ZIP64 extension extra fields) in `validate_lochdr`. Perhaps also refractor to a common helper function?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544754724

From cushon at openjdk.org  Fri Mar 29 18:43:32 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 29 Mar 2024 18:43:32 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <xG1cGAbW9_N7rp3sc5O4_Ph0MdGcuGzWDn2_w8TdJJs=.19418892-e737-4f5f-8b80-3aebcbb09270@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>
Message-ID: <XUYODMuRS6XfGuAgXViZ_L5ESbwqlPu5SfJmODyv6KI=.0ff24f29-9c13-41e3-948d-fa2c20d32df6@github.com>

On Fri, 29 Mar 2024 18:24:23 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:
>> 
>>   Maximum Zip64 extra field length is 32
>
> src/java.base/share/native/libjli/parse_manifest.c line 197:
> 
>> 195:   jlong cenoff = CENOFF(cenhdr);
>> 196:   jlong cenext = CENEXT(cenhdr);
>> 197:   if (cenoff == ZIP64_MAGICVAL && cenext > 0) {
> 
> Probably also need to check if `cenlen` or `censiz` is ZIP64_MAGICVAL?

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544765889

From cushon at openjdk.org  Fri Mar 29 18:46:31 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 29 Mar 2024 18:46:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <VjU5pqgy901DyvRdYqIUPVqgV6ueuiBjRTMZ88DVWME=.e336162b-c009-48cc-90cd-a7d58c87e6b4@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
 <VjU5pqgy901DyvRdYqIUPVqgV6ueuiBjRTMZ88DVWME=.e336162b-c009-48cc-90cd-a7d58c87e6b4@github.com>
Message-ID: <61iK9MNKUtcqjAtlw60xe8FMq9Vlkh187UmIupEs-ak=.b8ddfe14-226e-46ec-b94a-e0579778972b@github.com>

On Fri, 29 Mar 2024 18:28:37 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:
>> 
>>   Maximum Zip64 extra field length is 32
>
> src/java.base/share/native/libjli/parse_manifest.c line 506:
> 
>> 504:               jlong offset = 0;
>> 505:               while (offset < cenext) {
>> 506:                 short headerId = ZIPEXT_HDR(base + offset);
> 
> This block of code is very similar to the corresponding part (reading the ZIP64 extension extra fields) in `validate_lochdr`. Perhaps also refractor to a common helper function?

The other loop uses `readAt` to read in additional data and advance through the extra fields, this loop already has access to a buffer that contains all of the data for the extra fields and doesn't need to do that.

I considered having the other loop read in all of the data for the extra fields so there could be a shared helper, but the data is variable length, so that would have required having a large fixed-size buffer or allocating memory, which this code seems to be trying to avoid.

Do you see a good way to share the loop?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544768965

From jiangli at openjdk.org  Fri Mar 29 19:57:31 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 29 Mar 2024 19:57:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <XUYODMuRS6XfGuAgXViZ_L5ESbwqlPu5SfJmODyv6KI=.0ff24f29-9c13-41e3-948d-fa2c20d32df6@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>
Message-ID: <Gqic1iX5dcKEkn0uBtvcBpqloUH1QcLCEjGgHMjaQ-8=.1ddc1947-f7f9-4d1d-8b43-656753218957@github.com>

On Fri, 29 Mar 2024 18:41:09 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/java.base/share/native/libjli/parse_manifest.c line 197:
>> 
>>> 195:   jlong cenoff = CENOFF(cenhdr);
>>> 196:   jlong cenext = CENEXT(cenhdr);
>>> 197:   if (cenoff == ZIP64_MAGICVAL && cenext > 0) {
>> 
>> Probably also need to check if `cenlen` or `censiz` is ZIP64_MAGICVAL?
>
> 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?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1544820598

From bchristi at openjdk.org  Fri Mar 29 20:41:49 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 29 Mar 2024 20:41:49 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v19]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <zXNhXn6hpbCQAMaZqCedAtqemB8tAqxg-9EaVaO9vCY=.596b3321-5221-43a8-a7da-60bf732c9d6a@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:

  Re-remove paragraph break

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/0748ed04..4648d064

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 bchristi at openjdk.org  Fri Mar 29 20:48:09 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 29 Mar 2024 20:48:09 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v20]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <zaNYbEwbrsNO0cHpiVOQdTHoRah2Y7mNtnx7TBlFvU8=.5bf10d68-1a75-4a80-a6e1-64b97be266a1@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:

  Stray blank line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/4648d064..170c9814

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=18-19

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 tprinzing at openjdk.org  Fri Mar 29 20:51:31 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Fri, 29 Mar 2024 20:51:31 GMT
Subject: RFR: 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: <u2efcIPGCJXkSOQMCdqOT3LVLRqW42S-uRuMcwVoPPs=.2975a724-467c-4b62-852a-691b07bfe2d9@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.

Okay, I'll update those two places to emit the event.  It looks like adding a file descriptor property to the event is needed, and there would be no file path in those cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2027722419

From sgibbons at openjdk.org  Fri Mar 29 22:39:11 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 29 Mar 2024 22:39:11 GMT
Subject: RFR: 8329331: Intrinsify Unsafe::setMemory
Message-ID: <5bNiITzJzFEdC6ARozUJBF2NCQaCLdHe_QwKIkcgwfU=.b87cab09-81b8-43f3-bf7a-e2b641881f9c@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)

-------------

Commit messages:
 - Clean up code for PR
 - Fixed bug - incorrect interface to *_fill_entry
 - Address review comment
 - Restore intrinsic
 - Add benchmark
 - Test removing intrinsic
 - Removed setMemory1; debugged intrinsic code
 - Added actual intrinsic
 - Add Unsafe.setMemory as intrinsic

Changes: https://git.openjdk.org/jdk/pull/18555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329331
  Stats: 362 lines in 21 files changed: 311 ins; 49 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 jiefu at openjdk.org  Sat Mar 30 02:30:55 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Sat, 30 Mar 2024 02:30:55 GMT
Subject: RFR: 8329354: java/text/Format/MessageFormat/CompactSubFormats.java
 fails
Message-ID: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>

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

-------------

Commit messages:
 - 8329354: java/text/Format/MessageFormat/CompactSubFormats.java fails

Changes: https://git.openjdk.org/jdk/pull/18557/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18557&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329354
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18557.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18557/head:pull/18557

PR: https://git.openjdk.org/jdk/pull/18557

From jiefu at openjdk.org  Sat Mar 30 02:32:40 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Sat, 30 Mar 2024 02:32:40 GMT
Subject: RFR: JDK-8329118: Run MessageFormat additional subformat pattern
 tests under en_US locale [v4]
In-Reply-To: <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>
Message-ID: <0CnJenyEVXAB2BQa9-u9TJzfW6a3kTAgez9barB0m9k=.ecf1c355-d9bd-480d-948d-b7ed8b31d652@github.com>

On Tue, 26 Mar 2024 23:32:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
>> 
>> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
>> 
>> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop loc field for US constant

Hi, please see the test failure: https://github.com/openjdk/jdk/pull/18557
Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18498#issuecomment-2027884264

From jiangli at openjdk.org  Sat Mar 30 03:24:35 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 30 Mar 2024 03:24:35 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <61iK9MNKUtcqjAtlw60xe8FMq9Vlkh187UmIupEs-ak=.b8ddfe14-226e-46ec-b94a-e0579778972b@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
 <VjU5pqgy901DyvRdYqIUPVqgV6ueuiBjRTMZ88DVWME=.e336162b-c009-48cc-90cd-a7d58c87e6b4@github.com>
 <61iK9MNKUtcqjAtlw60xe8FMq9Vlkh187UmIupEs-ak=.b8ddfe14-226e-46ec-b94a-e0579778972b@github.com>
Message-ID: <mgdwKmoScpaYp7aJpL-AUGHGFLF7zvrPPNZwgPA1HYo=.55387c0b-9495-4f45-8c56-b8d6dcd66a0f@github.com>

On Fri, 29 Mar 2024 18:43:51 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/java.base/share/native/libjli/parse_manifest.c line 506:
>> 
>>> 504:               jlong offset = 0;
>>> 505:               while (offset < cenext) {
>>> 506:                 short headerId = ZIPEXT_HDR(base + offset);
>> 
>> This block of code is very similar to the corresponding part (reading the ZIP64 extension extra fields) in `validate_lochdr`. Perhaps also refractor to a common helper function?
>
> The other loop uses `readAt` to read in additional data and advance through the extra fields, this loop already has access to a buffer that contains all of the data for the extra fields and doesn't need to do that.
> 
> I considered having the other loop read in all of the data for the extra fields so there could be a shared helper, but the data is variable length, so that would have required having a large fixed-size buffer or allocating memory, which this code seems to be trying to avoid.
> 
> Do you see a good way to share the loop?

How about something like the following (I haven't tried to compile or test, please double check if everything is correct)? The size of the extra fields is recorded in the 2-byte field, `extra field length`, so we can just read all extra fields in a temp buffer. It causes less overhead with just one read. 


jboolean read_zip64_ext(int fd, jlong censtart, jlong base_offset, Byte *cenhdr,
                                           jboolean check_offset_only, jboolean read_extra_fields) {
  jlong cenlen = CENLEN(cenhdr);
  jlong censiz = CENSIZ(cenhdr);
  jlong cenoff = CENOFF(cenhdr);
  if (cenoff == ZIP64_MAGICVAL ||
      (!check_offset_only && (censiz == ZIP64_MAGICVAL || cenlen == ZIP64_MAGICVAL))) {
    jlong cenext = CENEXT(cenhdr);
    if (cenext == 0) {
      return JNI_FALSE;
    }

    jlong start = censtart + CENHDR + CENNAM(cenhdr);
    jlong offset = 0;
    Byte *p = start;

    // Read the extra fields if needed.
    if (read_extra_fields) {
      *p = (Byte*)malloc(cenext);
      if (p == NULL) {
        return JNI_FALSE;
      }
      if (!readAt(fd, start + offset, cenext, p)) {
        free(p);
        return JNI_FALSE;
      } 
    }
    
    while (offset < cenext) { 
      short headerId = ZIPEXT_HDR(p + offset);
      short headerSize = ZIPEXT_SIZ(p + offset);
      if (headerId == ZIP64_EXTID) {
        if (!read_zip64_ext(p, &cenlen, &censiz, &cenoff, CENDSK(cenhdr))) {
          if (p != start) {
            free(p);
          }
          return JNI_FALSE;
        }
        break;
      }
      offset += 4 + headerSize;
    }
  }
  
  if (p != start) {
    free(p);
  }
  return JNI_TRUE;
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1545055704

From cushon at openjdk.org  Sat Mar 30 03:49:31 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 30 Mar 2024 03:49:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <mgdwKmoScpaYp7aJpL-AUGHGFLF7zvrPPNZwgPA1HYo=.55387c0b-9495-4f45-8c56-b8d6dcd66a0f@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
 <VjU5pqgy901DyvRdYqIUPVqgV6ueuiBjRTMZ88DVWME=.e336162b-c009-48cc-90cd-a7d58c87e6b4@github.com>
 <61iK9MNKUtcqjAtlw60xe8FMq9Vlkh187UmIupEs-ak=.b8ddfe14-226e-46ec-b94a-e0579778972b@github.com>
 <mgdwKmoScpaYp7aJpL-AUGHGFLF7zvrPPNZwgPA1HYo=.55387c0b-9495-4f45-8c56-b8d6dcd66a0f@github.com>
Message-ID: <JjK7dv0H9CF0DdKhN7fu-mRvp_T4eM2z3OaHGCmU5xQ=.20052925-c647-4504-8574-419dde0a790c@github.com>

On Sat, 30 Mar 2024 03:21:39 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> The other loop uses `readAt` to read in additional data and advance through the extra fields, this loop already has access to a buffer that contains all of the data for the extra fields and doesn't need to do that.
>> 
>> I considered having the other loop read in all of the data for the extra fields so there could be a shared helper, but the data is variable length, so that would have required having a large fixed-size buffer or allocating memory, which this code seems to be trying to avoid.
>> 
>> Do you see a good way to share the loop?
>
> How about something like the following (I haven't tried to compile or test, please double check if everything is correct)? The size of the extra fields is recorded in the 2-byte field, `extra field length`, so we can just read all extra fields in a temp buffer. It causes less overhead with just one read. 
> 
> 
> jboolean read_zip64_ext(int fd, jlong censtart, jlong base_offset, Byte *cenhdr,
>                                            jboolean check_offset_only, jboolean read_extra_fields) {
>   jlong cenlen = CENLEN(cenhdr);
>   jlong censiz = CENSIZ(cenhdr);
>   jlong cenoff = CENOFF(cenhdr);
>   if (cenoff == ZIP64_MAGICVAL ||
>       (!check_offset_only && (censiz == ZIP64_MAGICVAL || cenlen == ZIP64_MAGICVAL))) {
>     jlong cenext = CENEXT(cenhdr);
>     if (cenext == 0) {
>       return JNI_FALSE;
>     }
> 
>     jlong start = censtart + CENHDR + CENNAM(cenhdr);
>     jlong offset = 0;
>     Byte *p = start;
> 
>     // Read the extra fields if needed.
>     if (read_extra_fields) {
>       *p = (Byte*)malloc(cenext);
>       if (p == NULL) {
>         return JNI_FALSE;
>       }
>       if (!readAt(fd, start + offset, cenext, p)) {
>         free(p);
>         return JNI_FALSE;
>       } 
>     }
>     
>     while (offset < cenext) { 
>       short headerId = ZIPEXT_HDR(p + offset);
>       short headerSize = ZIPEXT_SIZ(p + offset);
>       if (headerId == ZIP64_EXTID) {
>         if (!read_zip64_ext(p, &cenlen, &censiz, &cenoff, CENDSK(cenhdr))) {
>           if (p != start) {
>             free(p);
>           }
>           return JNI_FALSE;
>         }
>         break;
>       }
>       offset += 4 + headerSize;
>     }
>   }
>   
>   if (p != start) {
>     free(p);
>   }
>   return JNI_TRUE;
> }

I think that's similar idea to one of the alternatives I mentioned earlier, won't that allocate for every central directory entry? This callsite has already read the data we need into a buffer, if we end up doing something like that it might be better to do the allocation only for the call site in `validate_lochdr`, and have the shared helper take the pointer to the buffer instead of having a duplicate read.

It seems like there are some tradeoffs here, I can definitely restructure this, but I'd also like to get some feedback from a core-libs owner on the overall approach before iterating too much more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1545070043

From alanb at openjdk.org  Sat Mar 30 10:08:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 30 Mar 2024 10:08:30 GMT
Subject: RFR: 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: <5WxpEWPgGFA1cNFyaD0ww5qSGnC1a1axgcgzBcH22CA=.6b54905a-92fd-4d2c-84cf-ffabd88be2c0@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.

> It looks like adding a file descriptor property to the event is needed, and there would be no file path in those cases.

The AsynchonrousFileChannel implementations can keep a reference to the file path, that should be easy. FileDescriptor.sync does need more thought, maybe it's not worth doing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2028000449

From jiangli at openjdk.org  Sat Mar 30 17:30:38 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 30 Mar 2024 17:30:38 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <JjK7dv0H9CF0DdKhN7fu-mRvp_T4eM2z3OaHGCmU5xQ=.20052925-c647-4504-8574-419dde0a790c@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
 <VjU5pqgy901DyvRdYqIUPVqgV6ueuiBjRTMZ88DVWME=.e336162b-c009-48cc-90cd-a7d58c87e6b4@github.com>
 <61iK9MNKUtcqjAtlw60xe8FMq9Vlkh187UmIupEs-ak=.b8ddfe14-226e-46ec-b94a-e0579778972b@github.com>
 <mgdwKmoScpaYp7aJpL-AUGHGFLF7zvrPPNZwgPA1HYo=.55387c0b-9495-4f45-8c56-b8d6dcd66a0f@github.com>
 <JjK7dv0H9CF0DdKhN7fu-mRvp_T4eM2z3OaHGCmU5xQ=.20052925-c647-4504-8574-419dde0a790c@github.com>
Message-ID: <1S1h4wfnnX8pnSloDDN3599roWTzAPytlcZWy_MFH5o=.3b11e72f-fe85-4c40-ace7-fbb07af21e3c@github.com>

On Sat, 30 Mar 2024 03:47:10 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> I think that's similar idea to one of the alternatives I mentioned earlier, won't that allocate for every central directory entry?

Ok. Re-reading your earlier comment more closely, I see you mentioned allocating memory option.

The allocation of the buffer for reading extra fields is only done when needed (if `cen_offset` is `ZIP64_MAGICVAL` for the validate_lochdr case). I think I'm missing the part about the "allocate for every central directory entry" with the approach. Could you please elaborate a bit more?

> This callsite has already read the data we need into a buffer, if we end up doing something like that it might be better to do the allocation only for the call site in `validate_lochdr`, and have the shared helper take the pointer to the buffer instead of having a duplicate read.
> 
> It seems like there are some tradeoffs here, I can definitely restructure this, but I'd also like to get some feedback from a core-libs owner on the overall approach before iterating too much more.

Yeah, agreed. It's a good idea to have someone work closely with ZIP and have more insights on central directory structure to take a look at this change now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1545465731

From cushon at openjdk.org  Sat Mar 30 18:32:31 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 30 Mar 2024 18:32:31 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v4]
In-Reply-To: <1S1h4wfnnX8pnSloDDN3599roWTzAPytlcZWy_MFH5o=.3b11e72f-fe85-4c40-ace7-fbb07af21e3c@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <eNXbh5sPTQEffiePWBmolsrwuUs9uapg1UJQYeBnHyU=.3f0e37a3-f40c-4984-ac06-434e72ec3ddb@github.com>
 <VjU5pqgy901DyvRdYqIUPVqgV6ueuiBjRTMZ88DVWME=.e336162b-c009-48cc-90cd-a7d58c87e6b4@github.com>
 <61iK9MNKUtcqjAtlw60xe8FMq9Vlkh187UmIupEs-ak=.b8ddfe14-226e-46ec-b94a-e0579778972b@github.com>
 <mgdwKmoScpaYp7aJpL-AUGHGFLF7zvrPPNZwgPA1HYo=.55387c0b-9495-4f45-8c56-b8d6dcd66a0f@github.com>
 <JjK7dv0H9CF0DdKhN7fu-mRvp_T4eM2z3OaHGCmU5xQ=.20052925-c647-4504-8574-419dde0a790c@github.com>
 <1S1h4wfnnX8pnSloDDN3599roWTzAPytlcZWy_MFH5o=.3b11e72f-fe85-4c40-ace7-fbb07af21e3c@github.com>
Message-ID: <VzsRsValAAdMgWTTCN2l8OHR_XepWSoLAijd3SDOf2c=.63954be3-c9a0-4e5f-947b-ba28a8b04a7f@github.com>

On Sat, 30 Mar 2024 17:28:11 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> I think that's similar idea to one of the alternatives I mentioned earlier, won't that allocate for every central directory entry? This callsite has already read the data we need into a buffer, if we end up doing something like that it might be better to do the allocation only for the call site in `validate_lochdr`, and have the shared helper take the pointer to the buffer instead of having a duplicate read.
>> 
>> It seems like there are some tradeoffs here, I can definitely restructure this, but I'd also like to get some feedback from a core-libs owner on the overall approach before iterating too much more.
>
>> I think that's similar idea to one of the alternatives I mentioned earlier, won't that allocate for every central directory entry?
> 
> Ok. Re-reading your earlier comment more closely, I see you mentioned allocating memory option.
> 
> The allocation of the buffer for reading extra fields is only done when needed (if `cen_offset` is `ZIP64_MAGICVAL` for the validate_lochdr case). I think I'm missing the part about the "allocate for every central directory entry" with the approach. Could you please elaborate a bit more?
> 
>> This callsite has already read the data we need into a buffer, if we end up doing something like that it might be better to do the allocation only for the call site in `validate_lochdr`, and have the shared helper take the pointer to the buffer instead of having a duplicate read.
>> 
>> It seems like there are some tradeoffs here, I can definitely restructure this, but I'd also like to get some feedback from a core-libs owner on the overall approach before iterating too much more.
> 
> Yeah, agreed. It's a good idea to have someone work closely with ZIP and have more insights on central directory structure to take a look at this change now.

The alternative I looked at was something like https://github.com/openjdk/jdk/commit/04e4410bb0c250ee270dda10bcf2dbd5aac90743. It avoids duplicating the loop and makes the diff very slightly shorter, but requires doing a `malloc(cenext)`. I think I was mistaken about 'allocate for every central directory entry', `validate_lochdr` should only be a small constant number of times. That still seems a little unfortunate because we don't know how big `cenext` is, but maybe that's not worth worrying about.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1545474395

From jlu at openjdk.org  Sat Mar 30 22:03:31 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 30 Mar 2024 22:03: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: <YC6n_tlt_PA0Wz_9xwJwR8c8SCJm8HHotJXsMVif8rU=.cbdd4307-1e3a-47b5-a29e-b4250c67dffc@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

Hi Jie,

This is indeed the correct solution to ensure that the DecimalFormat, (specifically, the underlying DecimalFormatSymbols) has the same locale as the MessageFormat subformat.

Thank you for the fix, it LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18557#pullrequestreview-1970062699

From jiefu at openjdk.org  Sun Mar 31 11:03:30 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 31 Mar 2024 11:03:30 GMT
Subject: RFR: 8329354:
 java/text/Format/MessageFormat/CompactSubFormats.java fails
In-Reply-To: <YC6n_tlt_PA0Wz_9xwJwR8c8SCJm8HHotJXsMVif8rU=.cbdd4307-1e3a-47b5-a29e-b4250c67dffc@github.com>
References: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
 <YC6n_tlt_PA0Wz_9xwJwR8c8SCJm8HHotJXsMVif8rU=.cbdd4307-1e3a-47b5-a29e-b4250c67dffc@github.com>
Message-ID: <hQHRsRgkNADsegx73q2LegWbTD2z6O6ytUKqrbYYDBc=.05d322e5-f5dd-4417-8086-5e5284fadce0@github.com>

On Sat, 30 Mar 2024 22:00:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This is indeed the correct solution to ensure that the DecimalFormat, (specifically, the underlying DecimalFormatSymbols) has the same locale as the MessageFormat subformat.

Thanks @justin-curtis-lu for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18557#issuecomment-2028644596