From duke at openjdk.org  Sat Jun  1 00:15:05 2024
From: duke at openjdk.org (xiaotaonan)
Date: Sat, 1 Jun 2024 00:15:05 GMT
Subject: Withdrawn: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
References: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
Message-ID: <yK1r77_h7TlU3YkV8RTZvIFLJ5_R22pLjKzg8X4KP_4=.5f54e7e4-d708-4bc0-9b4f-b223a1be1290@github.com>

On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Clean up non-standard use of /// comments in `java.base`

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Sat Jun  1 01:45:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Jun 2024 01:45:08 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
In-Reply-To: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
Message-ID: <5lZInTjc2WI4OVBkZG06EMR_T9kJMOhmhua5Jze6bdA=.be4a8991-6cf2-48d9-bc60-ff704c8ccdcc@github.com>

On Fri, 17 May 2024 12:01:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
> 
> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.

Indeed, I put the JBS issue to target release 24. I believe given the potential behavioral changes, rushing into release 23 is a risky choice. (the 4 new tests can target 23 in a separate patch, but they require removal of a few redundant assertions in old generic code)

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

PR Comment: https://git.openjdk.org/jdk/pull/19281#issuecomment-2143205523

From almatvee at openjdk.org  Sat Jun  1 02:01:07 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 1 Jun 2024 02:01:07 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
Message-ID: <mgChbJhjQHFA_sVa7DrysbOBupE0Ri1VXuGuvKUgPyY=.3fa2d8e8-904f-4e94-ad7d-7a78a64f59cb@github.com>

On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.
> 
> Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.
> 
> These loopholes were eliminated:
> 
>  - stdout and stderr of app launchers is never suppressed;
>  - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
>  - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.
> 
> Other changes are due to changes in HelloApp.AppOutputVerifier class.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19502#pullrequestreview-2091922907

From jpai at openjdk.org  Sat Jun  1 04:38:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 1 Jun 2024 04:38:26 GMT
Subject: RFR: 8026127: Deflater/Inflater documentation incomplete/misleading
Message-ID: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>

Can I please get a review of this doc-only change which proposes to improve the code snippet that's in `java.util.zip.Deflater` and `java.util.zip.Inflater` to better explain the usage of those classes? This addresses https://bugs.openjdk.org/browse/JDK-8026127.

The commit in the PR cleans up the snippet to correctly compress/decompress till the `Deflater` and `Inflater` are `finished()`.  Additionally, the snippet also shows that the `Deflater` and `Inflater` are expected to be closed when their usage it done, to release the resources held by those instances.

I've run `make docs-image` locally to verify that the generated snippet content as well as the link from `Inflater` work fine in the rendered javadoc HTML.

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

Commit messages:
 - 8026127: Deflater/Inflater documentation incomplete/misleading

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

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

From jpai at openjdk.org  Sat Jun  1 05:18:17 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 1 Jun 2024 05:18:17 GMT
Subject: RFR: 7022325: TEST_BUG:
 test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails
 [v2]
In-Reply-To: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
References: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
Message-ID: <AsIhELH4VDUAfr6wtIP1N9KTyvK7PctasigJnSDUS5Y=.d507cfc0-4eeb-4f81-ac2f-3549e4e4e87f@github.com>

> Can I please get a review of this test-only change which updates a couple of places in the test to use `try-with-resource`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-7022325 this change should prevent leaking of resources in case there's any failure in the test. The test continues to pass with this change.

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

  convert the test to junit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19492/files
  - new: https://git.openjdk.org/jdk/pull/19492/files/3ce9ca81..b9d56006

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

  Stats: 122 lines in 1 file changed: 28 ins; 60 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/19492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19492/head:pull/19492

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

From jpai at openjdk.org  Sat Jun  1 05:23:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 1 Jun 2024 05:23:03 GMT
Subject: RFR: 8333270: HandlersOnComplexResetUpdate and
 HandlersOnComplexUpdate tests fail with "Unexpected reference" if
 timeoutFactor is less than 1/3
In-Reply-To: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>
References: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>
Message-ID: <wz9mArPySKPc9M8x7ob5gavv81namVBZSu6F1tb_51o=.644b7d0f-2e3b-489f-856b-53f66e42ad9f@github.com>

On Fri, 31 May 2024 14:55:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that loggers are GC'ed (or not GC'ed) after a reset or an update. For that they poll a ReferenceQueue in a loop. The number of iteration is adjusted according to the jtreg timeout factor. However, the logic in the test did not expect that the timeout might be less than 1.
> 
> This fix does two things:
> 
> 1. fix the adjustCount logic - so that the number of iteration can only be increased
> 2. use remove(timeout) instead of poll() in order to minimize the waiting time.

test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java line 219:

> 217:         }
> 218:         WeakReference<Logger> barRef = new WeakReference<>(Logger.getLogger("com.bar"), queue);
> 219:         if (!barRef.refersTo(barChild.getParent())) {

Hello Daniel, since `refersTo()` is the preferred API in cases like this, should this same change be done in the other `HandlersOnComplexUpdate` test that's being updated in this PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19503#discussion_r1623151595

From jpai at openjdk.org  Sat Jun  1 05:44:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 1 Jun 2024 05:44:01 GMT
Subject: RFR: 7022325: TEST_BUG:
 test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails
 [v2]
In-Reply-To: <AsIhELH4VDUAfr6wtIP1N9KTyvK7PctasigJnSDUS5Y=.d507cfc0-4eeb-4f81-ac2f-3549e4e4e87f@github.com>
References: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
 <AsIhELH4VDUAfr6wtIP1N9KTyvK7PctasigJnSDUS5Y=.d507cfc0-4eeb-4f81-ac2f-3549e4e4e87f@github.com>
Message-ID: <dr98Wyg67F9vc2OhjdmcJ3X59xQLbzuGZBspTK4ONFY=.a9ce6c53-d8ee-408b-8be6-5038e826b897@github.com>

On Sat, 1 Jun 2024 05:18:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which updates a couple of places in the test to use `try-with-resource`?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-7022325 this change should prevent leaking of resources in case there's any failure in the test. The test continues to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert the test to junit

Hello Lance, I have now updated the PR to convert this test to junit test. While at it, I have also cleaned up the code to use `java.nio.file.Path` and use the jtreg scratch directory for the directories and the jar file this test creates. That way, we don't have to manually delete the directories when done. I have verified that the changes don't change the semantics of what was being tested in this test, which was a regression test for https://bugs.openjdk.org/browse/JDK-6374379.

The test continues to pass with these change in our CI against all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/19492#issuecomment-2143307371

From vklang at openjdk.org  Sat Jun  1 11:54:25 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 1 Jun 2024 11:54:25 GMT
Subject: RFR: 8327854: Test
 java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java
 failed with RuntimeException
Message-ID: <XE6lPDBjL0xi1Fc1AtuqboMDM9EdeD1wq_O3NcXMj0Q=.acaacd2d-7a06-40d0-8208-8719b39721e0@github.com>

This PR improves the test failure output for the failing test case, and the underlying issue is likely going to be addressed by https://github.com/openjdk/jdk/pull/19131 /cc @DougLea

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

Commit messages:
 - Improving the failure output of WhileOpStatefulTest

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

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

From asemenyuk at openjdk.org  Sat Jun  1 12:34:05 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 1 Jun 2024 12:34:05 GMT
Subject: Integrated: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
Message-ID: <ut3WpWuycVj9JOUMuZwJ2ljqgSMAy9hBpDnAkpZ8IHE=.0e238dbc-a6c9-4c7c-a062-500dc6b117db@github.com>

On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.
> 
> Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.
> 
> These loopholes were eliminated:
> 
>  - stdout and stderr of app launchers is never suppressed;
>  - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
>  - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.
> 
> Other changes are due to changes in HelloApp.AppOutputVerifier class.

This pull request has now been integrated.

Changeset: 24530022
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/24530022d066763f7573f5c6d2030a30dc55afa6
Stats:     122 lines in 5 files changed: 48 ins; 41 del; 33 mod

8331977: Crash: SIGSEGV in dlerror()

Reviewed-by: almatvee

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

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

From lancea at openjdk.org  Sat Jun  1 20:12:01 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 1 Jun 2024 20:12:01 GMT
Subject: RFR: 7022325: TEST_BUG:
 test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails
 [v2]
In-Reply-To: <AsIhELH4VDUAfr6wtIP1N9KTyvK7PctasigJnSDUS5Y=.d507cfc0-4eeb-4f81-ac2f-3549e4e4e87f@github.com>
References: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
 <AsIhELH4VDUAfr6wtIP1N9KTyvK7PctasigJnSDUS5Y=.d507cfc0-4eeb-4f81-ac2f-3549e4e4e87f@github.com>
Message-ID: <FqVURBJ9JPSDzZL9qoBgVMlIeER5R6HREjoDL_TEIg4=.ab2d24ca-ce83-4ea7-920e-cf637d8f8781@github.com>

On Sat, 1 Jun 2024 05:18:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which updates a couple of places in the test to use `try-with-resource`?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-7022325 this change should prevent leaking of resources in case there's any failure in the test. The test continues to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert the test to junit

thank you Jai,  changes look good

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19492#pullrequestreview-2092169070

From jpai at openjdk.org  Sun Jun  2 01:11:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 2 Jun 2024 01:11:07 GMT
Subject: Integrated: 7022325: TEST_BUG:
 test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails
In-Reply-To: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
References: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
Message-ID: <xlsqFGyf8v9KtgBtE3kmxBNKF3DF09MHaeH6-F1TFKA=.9371ea80-aba1-47bf-9e29-ff3894243a89@github.com>

On Fri, 31 May 2024 00:57:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which updates a couple of places in the test to use `try-with-resource`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-7022325 this change should prevent leaking of resources in case there's any failure in the test. The test continues to pass with this change.

This pull request has now been integrated.

Changeset: 4785461f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4785461f61d8f5c7444d2e6fd90f1e083dbc6fe4
Stats:     128 lines in 1 file changed: 34 ins; 68 del; 26 mod

7022325: TEST_BUG: test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails

Reviewed-by: lancea

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

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

From jpai at openjdk.org  Sun Jun  2 01:11:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 2 Jun 2024 01:11:06 GMT
Subject: RFR: 7022325: TEST_BUG:
 test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails
 [v2]
In-Reply-To: <AsIhELH4VDUAfr6wtIP1N9KTyvK7PctasigJnSDUS5Y=.d507cfc0-4eeb-4f81-ac2f-3549e4e4e87f@github.com>
References: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
 <AsIhELH4VDUAfr6wtIP1N9KTyvK7PctasigJnSDUS5Y=.d507cfc0-4eeb-4f81-ac2f-3549e4e4e87f@github.com>
Message-ID: <KKIu28vu8iFiVzS_ovdRWEiNyu4evR23Dh1rNcsPk5U=.450a8725-a46b-4ab3-921f-79a2db7ccd79@github.com>

On Sat, 1 Jun 2024 05:18:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which updates a couple of places in the test to use `try-with-resource`?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-7022325 this change should prevent leaking of resources in case there's any failure in the test. The test continues to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert the test to junit

Thank you Lance for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19492#issuecomment-2143653405

From vklang at openjdk.org  Sun Jun  2 14:36:09 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sun, 2 Jun 2024 14:36:09 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
Message-ID: <s_luHSrCCy_tcgxoO1g-7ruuk3pxMjua6jMpRLJYiYE=.a503aced-9a3d-4616-839d-615b9fea2d70@github.com>

On Fri, 31 May 2024 13:18:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reconcile changes

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1345:

> 1343:             int b = base, p = top, cap;
> 1344:             if (p - b > 0 && a != null && (cap = a.length) > 0) {
> 1345:                 for (int m = cap - 1, s, nb;;) {

@DougLea I'm curious, what effect did you see if moving the `p - b > 0` out of the loop conditional?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1623453077

From alanb at openjdk.org  Sun Jun  2 17:45:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 2 Jun 2024 17:45:13 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
Message-ID: <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>

On Wed, 22 May 2024 13:23:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 110 commits:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Fix new line in jlink.properties
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>  - Only add runtime track files for linkable runtimes
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Use shorter name for the build tool
>  - Review feedback from Erik J.
>  - Remove dependency on CDS which isn't needed anymore
>  - ... and 100 more: https://git.openjdk.org/jdk/compare/4f1a10f8...e1e3f02f

I've been looking through the changes. One thing that I'm wondering about is whether --generate-runtime-link-image should disable the keeping of packaged modules (set JLINK_KEEP_PACKAGED_MODULES to false). It seems surprising to use this configure option and have the jlink command in the build also copy the packaged modules into the image.

(Doing that would of course mean that several existing jlink tests would need some changes, either to `@requires` or to remove the checks for the `jmods` directory)

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

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

From duke at openjdk.org  Mon Jun  3 04:22:19 2024
From: duke at openjdk.org (lingjun-cg)
Date: Mon, 3 Jun 2024 04:22:19 GMT
Subject: RFR: 8333396: Performance regression of new DecimalFormat and
 DecimalFormat.format
Message-ID: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>

### Performance regression of DecimalFormat.format
>From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
So I added support for some new methods that accept StringBuilder which is lock-free.

### Performance regression of new DecimalFormat
After comparing the flame graph between current jdk and jdk 11,  the method java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time.  The performance becomes as good as jdk11 after replacing it with a simple loop implementation.

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

Commit messages:
 - 8333396: Performance regression of new DecimalFormat and DecimalFormat.format

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

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

From jpai at openjdk.org  Mon Jun  3 04:31:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Jun 2024 04:31:27 GMT
Subject: RFR: 8333398: Uncomment the commented test in
 test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java
Message-ID: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>

Can I please get a review of this test-only change which uncomments an additional test that was commented out in `test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java`?

As noted in https://bugs.openjdk.org/browse/JDK-8333398, the original issue due to which this line was commented out in the test, has been fixed several releases back and thus this line can now be uncommented.

I've verified that this test continues to pass with these changes.

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

Commit messages:
 - 8333398: Uncomment the commented test in test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java

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

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

From jpai at openjdk.org  Mon Jun  3 05:11:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Jun 2024 05:11:16 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's limited
 to Integer.MAX_VALUE
Message-ID: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>

Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?

`InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.

The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.

I'll open a CSR for this change.

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

Commit messages:
 - 8206447: InflaterInputStream.skip receives long but it's limited to Integer.MAX_VALUE

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

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

From iris at openjdk.org  Mon Jun  3 05:36:03 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 3 Jun 2024 05:36:03 GMT
Subject: RFR: 8333398: Uncomment the commented test in
 test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java
In-Reply-To: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>
References: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>
Message-ID: <h9kJfEvhWZuNnubLu6hJ9j0s7-6PCccyZhvPo7G_V6s=.a19698b4-1fc0-4e61-ac87-428c6778ac25@github.com>

On Mon, 3 Jun 2024 04:25:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which uncomments an additional test that was commented out in `test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8333398, the original issue due to which this line was commented out in the test, has been fixed several releases back and thus this line can now be uncommented.
> 
> I've verified that this test continues to pass with these changes.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19514#pullrequestreview-2092824056

From jpai at openjdk.org  Mon Jun  3 05:46:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Jun 2024 05:46:30 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE [v2]
In-Reply-To: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
Message-ID: <jgYqeVtocF9Qsi9AgSoIdJP0t0a7OO41CyMBRyeRUI0=.be89e0c4-965d-47c4-a545-4e04cb368039@github.com>

> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
> 
> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
> 
> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
> 
> I'll open a CSR for this change.

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

  also note that the method may block, just like DeflaterInputStream specifies it

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19515/files
  - new: https://git.openjdk.org/jdk/pull/19515/files/2a116fe4..e13e65d2

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

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

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

From jpai at openjdk.org  Mon Jun  3 05:46:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Jun 2024 05:46:30 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE
In-Reply-To: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
Message-ID: <LmnIpO2KxJ7Yzi_DbynoillkgKDPjlnuWfBOejC6v_k=.3937a49b-d300-4aad-9489-2ba48c62a07b@github.com>

On Mon, 3 Jun 2024 05:06:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
> 
> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
> 
> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
> 
> I'll open a CSR for this change.

The CSR is available for review at https://bugs.openjdk.org/browse/JDK-8333400

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

PR Comment: https://git.openjdk.org/jdk/pull/19515#issuecomment-2144323834

From duke at openjdk.org  Mon Jun  3 06:13:35 2024
From: duke at openjdk.org (lingjun-cg)
Date: Mon, 3 Jun 2024 06:13:35 GMT
Subject: RFR: 8333396: Performance regression of new DecimalFormat and
 DecimalFormat.format [v2]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <-uD4Wih5e1lvOwd2KFhBfcDKN1PrDr2aL_EVz1NzBC0=.48a676c7-cbac-422c-b3a5-763db15473ca@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Performance regression of new DecimalFormat
> After comparing the flame graph between current jdk and jdk 11,  the method java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time.  The performance becomes as good as jdk11 after replacing it with a simple loop implementation.
> 
> 
> 
> ### Test result
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of new DecimalFormat and DecimalFormat.format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/a6755f8f..b48962b5

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

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

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

From shade at openjdk.org  Mon Jun  3 08:13:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 3 Jun 2024 08:13:04 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v6]
In-Reply-To: <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>
Message-ID: <xJF02yBN_QU-0ck6Fafjpe6LJgh9ZMI8hPGvIeNx4jk=.d3a70088-113d-486f-9aa0-f47a2888005a@github.com>

On Fri, 31 May 2024 18:39:33 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing nits in benchmark

I believe GHA failure (serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage, x86_32) is unrelated to this change, it is a known issue fixed in current master. We can proceed with integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2144546824

From dholmes at openjdk.org  Mon Jun  3 08:40:09 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Jun 2024 08:40:09 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
Message-ID: <nQP1t6EuMVLeGihN8RTSfFMqMEJP77BEvoeb7pElQUg=.7ba77c32-a98d-4d7e-ad3b-040f8597264c@github.com>

On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.
> 
> Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.
> 
> These loopholes were eliminated:
> 
>  - stdout and stderr of app launchers is never suppressed;
>  - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
>  - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.
> 
> Other changes are due to changes in HelloApp.AppOutputVerifier class.

I am yet to see anything that actually explains the cause of the `dlerror` crash here ???

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

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2144616488

From sgehwolf at openjdk.org  Mon Jun  3 09:23:12 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 3 Jun 2024 09:23:12 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v3]
In-Reply-To: <fjbRaZcJI5fetXc1CnGpQK18sjgkhp2Ir6UWNhzYvLs=.f7bd259d-dc6a-46ea-bb58-e062d18eeedb@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <fjbRaZcJI5fetXc1CnGpQK18sjgkhp2Ir6UWNhzYvLs=.f7bd259d-dc6a-46ea-bb58-e062d18eeedb@github.com>
Message-ID: <dlnwQnVZ44GdDWZh-A9dfu85krPjrVlqe1Gu5byG5qI=.b8fb25f3-e530-48be-abb9-24b17e737a5f@github.com>

On Fri, 3 May 2024 16:05:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/88976cae...434430ca

Keep open bot. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2144706137

From duke at openjdk.org  Mon Jun  3 09:51:09 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 3 Jun 2024 09:51:09 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v10]
In-Reply-To: <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
 <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>
 <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
Message-ID: <tFHKOcQaqMAUnHcHsaXmnPp4fIiPV09Yoa9W7i1a6AY=.2f040ccc-c991-4ac6-b00a-241608cad8de@github.com>

On Wed, 22 May 2024 22:38:16 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/CallStaticInitOrder.java line 54:
>> 
>>> 52: 
>>> 53:     static int Init1Tick;
>>> 54:     public static class Init1 {
>> 
>> Is there a reason to change all the classes and methods to public?
>
> the test throws a java.lang.IllegalAccessError

Changed to original access modifier

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1624137975

From ihse at openjdk.org  Mon Jun  3 10:07:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 3 Jun 2024 10:07:05 GMT
Subject: Integrated: 8333301: Remove static builds using --enable-static-build
In-Reply-To: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
References: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
Message-ID: <iLIAigxyDkioN6NnVfeYkfLX7CvkZLROuZBZxI6FNQM=.0f408982-44ab-4ba8-9d15-e2a0b94bb210@github.com>

On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The original way of building static libraries in the JDK was to use the configure argument --enable-static-build, which set the value of the make variable STATIC_BUILD. (Note that this is not the same as the source code definition STATIC_BUILD, which will be set by other means as well.)
> 
> This method only ever worked on macOS, and has long since stopped working. It was originally introduced for the Mobile Project, but I've now learn that not even they use it anymore.
> 
> It just adds clutter to the build system, and should be removed.

This pull request has now been integrated.

Changeset: f0bffbce
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0bffbce35bb06e724857e8651dd429c4f9df284
Stats:     218 lines in 14 files changed: 4 ins; 206 del; 8 mod

8333301: Remove static builds using --enable-static-build

Reviewed-by: sgehwolf, erikj

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

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

From asotona at openjdk.org  Mon Jun  3 10:11:34 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 10:11:34 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v13]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <hkkIPOfgqgG6b7fVWvikd3cZmPC5B8Brl3mTMeObq0s=.789077a3-be7c-4098-9833-119fd27e269b@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

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

  added ProxyGenBench JMH micro benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/942342d5..834d65c5

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

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

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

From asotona at openjdk.org  Mon Jun  3 10:11:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 10:11:35 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v12]
In-Reply-To: <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>
Message-ID: <unzzJZANYa0ldo_4LyR9nXhht1Z66QLemdsr_rPPc-I=.c55d9516-e280-4ded-8cf4-212c9c727a33@github.com>

On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - obsolete import
>  - Merge branch 'master' into JDK-8332457-proxy-startup
>  - missing bracket
>  - Update src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - removed obsolete entry
>  - MTD_ cleanup
>  - fixed javadoc
>  - CONDY implementation of ProxyGenerator
>  - simplification of the proxy class loading
>  - more improvements
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/2ed35129...942342d5

Added `ProxyGenBenchmark` measuring generation time of 100 proxies.
Results for master branch:

Benchmark                            Mode  Cnt   Score   Error  Units
Proxy.ProxyGenBench.generateProxies    ss   10  12.266 ? 2.571  ms/op

Results for this PR:

Benchmark                            Mode  Cnt  Score   Error  Units
Proxy.ProxyGenBench.generateProxies    ss   10  9.851 ? 2.424  ms/op

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

PR Comment: https://git.openjdk.org/jdk/pull/19410#issuecomment-2144806554

From sgehwolf at openjdk.org  Mon Jun  3 10:12:16 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 3 Jun 2024 10:12:16 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
Message-ID: <KIaDNMbG1uyggkNjaxBME4l37wqCELM2uVRplVpm5bE=.5a33d1a7-a7d2-494c-916b-2ba7922cf2e7@github.com>

On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've been looking through the changes. One thing that I'm wondering about is whether --generate-runtime-link-image should disable the keeping of packaged modules (set JLINK_KEEP_PACKAGED_MODULES to false). It seems surprising to use this configure option and have the jlink command in the build also copy the packaged modules into the image.

@AlanBateman IMO those are orthogonal concepts. Note that the configure options are `--enable-packaged-modules` and `--enable-runtime-link-image`. The corresponding `jlink` options are `--keep-packaged-modules` and `--generate-linkable-runtime`. My mental model is that with this patch it allows a more flexible distribution of the JDK build. The testing story also seems easier in its current form. All non-linkable runtime tests run as-is - with a linkable runtime build - but also run linkable runtime tests (those have appropriate `@requires` tags). We've had some discussion around this already in this review thread. I'm arguing that both configure options make sense independently and in combination. The user can configure it to their liking. What I'd try to avoid is needing to produce two different builds whether or not the JDK is runtime linkable or not. That is because our prime use-case is to make `jmods` optional when `jlink` is being used post build and test.

I've tried to explain it earlier [here](https://github.com/openjdk/jdk/pull/14787#issuecomment-1999307995) and [here](https://github.com/openjdk/jdk/pull/14787#issuecomment-2003848668). @mlchung seemed OK with it [here](https://github.com/openjdk/jdk/pull/14787#issuecomment-2004605507) and @erikj79 was ok with it as well [here](https://github.com/openjdk/jdk/pull/14787#issuecomment-2004761747).

Is there a specific reason this needs to be done? With the current patch `--enable-runtime-link-image` influences how the `jimage` in `lib/modules` looks like (adds some metadata) nothing else. `--enable-packaged-modules` influences copying of the packaged modules.

Right now, what you are suggesting could be achieved with these configure options:
`--enable-runtime-link-image --disable-packaged-modules`

Is that not sufficient?

Thoughts?

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

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

From redestad at openjdk.org  Mon Jun  3 10:33:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 3 Jun 2024 10:33:03 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v13]
In-Reply-To: <hkkIPOfgqgG6b7fVWvikd3cZmPC5B8Brl3mTMeObq0s=.789077a3-be7c-4098-9833-119fd27e269b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <hkkIPOfgqgG6b7fVWvikd3cZmPC5B8Brl3mTMeObq0s=.789077a3-be7c-4098-9833-119fd27e269b@github.com>
Message-ID: <creyo1pZGAZyMg2gH0-sAFbjoAI6FZ7VGnSHnRbTFT8=.62a93acd-33c7-441e-953f-26b76a572211@github.com>

On Mon, 3 Jun 2024 10:11:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added ProxyGenBench JMH micro benchmark

test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyGenBench.java line 66:

> 64:         ClassDesc tempDesc = ClassDesc.ofDescriptor(Interfaze.class.descriptorString());
> 65:         loader = new ClsLoader();
> 66:         clsMap = new HashMap<>(100);

Suggestion:

        clsMap = HashMap.newHashMap(100);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1624192732

From lancea at openjdk.org  Mon Jun  3 11:03:03 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 3 Jun 2024 11:03:03 GMT
Subject: RFR: 8333398: Uncomment the commented test in
 test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java
In-Reply-To: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>
References: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>
Message-ID: <WFuC-Oq5uRDPLUXe_U9iTnp7jAXKOwRR9lRdqRD-pV4=.06c0f821-127b-45c8-9d75-7f001399fab1@github.com>

On Mon, 3 Jun 2024 04:25:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which uncomments an additional test that was commented out in `test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8333398, the original issue due to which this line was commented out in the test, has been fixed several releases back and thus this line can now be uncommented.
> 
> I've verified that this test continues to pass with these changes.

Change looks fine.

We should look at at a later date to convert this to junit and when we do, look to rework isMultiReleaseJar() as it actually runs multiple tests within the test itself and if one fails, the rest will not be run

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19514#pullrequestreview-2093508099

From lancea at openjdk.org  Mon Jun  3 11:07:01 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 3 Jun 2024 11:07:01 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE [v2]
In-Reply-To: <jgYqeVtocF9Qsi9AgSoIdJP0t0a7OO41CyMBRyeRUI0=.be89e0c4-965d-47c4-a545-4e04cb368039@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
 <jgYqeVtocF9Qsi9AgSoIdJP0t0a7OO41CyMBRyeRUI0=.be89e0c4-965d-47c4-a545-4e04cb368039@github.com>
Message-ID: <S5NEQlgUMun9l9o8Okye42MPfofCse0TTJol_g3nOSQ=.c34ec078-30b2-46c1-b9fa-d532bf5fa1f3@github.com>

On Mon, 3 Jun 2024 05:46:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
>> 
>> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
>> 
>> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
>> 
>> I'll open a CSR for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   also note that the method may block, just like DeflaterInputStream specifies it

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19515#pullrequestreview-2093515783

From asotona at openjdk.org  Mon Jun  3 11:09:31 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 11:09:31 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v14]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <5KL3je2BA4s5IEKwoV4WfzqOgCbbadPdiXI6zWZV6qg=.302bd6cd-5dc7-4cf9-9705-0f3b9c39c9b0@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

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

  ProxyGenBench simplification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/834d65c5..7b00967d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=12-13

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

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

From asotona at openjdk.org  Mon Jun  3 11:09:31 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 11:09:31 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v13]
In-Reply-To: <creyo1pZGAZyMg2gH0-sAFbjoAI6FZ7VGnSHnRbTFT8=.62a93acd-33c7-441e-953f-26b76a572211@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <hkkIPOfgqgG6b7fVWvikd3cZmPC5B8Brl3mTMeObq0s=.789077a3-be7c-4098-9833-119fd27e269b@github.com>
 <creyo1pZGAZyMg2gH0-sAFbjoAI6FZ7VGnSHnRbTFT8=.62a93acd-33c7-441e-953f-26b76a572211@github.com>
Message-ID: <-CsYt0CTtBan0JkQvdA3sC2ZDZSskBO_Sn2_GvF-Trg=.35c79ca5-2e99-4fbe-aacf-d353a26b35a9@github.com>

On Mon, 3 Jun 2024 10:30:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added ProxyGenBench JMH micro benchmark
>
> test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyGenBench.java line 66:
> 
>> 64:         ClassDesc tempDesc = ClassDesc.ofDescriptor(Interfaze.class.descriptorString());
>> 65:         loader = new ClsLoader();
>> 66:         clsMap = new HashMap<>(100);
> 
> Suggestion:
> 
>         clsMap = HashMap.newHashMap(100);

I've simplified it a lot. It uses a new `ClassLoader` instance for each proxy generation, instead of preparation of 100 different interfaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1624235034

From dl at openjdk.org  Mon Jun  3 11:19:08 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 3 Jun 2024 11:19:08 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <s_luHSrCCy_tcgxoO1g-7ruuk3pxMjua6jMpRLJYiYE=.a503aced-9a3d-4616-839d-615b9fea2d70@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
 <s_luHSrCCy_tcgxoO1g-7ruuk3pxMjua6jMpRLJYiYE=.a503aced-9a3d-4616-839d-615b9fea2d70@github.com>
Message-ID: <tU9QbyePlAGonu_08BLD6l8aYDRsAmFNZxuCLUYLKo8=.d23ef7bf-4acb-450c-983b-85e04d2805f8@github.com>

On Sun, 2 Jun 2024 14:33:45 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1345:
> 
>> 1343:             int b = base, p = top, cap;
>> 1344:             if (p - b > 0 && a != null && (cap = a.length) > 0) {
>> 1345:                 for (int m = cap - 1, s, nb;;) {
> 
> @DougLea I'm curious, what effect did you see if moving the `p - b > 0` out of the loop conditional?

This was part of saving a read in the common case of empty local queue. Barely but reliably worth doing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1624246576

From redestad at openjdk.org  Mon Jun  3 11:40:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 3 Jun 2024 11:40:02 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v14]
In-Reply-To: <5KL3je2BA4s5IEKwoV4WfzqOgCbbadPdiXI6zWZV6qg=.302bd6cd-5dc7-4cf9-9705-0f3b9c39c9b0@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <5KL3je2BA4s5IEKwoV4WfzqOgCbbadPdiXI6zWZV6qg=.302bd6cd-5dc7-4cf9-9705-0f3b9c39c9b0@github.com>
Message-ID: <YMBTwH95-k53igID6x628hjtQgNOFzluWuSKCQFcPp0=.bf7529fe-31f5-4c42-95fd-ed938922e60c@github.com>

On Mon, 3 Jun 2024 11:09:31 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ProxyGenBench simplification

test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyGenBench.java line 23:

> 21:  * questions.
> 22:  */
> 23: package org.openjdk.bench.java.lang.reflect.Proxy;

Package name needs to be lowercase. Not sure why the folder name is uppercase Proxy, but the two pre-existing benchmarks both have lower case package declarations. Uppercase letters in package names may subtly break a few tools

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1624270828

From asotona at openjdk.org  Mon Jun  3 12:00:30 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 12:00:30 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v15]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <c1sK6TArouWnfNRkngb9RYd1zttnzYe-gFNB_joihyI=.10e518eb-52ad-4e4f-8bbc-e5c907834bea@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

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

  ProxyGenBench moved

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/7b00967d..09baa376

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=13-14

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

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

From asotona at openjdk.org  Mon Jun  3 12:04:29 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 12:04:29 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v16]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <-NxgxkvbajhdQ8NO_N5rL77A8DyXQmdO28Fi7C76JH8=.f9bf1ac6-192b-4610-92ae-f3a4b9d81f89@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

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

  fixed package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/09baa376..29e269f5

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

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

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

From asotona at openjdk.org  Mon Jun  3 12:04:29 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 12:04:29 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v14]
In-Reply-To: <YMBTwH95-k53igID6x628hjtQgNOFzluWuSKCQFcPp0=.bf7529fe-31f5-4c42-95fd-ed938922e60c@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <5KL3je2BA4s5IEKwoV4WfzqOgCbbadPdiXI6zWZV6qg=.302bd6cd-5dc7-4cf9-9705-0f3b9c39c9b0@github.com>
 <YMBTwH95-k53igID6x628hjtQgNOFzluWuSKCQFcPp0=.bf7529fe-31f5-4c42-95fd-ed938922e60c@github.com>
Message-ID: <CB6__GOTliHpM1aI3JWWCTznLYGqVBtBPf_wRD6d_qU=.ae76eaea-7266-4433-b4b8-782cb38964e4@github.com>

On Mon, 3 Jun 2024 11:37:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ProxyGenBench simplification
>
> test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyGenBench.java line 23:
> 
>> 21:  * questions.
>> 22:  */
>> 23: package org.openjdk.bench.java.lang.reflect.Proxy;
> 
> Package name needs to be lowercase. Not sure why the folder name is uppercase Proxy, but the two pre-existing benchmarks both have lower case package declarations. Uppercase letters in package names may subtly break a few tools

Yes, I've moved it down to j/l/reflect. However the existing benchmarks probably need a separate treatment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1624297815

From vklang at openjdk.org  Mon Jun  3 12:26:06 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 3 Jun 2024 12:26:06 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <tU9QbyePlAGonu_08BLD6l8aYDRsAmFNZxuCLUYLKo8=.d23ef7bf-4acb-450c-983b-85e04d2805f8@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
 <s_luHSrCCy_tcgxoO1g-7ruuk3pxMjua6jMpRLJYiYE=.a503aced-9a3d-4616-839d-615b9fea2d70@github.com>
 <tU9QbyePlAGonu_08BLD6l8aYDRsAmFNZxuCLUYLKo8=.d23ef7bf-4acb-450c-983b-85e04d2805f8@github.com>
Message-ID: <c5Gb_o1-punZksUDg1jlLhbaSsa58EfU85SbgE3rHHQ=.3133ef40-47d5-4ec4-81fe-5089a28c3477@github.com>

On Mon, 3 Jun 2024 11:16:49 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1345:
>> 
>>> 1343:             int b = base, p = top, cap;
>>> 1344:             if (p - b > 0 && a != null && (cap = a.length) > 0) {
>>> 1345:                 for (int m = cap - 1, s, nb;;) {
>> 
>> @DougLea I'm curious, what effect did you see if moving the `p - b > 0` out of the loop conditional?
>
> This was part of saving a read in the common case of empty local queue. Barely but reliably worth doing.

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1624352663

From alanb at openjdk.org  Mon Jun  3 12:58:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Jun 2024 12:58:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
Message-ID: <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>

On Sun, 2 Jun 2024 17:41:55 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 110 commits:
>> 
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Fix new line in jlink.properties
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>>  - Only add runtime track files for linkable runtimes
>>  - Generate the runtime image link diff at jlink time
>>    
>>    But only do that once the plugin-pipeline has run. The generation is
>>    enabled with the hidden option '--generate-linkable-runtime' and
>>    the resource pools available at jlink time are being used to generate
>>    the diff.
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Use shorter name for the build tool
>>  - Review feedback from Erik J.
>>  - Remove dependency on CDS which isn't needed anymore
>>  - ... and 100 more: https://git.openjdk.org/jdk/compare/4f1a10f8...e1e3f02f
>
> I've been looking through the changes. One thing that I'm wondering about is whether --generate-runtime-link-image should disable the keeping of packaged modules (set JLINK_KEEP_PACKAGED_MODULES to false). It seems surprising to use this configure option and have the jlink command in the build also copy the packaged modules into the image.
> 
> (Doing that would of course mean that several existing jlink tests would need some changes, either to `@requires` or to remove the checks for the `jmods` directory)

> @AlanBateman IMO those are orthogonal concepts. 

The purpose of --enable-runtime-link-image is to produce a run-time image that is capable of running jlink without the packaged modules. The benefit is is a reducing size on the file system but you don't get that benefit if the packages modules are copied in the image.

So I think we may have the wrong default. Yes, they are separate configure and jlink options but I'm wondering if it would be more sensible to opt-in(not opt-out)  to keep the packaged modules when configured with --enable-runtime-link-image.

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

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

From duke at openjdk.org  Mon Jun  3 13:41:14 2024
From: duke at openjdk.org (jengebr)
Date: Mon, 3 Jun 2024 13:41:14 GMT
Subject: Integrated: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <zmW1iMOZkTT0syWhLCYKMULU0C8sYoNd9aOlp_oOBq0=.335a71f5-3773-4259-b471-3a6382e625ce@github.com>

On Tue, 21 May 2024 13:49:18 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
> 
> 
> After:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op

This pull request has now been integrated.

Changeset: 27af19d9
Author:    John Engebretson <jengebr at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27af19d921a5cf15f5146471b58961815690b4f2
Stats:     177 lines in 4 files changed: 170 ins; 1 del; 6 mod

8332586: Avoid cloning empty arrays in java.lang.reflect.{Method,Constructor}

Reviewed-by: shade, rriggs, liach

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

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

From asotona at openjdk.org  Mon Jun  3 13:50:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 13:50:19 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v17]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <etVj6yob8La7nAtFeOAxZIbFY9eP3CguIGuH44fGFV8=.090ab87b-f5ae-4396-9d27-1716ea196dfb@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

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

  ClassFile context made static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/29e269f5..fb3cdcdd

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

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

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

From asotona at openjdk.org  Mon Jun  3 14:39:12 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 14:39:12 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v3]
In-Reply-To: <AZiGAwtgnXbZ_b2VkBaRz_-VwvcQXP8tybroNYUS308=.b542b24e-a7f7-41a1-b65e-f7d042522df0@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <bLw0t5oT2Poi6g22CvAN2s3p4uQHyDa9GKYpBQ89DbQ=.649d7b2b-8389-44d4-bd32-3e5119566206@github.com>
 <AZiGAwtgnXbZ_b2VkBaRz_-VwvcQXP8tybroNYUS308=.b542b24e-a7f7-41a1-b65e-f7d042522df0@github.com>
Message-ID: <fyWwMjz8WAUjh1nCChQZP-PMwkm-JVh_xnTGk_m1EnA=.b430d68a-c24d-400a-a22b-e0f0892cf2c7@github.com>

On Mon, 27 May 2024 12:20:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   performance improvements
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 76:
> 
>> 74: 
>> 75:     private static final MethodTypeDesc
>> 76:             MTD_boolean = MethodTypeDescImpl.ofValidated(CD_boolean, ConstantUtils.EMPTY_CLASSDESC),
> 
> Maybe we can change the `MethodTypeDescImpl.ofValidated` to varargs so we don't need explicit array initializations.

Yes, I like that idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1624576109

From asemenyuk at openjdk.org  Mon Jun  3 14:41:07 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Jun 2024 14:41:07 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <nQP1t6EuMVLeGihN8RTSfFMqMEJP77BEvoeb7pElQUg=.7ba77c32-a98d-4d7e-ad3b-040f8597264c@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
 <nQP1t6EuMVLeGihN8RTSfFMqMEJP77BEvoeb7pElQUg=.7ba77c32-a98d-4d7e-ad3b-040f8597264c@github.com>
Message-ID: <DIn0iEluK0_nCbH2N3kqrDGap5IpmctZxwVJuYRd_qs=.137604f6-4e66-46e2-ae4f-75ca3c13e4b7@github.com>

On Mon, 3 Jun 2024 08:37:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.
>> 
>> Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.
>> 
>> These loopholes were eliminated:
>> 
>>  - stdout and stderr of app launchers is never suppressed;
>>  - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
>>  - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.
>> 
>> Other changes are due to changes in HelloApp.AppOutputVerifier class.
>
> I am yet to see anything that actually explains the cause of the `dlerror` crash here ???

@dholmes-ora there is no fix for the cause of the `dlerror` crash in this PR. The PR fixes jpackage tests to rerun a launcher if it crashes. This workaround for jpackage tests was first introduced in [JDK-8269403](https://bugs.openjdk.org/browse/JDK-8269403) fix but MainClassTest was left unfixed back then. This PR complements [JDK-8269403](https://bugs.openjdk.org/browse/JDK-8269403).

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

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2145373568

From asotona at openjdk.org  Mon Jun  3 14:43:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 3 Jun 2024 14:43:15 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v18]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <2gq6-2yMBh8Q-C8QE3-Mbqwz4EtSvLynO-TW0QN_Rh0=.97f6694a-778a-44f4-aa8e-d9cab29a5cff@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

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

  MethodTypeDescImpl::ofValidated changed to varargs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/fb3cdcdd..6ca164bc

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

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

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

From volker.simonis at gmail.com  Mon Jun  3 15:03:28 2024
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 3 Jun 2024 17:03:28 +0200
Subject: Status of project "Brisbane"?
Message-ID: <CA+3eh10N_hMYTJ9Nn4JAiznhd6NdbDjmEgHL0_R3n4sA3KnYag@mail.gmail.com>

Hi,

What's the status of Project Brisbane? According to [1], the Project
was approved two month ago on April 4th, but until now I can't find it
listed on openjdk.org nor can I find a corresponding mailing list?

Best regards,
Volker

[1] https://mail.openjdk.org/pipermail/announce/2024-April/000350.html

From sgehwolf at openjdk.org  Mon Jun  3 15:43:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 3 Jun 2024 15:43:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
 <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>
Message-ID: <Ok6ibGzy9-6oa-c2Ie-lCulQXObKKkusvHP1QeR_WlE=.799e6764-c532-4647-b61c-e5a19aadbc1c@github.com>

On Mon, 3 Jun 2024 12:55:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So I think we may have the wrong default. Yes, they are separate configure and jlink options but I'm wondering if it would be more sensible to opt-in(not opt-out) to keep the packaged modules when configured with --enable-runtime-link-image.

OK. I'll rework it so that we'll have:

| config opts | effect | equivalent to |
| -----------------|----------|---------------------|
| `--enable-runtime-link-image` | produces a linkable runtime **without** packaged modules even though the default of  `--enable-packaged-modules` is otherwise `true`.| `--enable-runtime-link-image --disable-packaged-modules`|
| `--enable-runtime-link-image --enable-packaged-modules`| produces a linkable runtime **with** packaged modules, overriding the default of packaged modules not being enabled when `--enable-runtime-link-image`  is being used otherwise | N/A|
| `--disable-runtime-link-image` | Default as of today. Adds packaged modules, with no run time link supporting jimage | `--disable-runtime-link-image --enable-packaged-modules`|
| `--disable-runtime-link-image --disable-packaged-modules` | No linkable jimage runtime, no packaged modules in the resulting JDK | N/A |

Does that proposal sound good?

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

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

From naoto at openjdk.org  Mon Jun  3 15:55:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Jun 2024 15:55:08 GMT
Subject: RFR: 8333103: Re-examine the console provider loading [v2]
In-Reply-To: <d45DFoxzcW07FcgKRb1tWGKQHx_y2D9Beb9j5InMHFI=.d8f116ab-f758-4074-8475-a8c381b6c24a@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <d45DFoxzcW07FcgKRb1tWGKQHx_y2D9Beb9j5InMHFI=.d8f116ab-f758-4074-8475-a8c381b6c24a@github.com>
Message-ID: <DXIh-kPl9nlooUevREgZaHaQle0CE-qRBaH6HROTNVY=.a4b6ccca-7da9-4d39-83fc-71bf9f7e9187@github.com>

On Thu, 30 May 2024 19:48:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify the comment for multiple impls in the module case

Thank you for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/19467#issuecomment-2145561992

From naoto at openjdk.org  Mon Jun  3 15:55:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Jun 2024 15:55:09 GMT
Subject: Integrated: 8333103: Re-examine the console provider loading
In-Reply-To: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
Message-ID: <DDpuZ2an7nJ7Y4NFlUWNq3lp-sfSCEg2Kf2RONJcotc=.e70e3c85-68ca-4b87-a40e-72b46c03ff94@github.com>

On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.

This pull request has now been integrated.

Changeset: 9686e804
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9686e804a2b058955ff88149c54a0a7896c0a2eb
Stats:     23 lines in 1 file changed: 5 ins; 0 del; 18 mod

8333103: Re-examine the console provider loading

Reviewed-by: redestad, jpai

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

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

From jjg at openjdk.org  Mon Jun  3 16:12:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 3 Jun 2024 16:12:09 GMT
Subject: RFR: 8330954: since-checker - Fix remaining `@since` tags in
 `java.base` [v4]
In-Reply-To: <vYbBnYVwb_7RfofV18_HtMmqPQGIwYYHJiTc0Q5u254=.b06b61ae-9130-4bae-b4b7-d1233c746858@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <vYbBnYVwb_7RfofV18_HtMmqPQGIwYYHJiTc0Q5u254=.b06b61ae-9130-4bae-b4b7-d1233c746858@github.com>
Message-ID: <LL6qLIEmfqe1-1B4m4XgWe9qg8bDCTtThRVdnTDqRd8=.e7e4fcf4-597f-4b3e-91b7-9f56497053ff@github.com>

On Mon, 13 May 2024 20:14:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - (C)
>  - (C)
>  - Move security classes changes to pr18373
>  - remove couple extra lines
>  - Pull request is now only about `@since` tags, might add an other commit
>  - add one more `{inheritDoc}` to `CompletableFuture.state`
>  - add `@throws` declarations to javadoc
>  - add ``{@inheritDoc}`` to new javadoc comments
>  - remove two extra spaces
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/39767aaa...b3574b97

I disagree somewhat with the statements in the comments that the checker should follow the javadoc rules, whatever they are.

The important thing is to decide what the rules for `@since` should be, in terms of changes to the set of signatures in the class.  Generally, I think the rule should be that _every_ declaration should have `@since` _except_ that members need not have the tag if it would be the same as for the enclosing class or interface.  As far as adding an overriding method is concerned, if it has the same VM descriptor as the overridden method, it is not a "new" method in the class;  if it has a covariant return type, that is a significant change to the descriptor and so such methods should have `@since`.

As a practical rule for deciding whether any declaration is new or not, imagine writing a test program that refers to the most specific form of the declaration. If that test program does not compile on JDK version N-1 and does compile on version N, then it warrants having `@since N`.  Put another way, `@since N` should identify the first release in which the declaration can be used in the given form.

Note, these rules are stated without reference to what `javadoc` does.  `javadoc` should follow these rules as well; it is a bug if the tool generates incorrect documentation based on `@since` tags following these rules.

Also, while the proposed new Since Checker should follow these rules when analysing declarations, it may go further when making suggestions to correct errors that it finds. For example, instead of simply saying _No `@since` tag found here_, it might analyze the history and say  _No `@since` tag found here; the declaration was introduced in X_ for an appropriate X.

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2145605004

From duke at openjdk.org  Mon Jun  3 18:00:35 2024
From: duke at openjdk.org (Sean Gwizdak)
Date: Mon, 3 Jun 2024 18:00:35 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
Message-ID: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com>

> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. 
> 
> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). 
> 
> Before:
> 
> Benchmark                         Mode  Cnt  Score   Error  Units
> # Intel Skylake
> MethodHashCode.benchmarkHashCode  avgt    5  1.843 ? 0.149  ns/op
> # Arm Neoverse N1
> MethodHashCode.benchmarkHashCode  avgt    5  2.363 ? 0.091  ns/op
> 
> 
> 
> After:
> 
> 
> Benchmark                         Mode  Cnt  Score   Error  Units
> # Intel Skylake
> MethodHashCode.benchmarkHashCode  avgt    5  1.121 ? 1.189  ns/op
> # Arm Neoverse N1
> MethodHashCode.benchmarkHashCode  avgt    5  1.001 ? 0.001  ns/op

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

 - Remove trailing whitespace.
 - Move hashCode benchmark into the newly created MethodBenchmark file
 - Merge branch 'master' into method-hashcode-JDK-8332249
 - Remove changes to JavaDoc per guidance.
 - Fix whitespace issues pointed by the bot
 - Micro-optimize Method.hashCode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19433/files
  - new: https://git.openjdk.org/jdk/pull/19433/files/2e4c0c94..4364d99d

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

  Stats: 30025 lines in 868 files changed: 18155 ins; 7339 del; 4531 mod
  Patch: https://git.openjdk.org/jdk/pull/19433.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19433/head:pull/19433

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

From duke at openjdk.org  Mon Jun  3 18:00:35 2024
From: duke at openjdk.org (Sean Gwizdak)
Date: Mon, 3 Jun 2024 18:00:35 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode
In-Reply-To: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
Message-ID: <1nHePCi8zFt1wPVCivejS_9ITXsGL0EXc4flQv3jieY=.3e19574a-29ce-47eb-9011-f3d152eec408@github.com>

On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak <duke at openjdk.org> wrote:

> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. 
> 
> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). 
> 
> Before:
> 
> Benchmark                         Mode  Cnt  Score   Error  Units
> # Intel Skylake
> MethodHashCode.benchmarkHashCode  avgt    5  1.843 ? 0.149  ns/op
> # Arm Neoverse N1
> MethodHashCode.benchmarkHashCode  avgt    5  2.363 ? 0.091  ns/op
> 
> 
> 
> After:
> 
> 
> Benchmark                         Mode  Cnt  Score   Error  Units
> # Intel Skylake
> MethodHashCode.benchmarkHashCode  avgt    5  1.121 ? 1.189  ns/op
> # Arm Neoverse N1
> MethodHashCode.benchmarkHashCode  avgt    5  1.001 ? 0.001  ns/op

Minor change after draft review -- moved Method hashCode benchmark into the newly created MethodBenchmark file.

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

PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2145806129

From nbenalla at openjdk.org  Mon Jun  3 18:05:43 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 3 Jun 2024 18:05:43 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java
Message-ID: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>

Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files.

The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like <body> and <html>. I did the conversion in place, renaming them in git but with the big amount of change git thinks it's a new file.

I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine.

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

Commit messages:
 - remove whitespace
 - 8332072: Convert package.html files in `java.naming` to package-info.java

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

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

From duke at openjdk.org  Mon Jun  3 19:03:15 2024
From: duke at openjdk.org (jengebr)
Date: Mon, 3 Jun 2024 19:03:15 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations
Message-ID: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>

Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.

Results from the included JMH benchmark:
Before:

Benchmark                                                    Mode  Cnt   Score   Error  Units
CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op


After:

Benchmark                                                    Mode  Cnt   Score   Error  Units
CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op

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

Commit messages:
 - Fixing whitespace
 - Removing toArray from benchmark
 - Reverting change to clone()
 - Merge branch 'openjdk:master' into CopyOnWriteArrayList_optimization
 - Adding JMH benchmark
 - Merge branch 'openjdk:master' into CopyOnWriteArrayList_optimization
 - Merge branch 'openjdk:master' into CopyOnWriteArrayList_optimization
 - Revert "Updating copyright yeaer"
 - Merge branch 'openjdk:master' into CopyOnWriteArrayList_optimization
 - Updating copyright yeaer
 - ... and 2 more: https://git.openjdk.org/jdk/compare/9686e804...ea7a0042

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

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

From shade at openjdk.org  Mon Jun  3 19:03:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 3 Jun 2024 19:03:16 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations
In-Reply-To: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
Message-ID: <UR52KBzfON-XkuGGvteCY6kckBn50uURisMK-hRUnNE=.63f0e3d8-2a29-47a1-9112-e865736540ec@github.com>

On Mon, 3 Jun 2024 16:47:20 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
> 
> 
> After:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op

Some initial comments. @DougLea might want to give it a sanity check.

Note there is a jcheck failure due to whitespace issues. Plus, I think the PR should still be named "8332842: Optimize empty CopyOnWriteArrayList allocations"?

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 338:

> 336:      */
> 337:     public Object[] toArray() {
> 338:         return getArray().length == 0 ? getArray() : getArray().clone();

Unfortunately, I think this is against the spec for this method, which explicitly says the method must allocate a new array. Yes, this change would be within the spirit of the spec ("You can modify the array", which you cannot if the object is empty), but is against the letter of it.

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

PR Review: https://git.openjdk.org/jdk/pull/19527#pullrequestreview-2094435376
PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2145853813
PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1624791561

From dl at openjdk.org  Mon Jun  3 19:03:16 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 3 Jun 2024 19:03:16 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations
In-Reply-To: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
Message-ID: <96SNKGdvRhf20ArPe4-IdcXkhzvKDnwQ7W1VlXX689I=.78e6fc24-980e-42e4-aa67-090968a5b215@github.com>

On Mon, 3 Jun 2024 16:47:20 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
> 
> 
> After:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op

The jmh benchmark checks only the empty case, you need to also show lack of impact on non-empty cases.

Assuming you demonstrate this, it seems basically OK, (Deja vu previous cases including hash maps). It is only a small band-aid -- programs generating lots of them still have to allocate the COWAL object, so the savings are small compared to not generating them at all unless needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2145896233

From duke at openjdk.org  Mon Jun  3 19:03:16 2024
From: duke at openjdk.org (jengebr)
Date: Mon, 3 Jun 2024 19:03:16 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations
In-Reply-To: <UR52KBzfON-XkuGGvteCY6kckBn50uURisMK-hRUnNE=.63f0e3d8-2a29-47a1-9112-e865736540ec@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <UR52KBzfON-XkuGGvteCY6kckBn50uURisMK-hRUnNE=.63f0e3d8-2a29-47a1-9112-e865736540ec@github.com>
Message-ID: <pYHcDS7xd3TFxmQgF87Q3fxBY1IkM1Wzvja5Hzz3s6A=.c4b13f44-6e6a-44bb-900d-1647cac964d2@github.com>

On Mon, 3 Jun 2024 17:07:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op
>
> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 338:
> 
>> 336:      */
>> 337:     public Object[] toArray() {
>> 338:         return getArray().length == 0 ? getArray() : getArray().clone();
> 
> Unfortunately, I think this is against the spec for this method, which explicitly says the method must allocate a new array. Yes, this change would be within the spirit of the spec ("You can modify the array", which you cannot if the object is empty), but is against the letter of it.

I think you're right, I'll remove the change to toArray().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1624873832

From alanb at openjdk.org  Mon Jun  3 19:12:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Jun 2024 19:12:43 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <Ok6ibGzy9-6oa-c2Ie-lCulQXObKKkusvHP1QeR_WlE=.799e6764-c532-4647-b61c-e5a19aadbc1c@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
 <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>
 <Ok6ibGzy9-6oa-c2Ie-lCulQXObKKkusvHP1QeR_WlE=.799e6764-c532-4647-b61c-e5a19aadbc1c@github.com>
Message-ID: <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>

On Mon, 3 Jun 2024 15:40:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Does that proposal sound good?

That table is useful, I think it's right. No change to default behavior. If someone configures with --enable-runtime-image then they get a JDK run-time image that supports jlink (with some limitations) but is significantly small as it doesn't include the packaged modules.

I've read through most of the changes now. Overall I think it's looking good, just a few terminology and minor points that I'll add as comments.

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

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

From vlivanov at openjdk.org  Mon Jun  3 19:36:58 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 3 Jun 2024 19:36:58 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
 [v2]
In-Reply-To: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
Message-ID: <BknxIyKtS1mS1yFR8ebXJ8-PWGqSDF6GW-Cz3KSe69k=.699dc9a3-6b36-43c9-962b-2969944d9737@github.com>

> JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 
> 
> There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.
> 
> Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 
> 
> In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  
> 
> Testing: hs-tier1 - hs-tier4

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

  Renaming: isTypeVisible -> ensureTypeVisible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19319/files
  - new: https://git.openjdk.org/jdk/pull/19319/files/805d42fc..058cdba3

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

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

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

From vlivanov at openjdk.org  Mon Jun  3 19:36:58 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 3 Jun 2024 19:36:58 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
In-Reply-To: <vmW1VnaMfGWrfxuQfOpDjbYBExhlEq-WNkV2SX6ggXc=.870503d8-8b8d-40a7-9a14-430e7ab2521f@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
 <QNXNxP3DEo9d4wqp3Af93Rg5D_zTbdtWDbPQ6dC3p2k=.cffa3736-0c7d-421d-b7b1-cbb0b7aa24e7@github.com>
 <vmW1VnaMfGWrfxuQfOpDjbYBExhlEq-WNkV2SX6ggXc=.870503d8-8b8d-40a7-9a14-430e7ab2521f@github.com>
Message-ID: <eiZH1QjihUCYu-CN4kuth5LTobCdSm-JqNUls_9Gdmo=.b388f4f3-e357-436c-a4fc-a40eda3f44bb@github.com>

On Tue, 21 May 2024 20:14:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Class loading triggered by `Class.forName()` call is at the core of `isTypeVisible`. (The rest is fast path checks.) It's what makes `isTypeVisible` query idempotent. 
>> 
>> I can definitely name it differently (e.g, `ensureTypeVisible`), but making a separate class loading pass across signature classes doesn't make much sense.
>
>> I can definitely name it differently (e.g, ensureTypeVisible), but making a separate class loading pass across signature classes doesn't make much sense.
> 
> Ok, in that case I suggest also renaming `MemberName::checkForTypeAlias`, maybe to `ensureTypeVisible` as well.

@JornVernee ok, renamed.

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

PR Comment: https://git.openjdk.org/jdk/pull/19319#issuecomment-2145967665

From asemenyuk at openjdk.org  Mon Jun  3 20:36:38 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Jun 2024 20:36:38 GMT
Subject: RFR: 8333452: Make logging in
 jdk.jpackage.internal.OverridableResource class configurable
Message-ID: <FZElHkAiU7dzYn0rZ0kNAFoZvgjkmL7P8uTyjl77PeA=.07dfae56-4901-417c-83fa-5916bfe54592@github.com>

8333452: Make logging in jdk.jpackage.internal.OverridableResource class configurable

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

Commit messages:
 - 8333452: Make logging in jdk.jpackage.internal.OverridableResource class configurable

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

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

From asemenyuk at openjdk.org  Mon Jun  3 20:51:32 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Jun 2024 20:51:32 GMT
Subject: RFR: 8333452: Make logging in
 jdk.jpackage.internal.OverridableResource class configurable
In-Reply-To: <FZElHkAiU7dzYn0rZ0kNAFoZvgjkmL7P8uTyjl77PeA=.07dfae56-4901-417c-83fa-5916bfe54592@github.com>
References: <FZElHkAiU7dzYn0rZ0kNAFoZvgjkmL7P8uTyjl77PeA=.07dfae56-4901-417c-83fa-5916bfe54592@github.com>
Message-ID: <6Ft3j082LGTr9PYq6SkggwO61-AQcISPyJMpskSoeXA=.76084516-65e4-497b-a3ef-4bddcb828f00@github.com>

On Mon, 3 Jun 2024 20:29:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8333452: Make logging in jdk.jpackage.internal.OverridableResource class configurable

@sashamatveev, please review

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

PR Comment: https://git.openjdk.org/jdk/pull/19532#issuecomment-2146097131

From jvernee at openjdk.org  Mon Jun  3 20:51:32 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Jun 2024 20:51:32 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
 [v2]
In-Reply-To: <BknxIyKtS1mS1yFR8ebXJ8-PWGqSDF6GW-Cz3KSe69k=.699dc9a3-6b36-43c9-962b-2969944d9737@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
 <BknxIyKtS1mS1yFR8ebXJ8-PWGqSDF6GW-Cz3KSe69k=.699dc9a3-6b36-43c9-962b-2969944d9737@github.com>
Message-ID: <yUjuQviBxCHxbZn5V1-aGEvTrUx2VcDS9Q-fKEirDvs=.44c8a38d-bd5a-4057-b9fb-b5799a83870e@github.com>

On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 
>> 
>> There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.
>> 
>> Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 
>> 
>> In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  
>> 
>> Testing: hs-tier1 - hs-tier4
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming: isTypeVisible -> ensureTypeVisible

Thanks

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19319#pullrequestreview-2094825208

From kak at google.com  Mon Jun  3 21:24:56 2024
From: kak at google.com (Kurt Alfred Kluever)
Date: Mon, 3 Jun 2024 17:24:56 -0400
Subject: Instant.now(Clock) and InstantSource
Message-ID: <CAB3z6Ajk6zNaTtY6y01EYNe=GUyBWFXV-uEe4fJasvnBvBaQFQ@mail.gmail.com>

Hi folks,

It feels a bit strange that you can't pass an `InstantSource` to
`Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a
"useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to
propose one of the following API changes:

1) adding `Instant.now(InstantSource)`
2) deprecating `Instant.now(Clock)` in favor of `clock.instant()`

(I believe removing `Instant.now(Clock)` would be binary compatible, so
that's not an option, right?)

There's also a related discussion about adding an InstantSource-based
static factory method to the "local" types (e.g.,
`LocalDate.now(InstantSource, ZoneId)`). However, I always avoid using the
static factories on those types and have been quite happy with the fluent
pattern instead (e.g., `instantSource.instant().atZone(...).toLocalDate()`).

Thoughts?

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

From darcy at openjdk.org  Mon Jun  3 21:32:33 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Jun 2024 21:32:33 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java
In-Reply-To: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
Message-ID: <VhKqWWj1ToXxW-G3hWgBrYENM9WOaPGsROAX--_pdUs=.2e6be72a-e197-4f7f-9006-6ed8ae029a1e@github.com>

On Mon, 3 Jun 2024 17:26:52 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files.
> 
> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `<body>` and `<html>`. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file.
> 
> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine.

I recommend having the new package-info.java files follow the now-current javadoc conventions including:

* Using `{@code foo}` in preference to `<code>foo</code>`
* Using the `@snippet` tag in preference to `<blockquore><pre>`
* etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/19529#issuecomment-2146157205

From almatvee at openjdk.org  Mon Jun  3 21:55:44 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 3 Jun 2024 21:55:44 GMT
Subject: RFR: 8333452: Make logging in
 jdk.jpackage.internal.OverridableResource class configurable
In-Reply-To: <FZElHkAiU7dzYn0rZ0kNAFoZvgjkmL7P8uTyjl77PeA=.07dfae56-4901-417c-83fa-5916bfe54592@github.com>
References: <FZElHkAiU7dzYn0rZ0kNAFoZvgjkmL7P8uTyjl77PeA=.07dfae56-4901-417c-83fa-5916bfe54592@github.com>
Message-ID: <10WPt_KgCEXUX8V3piQE1apNek2ewk1qffe6O-TcCF0=.f9002b64-6c54-42c6-83d8-b02e8f67ff6e@github.com>

On Mon, 3 Jun 2024 20:29:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8333452: Make logging in jdk.jpackage.internal.OverridableResource class configurable

OverridableResource uses Log.verbose, which will log if -verbose is specified. What do you mean by "OverridableResource class unconditionally writes in the log."? Why "In some situations emitting log messages is not desired."? If we do not need to log them when "-verbose" is specified then lets just remove them.

`NoLogging` class is only used by test. Can we modify `OverridableResource` in such way it does not require additional code which is used by test only?

This added functionality is not used. It is completely unclear from PR and/or issue description why we need this and how it will be used in the future?

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

PR Comment: https://git.openjdk.org/jdk/pull/19532#issuecomment-2146189724

From jlu at openjdk.org  Mon Jun  3 22:03:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Jun 2024 22:03:48 GMT
Subject: Integrated: 8332424: Update IANA Language Subtag Registry to Version
 2024-05-16
In-Reply-To: <EiHinNf2U1SQ2iKSeACo7c_hyftoKjJPQeei-fSdJSY=.b4fdfe97-c866-4bec-932b-c5ae0ecbd24a@github.com>
References: <EiHinNf2U1SQ2iKSeACo7c_hyftoKjJPQeei-fSdJSY=.b4fdfe97-c866-4bec-932b-c5ae0ecbd24a@github.com>
Message-ID: <hYI7qNtC8WGA634kgs4XMwulcyuAFdNtCIpAGuC4DLQ=.6cd1f837-d3c9-4138-90cf-83dce2199bad@github.com>

On Fri, 17 May 2024 18:04:02 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-05-16. Locale tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-May/000091.html

This pull request has now been integrated.

Changeset: 6dac8d64
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6dac8d64527b4e9ade783b99f82fbecd81c426a6
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8332424: Update IANA Language Subtag Registry to Version 2024-05-16

Reviewed-by: naoto, iris

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

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

From liach at openjdk.org  Mon Jun  3 22:33:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Jun 2024 22:33:49 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
 [v2]
In-Reply-To: <BknxIyKtS1mS1yFR8ebXJ8-PWGqSDF6GW-Cz3KSe69k=.699dc9a3-6b36-43c9-962b-2969944d9737@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
 <BknxIyKtS1mS1yFR8ebXJ8-PWGqSDF6GW-Cz3KSe69k=.699dc9a3-6b36-43c9-962b-2969944d9737@github.com>
Message-ID: <1WnYxErQWK4DWeiSqd-P0wB5k5HrlTkZtjtVp8bXV8A=.d74c9626-1889-4ae9-b197-9991cb21ee06@github.com>

On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 
>> 
>> There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.
>> 
>> Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 
>> 
>> In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  
>> 
>> Testing: hs-tier1 - hs-tier4
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming: isTypeVisible -> ensureTypeVisible

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/19319#pullrequestreview-2094960904

From asemenyuk at openjdk.org  Mon Jun  3 22:34:01 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Jun 2024 22:34:01 GMT
Subject: Withdrawn: 8333452: Make logging in
 jdk.jpackage.internal.OverridableResource class configurable
In-Reply-To: <FZElHkAiU7dzYn0rZ0kNAFoZvgjkmL7P8uTyjl77PeA=.07dfae56-4901-417c-83fa-5916bfe54592@github.com>
References: <FZElHkAiU7dzYn0rZ0kNAFoZvgjkmL7P8uTyjl77PeA=.07dfae56-4901-417c-83fa-5916bfe54592@github.com>
Message-ID: <nkTUI0qKD_kTyW6gi2Wy1SMhR3e5q8WOfMU325R2Nz8=.acba9dbb-95ee-4db9-9173-2bfb1aba4aa6@github.com>

On Mon, 3 Jun 2024 20:29:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8333452: Make logging in jdk.jpackage.internal.OverridableResource class configurable

This pull request has been closed without being integrated.

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

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

From asemenyuk at openjdk.org  Mon Jun  3 22:33:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Jun 2024 22:33:59 GMT
Subject: RFR: 8333452: Make logging in
 jdk.jpackage.internal.OverridableResource class configurable
In-Reply-To: <10WPt_KgCEXUX8V3piQE1apNek2ewk1qffe6O-TcCF0=.f9002b64-6c54-42c6-83d8-b02e8f67ff6e@github.com>
References: <FZElHkAiU7dzYn0rZ0kNAFoZvgjkmL7P8uTyjl77PeA=.07dfae56-4901-417c-83fa-5916bfe54592@github.com>
 <10WPt_KgCEXUX8V3piQE1apNek2ewk1qffe6O-TcCF0=.f9002b64-6c54-42c6-83d8-b02e8f67ff6e@github.com>
Message-ID: <RFKOwDyw-TZPYevtkHEgvJ1p4inr64mf6l0cQUuHDoY=.15880a9b-b9f9-4624-9a00-c400b9bc0731@github.com>

On Mon, 3 Jun 2024 21:53:06 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This added functionality is not used. It is completely unclear from PR and/or issue description why we need this and how it will be used in the future?

It was supposed to be used in [WiX4 project](https://bugs.openjdk.org/browse/JDK-8319457). In this project the same resource was supposed to be saved multiple times, producing duplicated messages in the log. This was the case at the early stage of the project. I looked closer and it is not needed any more. I'll withdraw this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19532#issuecomment-2146217269

From asemenyuk at openjdk.org  Mon Jun  3 22:35:00 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Jun 2024 22:35:00 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <J0FOUXYzshUOc96a0oC8K7aP1xvtH0U_6fyFdg4Z1sg=.fbbdb161-c1c3-4fb3-9e32-cfaeb1a760f3@github.com>

On Mon, 20 May 2024 21:14:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for WiX4 in jpackage.
> 
> jpackage supports both WiX3 and WiX4. It will pick WiX4 if both versions are installed.
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

@sashamatveev please review

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2146229622

From asemenyuk at openjdk.org  Mon Jun  3 22:34:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Jun 2024 22:34:59 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
Message-ID: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>

Add support for WiX4 in jpackage.

jpackage supports both WiX3 and WiX4. It will pick WiX4 if both versions are installed.

Custom WiX3 sources will be automatically converted to WiX4 format if WiX4 is used. The converter provides:

- full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
- partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;

The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

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

Commit messages:
 - Revert "Revert "Rollback unneeded change""
 - Support the use of custom wix source converter
 - Ensure WiX source converter works with the default JDK XSLT processor and Saxon HE (v12.4)
 - Revert "Rollback unneeded change"
 - Rollback unneeded change
 - Merge branch 'master' into JDK-8319457
 - Don't suppress jpackage output when it is detecting what packaging tools available and what bundlers are supported.
 - Fix issue with running jtreg tests when wix.exe is not available in the PATH. When wix.exe is not in the PATH, jpackage uses %USERPROFILE% env variable to get user home directory. But jtreg removes it from the environment when running tests, so without wix.exe in the PATH all jpackage tests will fail on Windows. This makes it impossible to test jpackage with wix3. This patch addresses this issue by reading user home additionally from "java.home" system property.
 - Merge branch 'master' into JDK-8319457
 - Got rid of Wix36 WiX toolset type
 - ... and 16 more: https://git.openjdk.org/jdk/compare/5abc0292...fbb9f418

Changes: https://git.openjdk.org/jdk/pull/19318/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19318&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319457
  Stats: 1485 lines in 22 files changed: 1154 ins; 91 del; 240 mod
  Patch: https://git.openjdk.org/jdk/pull/19318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19318/head:pull/19318

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

From jlu at openjdk.org  Mon Jun  3 22:39:08 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Jun 2024 22:39:08 GMT
Subject: RFR: 8333456: CompactNumberFormat integer parsing fails when string
 has no suffix
Message-ID: <Yz_-c-Nr6p86TFltSwsjZyjOUh_k-xEFo-s52Fczkew=.4357fab6-4ba7-4051-be91-3c9245426008@github.com>

Please review this PR which handles incorrect CompactNumberFormat integer only parsing when there is no suffix.

See the following snippet,


var fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT)
fmt.setParseIntegerOnly(true)
fmt.parse("5K") // returns 5000
fmt.parse("50.00") // returns 50
fmt.parse("5") // unexpectedly throws StringIndexOutOfBoundsException 
fmt.parse("5 ") // returns 5


Within the `parse` method, there is code that advances `position` past the fractional portion to find the suffix when `parseIntegerOnly()` is true. However, if a valid string input is given with no suffix, `DecimalFormat.subparseNumber()` will fully iterate through the string and `position` will be equal to the length of the string, throwing StringIndexOutOfBoundsException when `charAt` is invoked (line 1740).

We should check to make sure position does not exceed the string length before deciding to check for a decimal symbol.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Mon Jun  3 23:01:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Jun 2024 23:01:31 GMT
Subject: RFR: 8333396: Performance regression of new DecimalFormat and
 DecimalFormat.format [v2]
In-Reply-To: <-uD4Wih5e1lvOwd2KFhBfcDKN1PrDr2aL_EVz1NzBC0=.48a676c7-cbac-422c-b3a5-763db15473ca@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <-uD4Wih5e1lvOwd2KFhBfcDKN1PrDr2aL_EVz1NzBC0=.48a676c7-cbac-422c-b3a5-763db15473ca@github.com>
Message-ID: <-lR14fPp8p-mX7THuFYQEDdZRHoP8OKwgOdgxEVEo0s=.d079484f-fa05-4786-bc71-f4b76fe7bea4@github.com>

On Mon, 3 Jun 2024 06:13:35 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Performance regression of new DecimalFormat
>> After comparing the flame graph between current jdk and jdk 11,  the method java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time.  The performance becomes as good as jdk11 after replacing it with a simple loop implementation.
>> 
>> 
>> 
>> ### Test result
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndForma...
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of new DecimalFormat and DecimalFormat.format

Hi,

Can you please provide more details? As to StringBuffer, I think it is being used since those classes in `java.text` package have been created. I am not sure why that contributes to what you described as the "performance regression".

Separately, please split this PR into two, as combining two different issues into a single JBS issue/PR is not right. The second issue is likely due to loading stream classes for the first time at JVM startup.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146264799

From nbenalla at openjdk.org  Tue Jun  4 00:41:07 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 00:41:07 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <g8LobAe5ZNYKbM6gXSF_nqEwM3PvH7sggS2mVOjOqCQ=.1713b92b-6539-41ad-9d6a-d3a4fff08d27@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

Here is a snippet from the report of the checker with the relevant bits for this PR

STDERR:
method: void java.io.PrintStream.write(byte[]): `@since` version is 14 but the element exists before JDK 10
method: java.lang.invoke.MethodHandle java.lang.invoke.MethodHandles.tableSwitch(java.lang.invoke.MethodHandle,java.lang.invoke.MethodHandle[]): `@since` version is 9 instead of 17
method: void java.lang.reflect.MalformedParameterizedTypeException.<init>(java.lang.String): `@since` version is 9 instead of 10
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(int,int): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.duplicate(): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.compact(): `@since` version is 9 instead of 17
method: void java.util.Properties.<init>(int): `@since` version is 9 instead of 10
method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float): `@since` version is 9 instead of 17
method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float,float): `@since` version is 9 instead of 17
method: void java.util.zip.Deflater.setDictionary(java.nio.ByteBuffer): `@since` version is 9 instead of 11




Here is the full report

STDERR:
method: void java.io.PrintStream.write(byte[]): `@since` version is 14 but the element exists before JDK 10
method: byte[] java.io.FileInputStream.readNBytes(int): `@since` version is 9 instead of 11
method: java.lang.classfile.Signature.ClassTypeSig java.lang.classfile.ClassSignature.superclassSignature(): `@since` version is 22 instead of 23
method: java.lang.classfile.constantpool.PoolEntry java.lang.classfile.ClassReader.readEntryOrNull(int,java.lang.Class): `@since` version is 24 instead of 23
method: java.lang.classfile.constantpool.PoolEntry java.lang.classfile.constantpool.ConstantPool.entryByIndex(int,java.lang.Class): `@since` version is 24 instead of 23
method: java.lang.Class java.lang.constant.ClassDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version is 12 instead of 21
method: java.lang.invoke.MethodType java.lang.constant.MethodTypeDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version is 12 instead of 21
method: java.lang.invoke.MethodHandle java.lang.constant.MethodHandleDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version is 12 instead of 21
method: long java.lang.foreign.MemorySegment.maxByteAlignment(): `@since` version is 22 instead of 23
method: java.lang.invoke.MethodHandle java.lang.invoke.MethodHandles.tableSwitch(java.lang.invoke.MethodHandle,java.lang.invoke.MethodHandle[]): `@since` version is 9 instead of 17
method: java.lang.Object java.lang.ref.Reference.clone(): `@since` version is 11 but the element exists before JDK 10
method: void java.lang.reflect.MalformedParameterizedTypeException.<init>(java.lang.String): `@since` version is 9 instead of 10
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(int,int): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.duplicate(): `@since` version is 9 instead of 17
method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.compact(): `@since` version is 9 instead of 17
method: boolean java.text.ChoiceFormat.isStrict(): `@since` version is 9 instead of 23
method: void java.text.ChoiceFormat.setStrict(boolean): `@since` version is 9 instead of 23
method: void java.util.Properties.<init>(int): `@since` version is 9 instead of 10
method: java.lang.Object java.util.concurrent.FutureTask.resultNow(): `@since` version is 9 instead of 19
method: java.lang.Throwable java.util.concurrent.FutureTask.exceptionNow(): `@since` version is 9 instead of 19
method: java.util.concurrent.Future.State java.util.concurrent.FutureTask.state(): `@since` version is 9 instead of 19
method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float): `@since` version is 9 instead of 17
method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float,float): `@since` version is 9 instead of 17
method: java.util.concurrent.Future.State java.util.concurrent.ForkJoinTask.state(): `@since` version is 9 instead of 19
method: java.lang.Object java.util.concurrent.ForkJoinTask.resultNow(): `@since` version is 9 instead of 19
method: java.lang.Throwable java.util.concurrent.ForkJoinTask.exceptionNow(): `@since` version is 9 instead of 19
method: java.util.concurrent.Delayed java.util.concurrent.DelayQueue.remove(): `@since` version is 9 instead of 21
method: java.lang.Object java.util.concurrent.CompletableFuture.resultNow(): `@since` version is 9 instead of 19
method: java.lang.Throwable java.util.concurrent.CompletableFuture.exceptionNow(): `@since` version is 9 instead of 19
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyAsync(java.util.function.Function): `@since` version is 9 instead of 12
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyAsync(java.util.function.Function,java.util.concurrent.Executor): `@since` version is 9 instead of 12
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyCompose(java.util.function.Function): `@since` version is 9 instead of 12
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyComposeAsync(java.util.function.Function): `@since` version is 9 instead of 12
method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyComposeAsync(java.util.function.Function,java.util.concurrent.Executor): `@since` version is 9 instead of 12
method: java.util.concurrent.Future.State java.util.concurrent.CompletableFuture.state(): `@since` version is 9 instead of 19
method: void java.util.zip.Deflater.setDictionary(java.nio.ByteBuffer): `@since` version is 9 instead of 11
java.lang.Exception: The `@since` checker found 37 problems
        at SinceChecker.checkModule(SinceChecker.java:262)
        at SinceChecker.main(SinceChecker.java:123)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.Exception
JavaTest Message: shutting down test


TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: The `@since` checker found 37 problems
--------------------------------------------------

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

PR Comment: https://git.openjdk.org/jdk/pull/18055#issuecomment-2146354662

From almatvee at openjdk.org  Tue Jun  4 01:23:11 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 4 Jun 2024 01:23:11 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <-o573bkx_xWBRkJS3IWGlevuqgWGL-4EyAxCexUvGUQ=.32f6db30-d90b-4be9-987b-7112349f11d4@github.com>

On Mon, 20 May 2024 21:14:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for WiX4 in jpackage.
> 
> jpackage supports both WiX3 and WiX4. It will pick WiX4 if both versions are installed.
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

Looks good overall. Only two minor comments.

1) Do we need to handle default case for unknown wix type? In same cases you have `default -> throw new IllegalArgumentException();` and in some you do not have.
2) Looks like resource files are saved in wrong format. Is it expected?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 1:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>

MsiInstallerStrings_de(ja,zh_CA).wxl are probably saved in wrong format. Can you double check if it is intentional change?

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

PR Review: https://git.openjdk.org/jdk/pull/19318#pullrequestreview-2095104559
PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1625207485

From almatvee at openjdk.org  Tue Jun  4 01:27:11 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 4 Jun 2024 01:27:11 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <vl66GAw13fAcrDR25WKxWfgNoIcxfbF_YIYdSniGV7A=.779162bc-8465-454a-a256-33ad593a41b7@github.com>

On Mon, 20 May 2024 21:14:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for WiX4 in jpackage.
> 
> jpackage supports both WiX3 and WiX4. It will pick WiX4 if both versions are installed.
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

WiX Toolset 5 is also available. Is there plan to add support for WiX 5?

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2146391220

From asemenyuk at openjdk.org  Tue Jun  4 01:31:24 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 01:31:24 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <_KH2nqfJlGhXRkSjfcbkoT0eh6BazisgILXajANJ4g0=.717d85e7-4979-404e-9683-3fb83f4cf9a5@github.com>

On Mon, 20 May 2024 21:14:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for WiX4 in jpackage.
> 
> jpackage supports both WiX3 and WiX4. It will pick WiX4 if both versions are installed.
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

Thank you for the review! I'll fix the L10N files.

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2146394454

From asemenyuk at openjdk.org  Tue Jun  4 01:31:24 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 01:31:24 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <vl66GAw13fAcrDR25WKxWfgNoIcxfbF_YIYdSniGV7A=.779162bc-8465-454a-a256-33ad593a41b7@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <vl66GAw13fAcrDR25WKxWfgNoIcxfbF_YIYdSniGV7A=.779162bc-8465-454a-a256-33ad593a41b7@github.com>
Message-ID: <MoUqz0AcISgDz8beoygDmh0hQt4360W1N1Cp3-eVIFo=.b524d976-4317-4743-9095-21b6b93dee90@github.com>

On Tue, 4 Jun 2024 01:24:15 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Is there plan to add support for WiX 5?

This patch supports WiX5 as well. There is not much difference between WiX4 and WiX5 from jpackage perspective. I'll update the description

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2146395368

From duke at openjdk.org  Tue Jun  4 01:39:12 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 4 Jun 2024 01:39:12 GMT
Subject: RFR: 8333396: Performance regression of new DecimalFormat and
 DecimalFormat.format [v2]
In-Reply-To: <-uD4Wih5e1lvOwd2KFhBfcDKN1PrDr2aL_EVz1NzBC0=.48a676c7-cbac-422c-b3a5-763db15473ca@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <-uD4Wih5e1lvOwd2KFhBfcDKN1PrDr2aL_EVz1NzBC0=.48a676c7-cbac-422c-b3a5-763db15473ca@github.com>
Message-ID: <YbwlgB8ZLoKx46kpjIFjSgLeULDLpS2POU0e-Uw4yuY=.17682b33-ca19-4ce2-8751-a5ac23314867@github.com>

On Mon, 3 Jun 2024 06:13:35 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Performance regression of new DecimalFormat
>> After comparing the flame graph between current jdk and jdk 11,  the method java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time.  The performance becomes as good as jdk11 after replacing it with a simple loop implementation.
>> 
>> 
>> 
>> ### Test result
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndForma...
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of new DecimalFormat and DecimalFormat.format

Hi naotaoj,
    What I mean "performance regression" is compare to JDK 11. We have an server side application that use DecimalFormat.format API seriously. When migrate it from JDK 11 to JDK 21, we found a performance  degradation.
So I write the JMH test case "JmhDecimalFormat".  It show that there a performance regression since JDK 21.

These are the perfasm output for running JMH on both JDK 11 and JDK21. There are some  hot regions around the atomic instructions in JDK 21, but no such problem in JDK 11.
[jdk11.txt](https://github.com/user-attachments/files/15541278/jdk11.txt)
[jdk21.txt](https://github.com/user-attachments/files/15541279/jdk21.txt)

Maybe the [JEP 374: Deprecate and Disable Biased Locking](https://openjdk.org/jeps/374) is the reason?
So I run the benchmark on JDK 11 again but with option '-XX:-UseBiasedLocking',  there only a minor gap between jdk11 and jdk 21.

OK, return to my patch. java.text use StringBuffer internally,  but nearly all methods in StringBuffer are synchronized:

    @Override
    public synchronized StringBuffer append(Object obj) {
        ....
    }

    @Override
    @IntrinsicCandidate
    public synchronized StringBuffer append(String str) {
        ...
    }


>From the above analysis, the atomic instructions slow down DecimalFormat.format, and StringBuffer's synchronized methods generate there atomic instructions. So If remove these synchronized methods, it will get a better performance.
So I replace StringBuffer with StringBuilder in  java.text.NumberFormat.

    public final String format(double number) {
        // Use fast-path for double result if that works
        String result = fastFormat(number);
        if (result != null)
            return result;

        -return format(number, new StringBuffer(),
        +return format(number, new StringBuilder(),
                      DontCareFieldPosition.INSTANCE).toString();
    }

@@ -367,7 +367,7 @@ public final String format(double number) {
     * @see java.text.Format#format
     */
    public final String format(long number) {
       - return format(number, new StringBuffer(),
       + return format(number, new StringBuilder(),
                      DontCareFieldPosition.INSTANCE).toString();
    }


> Separately, please split this PR into two, as combining two different issues into a single JBS issue/PR is not right. The second issue is likely due to loading stream classes for the first time at JVM startup.
This is the flame graph compare to JDK 11 and JDK 21:
[flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541397/flame-graph-jdk11-jdk21.zip)

OK. I will create a separate  issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146401596

From vdyakov at openjdk.org  Tue Jun  4 01:40:31 2024
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Tue, 4 Jun 2024 01:40:31 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <JgjBRMk8UueY98C4NZi-Khq9ZAN8IqTllqr9fP7tZRs=.b989db1d-2da5-4b2e-a342-90d71348aff1@github.com>

On Mon, 20 May 2024 21:14:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for WiX4 (and WiX5) in jpackage.
> 
> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

as we previously agreed this is for JDK 24 (mainline is becoming JDK 24 after 10am PT on Thu June 6) just do not jeopardize  by any kind of risks on stabilization part with all tests run cycle, so good to integrate once it is reviewed and approved after June 6th

WiX v5 for WiX v4 users

WiX v5 is highly compatible with WiX v4. WiX v5 continues in the traditions of WiX v4 and is available as both a .NET tool and an MSBuild SDK. The WiX v5 language uses the same XML namespace as WiX v4 and -- with a couple of exceptions -- is backward compatible with the WiX v4 language. That means that you don't need to translate your WiX v4 projects to use WiX v5.
https://wixtoolset.org/docs/fivefour/

So this is a good point to make it working with WiX 5 (not just WiX 4)

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2146401059
PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2146402910

From jpai at openjdk.org  Tue Jun  4 01:56:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 01:56:09 GMT
Subject: RFR: 8333398: Uncomment the commented test in
 test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java
In-Reply-To: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>
References: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>
Message-ID: <xGaKbJE45KJcvaIYsGgs4R5JKjf2p84gJX5x2DqR39k=.d69875ba-059c-4aa7-a982-ba68fe6a295c@github.com>

On Mon, 3 Jun 2024 04:25:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which uncomments an additional test that was commented out in `test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8333398, the original issue due to which this line was commented out in the test, has been fixed several releases back and thus this line can now be uncommented.
> 
> I've verified that this test continues to pass with these changes.

Thank you Iris and Lance for the reviews.

> We should look at at a later date to convert this to junit and when we do, look to rework isMultiReleaseJar() as it actually runs multiple tests within the test itself and if one fails, the rest will not be run

I have added it to my TODO to update this test in future.

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

PR Comment: https://git.openjdk.org/jdk/pull/19514#issuecomment-2146416470

From jpai at openjdk.org  Tue Jun  4 01:56:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 01:56:10 GMT
Subject: Integrated: 8333398: Uncomment the commented test in
 test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java
In-Reply-To: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>
References: <oCOjc_f1Jfrg13gsj3fviu3xve5gktbDXhW9ixZU-_8=.e947819b-d07b-457d-b99a-1276459f0f10@github.com>
Message-ID: <PSaeeOwAKJJ97H_wmseuYS3g6RHmjbnyMh6UH7aHa5s=.3384ed24-2d77-4653-a240-6d99b146b83b@github.com>

On Mon, 3 Jun 2024 04:25:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which uncomments an additional test that was commented out in `test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8333398, the original issue due to which this line was commented out in the test, has been fixed several releases back and thus this line can now be uncommented.
> 
> I've verified that this test continues to pass with these changes.

This pull request has now been integrated.

Changeset: d230b303
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d230b30353f59135287436b09949b80e9fd73a93
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8333398: Uncomment the commented test in test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java

Reviewed-by: iris, lancea

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

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

From duke at openjdk.org  Tue Jun  4 02:18:49 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 4 Jun 2024 02:18:49 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v3]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <PVzpg-_ibw6JM-KwRo6BoG48-ZVMUgZLjXyJSMdVsMs=.f6dc625a-00de-4a54-bb87-029512a92f92@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Test result
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/b48962b5..0a581428

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

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

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

From duke at openjdk.org  Tue Jun  4 02:39:24 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 4 Jun 2024 02:39:24 GMT
Subject: RFR: 8333462: Performance regression of new DecimalFormat() when
 compare to jdk11
Message-ID: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>

Run the below benchmark test  ,it show the average time of new DecimalFormat()  increase 18% when compare to jdk 11.

the result with jdk 11:

Benchmark                          Mode  Cnt    Score   Error  Units
JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op


the result with current jdk:

Benchmark                          Mode  Cnt    Score   Error  Units
JmhDecimalFormat.testNewOnly       avgt   50  303.381 ? 5.252  ns/op



@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class JmhDecimalFormat {

    @Setup(Level.Trial)
    public void setup() {
    }

    @Benchmark
    public void testNewOnly() throws InterruptedException {
        new DecimalFormat("#0.00000");
    }
}


Compare the flame graph it shows the java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. 
After replacing  the lambda implementation with a simple loop , it shows nearly the same performance as jdk 11.


Benchmark                          Mode  Cnt    Score   Error  Units
JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op


[flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541764/flame-graph-jdk11-jdk21.zip)

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

Commit messages:
 - 8333462: Performance regression of new DecimalFormat() when compare to jdk11

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

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

From almatvee at openjdk.org  Tue Jun  4 02:41:04 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 4 Jun 2024 02:41:04 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <MoUqz0AcISgDz8beoygDmh0hQt4360W1N1Cp3-eVIFo=.b524d976-4317-4743-9095-21b6b93dee90@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <vl66GAw13fAcrDR25WKxWfgNoIcxfbF_YIYdSniGV7A=.779162bc-8465-454a-a256-33ad593a41b7@github.com>
 <MoUqz0AcISgDz8beoygDmh0hQt4360W1N1Cp3-eVIFo=.b524d976-4317-4743-9095-21b6b93dee90@github.com>
Message-ID: <ul-uv7qR47M4w712xqL_58qj3Yv3pK2MooRhKpgOZKQ=.6d0232b7-4c24-4a22-a11b-d0e391bc6087@github.com>

On Tue, 4 Jun 2024 01:29:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> > Is there plan to add support for WiX 5?
> 
> This patch supports WiX5 as well. There is not much difference between WiX4 and WiX5 from jpackage perspective. I'll update the description

I assume WiX5 will just work if installed instead of WiX4? Do you think it will make sense to introduce Wix5 ToolsetType in case if we need to do something different between 4 and 5?

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2146460825

From almatvee at openjdk.org  Tue Jun  4 02:45:08 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 4 Jun 2024 02:45:08 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <QuBAno9aEVQTSYcuz3V-vXYY6QkFJUpmyY6XEZ9uWb0=.2d260f76-cf72-4a24-a769-1ad02919a7a2@github.com>

On Mon, 20 May 2024 21:14:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for WiX4 (and WiX5) in jpackage.
> 
> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java line 51:

> 49:     Candle3("candle", DottedVersion.lazy("3.0")),
> 50:     Light3("light", DottedVersion.lazy("3.0")),
> 51:     Wix4("wix", DottedVersion.lazy("4.0.4"));

Is there any reason to use "4.0.4" here? Latest released version is "4.0.5". Can we just put "4.0" similar to "3.0".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1625259023

From vlivanov at openjdk.org  Tue Jun  4 04:05:12 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 4 Jun 2024 04:05:12 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
 [v2]
In-Reply-To: <BknxIyKtS1mS1yFR8ebXJ8-PWGqSDF6GW-Cz3KSe69k=.699dc9a3-6b36-43c9-962b-2969944d9737@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
 <BknxIyKtS1mS1yFR8ebXJ8-PWGqSDF6GW-Cz3KSe69k=.699dc9a3-6b36-43c9-962b-2969944d9737@github.com>
Message-ID: <2fd-qvBsJuxYtZmX22F7u5ycAN7uDMobngVKi3Wqrtc=.dc93d9da-948d-433d-9aeb-a205407a41b5@github.com>

On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 
>> 
>> There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.
>> 
>> Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 
>> 
>> In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  
>> 
>> Testing: hs-tier1 - hs-tier4
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming: isTypeVisible -> ensureTypeVisible

Thanks for the reviews, Jorn and Chen.

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

PR Comment: https://git.openjdk.org/jdk/pull/19319#issuecomment-2146542294

From vlivanov at openjdk.org  Tue Jun  4 04:05:13 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 4 Jun 2024 04:05:13 GMT
Subject: Integrated: 8332547: Unloaded signature classes in DirectMethodHandles
In-Reply-To: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
Message-ID: <88jGtEXd70Hb-Qjg9oZKX_N3Ut3OOn8hAAhb1GsTFnU=.92540a2f-028d-4d4c-b2f1-e72f25d91942@github.com>

On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 
> 
> There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.
> 
> Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 
> 
> In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  
> 
> Testing: hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: 29e10e45
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29e10e4582c1a844a6db4c42ba01bd1d6d4dfd52
Stats:     83 lines in 4 files changed: 68 ins; 0 del; 15 mod

8332547: Unloaded signature classes in DirectMethodHandles

Reviewed-by: jvernee, liach

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

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

From dholmes at openjdk.org  Tue Jun  4 05:57:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Jun 2024 05:57:04 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <DIn0iEluK0_nCbH2N3kqrDGap5IpmctZxwVJuYRd_qs=.137604f6-4e66-46e2-ae4f-75ca3c13e4b7@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
 <nQP1t6EuMVLeGihN8RTSfFMqMEJP77BEvoeb7pElQUg=.7ba77c32-a98d-4d7e-ad3b-040f8597264c@github.com>
 <DIn0iEluK0_nCbH2N3kqrDGap5IpmctZxwVJuYRd_qs=.137604f6-4e66-46e2-ae4f-75ca3c13e4b7@github.com>
Message-ID: <m1Y5cDDzKuA26xv0pPOTzpf2DCrS7TPSCP3anxRk_Vo=.0677ca64-3757-46ef-ab67-bc8404219232@github.com>

On Mon, 3 Jun 2024 14:38:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> I am yet to see anything that actually explains the cause of the `dlerror` crash here ???
>
> @dholmes-ora there is no fix for the cause of the `dlerror` crash in this PR. The PR fixes jpackage tests to rerun a launcher if it crashes. This workaround for jpackage tests was first introduced in [JDK-8269403](https://bugs.openjdk.org/browse/JDK-8269403) fix but MainClassTest was left unfixed back then. This PR complements [JDK-8269403](https://bugs.openjdk.org/browse/JDK-8269403).

@alexeysemenyukoracle But now there is no bug to investigate the dlerrror crash! If you wanted to make the test more robust a new JBS issue should have been filed for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2146669916

From alanb at openjdk.org  Tue Jun  4 06:46:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Jun 2024 06:46:17 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <DIn0iEluK0_nCbH2N3kqrDGap5IpmctZxwVJuYRd_qs=.137604f6-4e66-46e2-ae4f-75ca3c13e4b7@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
 <nQP1t6EuMVLeGihN8RTSfFMqMEJP77BEvoeb7pElQUg=.7ba77c32-a98d-4d7e-ad3b-040f8597264c@github.com>
 <DIn0iEluK0_nCbH2N3kqrDGap5IpmctZxwVJuYRd_qs=.137604f6-4e66-46e2-ae4f-75ca3c13e4b7@github.com>
Message-ID: <WInqr2RGqxPIhoDlKiTCLFsB5N8lCkw-dNYp0zYyjCc=.88178d89-0552-45cb-9c47-8c85ca75a4fe@github.com>

On Mon, 3 Jun 2024 14:38:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> I am yet to see anything that actually explains the cause of the `dlerror` crash here ???
>
> @dholmes-ora there is no fix for the cause of the `dlerror` crash in this PR. The PR fixes jpackage tests to rerun a launcher if it crashes. This workaround for jpackage tests was first introduced in [JDK-8269403](https://bugs.openjdk.org/browse/JDK-8269403) fix but MainClassTest was left unfixed back then. This PR complements [JDK-8269403](https://bugs.openjdk.org/browse/JDK-8269403).

@alexeysemenyukoracle If I read JDK-8269403 correctly then there is an issue somewhere that hasn't been diagnosed. A workaround has been put in to "re-run" when there is a crash, thus hiding the issue. Are there follow-up issues created in JBS to continue the hunt for the original crash?

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

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2146731836

From scolebourne at joda.org  Tue Jun  4 07:17:07 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 4 Jun 2024 08:17:07 +0100
Subject: Instant.now(Clock) and InstantSource
In-Reply-To: <CAB3z6Ajk6zNaTtY6y01EYNe=GUyBWFXV-uEe4fJasvnBvBaQFQ@mail.gmail.com>
References: <CAB3z6Ajk6zNaTtY6y01EYNe=GUyBWFXV-uEe4fJasvnBvBaQFQ@mail.gmail.com>
Message-ID: <CACzrW9AJsm_Lq0AOSYjER_RYS0h+xP5WaKnMZR+0w=7aU=R2LA@mail.gmail.com>

On Mon, 3 Jun 2024 at 22:25, Kurt Alfred Kluever <kak at google.com> wrote:
> It feels a bit strange that you can't pass an `InstantSource` to `Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a "useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to propose one of the following API changes:
>
> 1) adding `Instant.now(InstantSource)`
> 2) deprecating `Instant.now(Clock)` in favor of `clock.instant()`

I have no problem with adding `Instant.now(InstantSource)`, but I
think deprecating the `Clock` method is unnecessary (given it will
never be removed AFAICT, and it is no doubt in widespread use).
Stephen

From duke at openjdk.org  Tue Jun  4 07:25:07 2024
From: duke at openjdk.org (kuaiwei)
Date: Tue, 4 Jun 2024 07:25:07 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v3]
In-Reply-To: <PVzpg-_ibw6JM-KwRo6BoG48-ZVMUgZLjXyJSMdVsMs=.f6dc625a-00de-4a54-bb87-029512a92f92@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <PVzpg-_ibw6JM-KwRo6BoG48-ZVMUgZLjXyJSMdVsMs=.f6dc625a-00de-4a54-bb87-029512a92f92@github.com>
Message-ID: <NkP_fLSFaQDFsLgsHezHGLvbQQDmvdxHzqxY6jP0sCo=.cb8fd101-4a69-4c15-a639-f2754b10e6b5@github.com>

On Tue, 4 Jun 2024 02:18:49 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Test result
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Hi, I think you can add the jmh test case.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146791250

From syan at openjdk.org  Tue Jun  4 07:51:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Jun 2024 07:51:36 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
Message-ID: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>

Hi all,
  This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.

Thanks.

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

Commit messages:
 - 8333477: Delete extra empty spaces in Makefiles

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

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

From duke at openjdk.org  Tue Jun  4 07:53:02 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 4 Jun 2024 07:53:02 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v3]
In-Reply-To: <NkP_fLSFaQDFsLgsHezHGLvbQQDmvdxHzqxY6jP0sCo=.cb8fd101-4a69-4c15-a639-f2754b10e6b5@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <PVzpg-_ibw6JM-KwRo6BoG48-ZVMUgZLjXyJSMdVsMs=.f6dc625a-00de-4a54-bb87-029512a92f92@github.com>
 <NkP_fLSFaQDFsLgsHezHGLvbQQDmvdxHzqxY6jP0sCo=.cb8fd101-4a69-4c15-a639-f2754b10e6b5@github.com>
Message-ID: <e2WgzgI_iy7XTE8QiwVwKKRdThUUBvkOZ1h4CjL63do=.e3618e42-891b-4fd9-8a14-fa32dd587112@github.com>

On Tue, 4 Jun 2024 07:21:15 GMT, kuaiwei <duke at openjdk.org> wrote:

> Hi, I think you can add the jmh test case.

https://github.com/openjdk/jdk/pull/19513#issue-2330131051 already contains the test case.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146844849

From duke at openjdk.org  Tue Jun  4 07:58:16 2024
From: duke at openjdk.org (kuaiwei)
Date: Tue, 4 Jun 2024 07:58:16 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v3]
In-Reply-To: <PVzpg-_ibw6JM-KwRo6BoG48-ZVMUgZLjXyJSMdVsMs=.f6dc625a-00de-4a54-bb87-029512a92f92@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <PVzpg-_ibw6JM-KwRo6BoG48-ZVMUgZLjXyJSMdVsMs=.f6dc625a-00de-4a54-bb87-029512a92f92@github.com>
Message-ID: <LCD6lVO-VZLSzu7qI8w-7PTycv7q6XB604fTTe5Yi2o=.cd20c672-df34-42d3-ae1d-01b33b6adb91@github.com>

On Tue, 4 Jun 2024 02:18:49 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

> > Hi, I think you can add the jmh test case.
> 
> [#19513 (comment)](https://github.com/openjdk/jdk/pull/19513#issue-2330131051) already contains the test case.

I mean it can be added as a test case in test/micro and be evaluated in future build.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146853395

From duke at openjdk.org  Tue Jun  4 09:01:04 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 4 Jun 2024 09:01:04 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v3]
In-Reply-To: <LCD6lVO-VZLSzu7qI8w-7PTycv7q6XB604fTTe5Yi2o=.cd20c672-df34-42d3-ae1d-01b33b6adb91@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <PVzpg-_ibw6JM-KwRo6BoG48-ZVMUgZLjXyJSMdVsMs=.f6dc625a-00de-4a54-bb87-029512a92f92@github.com>
 <LCD6lVO-VZLSzu7qI8w-7PTycv7q6XB604fTTe5Yi2o=.cd20c672-df34-42d3-ae1d-01b33b6adb91@github.com>
Message-ID: <jEIvH2gC5F2WGQKoXiSYv3dfTICQ-QYSsZHtA9IP9ds=.e15a7afd-33a0-4d35-b419-f668c3767977@github.com>

On Tue, 4 Jun 2024 07:54:56 GMT, kuaiwei <duke at openjdk.org> wrote:

> > > Hi, I think you can add the jmh test case.
> > 
> > 
> > [#19513 (comment)](https://github.com/openjdk/jdk/pull/19513#issue-2330131051) already contains the test case.
> 
> I mean it can be added as a test case in test/micro and be evaluated in future build.

Thanks for your remainder. There exist a JMH  test case which named  'test/micro/org/openjdk/bench/java/text/DefFormatterBench.java'.

This JMH test case run in throughput mode.
If  run without the patch, the output is:

Benchmark                                  Mode  Cnt     Score    Error   Units
DefFormatterBench.testDefNumberFormatter  thrpt    5  1842.666 ? 83.694  ops/ms


If run with after apply the patch, the output is:

Benchmark                                  Mode  Cnt     Score     Error   Units
DefFormatterBench.testDefNumberFormatter  thrpt    5  3988.274 ? 513.434  ops/ms


The score is increased by  (3988.274-1842.666)/1842.666 = 116%.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146983441

From ihse at openjdk.org  Tue Jun  4 09:07:22 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Jun 2024 09:07:22 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
 <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>
 <Ok6ibGzy9-6oa-c2Ie-lCulQXObKKkusvHP1QeR_WlE=.799e6764-c532-4647-b61c-e5a19aadbc1c@github.com>
 <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>
Message-ID: <RDoTbqMFZmxaHTIzXrbjjUGb17GEV--wLyUz3dqM7kc=.727177ca-4ee1-45fd-be68-5ff200cc8d1f@github.com>

On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Does that proposal sound good?

What you basically is saying is that the default value of `packaged-modules` should be `! runtime-link-image` (i.e. the inverse)?

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

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

From duke at openjdk.org  Tue Jun  4 09:07:44 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 4 Jun 2024 09:07:44 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/0a581428..6210c61e

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

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

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

From duke at openjdk.org  Tue Jun  4 09:09:05 2024
From: duke at openjdk.org (kuaiwei)
Date: Tue, 4 Jun 2024 09:09:05 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v3]
In-Reply-To: <jEIvH2gC5F2WGQKoXiSYv3dfTICQ-QYSsZHtA9IP9ds=.e15a7afd-33a0-4d35-b419-f668c3767977@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <PVzpg-_ibw6JM-KwRo6BoG48-ZVMUgZLjXyJSMdVsMs=.f6dc625a-00de-4a54-bb87-029512a92f92@github.com>
 <LCD6lVO-VZLSzu7qI8w-7PTycv7q6XB604fTTe5Yi2o=.cd20c672-df34-42d3-ae1d-01b33b6adb91@github.com>
 <jEIvH2gC5F2WGQKoXiSYv3dfTICQ-QYSsZHtA9IP9ds=.e15a7afd-33a0-4d35-b419-f668c3767977@github.com>
Message-ID: <2W8HmjrFpkx70jtdbOELneBDxX8m4QxG-Pvxa00f9cs=.428ef3eb-e3aa-48e7-9bc2-4f1112c692ea@github.com>

On Tue, 4 Jun 2024 08:58:38 GMT, lingjun-cg <duke at openjdk.org> wrote:

> > > > Hi, I think you can add the jmh test case.
> > > 
> > > 
> > > [#19513 (comment)](https://github.com/openjdk/jdk/pull/19513#issue-2330131051) already contains the test case.
> > 
> > 
> > I mean it can be added as a test case in test/micro and be evaluated in future build.
> 
> Thanks for your remainder. There exist a JMH test case which named 'test/micro/org/openjdk/bench/java/text/DefFormatterBench.java'.
> 
> This JMH test case run in throughput mode. If run without the patch, the output is:
> 
> ```
> Benchmark                                  Mode  Cnt     Score    Error   Units
> DefFormatterBench.testDefNumberFormatter  thrpt    5  1842.666 ? 83.694  ops/ms
> ```
> 
> If run with after apply the patch, the output is:
> 
> ```
> Benchmark                                  Mode  Cnt     Score     Error   Units
> DefFormatterBench.testDefNumberFormatter  thrpt    5  3988.274 ? 513.434  ops/ms
> ```
> 
> The score is increased by (3988.274-1842.666)/1842.666 = 116%.

Yes, it's what I expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146999574

From sgehwolf at openjdk.org  Tue Jun  4 09:11:28 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Jun 2024 09:11:28 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <RDoTbqMFZmxaHTIzXrbjjUGb17GEV--wLyUz3dqM7kc=.727177ca-4ee1-45fd-be68-5ff200cc8d1f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
 <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>
 <Ok6ibGzy9-6oa-c2Ie-lCulQXObKKkusvHP1QeR_WlE=.799e6764-c532-4647-b61c-e5a19aadbc1c@github.com>
 <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>
 <RDoTbqMFZmxaHTIzXrbjjUGb17GEV--wLyUz3dqM7kc=.727177ca-4ee1-45fd-be68-5ff200cc8d1f@github.com>
Message-ID: <B7v3jyePcdnwp-RRWjCkBUbGh3aEn63pJcOWOTU4lg0=.bcf83d33-a926-401e-9f59-bd8051db0ed4@github.com>

On Tue, 4 Jun 2024 09:04:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Does that proposal sound good?
> 
> What you basically is saying is that the default value of `packaged-modules` should be `! runtime-link-image` (i.e. the inverse)?

Yes. **default** of the `packaged-modules` value being the key.

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

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

From sgehwolf at openjdk.org  Tue Jun  4 09:54:27 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Jun 2024 09:54:27 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support
Message-ID: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>

Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.

I'm adding those tests in order to not regress another time.

Testing:
- [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
- [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
- [x] GHA

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

Commit messages:
 - Fix comments
 - 8333446: Add tests for hierarchical container support

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

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

From sgehwolf at openjdk.org  Tue Jun  4 09:54:27 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Jun 2024 09:54:27 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <Fv3DeJKTuhT9MAk1LR-yrOayFl_KsYjflSrxDNJEFzo=.204e6e6d-c860-410b-bfa5-ad232342488f@github.com>

On Mon, 3 Jun 2024 17:28:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
> 
> I'm adding those tests in order to not regress another time.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
> - [x] GHA

GHA failure of macos-x64 seems infra related and not related to this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2147097626

From sgehwolf at openjdk.org  Tue Jun  4 09:59:29 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Jun 2024 09:59:29 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
 <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>
 <Ok6ibGzy9-6oa-c2Ie-lCulQXObKKkusvHP1QeR_WlE=.799e6764-c532-4647-b61c-e5a19aadbc1c@github.com>
 <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>
Message-ID: <qfwrOreRLLUdVpzUCyxPNBzN0J6Gd4k8OXkLTRYrFs4=.5240944b-8627-4ae0-ad9d-773487edd3c7@github.com>

On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've read through most of the changes now. Overall I think it's looking good, just a few terminology and minor points that I'll add as comments.

@AlanBateman I don't see those comments. Should I?

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

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

From jpai at openjdk.org  Tue Jun  4 11:38:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:38:09 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <uWRhKu369gf7BDLKcCkB0vd5ptaNcbHiMvXFIRp5QGU=.8f31d58d-d217-4dfe-8c2c-4ce297d74a76@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/io/PrintStream.java line 683:

> 681:      * @see #write(byte[],int,int)
> 682:      *
> 683:      * @since 14

The `@since 14` was added here as part of https://bugs.openjdk.org/browse/JDK-8187898. The CSR explains what the changes were https://bugs.openjdk.org/browse/JDK-8230625. As noted in that CSR's specification (and attached images), the change for this method in that issue ended up being just API clarification (through a `@apiNote`) and no other change to this specific method. It continued to have the same signature including the throws clause that was previously available on this class through the super `FilterOutputStream#write(byte[])` method.

So removing this `@since 14` looks correct to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625840895

From jpai at openjdk.org  Tue Jun  4 11:41:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:41:07 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <9cNhL1WSyM-7ciSlWChw51xUvYUQYf8-mKxII-yT9Z4=.262297ee-ee41-4112-bcec-d6c706559d68@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7925:

> 7923:      * @since 17
> 7924:      */
> 7925:     public static MethodHandle tableSwitch(MethodHandle fallback, MethodHandle... targets) {

This method was introduced in Java 17 through https://bugs.openjdk.org/browse/JDK-8263087. So this addition of `@since 17` looks fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625845162

From jpai at openjdk.org  Tue Jun  4 11:44:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:44:05 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <aZVdWWOpBrlzcEAKpfAMaQWxi6Ygia0qvJtrzb2-DOM=.18637220-5c17-477b-90a8-868d8ee32a98@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/lang/reflect/MalformedParameterizedTypeException.java line 56:

> 54:      * @since 10
> 55:      */
> 56:     public MalformedParameterizedTypeException(String message) {

Both this and the explicit no-arg constructor were introduced in this class through https://bugs.openjdk.org/browse/JDK-8183175 in Java 10. Since an (implicit) no-arg constructor was always available even before that change, it makes sense to add a `@since 10` to only this explicit constructor. This change looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625848542

From jpai at openjdk.org  Tue Jun  4 11:53:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:53:09 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <4iicrOFX4yXDID9AdiLV73BBhTU8GuFT5z3mq1g9Zn4=.7d507deb-35b4-40bc-8d47-dc8165b22730@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/nio/MappedByteBuffer.java line 404:

> 402:      */
> 403:     @Override
> 404:     public abstract MappedByteBuffer slice();

This and the other 3 methods on which this `@since 17` is being added here were introduced in Java 17, through https://bugs.openjdk.org/browse/JDK-4833719. Before that change, these methods would have been available on this `MappedByteBuffer` through the super `ByteBuffer` class and those methods have been specified to return a `ByteBuffer`. After that change in JDK-4833719, these methods now return a `MappedByteBuffer` which is an observable change. So adding `@since 17` to these methods looks correct to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625858949

From jpai at openjdk.org  Tue Jun  4 11:56:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 11:56:32 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <X8xDmi3GecEzZZOLCQ5rhqfUCj1JUP5oM6DeFZ8ioA0=.92ea7709-8eb0-4d3b-998a-3a88df933034@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/util/Properties.java line 190:

> 188:      * @since 10
> 189:      */
> 190:     public Properties(int initialCapacity) {

This constructor was introduced in Java 10 through https://bugs.openjdk.org/browse/JDK-8189319, so adding `@since 10` here looks correct to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625864049

From jpai at openjdk.org  Tue Jun  4 12:02:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 12:02:10 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <SbEk9j4jgaUfABUNVroMZxdupxj5oVCpZmmHLFsrUY8=.eb20204c-6363-49cd-ad21-77a3702d0649@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 513:

> 511:      */
> 512:     @Override
> 513:     public float nextFloat(float bound) {

These 2 `nextFloat(...)` methods which take parameters were introduced in Java 17 https://bugs.openjdk.org/browse/JDK-8248862, whereas the no-arg `nextFloat()` method existed prior to that. So adding `@since 17` to these 2 methods looks correct to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625871382

From jpai at openjdk.org  Tue Jun  4 12:09:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 12:09:13 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <3BU-FyIAlIKRp6fuWFZ1RLtiNk4Jqn1PzvpXBnUH8GI=.2b2a55d1-6db9-4e15-9411-c0b2c36d8552@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

These changes look good to me. Thank you Nizar for the work on the `@since` checker and these PRs in individual areas.

src/java.base/share/classes/java/util/zip/Deflater.java line 342:

> 340:      * @since 11
> 341:      */
> 342:     public void setDictionary(ByteBuffer dictionary) {

This method was introduced in Java 11 through https://bugs.openjdk.org/browse/JDK-6341887. It appears to be an oversight that a `@since 11` wasn't added to this method in that change, because other new methods introduced in that change did come with a `@since 11`. So this addition of `@since 11` now looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18055#pullrequestreview-2096192264
PR Review Comment: https://git.openjdk.org/jdk/pull/18055#discussion_r1625879138

From liach at openjdk.org  Tue Jun  4 12:17:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Jun 2024 12:17:03 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
Message-ID: <9b1t-nvBzroL2HmUPp287t-GaRiYO1AtrriSX87ktnE=.2ff3c363-a1d9-4841-8e02-c0d667153a7a@github.com>

On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

src/java.base/share/classes/java/text/NumberFormat.java line 405:

> 403:                          StringBuilder toAppendTo,
> 404:                          FieldPosition pos) {
> 405:         throw new UnsupportedOperationException("Subclasses should override this " +

NumberFormat supports user-created classes, as it is abstract and has a protected constructor. This will cause exceptions in formatting users' custom NumberFormat subclasses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1625890872

From liach at openjdk.org  Tue Jun  4 12:21:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Jun 2024 12:21:05 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
Message-ID: <YW4H8oXvZtvvVElsknTNsNyHn4qSqm6NgZlxxGmJe_k=.eb798efb-46bb-4b4e-a324-475b2a831428@github.com>

On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

src/java.base/share/classes/java/text/NumberFormat.java line 350:

> 348:             return result;
> 349: 
> 350:         return format(number, new StringBuffer(),

Instead of just calling the package-private method that cannot be implemented by user subclasses, we can probably add a package-private method like `boolean isInternalSubclass` to decide if we should call the Buffer or Builder version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1625900669

From liach at openjdk.org  Tue Jun  4 12:23:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Jun 2024 12:23:15 GMT
Subject: RFR: 8333462: Performance regression of new DecimalFormat() when
 compare to jdk11
In-Reply-To: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
References: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
Message-ID: <aoKL7_Mjuf3hDNKPK4zKDgRaAo6t_VDsGDKMjWfZ_no=.ad01a3b8-34f0-48df-bea2-2f7e4f76ea92@github.com>

On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg <duke at openjdk.org> wrote:

> Run the below benchmark test  ,it show the average time of new DecimalFormat()  increase 18% when compare to jdk 11.
> 
> the result with jdk 11:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
> 
> 
> the result with current jdk:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     @Setup(Level.Trial)
>     public void setup() {
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> }
> 
> 
> Compare the flame graph it shows the java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. 
> After replacing  the lambda implementation with a simple loop , it shows nearly the same performance as jdk 11.
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> [flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541764/flame-graph-jdk11-jdk21.zip)

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/19534#pullrequestreview-2096229334

From asemenyuk at openjdk.org  Tue Jun  4 12:36:34 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 12:36:34 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <QuBAno9aEVQTSYcuz3V-vXYY6QkFJUpmyY6XEZ9uWb0=.2d260f76-cf72-4a24-a769-1ad02919a7a2@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <QuBAno9aEVQTSYcuz3V-vXYY6QkFJUpmyY6XEZ9uWb0=.2d260f76-cf72-4a24-a769-1ad02919a7a2@github.com>
Message-ID: <a1FiBllPxCTJNlxcAJAMOLDDajDrR6AQZLL65hpucKQ=.25c2bec1-b8bd-43b3-9e81-a8dca99fbb81@github.com>

On Tue, 4 Jun 2024 02:41:29 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Add support for WiX4 (and WiX5) in jpackage.
>> 
>> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
>> 
>> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
>> 
>> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
>> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
>> 
>> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java line 51:
> 
>> 49:     Candle3("candle", DottedVersion.lazy("3.0")),
>> 50:     Light3("light", DottedVersion.lazy("3.0")),
>> 51:     Wix4("wix", DottedVersion.lazy("4.0.4"));
> 
> Is there any reason to use "4.0.4" here? Latest released version is "4.0.5". Can we just put "4.0" similar to "3.0".

WiX4 prior v4.0.4 has a security vulnerability - https://www.tenable.com/plugins/nessus/190557
So v4.0.4 is the minimal WiX4 version jpackage will support.

As for WiX3, I don't think we should alter the minimal supported version due to backward compatibility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1625923156

From asemenyuk at openjdk.org  Tue Jun  4 12:41:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 12:41:03 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
In-Reply-To: <ul-uv7qR47M4w712xqL_58qj3Yv3pK2MooRhKpgOZKQ=.6d0232b7-4c24-4a22-a11b-d0e391bc6087@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <vl66GAw13fAcrDR25WKxWfgNoIcxfbF_YIYdSniGV7A=.779162bc-8465-454a-a256-33ad593a41b7@github.com>
 <MoUqz0AcISgDz8beoygDmh0hQt4360W1N1Cp3-eVIFo=.b524d976-4317-4743-9095-21b6b93dee90@github.com>
 <ul-uv7qR47M4w712xqL_58qj3Yv3pK2MooRhKpgOZKQ=.6d0232b7-4c24-4a22-a11b-d0e391bc6087@github.com>
Message-ID: <oBymKYvjhTzQUU-tqclGEF33jSagR0p926gyu2pFh_A=.847bd07c-70d8-45be-993a-65e7c16166d5@github.com>

On Tue, 4 Jun 2024 02:38:51 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> I assume WiX5 will just work if installed instead of WiX4?

Correct.

> Do you think it will make sense to introduce Wix5 ToolsetType in case if we need to do something different between 4 and 5?

They claim WiX5 is backward compatible with WiX4, i.e. WiX4 code should work with WiX5 toolkit. So I don't see a reason to introduce Wix5 ToolsetType now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2147430144

From asemenyuk at openjdk.org  Tue Jun  4 12:45:11 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 12:45:11 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
Message-ID: <zZqZpW1LEq9pGvIYptybZwtgVVqbcTDpe_koCaiSGc4=.5d797e32-d564-48c3-b33e-b9014e2b2185@github.com>

On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.
> 
> Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.
> 
> These loopholes were eliminated:
> 
>  - stdout and stderr of app launchers is never suppressed;
>  - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
>  - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.
> 
> Other changes are due to changes in HelloApp.AppOutputVerifier class.

There is [JDK-8263466](https://bugs.openjdk.org/browse/JDK-8263466) with the same symptoms to be investigated. It is linked to this bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2147440644

From alanb at openjdk.org  Tue Jun  4 12:51:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Jun 2024 12:51:20 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
Message-ID: <na-_srrWKWDtjo5oIIrzgCQUcbyyOYWbxv8z9BymuFE=.5b7c09c2-9da7-415b-a81a-f4191668c1c3@github.com>

On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all,
> 
> I think there's some consensus that we need some follow up cleanup issues for the JNI spec, renaming constants, fixing return codes, etc.
> 
> Seeing how that grows the scope of the issue quite a bit, I'd like to push this patch and track the other issues brought up separately.
> 
> If there are no objections about the current state, I'd like to integrate some time next week. Let me know your thoughts.
> 
> cc: @jaikiran, @AlanBateman

Okay. The follow-on issue can remove CHECK_EXCEPTION_NULL_FAIL introduced by this PR or replace it with something simple that just checks if the ID is null.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2147452633

From duke at openjdk.org  Tue Jun  4 12:53:06 2024
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Jun 2024 12:53:06 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations
In-Reply-To: <96SNKGdvRhf20ArPe4-IdcXkhzvKDnwQ7W1VlXX689I=.78e6fc24-980e-42e4-aa67-090968a5b215@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <96SNKGdvRhf20ArPe4-IdcXkhzvKDnwQ7W1VlXX689I=.78e6fc24-980e-42e4-aa67-090968a5b215@github.com>
Message-ID: <RwAY7i4jJpcckvIkSbWYIyewlHwmh2bE9k1vZpBQ6mQ=.aff7ea4a-032e-43de-9666-96ac1b78edf5@github.com>

On Mon, 3 Jun 2024 18:48:48 GMT, Doug Lea <dl at openjdk.org> wrote:

> The jmh benchmark checks only the empty case, you need to also show lack of impact on non-empty cases.

After removing `toArray`, I think this is covered.  Can you please confirm?

> Assuming you demonstrate this, it seems basically OK, (Deja vu previous cases including hash maps). It is only a small band-aid -- programs generating lots of them still have to allocate the COWAL object, so the savings are small compared to not generating them at all unless needed.

The motivation for this change is an app that retains 23K instances of CopyOnWriteArrayList, 22K of which have zero items.  The 22K instances each have their own copy of an Object[0].  This change eliminates 343KB of retained memory and 22K objects.  I had initially modified `toArray()` for the sake of completeness but don't directly benefit from it, so I'm willing to drop that to remain within spec.

FWIW the issue arises inside `org.jboss.resteasy` so the benefit is broad, albeit shallow.

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

PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2147454256

From asemenyuk at openjdk.org  Tue Jun  4 12:53:12 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 12:53:12 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <WInqr2RGqxPIhoDlKiTCLFsB5N8lCkw-dNYp0zYyjCc=.88178d89-0552-45cb-9c47-8c85ca75a4fe@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
 <nQP1t6EuMVLeGihN8RTSfFMqMEJP77BEvoeb7pElQUg=.7ba77c32-a98d-4d7e-ad3b-040f8597264c@github.com>
 <DIn0iEluK0_nCbH2N3kqrDGap5IpmctZxwVJuYRd_qs=.137604f6-4e66-46e2-ae4f-75ca3c13e4b7@github.com>
 <WInqr2RGqxPIhoDlKiTCLFsB5N8lCkw-dNYp0zYyjCc=.88178d89-0552-45cb-9c47-8c85ca75a4fe@github.com>
Message-ID: <AUx53AOPM8vUrl9xRWwXoWklybCgyLMJ2vYSmajHBY8=.bc6d0405-7857-4b9c-bc80-59e994fc468a@github.com>

On Tue, 4 Jun 2024 06:43:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If I read JDK-8269403 correctly then there is an issue somewhere that hasn't been diagnosed.

Correct.

> A workaround has been put in to "re-run" when there is a crash, thus hiding the issue.

Correct.

> Are there follow-up issues created in JBS to continue the hunt for the original crash?

The issue was first reported in [JDK-8263466](https://bugs.openjdk.org/browse/JDK-8263466). It was "fixed" by rerunning the launcher. The fix didn't cover all the scenarios of launcher executions in jpackage tests. One of these uncovered scenarios caused the issue of this PR.

We already have [JDK-8263466](https://bugs.openjdk.org/browse/JDK-8263466) to find the original crash.

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

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2147454916

From syan at openjdk.org  Tue Jun  4 12:58:11 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Jun 2024 12:58:11 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <mQZHfdS_ok6O6dLazsSYrUXBkojv8GVa_HsRDxHbPzo=.38469b85-ad58-4500-aea7-8b22559a39d7@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

> /label build

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147467980

From alanb at openjdk.org  Tue Jun  4 12:58:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Jun 2024 12:58:15 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <AUx53AOPM8vUrl9xRWwXoWklybCgyLMJ2vYSmajHBY8=.bc6d0405-7857-4b9c-bc80-59e994fc468a@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
 <nQP1t6EuMVLeGihN8RTSfFMqMEJP77BEvoeb7pElQUg=.7ba77c32-a98d-4d7e-ad3b-040f8597264c@github.com>
 <DIn0iEluK0_nCbH2N3kqrDGap5IpmctZxwVJuYRd_qs=.137604f6-4e66-46e2-ae4f-75ca3c13e4b7@github.com>
 <WInqr2RGqxPIhoDlKiTCLFsB5N8lCkw-dNYp0zYyjCc=.88178d89-0552-45cb-9c47-8c85ca75a4fe@github.com>
 <AUx53AOPM8vUrl9xRWwXoWklybCgyLMJ2vYSmajHBY8=.bc6d0405-7857-4b9c-bc80-59e994fc468a@github.com>
Message-ID: <C3QOqiLhQ4aQBx9a5tWU08SrIeeKRNo7-19PgCGqMvA=.0358c881-78cf-46fe-97cc-4002de6981a0@github.com>

On Tue, 4 Jun 2024 12:49:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> We already have [JDK-8263466](https://bugs.openjdk.org/browse/JDK-8263466) to find the original crash.

Thanks, just making sure the issue that there is an issue tracking it as it's a bit unsettling that a re-run may be hiding something serious

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

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2147467566

From erikj at openjdk.org  Tue Jun  4 13:01:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Jun 2024 13:01:12 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <-zitWvnM2OMNoksPkobR-GY7ydETAQyBLwcrdcoiLWE=.c1e182c2-7b34-43e9-a96f-e3bf1b367f8f@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2096319123

From jpai at openjdk.org  Tue Jun  4 13:02:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 13:02:16 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
Message-ID: <RnsyfmYO-nlMeSFAeohPJM2vMLCJj1Bfk5LeKAdcWnk=.9594d531-04d7-464e-ac99-520c72e2debb@github.com>

On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decreasing diff size addressing unnecessary changes
>
> Hi all,  
> 
> I think there's some consensus that we need some follow up cleanup issues for the JNI spec, renaming constants, fixing return codes, etc. 
> 
> Seeing how that grows the scope of the issue quite a bit, I'd like to push this patch and track the other issues brought up separately. 
> 
> If there are no objections about the current state, I'd like to integrate some time next week. Let me know your thoughts.
> 
> cc: @jaikiran, @AlanBateman

Hello Sonia @SoniaZaldana, so based on Alan's latest inputs, the next thing to do on this PR is to refresh the PR to merge it with the latest master branch changes and then run tier1, tier2 and tier3 tests to make sure they continue to pass and have this integrated soon.

I'll file follow up issue(s) and also trigger CI testing of this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2147476871

From vklang at openjdk.org  Tue Jun  4 13:06:08 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 4 Jun 2024 13:06:08 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations
In-Reply-To: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
Message-ID: <ZRFgnMzbNR_9odHGXWQrPWFaNmHq6MJPd5Q1GSM3ANA=.f4de435c-b62f-4671-9b76-c3993fc69309@github.com>

On Mon, 3 Jun 2024 16:47:20 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
> 
> 
> After:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 103:

> 101:     private static final long serialVersionUID = 8673264195747942595L;
> 102: 
> 103:     private static final Object[] EMPTY_ELEMENTDATA = {};

Looks like readObject() ought to also be changed to use the EMPTY_ELEMENTDATA if the length of the read array is 0? And perhaps `clone()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1625968254

From asemenyuk at openjdk.org  Tue Jun  4 13:52:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 13:52:03 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
 [v2]
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <n7qbDcbHgWsBTkYu1KaAciboafKVNuERhcRcFkr3r58=.b52a5edb-a933-4137-807b-8d0b2f50ff14@github.com>

> Add support for WiX4 (and WiX5) in jpackage.
> 
> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

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

 - EOLs restored
 - Merge branch 'master' into JDK-8319457
 - Revert "Revert "Rollback unneeded change""
   
   This reverts commit 5fded0b107643b20a5c517a58f611b89406aec8e.
 - Support the use of custom wix source converter
 - Ensure WiX source converter works with the default JDK XSLT processor and Saxon HE (v12.4)
 - Revert "Rollback unneeded change"
   
   This reverts commit 00d7cc6c102f3b2c8db84d47cc6a04aad53f74fc.
 - Rollback unneeded change
 - Merge branch 'master' into JDK-8319457
 - Don't suppress jpackage output when it is detecting what packaging tools available and what bundlers are supported.
 - Fix issue with running jtreg tests when wix.exe is not available in the PATH. When wix.exe is not in the PATH, jpackage uses %USERPROFILE% env variable to get user home directory. But jtreg removes it from the environment when running tests, so without wix.exe in the PATH all jpackage tests will fail on Windows. This makes it impossible to test jpackage with wix3. This patch addresses this issue by reading user home additionally from "java.home" system property.
 - ... and 18 more: https://git.openjdk.org/jdk/compare/9686e804...99aac323

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

Changes: https://git.openjdk.org/jdk/pull/19318/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19318&range=01
  Stats: 1471 lines in 22 files changed: 1155 ins; 92 del; 224 mod
  Patch: https://git.openjdk.org/jdk/pull/19318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19318/head:pull/19318

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

From asemenyuk at openjdk.org  Tue Jun  4 14:01:41 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 14:01:41 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
 [v3]
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <46rNKmM6sX8QF8XEuEtbKFaQe4jylFVn8IaQtX9sX-c=.93d21c3d-02eb-4b2d-a6fe-f3441ba3d47b@github.com>

> Add support for WiX4 (and WiX5) in jpackage.
> 
> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

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

  EOLs restored

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19318/files
  - new: https://git.openjdk.org/jdk/pull/19318/files/99aac323..782d121b

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

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

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

From asemenyuk at openjdk.org  Tue Jun  4 14:01:41 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 14:01:41 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
 [v3]
In-Reply-To: <-o573bkx_xWBRkJS3IWGlevuqgWGL-4EyAxCexUvGUQ=.32f6db30-d90b-4be9-987b-7112349f11d4@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <-o573bkx_xWBRkJS3IWGlevuqgWGL-4EyAxCexUvGUQ=.32f6db30-d90b-4be9-987b-7112349f11d4@github.com>
Message-ID: <7gOdTXsL65PTSgWKTwmDDFUn4qvCu1DY0LIfbIyTh-k=.cd1d834e-40ed-40a4-8ca2-570554542359@github.com>

On Tue, 4 Jun 2024 01:07:15 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   EOLs restored
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 1:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 
> MsiInstallerStrings_de(ja,zh_CA).wxl are probably saved in wrong format. Can you double check if it is intentional change?

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1626070251

From dfuchs at openjdk.org  Tue Jun  4 15:17:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Jun 2024 15:17:33 GMT
Subject: RFR: 8333270: HandlersOnComplexResetUpdate and
 HandlersOnComplexUpdate tests fail with "Unexpected reference" if
 timeoutFactor is less than 1/3 [v2]
In-Reply-To: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>
References: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>
Message-ID: <x5GFN2GWsP7cAnIOKap40b2K0tRCJOvweAGocrIvkmo=.e3724d9c-4840-44d1-821b-a95a1df663b1@github.com>

> HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that loggers are GC'ed (or not GC'ed) after a reset or an update. For that they poll a ReferenceQueue in a loop. The number of iteration is adjusted according to the jtreg timeout factor. However, the logic in the test did not expect that the timeout might be less than 1.
> 
> This fix does two things:
> 
> 1. fix the adjustCount logic - so that the number of iteration can only be increased
> 2. use remove(timeout) instead of poll() in order to minimize the waiting time.

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

  Review feedback: use Reference::refersTo consistently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19503/files
  - new: https://git.openjdk.org/jdk/pull/19503/files/be5a4d82..75576a8d

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

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

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

From dfuchs at openjdk.org  Tue Jun  4 15:17:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Jun 2024 15:17:33 GMT
Subject: RFR: 8333270: HandlersOnComplexResetUpdate and
 HandlersOnComplexUpdate tests fail with "Unexpected reference" if
 timeoutFactor is less than 1/3 [v2]
In-Reply-To: <wz9mArPySKPc9M8x7ob5gavv81namVBZSu6F1tb_51o=.644b7d0f-2e3b-489f-856b-53f66e42ad9f@github.com>
References: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>
 <wz9mArPySKPc9M8x7ob5gavv81namVBZSu6F1tb_51o=.644b7d0f-2e3b-489f-856b-53f66e42ad9f@github.com>
Message-ID: <qZ4SkBwQRuHikyGHfNFnCU2HKBN_ynDVu6ktYY7oIp0=.28750705-4267-4b79-98d6-d437e36698d1@github.com>

On Sat, 1 Jun 2024 05:20:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback: use Reference::refersTo consistently
>
> test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java line 219:
> 
>> 217:         }
>> 218:         WeakReference<Logger> barRef = new WeakReference<>(Logger.getLogger("com.bar"), queue);
>> 219:         if (!barRef.refersTo(barChild.getParent())) {
> 
> Hello Daniel, since `refersTo()` is the preferred API in cases like this, should this same change be done in the other `HandlersOnComplexUpdate` test that's being updated in this PR?

Good point. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19503#discussion_r1626196539

From asotona at openjdk.org  Tue Jun  4 15:17:48 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 4 Jun 2024 15:17:48 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <uHPyShsCJxwFslId18ezLHJ2KeLQYm_RHSoiMcmtq6w=.78dbbf6f-5427-4ffa-9468-c6027e8fccd6@github.com>

On Thu, 30 May 2024 13:50:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

It looks like a legit performance trick.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19479#pullrequestreview-2096720909

From asemenyuk at openjdk.org  Tue Jun  4 16:07:18 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 16:07:18 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
 [v4]
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <xbNenP7KZJS9jQYFOnMd_rCNOWmcUhneP5oYCX1MH2I=.75c0efc3-fa74-4e88-814d-071dbe6ae93e@github.com>

> Add support for WiX4 (and WiX5) in jpackage.
> 
> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - WixSourceConverter#applyTo should do what OverridableResource#saveToFile() does: create parent directory and replace output file if it exists.
 - Fix issue with overwriting custom l10n file in the resource directory. All WiX source files from the resource directory should be copied to jpackage work directory before running wxi tools. jpackage should not change files in the resource directory.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19318/files
  - new: https://git.openjdk.org/jdk/pull/19318/files/782d121b..af8fb680

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

  Stats: 11 lines in 3 files changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19318/head:pull/19318

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

From chagedorn at openjdk.org  Tue Jun  4 16:11:03 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 4 Jun 2024 16:11:03 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <R_z406J_82pGfaVP_3M5mmQ4zGsuS3H4rCPOr-a5Ti8=.ac63077f-25ac-4bb0-b486-b48e4ffffa12@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

Looks good! Somehow the integrate command did not work.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2096615859

From syan at openjdk.org  Tue Jun  4 16:11:05 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Jun 2024 16:11:05 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <DsmVGdauwSMGAL3nJElLM_iKxrfM7vK4ujpQadJozNQ=.d43b195b-e33d-4a72-82ee-5cb6ecec6a2c@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

Thanks for the review.

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147523325
PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147711173

From szaldana at openjdk.org  Tue Jun  4 16:17:36 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 4 Jun 2024 16:17:36 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v11]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <VcPVPlqlpN2f2PXXOfkhjzPfd0W7CYzLSAQSrfi5nxk=.f274f332-1068-4d2d-af1a-743be414374f@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

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

 - Merge branch 'openjdk:master' into JDK-8329581
 - Decreasing diff size addressing unnecessary changes
 - Fixing indentation
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Fixing broken uncaught exception mechanism
 - Make deleting file OS agnostic
 - Adding test case
 - Removing long lines
 - Using new macro to avoid reporting JNI error
 - Changes based on feedback
 - Fixing space formatting
 - ... and 4 more: https://git.openjdk.org/jdk/compare/d654de0c...12fe416c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/1a0c76f2..12fe416c

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

  Stats: 582850 lines in 7246 files changed: 146903 ins; 86361 del; 349586 mod
  Patch: https://git.openjdk.org/jdk/pull/18786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786

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

From stuefe at openjdk.org  Tue Jun  4 16:17:37 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 4 Jun 2024 16:17:37 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v11]
In-Reply-To: <VcPVPlqlpN2f2PXXOfkhjzPfd0W7CYzLSAQSrfi5nxk=.f274f332-1068-4d2d-af1a-743be414374f@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <VcPVPlqlpN2f2PXXOfkhjzPfd0W7CYzLSAQSrfi5nxk=.f274f332-1068-4d2d-af1a-743be414374f@github.com>
Message-ID: <iomnmAuYOYBIpwXGHLN-XKHX4uRA1BNZ2nXbqspqmp8=.2936206f-9b37-4ad3-b8da-7d3cd0982914@github.com>

On Tue, 4 Jun 2024 13:34:30 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8329581
>  - Decreasing diff size addressing unnecessary changes
>  - Fixing indentation
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Fixing broken uncaught exception mechanism
>  - Make deleting file OS agnostic
>  - Adding test case
>  - Removing long lines
>  - Using new macro to avoid reporting JNI error
>  - Changes based on feedback
>  - Fixing space formatting
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d654de0c...12fe416c

Latest version is still good.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18786#pullrequestreview-2096358502

From alanb at openjdk.org  Tue Jun  4 16:17:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Jun 2024 16:17:45 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <s-FzuDBQCAj8wUPXd5TVVvH_j1zjsfN_LGWlG4RAf4s=.6ba72bf2-a7b0-4ca2-9b9d-d609d1d681f2@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
 <s-FzuDBQCAj8wUPXd5TVVvH_j1zjsfN_LGWlG4RAf4s=.6ba72bf2-a7b0-4ca2-9b9d-d609d1d681f2@github.com>
Message-ID: <PQWd47pVbkmUf-waSk8EavMeVqWzjxPW3lfNzaHG2J4=.89248e3f-3304-409d-b3cd-5b5b6da06420@github.com>

On Tue, 4 Jun 2024 13:17:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Curious, why tier 1 to 3 specifically? Is there anything specific in tier 3 you want to have tested?

I think just prudent to run more tests when touching the launcher as it has options that aren't tested much in tier1. Shouldn't be an issue here but thinking of the splash screen tests (jdk_desktop test group), and tests for Java agents. Also jlink and jpackage can be useful when testing changes to the launcher.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2147552797

From alanb at openjdk.org  Tue Jun  4 16:17:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Jun 2024 16:17:41 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <RnsyfmYO-nlMeSFAeohPJM2vMLCJj1Bfk5LeKAdcWnk=.9594d531-04d7-464e-ac99-520c72e2debb@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
 <RnsyfmYO-nlMeSFAeohPJM2vMLCJj1Bfk5LeKAdcWnk=.9594d531-04d7-464e-ac99-520c72e2debb@github.com>
Message-ID: <RByZ-TjpRLhlNJaKVbYEvAKCZwPQ0TvOcewsY2CeVCo=.789ac5e8-fcbf-41f2-849d-b301503524ea@github.com>

On Tue, 4 Jun 2024 12:59:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I'll file follow up issue(s) and also trigger CI testing of this PR.

Thanks, the regressions fixed here are important to fix. It's unfortunate there the original changes weren't changes weren't caught by tests. There is a good test coverage added here but I think we'll need to see if there are other testing gaps.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2147492466

From stuefe at openjdk.org  Tue Jun  4 16:17:45 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 4 Jun 2024 16:17:45 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
Message-ID: <s-FzuDBQCAj8wUPXd5TVVvH_j1zjsfN_LGWlG4RAf4s=.6ba72bf2-a7b0-4ca2-9b9d-d609d1d681f2@github.com>

On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decreasing diff size addressing unnecessary changes
>
> Hi all,  
> 
> I think there's some consensus that we need some follow up cleanup issues for the JNI spec, renaming constants, fixing return codes, etc. 
> 
> Seeing how that grows the scope of the issue quite a bit, I'd like to push this patch and track the other issues brought up separately. 
> 
> If there are no objections about the current state, I'd like to integrate some time next week. Let me know your thoughts.
> 
> cc: @jaikiran, @AlanBateman

> Hello Sonia @SoniaZaldana, so based on Alan's latest inputs, the next thing to do on this PR is to refresh the PR to merge it with the latest master branch changes and then run tier1, tier2 and tier3 tests to make sure they continue to pass and have this integrated soon.

Curious, why tier 1 to 3 specifically? Is there anything specific in tier 3 you want to have tested?

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2147514185

From nbenalla at openjdk.org  Tue Jun  4 16:17:54 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 16:17:54 GMT
Subject: RFR: 8326951: since-checker - missing @ since tags [v9]
In-Reply-To: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
 <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>
Message-ID: <9rwcxCtDSvNErRJA2krVv4LtregWT6UJflZ51MEpbBk=.e3b907f8-6734-4e14-8aef-5ec61d94cad7@github.com>

On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla <nbenalla 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).
>> 
>> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
>> 
>> This is similar to #18032 and #18373 
>> 
>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit and merge

Thanks for the thorough review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18055#issuecomment-2147542776

From naoto.sato at oracle.com  Tue Jun  4 16:23:15 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 4 Jun 2024 09:23:15 -0700
Subject: Instant.now(Clock) and InstantSource
In-Reply-To: <CACzrW9AJsm_Lq0AOSYjER_RYS0h+xP5WaKnMZR+0w=7aU=R2LA@mail.gmail.com>
References: <CAB3z6Ajk6zNaTtY6y01EYNe=GUyBWFXV-uEe4fJasvnBvBaQFQ@mail.gmail.com>
 <CACzrW9AJsm_Lq0AOSYjER_RYS0h+xP5WaKnMZR+0w=7aU=R2LA@mail.gmail.com>
Message-ID: <55a29f76-c34b-4244-97c5-2a627af6c586@oracle.com>

+1 for not deprecating the method that takes Clock. It would give 
existing users unnecessary warnings.

Naoto

On 6/4/24 12:17 AM, Stephen Colebourne wrote:
> On Mon, 3 Jun 2024 at 22:25, Kurt Alfred Kluever <kak at google.com> wrote:
>> It feels a bit strange that you can't pass an `InstantSource` to `Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a "useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to propose one of the following API changes:
>>
>> 1) adding `Instant.now(InstantSource)`
>> 2) deprecating `Instant.now(Clock)` in favor of `clock.instant()`
> 
> I have no problem with adding `Instant.now(InstantSource)`, but I
> think deprecating the `Clock` method is unnecessary (given it will
> never be removed AFAICT, and it is no doubt in widespread use).
> Stephen

From sgehwolf at openjdk.org  Tue Jun  4 16:23:19 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Jun 2024 16:23:19 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
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: <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@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 113 commits:

 - Mark some tests with requiring packaged modules
 - Correctly set packaged modules default
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Fix new line in jlink.properties
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Simplify JLINK_JDK_EXTRA_OPTS var handling
 - Only add runtime track files for linkable runtimes
 - Generate the runtime image link diff at jlink time
   
   But only do that once the plugin-pipeline has run. The generation is
   enabled with the hidden option '--generate-linkable-runtime' and
   the resource pools available at jlink time are being used to generate
   the diff.
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d

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

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=29
  Stats: 3473 lines in 41 files changed: 3312 ins; 117 del; 44 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  Tue Jun  4 16:23:23 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Jun 2024 16:23:23 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
 <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>
 <Ok6ibGzy9-6oa-c2Ie-lCulQXObKKkusvHP1QeR_WlE=.799e6764-c532-4647-b61c-e5a19aadbc1c@github.com>
 <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>
Message-ID: <Xc1lSn7gHH8Dc1rLRAjdFUxOY8dzNKzFAOgH-QozOhc=.8d786d7f-54ef-4fc6-b1d6-e0a5c398e6aa@github.com>

On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Does that proposal sound good?
> 
> That table is useful, I think it's right. No change to default behavior. If someone configures with --enable-runtime-image then they get a JDK run-time image that supports jlink (with some limitations) but is significantly small as it doesn't include the packaged modules.

https://github.com/openjdk/jdk/pull/14787/commits/5fef297ba999963d60452f098193d2cba33a941b implements this.

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

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

From sgehwolf at openjdk.org  Tue Jun  4 16:23:24 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Jun 2024 16:23:24 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
Message-ID: <f3ivoB8Qwi8np9XhCg0QtSy6pG4sFP0_glyVAOaqZGI=.c5ab1624-afee-48fb-a749-0973920205d9@github.com>

On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> (Doing that would of course mean that several existing jlink tests would need some changes, either to `@requires` or to remove the checks for the `jmods` directory)

I've added a couple of `@requires jlink.packagedModules` (new with this patch) so that jlink tests don't start to fail with it. As a follow-up I've filed https://bugs.openjdk.org/browse/JDK-8333541. This change is becoming large enough as it is and would like to get this in before RDP1 on Thursday. The initial work was submitted almost a year ago.

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

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

From asemenyuk at openjdk.org  Tue Jun  4 16:33:17 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Jun 2024 16:33:17 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
 [v4]
In-Reply-To: <xbNenP7KZJS9jQYFOnMd_rCNOWmcUhneP5oYCX1MH2I=.75c0efc3-fa74-4e88-814d-071dbe6ae93e@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <xbNenP7KZJS9jQYFOnMd_rCNOWmcUhneP5oYCX1MH2I=.75c0efc3-fa74-4e88-814d-071dbe6ae93e@github.com>
Message-ID: <fvtH7NvHR-jrVyLnvNjvKuNVFZg8Bke5IPWj6ysoKIc=.713511f5-3531-42a7-836f-4ae6b32ca5d5@github.com>

On Tue, 4 Jun 2024 16:07:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Add support for WiX4 (and WiX5) in jpackage.
>> 
>> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
>> 
>> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
>> 
>> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
>> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
>> 
>> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - WixSourceConverter#applyTo should do what OverridableResource#saveToFile() does: create parent directory and replace output file if it exists.
>  - Fix issue with overwriting custom l10n file in the resource directory. All WiX source files from the resource directory should be copied to jpackage work directory before running wxi tools. jpackage should not change files in the resource directory.

Fixed WinL10nTest test failure. It didn't fail on my dev machine but failed in another environment. I thought it was sporadic but it turned out to be a bug in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2147915867

From naoto at openjdk.org  Tue Jun  4 16:33:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 16:33:00 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <ilzj5C5PKI7X0eoPAOR5Ncxmz67dWOsamq4IiA59Qgs=.cd3ec7e3-4db0-4a8c-9952-2bbf2fb6d254@github.com>

On Thu, 30 May 2024 13:50:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

Looks good with a minor nit.

test/jdk/jdk/internal/jline/LazyJdkConsoleProvider.java line 74:

> 72:             ProcessBuilder builder =
> 73:                     ProcessTools.createTestJavaProcessBuilder("--enable-preview",
> 74:                                                               "-verbose:class",

Better to explicitly specify `-Djdk.console=jdk.internal.le`

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

PR Review: https://git.openjdk.org/jdk/pull/19479#pullrequestreview-2096855434
PR Review Comment: https://git.openjdk.org/jdk/pull/19479#discussion_r1626281874

From jpai at openjdk.org  Tue Jun  4 16:47:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Jun 2024 16:47:57 GMT
Subject: RFR: 8333270: HandlersOnComplexResetUpdate and
 HandlersOnComplexUpdate tests fail with "Unexpected reference" if
 timeoutFactor is less than 1/3 [v2]
In-Reply-To: <x5GFN2GWsP7cAnIOKap40b2K0tRCJOvweAGocrIvkmo=.e3724d9c-4840-44d1-821b-a95a1df663b1@github.com>
References: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>
 <x5GFN2GWsP7cAnIOKap40b2K0tRCJOvweAGocrIvkmo=.e3724d9c-4840-44d1-821b-a95a1df663b1@github.com>
Message-ID: <wkE7AG_I-rN0FMKgI_2KYZT_-BpJpL1KkJsKjPFOTb8=.0d8caf40-9e18-4db7-a71f-0840fc0903c4@github.com>

On Tue, 4 Jun 2024 15:17:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that loggers are GC'ed (or not GC'ed) after a reset or an update. For that they poll a ReferenceQueue in a loop. The number of iteration is adjusted according to the jtreg timeout factor. However, the logic in the test did not expect that the timeout might be less than 1.
>> 
>> This fix does two things:
>> 
>> 1. fix the adjustCount logic - so that the number of iteration can only be increased
>> 2. use remove(timeout) instead of poll() in order to minimize the waiting time.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: use Reference::refersTo consistently

The changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19503#pullrequestreview-2096922118

From nbenalla at openjdk.org  Tue Jun  4 16:54:07 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 16:54:07 GMT
Subject: Integrated: 8326951: since-checker - 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: <6_AxWxwLvM8is87Q-BRTBSqIpBIbxsin3XUcCMHW-Ng=.fe4ee43d-c805-4fc3-acf5-0a8a40b73e35@github.com>

On Thu, 29 Feb 2024 09:45:35 GMT, Nizar Benalla <nbenalla 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).
> 
> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

This pull request has now been integrated.

Changeset: e0bab786
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e0bab786402d70e9a74d1816c029c772ea01f697
Stats:     24 lines in 7 files changed: 19 ins; 2 del; 3 mod

8326951: since-checker - missing @ since tags

Reviewed-by: jpai

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

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

From duke at openjdk.org  Tue Jun  4 17:01:01 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 4 Jun 2024 17:01:01 GMT
Subject: Integrated: 8333312: Incorrect since tags on new ClassReader and
 ConstantPool methods
In-Reply-To: <Jr9vq4Lgl1P9WYJvGMCFJo-vU-rnHgRw9VDK3YoEQgM=.70f480e1-dfdb-47d1-90a6-43fc0c97dd13@github.com>
References: <Jr9vq4Lgl1P9WYJvGMCFJo-vU-rnHgRw9VDK3YoEQgM=.70f480e1-dfdb-47d1-90a6-43fc0c97dd13@github.com>
Message-ID: <J9OQDHlwKj3EDZ0fuHRYQukQTeHfFywzAN_8b8beSnk=.653a7d95-505c-4349-85da-c71ac699f0da@github.com>

On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The new method additions ClassReader.readEntryOrNull(int, Class) and ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should be `@since 23`.

This pull request has now been integrated.

Changeset: b101dcb6
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b101dcb609eae00b406f387cd90e58487d5868df
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8333312: Incorrect since tags on new ClassReader and ConstantPool methods

Reviewed-by: liach, asotona

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

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

From naoto at openjdk.org  Tue Jun  4 17:24:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 17:24:56 GMT
Subject: RFR: 8333456: CompactNumberFormat integer parsing fails when
 string has no suffix
In-Reply-To: <Yz_-c-Nr6p86TFltSwsjZyjOUh_k-xEFo-s52Fczkew=.4357fab6-4ba7-4051-be91-3c9245426008@github.com>
References: <Yz_-c-Nr6p86TFltSwsjZyjOUh_k-xEFo-s52Fczkew=.4357fab6-4ba7-4051-be91-3c9245426008@github.com>
Message-ID: <bJOJe_Qh4AAvZFFW-TX3UI0F4EO5GYH3BRZCh7_jLIE=.4de29fec-0fc2-495d-89b4-fdb5ea51a1aa@github.com>

On Mon, 3 Jun 2024 22:32:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which handles incorrect CompactNumberFormat integer only parsing when there is no suffix.
> 
> See the following snippet,
> 
> 
> var fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT)
> fmt.setParseIntegerOnly(true)
> fmt.parse("5K") // returns 5000
> fmt.parse("50.00") // returns 50
> fmt.parse("5") // unexpectedly throws StringIndexOutOfBoundsException 
> fmt.parse("5 ") // returns 5
> 
> 
> Within the `parse` method, there is code that advances `position` past the fractional portion to find the suffix when `parseIntegerOnly()` is true. However, if a valid string input is given with no suffix, `DecimalFormat.subparseNumber()` will fully iterate through the string and `position` will be equal to the length of the string, throwing StringIndexOutOfBoundsException when `charAt` is invoked (line 1740).
> 
> We should check to make sure position does not exceed the string length before deciding to check for a decimal symbol.

The fix looks good. For the test, can we add the test case into an existing test, instead of creating a new test case file?

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

PR Review: https://git.openjdk.org/jdk/pull/19533#pullrequestreview-2096998510

From cushon at openjdk.org  Tue Jun  4 17:42:23 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 4 Jun 2024 17:42:23 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException [v3]
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: <xOVnmVU2LKDhGgj7EygsVwOYDihBXE0Il4K8sFzg1nI=.42b0b2f9-099b-4349-8429-6402df6a90e8@github.com>

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Check m.entrySet().hashCode() in MOAT
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Use AbstractImmutableSet
 - Throw UOE for all Map.of().entrySet() mutator methods
 - 8328821: Make the ImmutableCollections clear() call consistent
   
   Without overriding clear(), a call to it in an empty map would
   just return, as iterator.hasNext() would be false. However if
   calling Map.of().clear() throws an exception. To make the
   behavior of Map.of().entrySet().clear() consistent, we need to
   have an implementation of clear() for the entry set that throws
   as well.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18522/files
  - new: https://git.openjdk.org/jdk/pull/18522/files/17851d80..598af2e5

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

  Stats: 20292 lines in 534 files changed: 12666 ins; 5447 del; 2179 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 cushon at openjdk.org  Tue Jun  4 17:43:08 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 4 Jun 2024 17:43:08 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version
Message-ID: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>

This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.

The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8332744
 - Use jdk.internal.misc.Unsafe instead of sun.misc.Unsafe in microbenchmarks to avoid a sunapi warning
 - [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version

Changes: https://git.openjdk.org/jdk/pull/19397/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19397&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332744
  Stats: 159 lines in 20 files changed: 132 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/19397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19397/head:pull/19397

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

From cushon at openjdk.org  Tue Jun  4 17:43:24 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 4 Jun 2024 17:43:24 GMT
Subject: RFR: 8328995: Launcher can't open jar files where the offset of
 the manifest is >4GB [v7]
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: <_TvJQ-I5L2LkS4PrOqEX4MU_GBDxP0nJy_kkwMk9lr0=.ca7a9572-fdad-4c43-8355-8c273646bfc5@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 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 remote-tracking branch 'origin/master' into JDK-8328995
 - Move test to test/jdk/tools/launcher
 - Add some more comments
 - Maximum Zip64 extra field length is 32
 - Make cendsk an unsigned short
 - Fix disk number size
 - Improvements
   
   * don't rely on variable length arrays
   * only run the test of 64 bit machines, since it requires >4GB of heap
 - 8328995: launcher can't open jar files where the offset of the manifest is >4GB

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18479/files
  - new: https://git.openjdk.org/jdk/pull/18479/files/140e13b9..da36c059

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

  Stats: 232749 lines in 4679 files changed: 131506 ins; 74722 del; 26521 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 naoto at openjdk.org  Tue Jun  4 17:46:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 17:46:17 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v7]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <KiyoUZhNSI7GdvlluYV9n71YNDiN5C-2eujRLRFceAE=.7d7bccee-1af5-476a-9b97-51df8b135c1b@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

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

  Check restored echo with stty -a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19315/files
  - new: https://git.openjdk.org/jdk/pull/19315/files/2477adf4..c1ea5d59

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

  Stats: 68 lines in 2 files changed: 8 ins; 38 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315

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

From naoto at openjdk.org  Tue Jun  4 18:49:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 18:49:01 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
Message-ID: <u0nNz7D8K1HXMRIPmFqS5iMoaearEtkqeHzbH5nHL-w=.32db5472-1a1c-44e4-9232-a9197adab29b@github.com>

On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Thanks for splitting up the PR/JBS. For this one, I am still not sure why this StringBuffer/Builder locking became an issue, as the code is basically the same in JDK11 (meaning StringBuffer has always been used). Would it be possible if the regression was caused by some other changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2148184952

From naoto at openjdk.org  Tue Jun  4 18:50:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 18:50:57 GMT
Subject: RFR: 8333462: Performance regression of new DecimalFormat() when
 compare to jdk11
In-Reply-To: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
References: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
Message-ID: <_1kh4M6jLwCDhffLKwcdEvAVrP33zlFn-OguIgu3Eys=.9419d026-2a67-4589-8d83-c767f6bd269b@github.com>

On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg <duke at openjdk.org> wrote:

> Run the below benchmark test  ,it show the average time of new DecimalFormat()  increase 18% when compare to jdk 11.
> 
> the result with jdk 11:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
> 
> 
> the result with current jdk:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     @Setup(Level.Trial)
>     public void setup() {
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> }
> 
> 
> Compare the flame graph it shows the java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. 
> After replacing  the lambda implementation with a simple loop , it shows nearly the same performance as jdk 11.
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> [flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541764/flame-graph-jdk11-jdk21.zip)

LGTM

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 866:

> 864:     private char findNonFormatChar(String src, char defChar) {
> 865:         for (int i = 0; i < src.length(); i++) {
> 866:             if (Character.getType(src.charAt(i)) != Character.FORMAT) {

return of `src.charAt(i)` can be reused

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19534#pullrequestreview-2097161949
PR Review Comment: https://git.openjdk.org/jdk/pull/19534#discussion_r1626467416

From dl at openjdk.org  Tue Jun  4 19:43:57 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 4 Jun 2024 19:43:57 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations
In-Reply-To: <ZRFgnMzbNR_9odHGXWQrPWFaNmHq6MJPd5Q1GSM3ANA=.f4de435c-b62f-4671-9b76-c3993fc69309@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <ZRFgnMzbNR_9odHGXWQrPWFaNmHq6MJPd5Q1GSM3ANA=.f4de435c-b62f-4671-9b76-c3993fc69309@github.com>
Message-ID: <HDp4qCud6rEnlGBPnfnKbL34Fi24xyJd3q5fMpr81yk=.f9c5181a-8d5e-4995-8d10-c913d53a716d@github.com>

On Tue, 4 Jun 2024 13:03:45 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op
>
> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 103:
> 
>> 101:     private static final long serialVersionUID = 8673264195747942595L;
>> 102: 
>> 103:     private static final Object[] EMPTY_ELEMENTDATA = {};
> 
> Looks like readObject() ought to also be changed to use the EMPTY_ELEMENTDATA if the length of the read array is 0? And perhaps `clone()`.

Agreed. You might as well be consistent with this so that no one will need to re-address if some application does zillions of clones of empty lists.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1626520838

From naoto at openjdk.org  Tue Jun  4 19:47:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 19:47:57 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
Message-ID: <hUMj9-SHjn9oR21ije3f2YuAevrpNROsNWbjnzv4oAU=.632096ad-b8aa-4f8a-9033-e921d5f13615@github.com>

On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Also it would be helpful to compare the performance without biased locking in JDK11.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2148296971

From duke at openjdk.org  Tue Jun  4 19:56:10 2024
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Jun 2024 19:56:10 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v2]
In-Reply-To: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
Message-ID: <vVNpXhFMN-c2P2P099DDw-UiXozr49WZruPsFXS_60s=.244aec2c-c47b-4b5b-bd06-931bac1ef117@github.com>

> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
> 
> 
> After:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op

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

  Adding coverage to readObject()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19527/files
  - new: https://git.openjdk.org/jdk/pull/19527/files/ea7a0042..9ab83c9d

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

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

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

From duke at openjdk.org  Tue Jun  4 20:00:57 2024
From: duke at openjdk.org (jengebr)
Date: Tue, 4 Jun 2024 20:00:57 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v2]
In-Reply-To: <HDp4qCud6rEnlGBPnfnKbL34Fi24xyJd3q5fMpr81yk=.f9c5181a-8d5e-4995-8d10-c913d53a716d@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <ZRFgnMzbNR_9odHGXWQrPWFaNmHq6MJPd5Q1GSM3ANA=.f4de435c-b62f-4671-9b76-c3993fc69309@github.com>
 <HDp4qCud6rEnlGBPnfnKbL34Fi24xyJd3q5fMpr81yk=.f9c5181a-8d5e-4995-8d10-c913d53a716d@github.com>
Message-ID: <OoFXXPNbdWXcwXwloq28EK5chYINYYEN6nLLM81Pdwo=.8cba479e-ad7f-4f78-8d89-304ea61f7434@github.com>

On Tue, 4 Jun 2024 19:41:15 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 103:
>> 
>>> 101:     private static final long serialVersionUID = 8673264195747942595L;
>>> 102: 
>>> 103:     private static final Object[] EMPTY_ELEMENTDATA = {};
>> 
>> Looks like readObject() ought to also be changed to use the EMPTY_ELEMENTDATA if the length of the read array is 0? And perhaps `clone()`.
>
> Agreed. You might as well be consistent with this so that no one will need to re-address if some application does zillions of clones of empty lists.

I've updated `readObject` to match - thanks!  `clone()` isn't a big win since the array is allocated elsewhere and the application doesn't use that code path, so I'll leave that alone for now.

Sorry, I crossed wires with @DougLea 's comment, will add `clone`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1626537384
PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1626538689

From jlu at openjdk.org  Tue Jun  4 20:15:56 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Jun 2024 20:15:56 GMT
Subject: RFR: 8333462: Performance regression of new DecimalFormat() when
 compare to jdk11
In-Reply-To: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
References: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
Message-ID: <8_vJeH_-UgrmoTmXZZ1wMAoi4RtuLNWk4a-Aqsd6xHc=.bf8b1a8e-aaef-42e0-948a-2432696c6fa5@github.com>

On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg <duke at openjdk.org> wrote:

> Run the below benchmark test  ,it show the average time of new DecimalFormat()  increase 18% when compare to jdk 11.
> 
> the result with jdk 11:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
> 
> 
> the result with current jdk:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     @Setup(Level.Trial)
>     public void setup() {
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> }
> 
> 
> Compare the flame graph it shows the java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. 
> After replacing  the lambda implementation with a simple loop , it shows nearly the same performance as jdk 11.
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> [flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541764/flame-graph-jdk11-jdk21.zip)

LGTM. Also needs copyright year update

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19534#pullrequestreview-2097304072

From jlu at openjdk.org  Tue Jun  4 20:43:09 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Jun 2024 20:43:09 GMT
Subject: RFR: 8333456: CompactNumberFormat integer parsing fails when
 string has no suffix [v2]
In-Reply-To: <Yz_-c-Nr6p86TFltSwsjZyjOUh_k-xEFo-s52Fczkew=.4357fab6-4ba7-4051-be91-3c9245426008@github.com>
References: <Yz_-c-Nr6p86TFltSwsjZyjOUh_k-xEFo-s52Fczkew=.4357fab6-4ba7-4051-be91-3c9245426008@github.com>
Message-ID: <i6BMkj_B2Yy57kkdaAqoFsPj1wtDUsxfvePZtmfYtlc=.9e77c4bd-1b7e-4a4e-bf96-598e6448335d@github.com>

> Please review this PR which handles incorrect CompactNumberFormat integer only parsing when there is no suffix.
> 
> See the following snippet,
> 
> 
> var fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT)
> fmt.setParseIntegerOnly(true)
> fmt.parse("5K") // returns 5000
> fmt.parse("50.00") // returns 50
> fmt.parse("5") // unexpectedly throws StringIndexOutOfBoundsException 
> fmt.parse("5 ") // returns 5
> 
> 
> Within the `parse` method, there is code that advances `position` past the fractional portion to find the suffix when `parseIntegerOnly()` is true. However, if a valid string input is given with no suffix, `DecimalFormat.subparseNumber()` will fully iterate through the string and `position` will be equal to the length of the string, throwing StringIndexOutOfBoundsException when `charAt` is invoked (line 1740).
> 
> We should check to make sure position does not exceed the string length before deciding to check for a decimal symbol.

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

  move test to existing test file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19533/files
  - new: https://git.openjdk.org/jdk/pull/19533/files/b6bb7e56..accb1850

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

  Stats: 93 lines in 2 files changed: 24 ins; 68 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19533/head:pull/19533

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

From nbenalla at openjdk.org  Tue Jun  4 20:44:30 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 20:44:30 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v9]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <LpFJAA-UbrltHMtXk1PKP37FZI3SILLjM2CFnB-cqXA=.a2aa7474-9268-4840-9614-d03e09814c09@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla 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 17 additional commits since the last revision:

 - Improve checker report messages
 - Merge branch 'master' into source-based-since-checker
 - - removed unused parameter `i`
   - make rest of methods private
   - ".toString" instead of "toString"
   
   Signed-off-by: Nizar Benalla <nizar.benalla at oracle.com>
 - Add a few more legacy methods, needed a few more after changes to the checker
 - checking for null values directly rather than catching NPE
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Now only skipping the common methods that every record class will have, and will never need a new `@since`
 - - Not checking elements enclosed within a record, I doubt a record class will change after being created
   - Added a null check as `toString` can return an exception
 - - Added some legacy modules that existed long before preview features (they were incubating)
   - Not checking elements enclosed withing a record
   - Only check if the file is readable using `Files.isReadable`
   - Dropped the use of `Files.exists` and `Files.isDirectory`
   - Use `--add-modules` option now to resolve certain modules
 - mention packages in initial comment
 - ... and 7 more: https://git.openjdk.org/jdk/compare/544d8c3f...5be962b7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/85b2d1a5..5be962b7

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

  Stats: 77006 lines in 1512 files changed: 56440 ins; 13399 del; 7167 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

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

From nbenalla at openjdk.org  Tue Jun  4 20:46:59 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 20:46:59 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v8]
In-Reply-To: <Sl-YxaDHlRxKaXgli2T63-tOgWUfW-1Skj-w533G3_M=.12340b80-6ddc-4bae-8ea0-e1f525376e39@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <Sl-YxaDHlRxKaXgli2T63-tOgWUfW-1Skj-w533G3_M=.12340b80-6ddc-4bae-8ea0-e1f525376e39@github.com>
Message-ID: <c7MPNkxtfHtVURoXFZ6w7damLhLY6AhXh2vuvo4zK20=.01a571ea-feee-49c1-8808-665bad460816@github.com>

On Mon, 27 May 2024 12:04:20 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - removed unused parameter `i`
>   - make rest of methods private
>   - ".toString" instead of "toString"
>   
>   Signed-off-by: Nizar Benalla <nizar.benalla at oracle.com>

The checker's report has been improved, the result after running it on `java.base` is the following

        SinceChecker java.base
STDERR:
src/java.base/java/io/PrintStream.java:685 method: void java.io.PrintStream.write(byte[]): `@since` version is 14 but the element exists before JDK 10
src/java.base/java/io/FileInputStream.java:374 method: byte[] java.io.FileInputStream.readNBytes(int): `@since` version: 9; found: 11
src/java.base/java/lang/classfile/ClassSignature.java:45 method: java.lang.classfile.Signature.ClassTypeSig java.lang.classfile.ClassSignature.superclassSignature(): `@since` version: 22; found: 23
src/java.base/java/lang/classfile/ClassReader.java:131 method: java.lang.classfile.constantpool.PoolEntry java.lang.classfile.ClassReader.readEntryOrNull(int,java.lang.Class): `@since` version: 24; found: 23
src/java.base/java/lang/classfile/constantpool/ConstantPool.java:74 method: java.lang.classfile.constantpool.PoolEntry java.lang.classfile.constantpool.ConstantPool.entryByIndex(int,java.lang.Class): `@since` version: 24; found: 23
src/java.base/java/lang/constant/ClassDesc.java:378 method: java.lang.Class java.lang.constant.ClassDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version: 12; found: 21
src/java.base/java/lang/constant/MethodTypeDesc.java:226 method: java.lang.invoke.MethodType java.lang.constant.MethodTypeDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version: 12; found: 21
src/java.base/java/lang/constant/MethodHandleDesc.java:210 method: java.lang.invoke.MethodHandle java.lang.constant.MethodHandleDesc.resolveConstantDesc(java.lang.invoke.MethodHandles.Lookup): `@since` version: 12; found: 21
src/java.base/java/lang/foreign/MemorySegment.java:622 method: long java.lang.foreign.MemorySegment.maxByteAlignment(): `@since` version: 22; found: 23
src/java.base/java/lang/invoke/MethodHandles.java:7923 method: java.lang.invoke.MethodHandle java.lang.invoke.MethodHandles.tableSwitch(java.lang.invoke.MethodHandle,java.lang.invoke.MethodHandle[]): `@since` version: 9; found: 17
src/java.base/java/lang/ref/Reference.java:527 method: java.lang.Object java.lang.ref.Reference.clone(): `@since` version is 11 but the element exists before JDK 10
src/java.base/java/lang/reflect/MalformedParameterizedTypeException.java:54 method: void java.lang.reflect.MalformedParameterizedTypeException.<init>(java.lang.String): `@since` version: 9; found: 10
src/java.base/java/nio/MappedByteBuffer.java:401 method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(): `@since` version: 9; found: 17
src/java.base/java/nio/MappedByteBuffer.java:414 method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.slice(int,int): `@since` version: 9; found: 17
src/java.base/java/nio/MappedByteBuffer.java:420 method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.duplicate(): `@since` version: 9; found: 17
src/java.base/java/nio/MappedByteBuffer.java:427 method: java.nio.MappedByteBuffer java.nio.MappedByteBuffer.compact(): `@since` version: 9; found: 17
src/java.base/java/text/ChoiceFormat.java:589 method: boolean java.text.ChoiceFormat.isStrict(): `@since` version: 9; found: 23
src/java.base/java/text/ChoiceFormat.java:595 method: void java.text.ChoiceFormat.setStrict(boolean): `@since` version: 9; found: 23
src/java.base/java/util/Properties.java:189 method: void java.util.Properties.<init>(int): `@since` version: 9; found: 10
src/java.base/java/util/concurrent/FutureTask.java:208 method: java.lang.Object java.util.concurrent.FutureTask.resultNow(): `@since` version: 9; found: 19
src/java.base/java/util/concurrent/FutureTask.java:224 method: java.lang.Throwable java.util.concurrent.FutureTask.exceptionNow(): `@since` version: 9; found: 19
src/java.base/java/util/concurrent/FutureTask.java:239 method: java.util.concurrent.Future.State java.util.concurrent.FutureTask.state(): `@since` version: 9; found: 19
src/java.base/java/util/concurrent/ThreadLocalRandom.java:504 method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float): `@since` version: 9; found: 17
src/java.base/java/util/concurrent/ThreadLocalRandom.java:514 method: float java.util.concurrent.ThreadLocalRandom.nextFloat(float,float): `@since` version: 9; found: 17
src/java.base/java/util/concurrent/ForkJoinTask.java:890 method: java.util.concurrent.Future.State java.util.concurrent.ForkJoinTask.state(): `@since` version: 9; found: 19
src/java.base/java/util/concurrent/ForkJoinTask.java:899 method: java.lang.Object java.util.concurrent.ForkJoinTask.resultNow(): `@since` version: 9; found: 19
src/java.base/java/util/concurrent/ForkJoinTask.java:913 method: java.lang.Throwable java.util.concurrent.ForkJoinTask.exceptionNow(): `@since` version: 9; found: 19
src/java.base/java/util/concurrent/DelayQueue.java:331 method: java.util.concurrent.Delayed java.util.concurrent.DelayQueue.remove(): `@since` version: 9; found: 21
src/java.base/java/util/concurrent/CompletableFuture.java:2137 method: java.lang.Object java.util.concurrent.CompletableFuture.resultNow(): `@since` version: 9; found: 19
src/java.base/java/util/concurrent/CompletableFuture.java:2152 method: java.lang.Throwable java.util.concurrent.CompletableFuture.exceptionNow(): `@since` version: 9; found: 19
src/java.base/java/util/concurrent/CompletableFuture.java:2399 method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyAsync(java.util.function.Function): `@since` version: 9; found: 12
src/java.base/java/util/concurrent/CompletableFuture.java:2404 method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyAsync(java.util.function.Function,java.util.concurrent.Executor): `@since` version: 9; found: 12
src/java.base/java/util/concurrent/CompletableFuture.java:2409 method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyCompose(java.util.function.Function): `@since` version: 9; found: 12
src/java.base/java/util/concurrent/CompletableFuture.java:2414 method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyComposeAsync(java.util.function.Function): `@since` version: 9; found: 12
src/java.base/java/util/concurrent/CompletableFuture.java:2419 method: java.util.concurrent.CompletableFuture java.util.concurrent.CompletableFuture.exceptionallyComposeAsync(java.util.function.Function,java.util.concurrent.Executor): `@since` version: 9; found: 12
src/java.base/java/util/concurrent/CompletableFuture.java:2544 method: java.util.concurrent.Future.State java.util.concurrent.CompletableFuture.state(): `@since` version: 9; found: 19
src/java.base/java/util/zip/Deflater.java:340 method: void java.util.zip.Deflater.setDictionary(java.nio.ByteBuffer): `@since` version: 9; found: 11
java.lang.Exception: The `@since` checker found 37 problems
        at SinceChecker.checkModule(SinceChecker.java:262)
        at SinceChecker.main(SinceChecker.java:123)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.Exception
JavaTest Message: shutting down test


TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: The `@since` checker found 37 problems
--------------------------------------------------
Test results: failed: 1

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

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2148385307

From nbenalla at openjdk.org  Tue Jun  4 20:53:03 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Jun 2024 20:53:03 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v9]
In-Reply-To: <LpFJAA-UbrltHMtXk1PKP37FZI3SILLjM2CFnB-cqXA=.a2aa7474-9268-4840-9614-d03e09814c09@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <LpFJAA-UbrltHMtXk1PKP37FZI3SILLjM2CFnB-cqXA=.a2aa7474-9268-4840-9614-d03e09814c09@github.com>
Message-ID: <LQzgziOkWM9eJzuCCErAEuKx6wLmvUBXhdfi3EIp3-s=.25d93a34-91ea-4f62-bdd7-5e7329bce0c9@github.com>

On Tue, 4 Jun 2024 20:44:30 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla 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 17 additional commits since the last revision:
> 
>  - Improve checker report messages
>  - Merge branch 'master' into source-based-since-checker
>  - - removed unused parameter `i`
>    - make rest of methods private
>    - ".toString" instead of "toString"
>    
>    Signed-off-by: Nizar Benalla <nizar.benalla at oracle.com>
>  - Add a few more legacy methods, needed a few more after changes to the checker
>  - checking for null values directly rather than catching NPE
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Now only skipping the common methods that every record class will have, and will never need a new `@since`
>  - - Not checking elements enclosed within a record, I doubt a record class will change after being created
>    - Added a null check as `toString` can return an exception
>  - - Added some legacy modules that existed long before preview features (they were incubating)
>    - Not checking elements enclosed withing a record
>    - Only check if the file is readable using `Files.isReadable`
>    - Dropped the use of `Files.exists` and `Files.isDirectory`
>    - Use `--add-modules` option now to resolve certain modules
>  - mention packages in initial comment
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/026b5fc2...5be962b7

While this might seem like a lot, if a developer runs it before pushing, they should only encounter a few reports at most.

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

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2148393893

From joehw at openjdk.org  Tue Jun  4 21:22:03 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 4 Jun 2024 21:22:03 GMT
Subject: RFR: 8332750: Broken link in CatalogFeatures.html
Message-ID: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>

Fix a broken link.

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

Commit messages:
 - 8332750: Broken link in CatalogFeatures.html

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

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

From lancea at openjdk.org  Tue Jun  4 21:39:57 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Jun 2024 21:39:57 GMT
Subject: RFR: 8332750: Broken link in CatalogFeatures.html
In-Reply-To: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
References: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
Message-ID: <vEliRwnXMH6P-yf0rBiFIENyirfp52SuFhoz5LlBsto=.c0ec2cb4-20d2-4e47-8435-5e552f0ad631@github.com>

On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a broken link.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19551#pullrequestreview-2097429096

From iris at openjdk.org  Tue Jun  4 21:42:56 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Jun 2024 21:42:56 GMT
Subject: RFR: 8332750: Broken link in CatalogFeatures.html
In-Reply-To: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
References: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
Message-ID: <wqxQwN2sFiIsWmksDIbmgjKCZWorX_8ibfMW9TREJP0=.ee2b5810-d900-41d6-8316-81d92b2649be@github.com>

On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a broken link.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19551#pullrequestreview-2097432388

From naoto at openjdk.org  Tue Jun  4 22:37:20 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 22:37:20 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v8]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <Qm7gmy3-D_k4lPokofNax7HekCEiPHSHQjwqPWthbd4=.55304d6c-bdc2-4e50-bbe1-19aa8debf080@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Corrected comments
 - Merge branch 'master' into JDK-8332161-restoreEcho-Test
 - Check restored echo with stty -a
 - incorporated the same fix from 8332922
 - Merge branch 'master' into JDK-8332161-restoreEcho-Test
 - Merge branch 'master' into JDK-8332161-restoreEcho-Test
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Added comment for restoreEchoLock
 - fixing typo
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - ... and 16 more: https://git.openjdk.org/jdk/compare/9686e804...1c0ab8eb

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

Changes: https://git.openjdk.org/jdk/pull/19315/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=07
  Stats: 158 lines in 2 files changed: 158 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315

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

From naoto at openjdk.org  Tue Jun  4 22:44:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 22:44:55 GMT
Subject: RFR: 8332750: Broken link in CatalogFeatures.html
In-Reply-To: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
References: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
Message-ID: <1nquc3zcVM03Vh3zOHQ-jBH_E7lLb_BRIpXWuqm_9Uw=.ed4a4b88-d5ad-45ce-9fe6-12ff1040087e@github.com>

On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a broken link.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19551#pullrequestreview-2097510057

From bchristi at openjdk.org  Tue Jun  4 23:23:56 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Jun 2024 23:23:56 GMT
Subject: RFR: 8333462: Performance regression of new DecimalFormat() when
 compare to jdk11
In-Reply-To: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
References: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
Message-ID: <KWlqADcpYfiDN2ESTuFkG1nep6Gwa8Dk6SStAyYgEjc=.22b3f3b4-e702-4006-a212-3659f7902cdf@github.com>

On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg <duke at openjdk.org> wrote:

> Run the below benchmark test  ,it show the average time of new DecimalFormat()  increase 18% when compare to jdk 11.
> 
> the result with jdk 11:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
> 
> 
> the result with current jdk:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     @Setup(Level.Trial)
>     public void setup() {
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> }
> 
> 
> Compare the flame graph it shows the java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. 
> After replacing  the lambda implementation with a simple loop , it shows nearly the same performance as jdk 11.
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> [flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541764/flame-graph-jdk11-jdk21.zip)

Would it be better if the benchmark returned the created `DecimalFormat` ?
Just thinking about dead code elimination:
https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java

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

PR Comment: https://git.openjdk.org/jdk/pull/19534#issuecomment-2148568212

From bchristi at openjdk.org  Tue Jun  4 23:29:58 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Jun 2024 23:29:58 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
Message-ID: <M5LIV0VV_rgAKujiC4VGLZEir0ONQQL-iSvYl62g77Q=.0482e172-2a58-4c92-96c7-deb939155fc2@github.com>

On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

(Same comment as on the [other PR](https://github.com/openjdk/jdk/pull/19534#issuecomment-2148568212).)

Would it be better if the benchmarks returned the created DecimalFormats ?
Just thinking about dead code elimination:
https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2148572775

From liach at openjdk.org  Wed Jun  5 00:55:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Jun 2024 00:55:03 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <wpd5Ftokgz40YYJdiWk4pJAwrR5HFWcc3Ok2uxoWPAI=.cb28a3a2-1814-4392-85ee-28b4e785fca9@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

@altrisi As trivial and low-effort as this seems, this is actually fixing some technical debt for legacy Makefiles last changed before 8e7a855ee8f085cee080395058f79c8a75bfef40 when trailing whitespace checks applied to Makefiles.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2148641237

From nbenalla at openjdk.org  Wed Jun  5 01:29:00 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 5 Jun 2024 01:29:00 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java
In-Reply-To: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
Message-ID: <vm9uTx-glKPIn6DLh8Ka2m104lpuQP3a2SSJ1KTYjMM=.025971a3-8807-4312-b608-973d364930ed@github.com>

On Mon, 3 Jun 2024 17:26:52 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files.
> 
> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `<body>` and `<html>`. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file.
> 
> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine.

Sure, I will do it for this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/19529#issuecomment-2148690821

From duke at openjdk.org  Wed Jun  5 01:54:12 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 5 Jun 2024 01:54:12 GMT
Subject: RFR: 8333462: Performance regression of new DecimalFormat() when
 compare to jdk11 [v2]
In-Reply-To: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
References: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
Message-ID: <U0ucoc_ZT56s504oo4_JeCCt8XrcD6SD2e2VjTkFFB4=.3d927cac-bdee-4273-ad5d-5503501532f6@github.com>

> Run the below benchmark test  ,it show the average time of new DecimalFormat()  increase 18% when compare to jdk 11.
> 
> the result with jdk 11:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
> 
> 
> the result with current jdk:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     @Setup(Level.Trial)
>     public void setup() {
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> }
> 
> 
> Compare the flame graph it shows the java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. 
> After replacing  the lambda implementation with a simple loop , it shows nearly the same performance as jdk 11.
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> [flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541764/flame-graph-jdk11-jdk21.zip)

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333462: Performance regression of new DecimalFormat() when compare to jdk11

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19534/files
  - new: https://git.openjdk.org/jdk/pull/19534/files/a230ce00..d5b9ccfb

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

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

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

From duke at openjdk.org  Wed Jun  5 01:54:12 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 5 Jun 2024 01:54:12 GMT
Subject: Integrated: 8333462: Performance regression of new DecimalFormat()
 when compare to jdk11
In-Reply-To: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
References: <bzG5sikY-jQP-t5a9ntMPsQckpoTq5COf4uA09Kiolg=.816e63da-164b-4df7-9cc0-0d4246254f16@github.com>
Message-ID: <GdoAqhoLJNJ-LfDiBf-beT33FFuiWKZ1fpsMsPWOscE=.61120ed6-d704-4aa2-b931-bf5f88e73242@github.com>

On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg <duke at openjdk.org> wrote:

> Run the below benchmark test  ,it show the average time of new DecimalFormat()  increase 18% when compare to jdk 11.
> 
> the result with jdk 11:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
> 
> 
> the result with current jdk:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     @Setup(Level.Trial)
>     public void setup() {
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> }
> 
> 
> Compare the flame graph it shows the java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. 
> After replacing  the lambda implementation with a simple loop , it shows nearly the same performance as jdk 11.
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> [flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541764/flame-graph-jdk11-jdk21.zip)

This pull request has now been integrated.

Changeset: d8261279
Author:    lingjun.cg <lingjun.cg at alibaba-inc.com>
Committer: Denghui Dong <ddong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d826127970bd2ae8bf4cacc3c55634dc5af307c4
Stats:     8 lines in 1 file changed: 3 ins; 0 del; 5 mod

8333462: Performance regression of new DecimalFormat() when compare to jdk11

Reviewed-by: liach, naoto, jlu

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

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

From duke at openjdk.org  Wed Jun  5 02:01:56 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 5 Jun 2024 02:01:56 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <hUMj9-SHjn9oR21ije3f2YuAevrpNROsNWbjnzv4oAU=.632096ad-b8aa-4f8a-9033-e921d5f13615@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
 <hUMj9-SHjn9oR21ije3f2YuAevrpNROsNWbjnzv4oAU=.632096ad-b8aa-4f8a-9033-e921d5f13615@github.com>
Message-ID: <yHkYN3aMNBdlZP5JQu_6V4QSoeMnvfg2TcFLXDFh2t8=.fbbcb556-64d6-4db5-898d-edd82122b79f@github.com>

On Tue, 4 Jun 2024 19:44:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Also it would be helpful to compare the performance without biased locking in JDK11.

If run in JDK11 without biased locking, the performance is as same as run in current JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2148719265

From jpai at openjdk.org  Wed Jun  5 02:03:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 02:03:00 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
Message-ID: <iBdPwbp4NMfDQIcP9EMwMKDKH0fcg9SbtQV7QeJ8JgA=.b23402f5-ffe6-40b5-8335-e451aae5ecbc@github.com>

On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decreasing diff size addressing unnecessary changes
>
> Hi all,  
> 
> I think there's some consensus that we need some follow up cleanup issues for the JNI spec, renaming constants, fixing return codes, etc. 
> 
> Seeing how that grows the scope of the issue quite a bit, I'd like to push this patch and track the other issues brought up separately. 
> 
> If there are no objections about the current state, I'd like to integrate some time next week. Let me know your thoughts.
> 
> cc: @jaikiran, @AlanBateman

@SoniaZaldana CI testing of this PR along with latest master commits passed without any failures. So you can now integrate this.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2148719775

From joehw at openjdk.org  Wed Jun  5 02:56:00 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 5 Jun 2024 02:56:00 GMT
Subject: RFR: 8332750: Broken link in CatalogFeatures.html
In-Reply-To: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
References: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
Message-ID: <5aAgylOHQlZImmPrg1OGWFTF1FDbJnewyR5Jhv5N_co=.5485424f-f315-4c75-89d9-82401bb1209d@github.com>

On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a broken link.

Thanks all!

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

PR Comment: https://git.openjdk.org/jdk/pull/19551#issuecomment-2148759156

From joehw at openjdk.org  Wed Jun  5 02:56:00 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 5 Jun 2024 02:56:00 GMT
Subject: Integrated: 8332750: Broken link in CatalogFeatures.html
In-Reply-To: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
References: <H0-dqG-Qqw7jA0phvJQOX0NhFVs4oVrDQy-h2mL8u3Q=.94d6dee5-43b1-4f3a-a799-66b1fd78c2c6@github.com>
Message-ID: <sHYOmLd49oy-8Y67MVLsGCkPnMRh4Raqeg7E4y4S2YM=.6164a507-27c6-4553-88e6-57af931ff4e9@github.com>

On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a broken link.

This pull request has now been integrated.

Changeset: 9db7c950
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9db7c950190853513f4c2afa0efa9a4ff72b60d7
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8332750: Broken link in CatalogFeatures.html

Reviewed-by: lancea, iris, naoto

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

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

From duke at openjdk.org  Wed Jun  5 03:59:24 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 5 Jun 2024 03:59:24 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/6210c61e..1ab65e18

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

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

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

From almatvee at openjdk.org  Wed Jun  5 04:36:02 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 5 Jun 2024 04:36:02 GMT
Subject: RFR: 8319457: Update jpackage to support WiX Toolset 4 on Windows
 [v4]
In-Reply-To: <xbNenP7KZJS9jQYFOnMd_rCNOWmcUhneP5oYCX1MH2I=.75c0efc3-fa74-4e88-814d-071dbe6ae93e@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <xbNenP7KZJS9jQYFOnMd_rCNOWmcUhneP5oYCX1MH2I=.75c0efc3-fa74-4e88-814d-071dbe6ae93e@github.com>
Message-ID: <sjDT-FtOZJJm0hf7ckgTqiSWpbIV9AVzXfZNjDLFcos=.5e797275-f32c-49e7-b5f9-0e3e7408432d@github.com>

On Tue, 4 Jun 2024 16:07:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Add support for WiX4 (and WiX5) in jpackage.
>> 
>> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
>> 
>> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
>> 
>> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
>> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
>> 
>> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - WixSourceConverter#applyTo should do what OverridableResource#saveToFile() does: create parent directory and replace output file if it exists.
>  - Fix issue with overwriting custom l10n file in the resource directory. All WiX source files from the resource directory should be copied to jpackage work directory before running wxi tools. jpackage should not change files in the resource directory.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java line 157:

> 155: 
> 156:     @Override
> 157:     List<String> getLoggableWixFeatures() {

Maybe I am missing something, but is it used? I only see call to base class `WixFragmentBuilder::getLoggableWixFeatures`.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 44:

> 42: resource.installdirnotemptydlg-wix-file=Not empty install directory dialog WiX project file
> 43: resource.launcher-as-service-wix-file=Service installer WiX project file
> 44: resource.wix-src-conv=XSLT stylesheet converting WiX sources from WiX v3 to WiX v4 format

WiX v4 -> WiX v4/v5

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 46:

> 44: resource.wix-src-conv=XSLT stylesheet converting WiX sources from WiX v3 to WiX v4 format
> 45: 
> 46: error.no-wix-tools=Can not find WiX tools. Was looking for WiX v3 light.exe and candle.exe or WiX v4 wix.exe and none was found

WiX v4 -> WiX v4/v5

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1626887692
PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1626907533
PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1626909859

From duke at openjdk.org  Wed Jun  5 04:44:02 2024
From: duke at openjdk.org (David Alayachew)
Date: Wed, 5 Jun 2024 04:44:02 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v7]
In-Reply-To: <QN5C-_MG63Ku6hMtJQICTli-RVC9RxS6CWdw1iX67FM=.70337c4c-f3f6-4724-aa8a-6fa9030bc972@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <QN5C-_MG63Ku6hMtJQICTli-RVC9RxS6CWdw1iX67FM=.70337c4c-f3f6-4724-aa8a-6fa9030bc972@github.com>
Message-ID: <1A1-Oho1unVU40_M9kIkuTY43sNrNRWy8ZtIpcJ4CP0=.e3afed26-7d36-44e4-9327-bb834ec2314e@github.com>

On Wed, 8 May 2024 08:30:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed empty line.

Hey, I'm just curious -- why was the solution to remove an entire module? I understand the point of moving the relevant code over to `java.base`, but I don't understand why removing the random module made sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2148842095

From alanb at openjdk.org  Wed Jun  5 05:03:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 05:03:04 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v7]
In-Reply-To: <1A1-Oho1unVU40_M9kIkuTY43sNrNRWy8ZtIpcJ4CP0=.e3afed26-7d36-44e4-9327-bb834ec2314e@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <QN5C-_MG63Ku6hMtJQICTli-RVC9RxS6CWdw1iX67FM=.70337c4c-f3f6-4724-aa8a-6fa9030bc972@github.com>
 <1A1-Oho1unVU40_M9kIkuTY43sNrNRWy8ZtIpcJ4CP0=.e3afed26-7d36-44e4-9327-bb834ec2314e@github.com>
Message-ID: <gofOoBhoBNxEqJXNYIjkatnKH3_iUD23HzYlAQ2IWpM=.1bb6e3e0-a211-40b1-b688-a35fa8366c59@github.com>

On Wed, 5 Jun 2024 04:41:48 GMT, David Alayachew <duke at openjdk.org> wrote:

> Hey, I'm just curious -- why was the solution to remove an entire module? I understand the point of moving the relevant code over to `java.base`, but I don't understand why removing the random module made sense.

With the implementations moved, the jdk.random module didn't contain any classes. A placeholder module could have been left in place for this using jlink that might have a script that adds this module but it didn't seem worth it to do this for a release or two. It was a different answer for jdk.cryto.ec before it was removed. That module existed since JDK 9 so more likely be used in jlink scripts.

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

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2148858435

From duke at openjdk.org  Wed Jun  5 05:28:06 2024
From: duke at openjdk.org (David Alayachew)
Date: Wed, 5 Jun 2024 05:28:06 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v7]
In-Reply-To: <QN5C-_MG63Ku6hMtJQICTli-RVC9RxS6CWdw1iX67FM=.70337c4c-f3f6-4724-aa8a-6fa9030bc972@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <QN5C-_MG63Ku6hMtJQICTli-RVC9RxS6CWdw1iX67FM=.70337c4c-f3f6-4724-aa8a-6fa9030bc972@github.com>
Message-ID: <yNyPP9n8PHlfFkaOeDCWLVsubLLpUnzISIVJ5uUMSf0=.9733fdc2-2379-48a5-b6de-24ae6b650eb6@github.com>

On Wed, 8 May 2024 08:30:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed empty line.

oh lol, makes sense then.

It's wild though -- I always thought that deleting an entire module would
count as a backwards incompatible thing.


On Wed, Jun 5, 2024 at 1:00?AM Alan Bateman ***@***.***>
wrote:

> Hey, I'm just curious -- why was the solution to remove an entire module?
> I understand the point of moving the relevant code over to java.base, but
> I don't understand why removing the random module made sense.
>
> With the implementations moved, the jdk.random module didn't contain any
> classes. A placeholder module could have been left in place for this using
> jlink that might have a script that adds this module but it didn't seem
> worth it to do this for a release or two. It was a different answer for
> jdk.cryto.ec before it was removed. That module existed since JDK 9 so
> more likely be used in jlink scripts.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/18932#issuecomment-2148858435>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AJFR6SBJJMKKIZYHUOWJLSDZF2LPZAVCNFSM6AAAAABGW67KJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYHA2TQNBTGU>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2148883348

From thartmann at openjdk.org  Wed Jun  5 05:42:57 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 5 Jun 2024 05:42:57 GMT
Subject: RFR: 8333334: C2: Make result of `Node::dominates` more precise to
 enhance scalar replacement
In-Reply-To: <ARdyBPCqSDKlOM-u5kGZGqgOySxOT2MbznAiZaQMWx8=.21dfdc0c-1b92-4484-ad05-203e819a8569@github.com>
References: <ARdyBPCqSDKlOM-u5kGZGqgOySxOT2MbznAiZaQMWx8=.21dfdc0c-1b92-4484-ad05-203e819a8569@github.com>
Message-ID: <HE_qrvaDSpsJIHRATebcLfERUFVNEM1gMpyVtIWf7w8=.cbe7aeab-1682-43c7-b4c3-b11ecf9d9131@github.com>

On Fri, 31 May 2024 09:01:38 GMT, MaxXing <duke at openjdk.org> wrote:

> This patch changes the algorithm of `Node::dominates` to make the result more precise, and allows the iterators of `ConcurrentHashMap` to be scalar replaced.
> 
> The previous algorithm will return a conservative result when encountering a dead control flow, and only try the first two input paths of a multi-input Region node, which may prevent the scalar replacement in some cases.
> 
> For example, with G1 GC enabled, C2 generates GC barriers for `ConcurrentHashMap` iteration operations at some early phases, and then eliminates them in a later IGVN, but `LoadNode` is also idealized in the same IGVN. This causes `LoadNode::Ideal` to see some dead barrier control flows, and refuse to split some instance field loads through Phi due to the conservative result of `Node::dominates`, and thus the scalar replacement can not be applied to iterators in the later macro elimination phase.
> 
> This patch allows `Node::dominates` to try other paths of the last multi-input Region node when the first path is dead, and makes `ConcurrentHashMap` iteration ~30% faster:
> 
> 
> Benchmark                            (nkeys)  Mode  Cnt        Score       Error  Units
> Maps.testConcurrentHashMapIterators    10000  avgt   15   414099.085 ? 33230.945  ns/op   # baseline
> Maps.testConcurrentHashMapIterators    10000  avgt   15   315490.281 ?  3037.056  ns/op   # patch
> 
> 
> Testing: tier1-4.

Impressive results! I haven't looked at the change yet but here are a few questions / requests:
- Could you add a screenshot of the IR of the case you are describing?
- Wouldn't it help to add the LoadNode back to the IGVN worklist and wait for the dead path to be removed?
- Could you add an [IR framework](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/README.md) test that verifies that the optimization works as expected?

Thanks,
Tobias

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

PR Review: https://git.openjdk.org/jdk/pull/19496#pullrequestreview-2098076379

From jlahoda at openjdk.org  Wed Jun  5 05:59:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Jun 2024 05:59:16 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization [v2]
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <Ib8_j-d7hFxapl-DOiA8QRJI0UfA1vofSgrOmJNkJcE=.36c66f32-27a3-475b-8d14-0dc4bddc4f56@github.com>

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

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

  Reflecting review feedback - explicitly selecting the jdk.internal.le provider in the test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19479/files
  - new: https://git.openjdk.org/jdk/pull/19479/files/9886732e..7a0c448f

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

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

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

From thartmann at openjdk.org  Wed Jun  5 11:21:09 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 5 Jun 2024 11:21:09 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v12]
In-Reply-To: <2HF_LGpK7B6i1UcgJ8g9JgzGF27gVAHZkGnVQk-Fo4w=.98339735-cd89-4059-a449-6a4911e9af41@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>
 <2HF_LGpK7B6i1UcgJ8g9JgzGF27gVAHZkGnVQk-Fo4w=.98339735-cd89-4059-a449-6a4911e9af41@github.com>
Message-ID: <D7byoGb9coTCn4rna3tBqZwZuyDkl5cET7cpSDem99Q=.d9e03c2a-8f26-4a43-a650-d0f26c2ab125@github.com>

On Wed, 22 May 2024 14:19:36 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Volodymyr Paprotski 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 17 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ecc-montgomery
>>  - shenandoah verifier
>>  - comments from Sandhya
>>  - whitespace
>>  - add message back
>>  - whitespace
>>  - Use AffinePoint to exit Montgomery domain
>>    
>>    Style notes:
>>    Affine.equals()
>>        - Mismatched fields only appear to be used from testing, perhaps should be moved there instead
>>    Affine.getX(boolean)|getY(boolean)
>>        - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks
>>        - needed to convert Affine to Projective (need to stay in montgomery domain)
>>    ECOperations.PointMultiplier
>>       - changes could probably be restored to original (since ProjectivePoint handling no longer required)
>>       - consider these changes an improvement? (fewer nested classes)
>>       - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted)
>>  - whitespace
>>  - Comments from Tony and Jatin
>>  - Comments from Jatin and Tony
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/1adfff34...b1a33004
>
> Thanks Tobi!

Unfortunately, this caused a performance regression, see [JDK-8333583](https://bugs.openjdk.org/browse/JDK-8333583). @vpaprotsk, please have a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2149576062

From jpai at openjdk.org  Wed Jun  5 11:45:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 11:45:10 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE [v3]
In-Reply-To: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
Message-ID: <GmWfkRfZsmexqLZsEsEeWVNbE-bRIeQL82K6o6a2deQ=.53240d73-ede2-43a6-b538-613cfc61ac4c@github.com>

> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
> 
> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
> 
> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
> 
> I'll open a CSR for this change.

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

  review feedback updates from the CSR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19515/files
  - new: https://git.openjdk.org/jdk/pull/19515/files/e13e65d2..a43e96de

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

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

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

From alanb at openjdk.org  Wed Jun  5 11:48:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 11:48:01 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
Message-ID: <SQ_oU_XEPO8uWMGNNx09QomUW3kgeyOe29H0BW1_9fI=.156c85ee-a1fd-4901-96fd-e682f3dac2bf@github.com>

On Fri, 31 May 2024 13:18:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reconcile changes

Viktor (mostly) and I have been testing and reviewing these changes at each iteration. I think we are happy with where things are at, significantly very positive in some of the streams/gatherer tests. The Starvation test is the canary to catch a scenario that has been observed along the way, but not with the current version. So I think this is good to integrate.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19131#pullrequestreview-2098894992

From asotona at openjdk.org  Wed Jun  5 12:00:25 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Jun 2024 12:00:25 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v19]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

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

  An assortment of potential improvements
  
  Co-authored-by: Claes Redestad <redestad at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/6ca164bc..54376fe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=17-18

  Stats: 25 lines in 5 files changed: 15 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

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

From jpai at openjdk.org  Wed Jun  5 12:14:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 12:14:07 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE [v4]
In-Reply-To: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
Message-ID: <9UlaEbxrgbKs_KSP9pbE84Ws41jEDmEPZVEm3VjZbCc=.4abfbe92-731c-4014-97fc-c5e3a1e9878b@github.com>

> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
> 
> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
> 
> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
> 
> I'll open a CSR for this change.

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

  clarify blocking semantic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19515/files
  - new: https://git.openjdk.org/jdk/pull/19515/files/a43e96de..b7b870d5

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

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

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

From asotona at openjdk.org  Wed Jun  5 12:14:58 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Jun 2024 12:14:58 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v19]
In-Reply-To: <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
Message-ID: <nUFB9mhim9dn0-n-loRRPaWMZShyIcz738_nIdrvB-c=.7fa99886-d403-4c39-bcd9-ff05855394dd@github.com>

On Wed, 5 Jun 2024 12:00:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An assortment of potential improvements
>   
>   Co-authored-by: Claes Redestad <redestad at openjdk.org>

Name             Cnt          Base         Error           Test         Error         Unit  Change
Perfstartup-JMH   20        40.000 ?       0.000         40.000 ?       0.000        ms/op   1.00x (p = 0.000 )
  :.cycles           236365197.300 ? 3630668.331  224263724.700 ? 4160144.635       cycles   0.95x (p = 0.000*)
  :.instructions     602001346.250 ? 3134647.039  574894340.900 ? 2297441.310 instructions   0.95x (p = 0.000*)
  :.taskclock               60.000 ?       0.000         58.500 ?       3.181           ms   0.98x (p = 0.083 )
  * = significant

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

PR Comment: https://git.openjdk.org/jdk/pull/19410#issuecomment-2149681885

From alanb at openjdk.org  Wed Jun  5 12:21:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 12:21:57 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE [v4]
In-Reply-To: <9UlaEbxrgbKs_KSP9pbE84Ws41jEDmEPZVEm3VjZbCc=.4abfbe92-731c-4014-97fc-c5e3a1e9878b@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
 <9UlaEbxrgbKs_KSP9pbE84Ws41jEDmEPZVEm3VjZbCc=.4abfbe92-731c-4014-97fc-c5e3a1e9878b@github.com>
Message-ID: <Qo8zWFvQx2xTcwZXCVfMlsmT3bSkGR8e0VPuU1-qHTs=.3a92fe37-08d5-4165-8cf0-489c556e472c@github.com>

On Wed, 5 Jun 2024 12:14:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
>> 
>> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
>> 
>> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
>> 
>> I'll open a CSR for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify blocking semantic

This went through a few iterations in the CSR issue, looking good now.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19515#pullrequestreview-2098975614

From asotona at openjdk.org  Wed Jun  5 12:21:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Jun 2024 12:21:59 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v19]
In-Reply-To: <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
Message-ID: <hbDhFoRJyzfNs-_cOnO6ODst0AADmzYYUqltfytwIIs=.f534a9ee-31f3-4198-b393-5107ab004034@github.com>

On Wed, 5 Jun 2024 12:00:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An assortment of potential improvements
>   
>   Co-authored-by: Claes Redestad <redestad at openjdk.org>

Benchmark                                 Mode  Cnt   Score   Error  Units
ProxyGenBench.generate100Proxies(master)    ss   10  15.295 ? 5.435  ms/op
ProxyGenBench.generate100Proxies(#19410)    ss   10  11.761 ? 3.323  ms/op
Finished running test 'micro:.+ProxyGenBench.+'

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

PR Comment: https://git.openjdk.org/jdk/pull/19410#issuecomment-2149694078

From redestad at openjdk.org  Wed Jun  5 12:27:58 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 5 Jun 2024 12:27:58 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v19]
In-Reply-To: <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
Message-ID: <xCdFR8DfgbofAUsvMJsbGmPhy4nRtSLqCw-8mkL5hys=.a95767d8-7b4d-413c-b3db-046b70e12ca1@github.com>

On Wed, 5 Jun 2024 12:00:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An assortment of potential improvements
>   
>   Co-authored-by: Claes Redestad <redestad at openjdk.org>

Looks good. Generation of proxy classes gets a nice boost this way. The condy bsm calls that may happen later takes a small hit which we can improve in a follow-up.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19410#pullrequestreview-2098990024

From vklang at openjdk.org  Wed Jun  5 12:33:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 5 Jun 2024 12:33:05 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <SQ_oU_XEPO8uWMGNNx09QomUW3kgeyOe29H0BW1_9fI=.156c85ee-a1fd-4901-96fd-e682f3dac2bf@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
 <SQ_oU_XEPO8uWMGNNx09QomUW3kgeyOe29H0BW1_9fI=.156c85ee-a1fd-4901-96fd-e682f3dac2bf@github.com>
Message-ID: <U6PN6Nuv3xv5JBzPvmoWga66r20wytzaYChh5fArtis=.7b8830ab-247c-4afb-bc41-cc2970323364@github.com>

On Wed, 5 Jun 2024 11:45:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reconcile changes
>
> Viktor (mostly) and I have been testing and reviewing these changes at each iteration. I think we are happy with where things are at, significantly very positive in some of the streams/gatherer tests. The Starvation test is the canary to catch a scenario that has been observed along the way, but not with the current version. So I think this is good to integrate.

Seconding @AlanBateman, I've reviewed and provided feedback on this PR multiple times, and have had numerous runs of parallel streams / gatherers and I think this is good to go. If I was a reviewer my vote would matter, but I'm adding this comment here as an "enthusiastic supporter". :)

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

PR Comment: https://git.openjdk.org/jdk/pull/19131#issuecomment-2149714806

From jlahoda at openjdk.org  Wed Jun  5 12:36:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Jun 2024 12:36:33 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization [v3]
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <ULRi5T5ytMJO2a3N65np3ePCpnldssTY_wDGxdyoDdg=.327269fd-9961-4920-be99-63b0211fd74e@github.com>

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

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

  Correctly reflecting review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19479/files
  - new: https://git.openjdk.org/jdk/pull/19479/files/7a0c448f..f3259793

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

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

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

From liach at openjdk.org  Wed Jun  5 12:43:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Jun 2024 12:43:01 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v19]
In-Reply-To: <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
Message-ID: <krL64OfLLSEiJPDW47dGavUERSp0t_uoqi69Mvl2VJg=.d2869909-0e08-40f8-a1a7-561e6727d209@github.com>

On Wed, 5 Jun 2024 12:00:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An assortment of potential improvements
>   
>   Co-authored-by: Claes Redestad <redestad at openjdk.org>

src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 356:

> 354:         ClassDesc[] fullParamTypes = new ClassDesc[paramTypes.length + prefixLen];
> 355:         System.arraycopy(INDY_BOOTSTRAP_ARGS, 0, fullParamTypes, 0, prefixLen);
> 356:         System.arraycopy(paramTypes, 0, fullParamTypes, prefixLen, paramTypes.length);

I'm thinking about creating a basic MethodTypeDesc like `INDY_BOOTSTRAP_TYPE = MethodTypeDesc.ofValidated(CD_Object, INDY_BOOTSTRAP_ARGS)`, and we derive bsm with 

INDY_BOOTSTRAP_TYPE
    .insertParameterTypes(INDY_BOOTSTRAP_TYPE.parameterCount(), paramTypes)
    .changeReturnType(returnType)

which creates two MTD wrappers but they share the same parameter array

test/micro/org/openjdk/bench/java/lang/reflect/ProxyGenBench.java line 2:

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

Suggestion:

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

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1627683294
PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1627685503

From asotona at openjdk.org  Wed Jun  5 12:50:25 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Jun 2024 12:50:25 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v20]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <y-ZvONQ53OY0d_skOYHH3xhjTp3uZYz6MZICDTwxeQ4=.ce8261f2-e773-45d7-8cdc-04259cd1f736@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

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

  Update test/micro/org/openjdk/bench/java/lang/reflect/ProxyGenBench.java
  
  Co-authored-by: Chen Liang <liangchenblue at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/54376fe8..a0822718

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=18-19

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

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

From dl at openjdk.org  Wed Jun  5 13:05:10 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 5 Jun 2024 13:05:10 GMT
Subject: Integrated: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <KQCukyk4XzR3UGmpQ8C8OdGq9_nAGZwmb8sOHjQK7I0=.1c25da71-dd83-4f67-804d-9753fce04277@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

This pull request has now been integrated.

Changeset: 789f704d
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/789f704d9ab5aaf87193f508859c4c9a528d7779
Stats:     735 lines in 2 files changed: 250 ins; 184 del; 301 mod

8322732: ForkJoinPool may underutilize cores in async mode
8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException

Reviewed-by: alanb

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

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

From szaldana at openjdk.org  Wed Jun  5 13:09:10 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 5 Jun 2024 13:09:10 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>
Message-ID: <vONZV4zOagYV87jsQDOeDE6oU8kcNzLCU10JlSwJeVI=.0c86913a-b811-41c8-9410-e9b62b7dbb6c@github.com>

On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decreasing diff size addressing unnecessary changes
>
> Hi all,  
> 
> I think there's some consensus that we need some follow up cleanup issues for the JNI spec, renaming constants, fixing return codes, etc. 
> 
> Seeing how that grows the scope of the issue quite a bit, I'd like to push this patch and track the other issues brought up separately. 
> 
> If there are no objections about the current state, I'd like to integrate some time next week. Let me know your thoughts.
> 
> cc: @jaikiran, @AlanBateman

> @SoniaZaldana CI testing of this PR along with latest master commits passed without any failures. So you can now integrate this.

Thanks @jaikiran!

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2149833060

From liach at openjdk.org  Wed Jun  5 13:09:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Jun 2024 13:09:10 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v20]
In-Reply-To: <y-ZvONQ53OY0d_skOYHH3xhjTp3uZYz6MZICDTwxeQ4=.ce8261f2-e773-45d7-8cdc-04259cd1f736@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <y-ZvONQ53OY0d_skOYHH3xhjTp3uZYz6MZICDTwxeQ4=.ce8261f2-e773-45d7-8cdc-04259cd1f736@github.com>
Message-ID: <rkBwn4mjiQcMOf06M_GJey3sQbR58QcuoklnNQbUQ6s=.65e19b76-d9d0-4ca6-bcf1-ca3be2afb09e@github.com>

On Wed, 5 Jun 2024 12:50:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/micro/org/openjdk/bench/java/lang/reflect/ProxyGenBench.java
>   
>   Co-authored-by: Chen Liang <liangchenblue at gmail.com>

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/19410#pullrequestreview-2099091898

From szaldana at openjdk.org  Wed Jun  5 13:15:10 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 5 Jun 2024 13:15:10 GMT
Subject: Integrated: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <KqMVadh-Z6nZ94BEh3d_I0kElfgPyUgRT7I3iTRTBr8=.a1c53c7d-38df-489c-883e-d995ad345b8b@github.com>

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

This pull request has now been integrated.

Changeset: cbb6747e
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbb6747e6b9ce7e2b9e0ffb0a1f9499f7e0e13b0
Stats:     351 lines in 4 files changed: 309 ins; 10 del; 32 mod

8329581: Java launcher no longer prints a stack trace
8329420: Java 22 (and 23) launcher calls default constructor although main() is static
8330864: No error message when ExceptionInInitializerError thrown in static initializer

Reviewed-by: stuefe

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

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

From alanb at openjdk.org  Wed Jun  5 13:24:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 13:24:13 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <f3ivoB8Qwi8np9XhCg0QtSy6pG4sFP0_glyVAOaqZGI=.c5ab1624-afee-48fb-a749-0973920205d9@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
 <f3ivoB8Qwi8np9XhCg0QtSy6pG4sFP0_glyVAOaqZGI=.c5ab1624-afee-48fb-a749-0973920205d9@github.com>
Message-ID: <G_Y61dWsmwKGHpz0wm4BUYb1a_e2SZP3cYRjWBiLmJ8=.abc28300-f715-4542-b48d-3aea3aab0e65@github.com>

On Tue, 4 Jun 2024 14:39:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> I've added a couple of `@requires jlink.packagedModules` (new with this patch) so that jlink tests don't start to fail with it. 

Good, the `@requires jlink.packagedModules` make sense.

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

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

From alanb at openjdk.org  Wed Jun  5 13:24:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 13:24:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
Message-ID: <pBWOHFwswl6uCaY44BZwzN9Ta4ZBscTqHF8FFGF8RJE=.da6aef0c-1ab4-4752-959d-f4ab2b08ec14@github.com>

On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:
> 
>  - Mark some tests with requiring packaged modules
>  - Correctly set packaged modules default
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Fix new line in jlink.properties
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>  - Only add runtime track files for linkable runtimes
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d

> [5fef297](https://github.com/openjdk/jdk/commit/5fef297ba999963d60452f098193d2cba33a941b) implements this.

I think it was surprising that --enable-runtime-link-image still included the packaged modules so thanks for taking the feedback on this point.

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

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

From vklang at openjdk.org  Wed Jun  5 13:27:01 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 5 Jun 2024 13:27:01 GMT
Subject: RFR: 8312436: CompletableFuture never completes when
 'Throwable.toString()' method throws Exception
In-Reply-To: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
References: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
Message-ID: <RT2bKsjGfmBAXuE95lUZDgNG42SIsbkmYEjM6GGV3D4=.f8fa4aa7-153c-4ee1-83a3-50124a83fc36@github.com>

On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.
> 
> Nevertheless, there is some things we can do, as witnessed in this PR.

@AlanBateman Do you have a minute to review this one?

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

PR Comment: https://git.openjdk.org/jdk/pull/18988#issuecomment-2149910528

From alanb at openjdk.org  Wed Jun  5 13:27:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 13:27:14 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
Message-ID: <YyEGz4J-n97EjIaxkLlJK7UkdYCw-4A10939qTzutp4=.dcfbf932-243c-47d7-afd7-af5b276633d4@github.com>

On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:
> 
>  - Mark some tests with requiring packaged modules
>  - Correctly set packaged modules default
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Fix new line in jlink.properties
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>  - Only add runtime track files for linkable runtimes
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d

test/jdk/tools/lib/tests/JImageHelper.java line 38:

> 36:  * JDK Modular image iterator
> 37:  */
> 38: public class JImageHelper {

This is only usable in tests that use `@modules` to open jdk.internal.jimage.*. It might be better  co-locate this with the jlink tests for now. It may be that we do have test infra structure for jimage in the future but starting out with the supporting test lib in the jlink test tree should be okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627780757

From alanb at openjdk.org  Wed Jun  5 13:33:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 13:33:12 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
Message-ID: <Y0hhATacOutJ7YAYjdht8zpdg21Tqr7bO8ImDGz1-U8=.82958ed9-7f11-4cd4-8af0-911baba3fd68@github.com>

On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:
> 
>  - Mark some tests with requiring packaged modules
>  - Correctly set packaged modules default
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Fix new line in jlink.properties
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>  - Only add runtime track files for linkable runtimes
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d

make/Images.gmk line 101:

> 99: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
> 100:   JLINK_JDK_EXTRA_OPTS += --generate-linkable-runtime
> 101: endif

In passing, I suppose this could be JLINK_PRODUCE_LINKABLE_RUNTIME to be consistent with the configure option. No big deal of course, just noticed a few places where the words are transposed.

make/autoconf/jdk-options.m4 line 594:

> 592:     DEFAULT_PACKAGED_MODULES=false
> 593:   else
> 594:     DEFAULT_PACKAGED_MODULES=true

Good!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627791600
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627791805

From alanb at openjdk.org  Wed Jun  5 13:37:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 13:37:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
Message-ID: <IErzlTMOorHvxqGpOoVrfb91i6iwxGI8m7zX_bmn8XA=.bab222eb-537e-4fdd-8b9f-d2412f0da36b@github.com>

On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:
> 
>  - Mark some tests with requiring packaged modules
>  - Correctly set packaged modules default
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Fix new line in jlink.properties
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>  - Only add runtime track files for linkable runtimes
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 131:

> 129:     public boolean equals(Object obj) {
> 130:         if (obj instanceof JRTArchive) {
> 131:             JRTArchive other = (JRTArchive)obj;

Cleanup for later, you can use pattern matching here and avoid the cast.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627798949

From pminborg at openjdk.org  Wed Jun  5 13:39:57 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Jun 2024 13:39:57 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <e2ypna3AumYuZ17RHAjCCvwDINMZLFAFUq9qATiZtAU=.f232b73e-0f01-42ef-85a5-66799a84b62a@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <68bP4OaEhjeBisrD5wDLvmOBykXE4J_UlxO9BcFSZl8=.455e75dd-1983-4989-92cf-9101c3ff1696@github.com>
 <RmVBj_5UwgheR-GF78Hf-0PcXMnEskhhOJCt5BoSfRc=.e91d44ce-8629-46b8-b26f-ee4017108f87@github.com>
 <e2ypna3AumYuZ17RHAjCCvwDINMZLFAFUq9qATiZtAU=.f232b73e-0f01-42ef-85a5-66799a84b62a@github.com>
Message-ID: <xO7_Ps9ijurfuxvXH2boY69b3-WTs45qNvX5KX3gD4o=.609c6e8b-9d47-4496-af7f-7630fc1bfd7d@github.com>

On Wed, 29 May 2024 15:20:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This was something that I tried and I observed a performance regression on the ARM platform that I was testing. From my understanding, `@Stable` tells the compiler to trust the contents of this field which is only given when the field holder is a known constant. This is generally true for cases like `Enums` but not usually for `Method`. 
>> 
>> 
>> Benchmark                         Mode  Cnt  Score   Error  Units
>> # Intel Skylake
>> MethodHashCode.benchmarkHashCode  avgt    5  1.113 ? 1.146  ns/op
>> # Arm Neoverse N1
>> MethodHashCode.benchmarkHashCode  avgt    5  3.204 ? 0.001  ns/op
>
> Interesting, don't know about hotspot internals so I can't diagnose the exact cause of this regression.

In order to be eligible for constant folding, the benchmark must declare the `Method hashCodeMethod;` as `static final`.

It is hard for me to understand why a `@Stable` annotation should have a detrimental performance impact on an instance field.

Can we see a benchmark on Arm Neoverse N1 with the field declared `@Stable` compared to not declared `@Stable`? Also, if the field is `static final`, how would it look like?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1627803876

From pminborg at openjdk.org  Wed Jun  5 13:43:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Jun 2024 13:43:59 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <xO7_Ps9ijurfuxvXH2boY69b3-WTs45qNvX5KX3gD4o=.609c6e8b-9d47-4496-af7f-7630fc1bfd7d@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <68bP4OaEhjeBisrD5wDLvmOBykXE4J_UlxO9BcFSZl8=.455e75dd-1983-4989-92cf-9101c3ff1696@github.com>
 <RmVBj_5UwgheR-GF78Hf-0PcXMnEskhhOJCt5BoSfRc=.e91d44ce-8629-46b8-b26f-ee4017108f87@github.com>
 <e2ypna3AumYuZ17RHAjCCvwDINMZLFAFUq9qATiZtAU=.f232b73e-0f01-42ef-85a5-66799a84b62a@github.com>
 <xO7_Ps9ijurfuxvXH2boY69b3-WTs45qNvX5KX3gD4o=.609c6e8b-9d47-4496-af7f-7630fc1bfd7d@github.com>
Message-ID: <-iZhTXSd9kx0Eg5DOq1bAfhCKapEWykLJfft8Te4rb0=.d87c8953-599e-4b47-bfb8-a93aa1ecf38f@github.com>

On Wed, 5 Jun 2024 13:37:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Interesting, don't know about hotspot internals so I can't diagnose the exact cause of this regression.
>
> In order to be eligible for constant folding, the benchmark must declare the `Method hashCodeMethod;` as `static final`.
> 
> It is hard for me to understand why a `@Stable` annotation should have a detrimental performance impact on an instance field.
> 
> Can we see a benchmark on Arm Neoverse N1 with the field declared `@Stable` compared to not declared `@Stable`? Also, if the field is `static final`, how would it look like?

As a note, If we would have access to the contemplated `StableValue` and `hash` was declared even as an _instance variable_ `StableValue<Integer>` in a regular class, then it would be trusted and would be eligible for constant folding due to the VM will have special rules for  fields of StableValue type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1627810415

From pminborg at openjdk.org  Wed Jun  5 13:48:01 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Jun 2024 13:48:01 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <-iZhTXSd9kx0Eg5DOq1bAfhCKapEWykLJfft8Te4rb0=.d87c8953-599e-4b47-bfb8-a93aa1ecf38f@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <68bP4OaEhjeBisrD5wDLvmOBykXE4J_UlxO9BcFSZl8=.455e75dd-1983-4989-92cf-9101c3ff1696@github.com>
 <RmVBj_5UwgheR-GF78Hf-0PcXMnEskhhOJCt5BoSfRc=.e91d44ce-8629-46b8-b26f-ee4017108f87@github.com>
 <e2ypna3AumYuZ17RHAjCCvwDINMZLFAFUq9qATiZtAU=.f232b73e-0f01-42ef-85a5-66799a84b62a@github.com>
 <xO7_Ps9ijurfuxvXH2boY69b3-WTs45qNvX5KX3gD4o=.609c6e8b-9d47-4496-af7f-7630fc1bfd7d@github.com>
 <-iZhTXSd9kx0Eg5DOq1bAfhCKapEWykLJfft8Te4rb0=.d87c8953-599e-4b47-bfb8-a93aa1ecf38f@github.com>
Message-ID: <sppH9ncvDF5_5dBBXP0hiDrhQzQb2EfoIQ3fANqrsow=.274e6dff-5d00-456f-acd4-e1c760d7f7d7@github.com>

On Wed, 5 Jun 2024 13:41:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> In order to be eligible for constant folding, the benchmark must declare the `Method hashCodeMethod;` as `static final`.
>> 
>> It is hard for me to understand why a `@Stable` annotation should have a detrimental performance impact on an instance field.
>> 
>> ~~Can we see a benchmark on Arm Neoverse N1 with the field declared `@Stable` compared to not declared `@Stable`? ~~ Also, if the field is `static final`, how would it look like?
>
> As a note, If we would have access to the contemplated `StableValue` and `hash` was declared even as an _instance variable_ `StableValue<Integer>` in a regular class, then it would be trusted and would be eligible for constant folding due to the VM will have special rules for  fields of StableValue type.

Ahh. There was a benchmark in the initial message. Sorry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1627818122

From alanb at openjdk.org  Wed Jun  5 13:50:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 13:50:13 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
Message-ID: <sXexuq0XQn8Jc1tN4wUP8WUiHIAmmAuNXpufITrBDqY=.4ace66b5-7ed7-4509-ab6d-dc6e830be13f@github.com>

On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:
> 
>  - Mark some tests with requiring packaged modules
>  - Correctly set packaged modules default
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Fix new line in jlink.properties
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>  - Only add runtime track files for linkable runtimes
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 119:

> 117: 
> 118: err.runtime.link.not.linkable.runtime=The current run-time image does not support run-time linking.
> 119: err.runtime.link.jdk.jlink.prohibited=Including jdk.jlink module for run-time image based links is not allowed.

The phrase "run-time image based links" in this error message (and in the value of err.runtime.link.packaged.mods) is a bit unusual. As developers will see this message then maybe it could say that this jlink in the current run-time image doesn't contain packaged modules and cannot be used to create another run-time image that include the jdk.jlink module.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627820124

From alanb at openjdk.org  Wed Jun  5 13:57:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 13:57:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
Message-ID: <wdZDRuPUFv9yMqNKr2Q4z1ZOv8cBbZyA3DKyknyf2qY=.2368d7c6-4ad0-4cc2-9889-7d995ab828c1@github.com>

On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:
> 
>  - Mark some tests with requiring packaged modules
>  - Correctly set packaged modules default
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Fix new line in jlink.properties
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>  - Only add runtime track files for linkable runtimes
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourceDiff.java line 39:

> 37: 
> 38: /**
> 39:  * Class representing a difference between a jimage resource. For all intents

A difference between a jimage resource and ???  Someone might wonder about that.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourceDiff.java line 215:

> 213:             }
> 214:         } catch (IOException e) {
> 215:             e.printStackTrace();

Is this IOException swallowed by jlink when not running with the debugging option? I'm wondering about the printStackTrace here.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourcePoolReader.java line 33:

> 31: import jdk.tools.jlink.plugin.ResourcePool;
> 32: 
> 33: @SuppressWarnings("try")

Is this needed?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourcePoolReader.java line 49:

> 47:     @Override
> 48:     public List<String> getEntries() {
> 49:         return pool.entries().map(a -> a.path()).collect(Collectors.toList());

I think you can use toList() here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627830148
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627833211
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627828480
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1627828158

From alanb at openjdk.org  Wed Jun  5 14:38:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Jun 2024 14:38:59 GMT
Subject: RFR: 8312436: CompletableFuture never completes when
 'Throwable.toString()' method throws Exception
In-Reply-To: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
References: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
Message-ID: <Kf_wxwyTYMdykwGqyIZIUrxhTG49ky8MPrL0H_rAqKY=.8741621d-a7d8-448e-a0cf-632584d88884@github.com>

On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.
> 
> Nevertheless, there is some things we can do, as witnessed in this PR.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18988#pullrequestreview-2099417935

From vklang at openjdk.org  Wed Jun  5 14:43:03 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 5 Jun 2024 14:43:03 GMT
Subject: Integrated: 8312436: CompletableFuture never completes when
 'Throwable.toString()' method throws Exception
In-Reply-To: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
References: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
Message-ID: <tSkmzyuAtJCN4kDo2y2qcP8xb1G0C3cJXXG787N_BHw=.de49a264-cff0-4fbd-b244-4b76a96bb1cb@github.com>

On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.
> 
> Nevertheless, there is some things we can do, as witnessed in this PR.

This pull request has now been integrated.

Changeset: 326dbb1b
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/326dbb1b139dd1ec1b8605339b91697cdf49da9a
Stats:     63 lines in 2 files changed: 52 ins; 2 del; 9 mod

8312436: CompletableFuture never completes when 'Throwable.toString()' method throws Exception

Reviewed-by: alanb

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

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

From asemenyuk at openjdk.org  Wed Jun  5 14:56:02 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Jun 2024 14:56:02 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
 [v4]
In-Reply-To: <sjDT-FtOZJJm0hf7ckgTqiSWpbIV9AVzXfZNjDLFcos=.5e797275-f32c-49e7-b5f9-0e3e7408432d@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <xbNenP7KZJS9jQYFOnMd_rCNOWmcUhneP5oYCX1MH2I=.75c0efc3-fa74-4e88-814d-071dbe6ae93e@github.com>
 <sjDT-FtOZJJm0hf7ckgTqiSWpbIV9AVzXfZNjDLFcos=.5e797275-f32c-49e7-b5f9-0e3e7408432d@github.com>
Message-ID: <PW33nrTTqM99c4qzvrzG-lVanDURdtoBM2Zfiiafig4=.f13a9d74-838c-4301-9f4a-237114fe6eff@github.com>

On Wed, 5 Jun 2024 04:20:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - WixSourceConverter#applyTo should do what OverridableResource#saveToFile() does: create parent directory and replace output file if it exists.
>>  - Fix issue with overwriting custom l10n file in the resource directory. All WiX source files from the resource directory should be copied to jpackage work directory before running wxi tools. jpackage should not change files in the resource directory.
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 44:
> 
>> 42: resource.installdirnotemptydlg-wix-file=Not empty install directory dialog WiX project file
>> 43: resource.launcher-as-service-wix-file=Service installer WiX project file
>> 44: resource.wix-src-conv=XSLT stylesheet converting WiX sources from WiX v3 to WiX v4 format
> 
> WiX v4 -> WiX v4/v5

The converter does exactly as described, it converts WiX v3 sources into WiX v4 **format** that can be used with WiX v4 and WiX v5. So I believe the description should remain unchanged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1627942141

From duke at openjdk.org  Wed Jun  5 14:59:00 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 5 Jun 2024 14:59:00 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v2]
In-Reply-To: <OoFXXPNbdWXcwXwloq28EK5chYINYYEN6nLLM81Pdwo=.8cba479e-ad7f-4f78-8d89-304ea61f7434@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <ZRFgnMzbNR_9odHGXWQrPWFaNmHq6MJPd5Q1GSM3ANA=.f4de435c-b62f-4671-9b76-c3993fc69309@github.com>
 <HDp4qCud6rEnlGBPnfnKbL34Fi24xyJd3q5fMpr81yk=.f9c5181a-8d5e-4995-8d10-c913d53a716d@github.com>
 <OoFXXPNbdWXcwXwloq28EK5chYINYYEN6nLLM81Pdwo=.8cba479e-ad7f-4f78-8d89-304ea61f7434@github.com>
Message-ID: <PnqP1oYl3XPasxoTTBUla6Qqh1r-tyZ6a2b0BGlVbe4=.8e2c4622-afb4-4d92-b729-23a1faf4b0ef@github.com>

On Tue, 4 Jun 2024 19:58:41 GMT, jengebr <duke at openjdk.org> wrote:

>> Agreed. You might as well be consistent with this so that no one will need to re-address if some application does zillions of clones of empty lists.
>
> Sorry, I crossed wires with @DougLea 's comment, will add `clone`.

`clone()` performs a shallow copy, so there is currently no `Object[]` allocated and therefore nothing to optimize.  I don't think there's any work to do here.

@DougLea @viktorklang-ora can you confirm?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1627947686

From darcy at openjdk.org  Wed Jun  5 15:35:18 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Jun 2024 15:35:18 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v12]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <EJ9-O-KsZUomvRpjLed9qyQq3-Pi1JEsdYaocV7iXwY=.38666128-76c1-407a-98c4-634be80f6ec0@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Update copyright.
 - Updated problem list after bug fix.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Temporarily problem list java.lang.instrument tests until jar generation is fixed.
 - Merge branch 'master' into JDK-8330188
 - Update symbol files for JDK 23 build 25.
 - Correct release year.
 - Merge branch 'master' into JDK-8330188
 - Add symbol files current with JDK 23 build 24.
 - ... and 13 more: https://git.openjdk.org/jdk/compare/4369856c...f4a5026b

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

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=11
  Stats: 2083 lines in 50 files changed: 2019 ins; 7 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

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

From asotona at openjdk.org  Wed Jun  5 15:36:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Jun 2024 15:36:08 GMT
Subject: Integrated: 8332457: Examine startup overheads from JDK-8294961
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <3KhVxR6fDkAmIz1GOzh5sU_HaxfgOHz4r3thIUutGVc=.98ba1c26-853f-4ce2-9c4a-58562d4a6652@github.com>

On Mon, 27 May 2024 09:01:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: d85b0ca5
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d85b0ca5cdc1820a886c46bf555b2051fed7f167
Stats:     500 lines in 9 files changed: 174 ins; 197 del; 129 mod

8332457: Examine startup overheads from JDK-8294961
8229959: Convert proxy class to use constant dynamic

Reviewed-by: liach, redestad

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

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

From lancea at openjdk.org  Wed Jun  5 15:40:02 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 5 Jun 2024 15:40:02 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE [v4]
In-Reply-To: <9UlaEbxrgbKs_KSP9pbE84Ws41jEDmEPZVEm3VjZbCc=.4abfbe92-731c-4014-97fc-c5e3a1e9878b@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
 <9UlaEbxrgbKs_KSP9pbE84Ws41jEDmEPZVEm3VjZbCc=.4abfbe92-731c-4014-97fc-c5e3a1e9878b@github.com>
Message-ID: <_0bu3ts3mntxSur9c7vRLEfiYfS7K-A9OSR1u1qtV9g=.660eeaa1-71a8-4ea2-8b43-322abb98d619@github.com>

On Wed, 5 Jun 2024 12:14:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
>> 
>> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
>> 
>> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
>> 
>> I'll open a CSR for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify blocking semantic

latest update looks good.  Thank you and Alan for the additional wordsmithing

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19515#pullrequestreview-2099574770

From asemenyuk at openjdk.org  Wed Jun  5 15:41:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Jun 2024 15:41:59 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
 [v4]
In-Reply-To: <-o573bkx_xWBRkJS3IWGlevuqgWGL-4EyAxCexUvGUQ=.32f6db30-d90b-4be9-987b-7112349f11d4@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <-o573bkx_xWBRkJS3IWGlevuqgWGL-4EyAxCexUvGUQ=.32f6db30-d90b-4be9-987b-7112349f11d4@github.com>
Message-ID: <oiM06QhbN7s4BApzbli6kJrt-c_IBxg9Um5U4d3gJ0I=.314ba19c-11e9-4bae-bc56-804bdf2a341a@github.com>

On Tue, 4 Jun 2024 01:20:15 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Do we need to handle default case for unknown wix type? In same cases you have default -> throw new IllegalArgumentException(); and in some you do not have.

Good catch. I'll update the code to make `switch(wixVersion) ...`  expressions consistent as follows:

switch (wixVersion) {
  case Wix3 -> {}
  case WiX4 -> {}
  default -> throw new IllegalArgumentException();
}

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2150382290

From iris at openjdk.org  Wed Jun  5 15:45:05 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 5 Jun 2024 15:45:05 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v12]
In-Reply-To: <EJ9-O-KsZUomvRpjLed9qyQq3-Pi1JEsdYaocV7iXwY=.38666128-76c1-407a-98c4-634be80f6ec0@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <EJ9-O-KsZUomvRpjLed9qyQq3-Pi1JEsdYaocV7iXwY=.38666128-76c1-407a-98c4-634be80f6ec0@github.com>
Message-ID: <oPl5E-TfDPqOthDQzF-5rsY878yBGcWJNe4oz-OxUVo=.ebb4481c-f404-4b6d-9aef-c14bfd6d654a@github.com>

On Wed, 5 Jun 2024 15:35:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Update copyright.
>  - Updated problem list after bug fix.
>  - Merge branch 'master' into JDK-8330188
>  - Merge branch 'master' into JDK-8330188
>  - Temporarily problem list java.lang.instrument tests until jar generation is fixed.
>  - Merge branch 'master' into JDK-8330188
>  - Update symbol files for JDK 23 build 25.
>  - Correct release year.
>  - Merge branch 'master' into JDK-8330188
>  - Add symbol files current with JDK 23 build 24.
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/4369856c...f4a5026b

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2099585754

From asemenyuk at openjdk.org  Wed Jun  5 15:49:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Jun 2024 15:49:03 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
 [v4]
In-Reply-To: <sjDT-FtOZJJm0hf7ckgTqiSWpbIV9AVzXfZNjDLFcos=.5e797275-f32c-49e7-b5f9-0e3e7408432d@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <xbNenP7KZJS9jQYFOnMd_rCNOWmcUhneP5oYCX1MH2I=.75c0efc3-fa74-4e88-814d-071dbe6ae93e@github.com>
 <sjDT-FtOZJJm0hf7ckgTqiSWpbIV9AVzXfZNjDLFcos=.5e797275-f32c-49e7-b5f9-0e3e7408432d@github.com>
Message-ID: <Xh3Yw6N0OH42_aNDYKRd8oy8A0AbR7vTZLyQtUx4IlE=.7732aaf1-3596-4281-9dbc-a815172e451f@github.com>

On Wed, 5 Jun 2024 03:54:46 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - WixSourceConverter#applyTo should do what OverridableResource#saveToFile() does: create parent directory and replace output file if it exists.
>>  - Fix issue with overwriting custom l10n file in the resource directory. All WiX source files from the resource directory should be copied to jpackage work directory before running wxi tools. jpackage should not change files in the resource directory.
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java line 157:
> 
>> 155: 
>> 156:     @Override
>> 157:     List<String> getLoggableWixFeatures() {
> 
> Maybe I am missing something, but is it used? I only see call to base class `WixFragmentBuilder::getLoggableWixFeatures`.

`WixFragmentBuilder::getLoggableWixFeatures` is equivalent to:

new Function<WixFragmentBuilder, List<String>>() {
  public List<String> apply(WixFragmentBuilder obj) {
    return obj.getLoggableWixFeatures();
  }
}


An overridden WixAppImageFragmentBuilder#getLoggableWixFeatures() method will be called when WixAppImageFragmentBuilder instance is given.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1628020809

From jpai at openjdk.org  Wed Jun  5 16:00:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 16:00:04 GMT
Subject: RFR: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE [v4]
In-Reply-To: <9UlaEbxrgbKs_KSP9pbE84Ws41jEDmEPZVEm3VjZbCc=.4abfbe92-731c-4014-97fc-c5e3a1e9878b@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
 <9UlaEbxrgbKs_KSP9pbE84Ws41jEDmEPZVEm3VjZbCc=.4abfbe92-731c-4014-97fc-c5e3a1e9878b@github.com>
Message-ID: <Wj1U8K8aeYABKCV6qBuxpZCaJXU7k_P9mepn_6vrctk=.8b8e2244-d6a2-4d23-b477-385e01e9424b@github.com>

On Wed, 5 Jun 2024 12:14:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
>> 
>> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
>> 
>> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
>> 
>> I'll open a CSR for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify blocking semantic

Thank you all for the reviews and the inputs to the specification text. The CSR has been approved, so I'll integrate this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19515#issuecomment-2150413847

From jpai at openjdk.org  Wed Jun  5 16:00:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Jun 2024 16:00:05 GMT
Subject: Integrated: 8206447: InflaterInputStream.skip receives long but it's
 limited to Integer.MAX_VALUE
In-Reply-To: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
References: <BV6kUwvF7M1acGNVf9AUmzreT1WPXTWlG8ZeXds_p9A=.d4ab288b-623f-4924-ab1b-f2234101e23e@github.com>
Message-ID: <pDZnmlCamkmay81psTTN3292ChNXPpoe0J4HC5CGl1U=.fcec8fcd-c078-4ea2-8e0e-6eec251af505@github.com>

On Mon, 3 Jun 2024 05:06:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which updates the API specification of `java.util.zip.InflaterInputStream.skip()` method to match its current implementation?
> 
> `InflaterInputStream.skip()`, just like `DeflaterInputStream.skip()`, takes a `long` value `n` representing the number of bytes to skip. When a value greater than `Integer.MAX_VALUE` is passed to this `InflaterInputStream.skip()` method, the current implementation in that method only skips at most `Integer.MAX_VALUE` bytes. `DeflaterInputStream.skip()` too has the same behaviour. However, in the case of `DeflaterInputStream.skip()`, this semantic is clearly noted in that method's API documentation. `InflaterInputStream.skip()` currently doesn't specify this behaviour.
> 
> The commit in this PR updates the `InflaterInputStream.skip()` to specify the current implementation.
> 
> I'll open a CSR for this change.

This pull request has now been integrated.

Changeset: d7d1afb0
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7d1afb0a84e771870e9f43e08c4a63c8fdccdd9
Stats:     21 lines in 2 files changed: 11 ins; 2 del; 8 mod

8206447: InflaterInputStream.skip receives long but it's limited to Integer.MAX_VALUE

Reviewed-by: lancea, alanb

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

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

From sgehwolf at openjdk.org  Wed Jun  5 16:54:10 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Jun 2024 16:54:10 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <wdZDRuPUFv9yMqNKr2Q4z1ZOv8cBbZyA3DKyknyf2qY=.2368d7c6-4ad0-4cc2-9889-7d995ab828c1@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
 <wdZDRuPUFv9yMqNKr2Q4z1ZOv8cBbZyA3DKyknyf2qY=.2368d7c6-4ad0-4cc2-9889-7d995ab828c1@github.com>
Message-ID: <NFjlbN83PC1Sitil1SodhpVST7s_DPILoGnHdAqqDDw=.43398cef-b9df-4f7a-ac2e-1bcec78bef85@github.com>

On Wed, 5 Jun 2024 13:52:43 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 113 commits:
>> 
>>  - Mark some tests with requiring packaged modules
>>  - Correctly set packaged modules default
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Fix new line in jlink.properties
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>>  - Only add runtime track files for linkable runtimes
>>  - Generate the runtime image link diff at jlink time
>>    
>>    But only do that once the plugin-pipeline has run. The generation is
>>    enabled with the hidden option '--generate-linkable-runtime' and
>>    the resource pools available at jlink time are being used to generate
>>    the diff.
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourceDiff.java line 39:
> 
>> 37: 
>> 38: /**
>> 39:  * Class representing a difference between a jimage resource. For all intents
> 
> A difference between a jimage resource and ???  Someone might wonder about that.

I've updated the comment a bit to make it clearer.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourcePoolReader.java line 33:
> 
>> 31: import jdk.tools.jlink.plugin.ResourcePool;
>> 32: 
>> 33: @SuppressWarnings("try")
> 
> Is this needed?

Yes. Otherwise this warning is produced:


src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourcePoolReader.java:32: warning: [try] auto-closeable resource ResourcePoolReader has a member method close() that could throw InterruptedException
public class ResourcePoolReader implements ImageResource {
       ^
error: warnings found and -Werror specified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1628112307
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1628111856

From sgehwolf at openjdk.org  Wed Jun  5 16:57:12 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Jun 2024 16:57:12 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <wdZDRuPUFv9yMqNKr2Q4z1ZOv8cBbZyA3DKyknyf2qY=.2368d7c6-4ad0-4cc2-9889-7d995ab828c1@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
 <wdZDRuPUFv9yMqNKr2Q4z1ZOv8cBbZyA3DKyknyf2qY=.2368d7c6-4ad0-4cc2-9889-7d995ab828c1@github.com>
Message-ID: <soeQx6yqiu8L1JI0dsKupSoEWCCDm1He2P3cNSR2duw=.8ec77fe7-b7af-4004-bac6-1148bf81ce97@github.com>

On Wed, 5 Jun 2024 13:54: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 113 commits:
>> 
>>  - Mark some tests with requiring packaged modules
>>  - Correctly set packaged modules default
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Fix new line in jlink.properties
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>>  - Only add runtime track files for linkable runtimes
>>  - Generate the runtime image link diff at jlink time
>>    
>>    But only do that once the plugin-pipeline has run. The generation is
>>    enabled with the hidden option '--generate-linkable-runtime' and
>>    the resource pools available at jlink time are being used to generate
>>    the diff.
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourceDiff.java line 215:
> 
>> 213:             }
>> 214:         } catch (IOException e) {
>> 215:             e.printStackTrace();
> 
> Is this IOException swallowed by jlink when not running with the debugging option? I'm wondering about the printStackTrace here.

I think this is a left-over of some devevelopment work. Removed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1628115979

From naoto at openjdk.org  Wed Jun  5 17:09:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Jun 2024 17:09:57 GMT
Subject: RFR: 8333456: CompactNumberFormat integer parsing fails when
 string has no suffix [v2]
In-Reply-To: <i6BMkj_B2Yy57kkdaAqoFsPj1wtDUsxfvePZtmfYtlc=.9e77c4bd-1b7e-4a4e-bf96-598e6448335d@github.com>
References: <Yz_-c-Nr6p86TFltSwsjZyjOUh_k-xEFo-s52Fczkew=.4357fab6-4ba7-4051-be91-3c9245426008@github.com>
 <i6BMkj_B2Yy57kkdaAqoFsPj1wtDUsxfvePZtmfYtlc=.9e77c4bd-1b7e-4a4e-bf96-598e6448335d@github.com>
Message-ID: <NcKv9S_sj07j25AoFPkt5sR3aUhP2vzeA8lrKnRzq8k=.3471be59-96f1-49fe-a448-4588e481cc6c@github.com>

On Tue, 4 Jun 2024 20:43:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which handles incorrect CompactNumberFormat integer only parsing when there is no suffix.
>> 
>> See the following snippet,
>> 
>> 
>> var fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT)
>> fmt.setParseIntegerOnly(true)
>> fmt.parse("5K") // returns 5000
>> fmt.parse("50.00") // returns 50
>> fmt.parse("5") // unexpectedly throws StringIndexOutOfBoundsException 
>> fmt.parse("5 ") // returns 5
>> 
>> 
>> Within the `parse` method, there is code that advances `position` past the fractional portion to find the suffix when `parseIntegerOnly()` is true. However, if a valid string input is given with no suffix, `DecimalFormat.subparseNumber()` will fully iterate through the string and `position` will be equal to the length of the string, throwing StringIndexOutOfBoundsException when `charAt` is invoked (line 1740).
>> 
>> We should check to make sure position does not exceed the string length before deciding to check for a decimal symbol.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move test to existing test file

LGTM. Thanks for the changes.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19533#pullrequestreview-2099786378

From naoto at openjdk.org  Wed Jun  5 17:16:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Jun 2024 17:16:56 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization [v3]
In-Reply-To: <ULRi5T5ytMJO2a3N65np3ePCpnldssTY_wDGxdyoDdg=.327269fd-9961-4920-be99-63b0211fd74e@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
 <ULRi5T5ytMJO2a3N65np3ePCpnldssTY_wDGxdyoDdg=.327269fd-9961-4920-be99-63b0211fd74e@github.com>
Message-ID: <VXNACBgyDDo6BPzTXiaKOYbwesDagw_o1myy5B0lXU4=.a7435c32-c894-4286-994a-b99c744a54da@github.com>

On Wed, 5 Jun 2024 12:36:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider these two programs:
>> 
>> 
>> public class SystemPrint {
>>     public static void main(String... args) {
>>         System.err.println("Hello!");
>>     }
>> }
>> 
>> and:
>> 
>> public class IOPrint {
>>     public static void main(String... args) {
>>         java.io.IO.println("Hello!");
>>     }
>> }
>> 
>> 
>> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
>> 
>> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
>> 
>> For example, on my computer:
>> 
>> $ time java -classpath /tmp SystemPrint 
>> Hello!
>> 
>> real    0m0,035s
>> user    0m0,019s
>> sys     0m0,019s
>> 
>> $ time java -classpath /tmp --enable-preview IOPrint 
>> Hello!
>> 
>> real    0m0,165s
>> user    0m0,324s
>> sys     0m0,042s
>> 
>> 
>> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
>> 
>> With this patch, I can get timing like this:
>> 
>> $ time java --enable-preview -classpath /tmp/ IOPrint 
>> Hello!
>> 
>> real    0m0,051s
>> user    0m0,038s
>> sys     0m0,020s
>> 
>> 
>> which seems much more acceptable.
>> 
>> There is also #19467, which may reduce the time further.
>> 
>> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correctly reflecting review feedback

LGTM. Thanks for the changes.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19479#pullrequestreview-2099801902

From sgehwolf at openjdk.org  Wed Jun  5 17:21:12 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Jun 2024 17:21:12 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <sXexuq0XQn8Jc1tN4wUP8WUiHIAmmAuNXpufITrBDqY=.4ace66b5-7ed7-4509-ab6d-dc6e830be13f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
 <sXexuq0XQn8Jc1tN4wUP8WUiHIAmmAuNXpufITrBDqY=.4ace66b5-7ed7-4509-ab6d-dc6e830be13f@github.com>
Message-ID: <ndPBQM-8BNCYRTxGfw5e-QptJlRKZRTYMYS0HHIWn8U=.9736cf1f-0a9a-4ba8-ba07-a3f1ff454551@github.com>

On Wed, 5 Jun 2024 13:46:59 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 113 commits:
>> 
>>  - Mark some tests with requiring packaged modules
>>  - Correctly set packaged modules default
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Fix new line in jlink.properties
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>>  - Only add runtime track files for linkable runtimes
>>  - Generate the runtime image link diff at jlink time
>>    
>>    But only do that once the plugin-pipeline has run. The generation is
>>    enabled with the hidden option '--generate-linkable-runtime' and
>>    the resource pools available at jlink time are being used to generate
>>    the diff.
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 119:
> 
>> 117: 
>> 118: err.runtime.link.not.linkable.runtime=The current run-time image does not support run-time linking.
>> 119: err.runtime.link.jdk.jlink.prohibited=Including jdk.jlink module for run-time image based links is not allowed.
> 
> The phrase "run-time image based links" in this error message (and in the value of err.runtime.link.packaged.mods) is a bit unusual. As developers will see this message then maybe it could say that this jlink in the current run-time image doesn't contain packaged modules and cannot be used to create another run-time image that include the jdk.jlink module.

I've used alternative phrasing. Hopefully better now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1628146154

From jlahoda at openjdk.org  Wed Jun  5 17:23:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Jun 2024 17:23:02 GMT
Subject: Integrated: 8333086: Using Console.println is unnecessarily slow due
 to JLine initalization
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <fydIIdPjQWj9UO6r7Gg077GfmupsjYAp_8YfwuqTjLI=.f6e5a5b2-3f60-4121-93de-f6b843b83124@github.com>

On Thu, 30 May 2024 13:50:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

This pull request has now been integrated.

Changeset: f7dbb98f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7dbb98fe69eb98f8544577d81550b4fd817864b
Stats:     226 lines in 2 files changed: 213 ins; 1 del; 12 mod

8333086: Using Console.println is unnecessarily slow due to JLine initalization

Reviewed-by: asotona, naoto

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

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

From sgehwolf at openjdk.org  Wed Jun  5 17:31:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Jun 2024 17:31:45 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v30]
In-Reply-To: <pBWOHFwswl6uCaY44BZwzN9Ta4ZBscTqHF8FFGF8RJE=.da6aef0c-1ab4-4752-959d-f4ab2b08ec14@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <aRk5UKgmkiEKzBKmUYSINbRbA2z9kEpZ7rvxlF4RXJA=.46d77ce2-8a85-41a2-97c2-c1c5071ba115@github.com>
 <pBWOHFwswl6uCaY44BZwzN9Ta4ZBscTqHF8FFGF8RJE=.da6aef0c-1ab4-4752-959d-f4ab2b08ec14@github.com>
Message-ID: <7fLmkNjG530Uyw1huywfUiSRPtpiWuJRWmEdlJqiOTs=.0add5d71-c32e-47fa-9d71-1e00772bb50a@github.com>

On Wed, 5 Jun 2024 13:21:20 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 113 commits:
>> 
>>  - Mark some tests with requiring packaged modules
>>  - Correctly set packaged modules default
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Fix new line in jlink.properties
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>>  - Only add runtime track files for linkable runtimes
>>  - Generate the runtime image link diff at jlink time
>>    
>>    But only do that once the plugin-pipeline has run. The generation is
>>    enabled with the hidden option '--generate-linkable-runtime' and
>>    the resource pools available at jlink time are being used to generate
>>    the diff.
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - ... and 103 more: https://git.openjdk.org/jdk/compare/64bbae75...0eb1e48d
>
>> [5fef297](https://github.com/openjdk/jdk/commit/5fef297ba999963d60452f098193d2cba33a941b) implements this.
> 
> I think it was surprising that --enable-runtime-link-image still included the packaged modules so thanks for taking the feedback on this point.

Thanks for the review, @AlanBateman! Updates pushed.

> test/jdk/tools/lib/tests/JImageHelper.java line 38:
> 
>> 36:  * JDK Modular image iterator
>> 37:  */
>> 38: public class JImageHelper {
> 
> This is only usable in tests that use `@modules` to open jdk.internal.jimage.*. It might be better  co-locate this with the jlink tests for now. It may be that we do have test infra structure for jimage in the future but starting out with the supporting test lib in the jlink test tree should be okay.

Sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2150589379
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1628156069

From sgehwolf at openjdk.org  Wed Jun  5 17:31:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Jun 2024 17:31:44 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v31]
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: <XPFeBJ4pD_uV4sMSb41lBYGV5gVRLe3JZnB9iuOUicM=.1bca239e-b52c-4b5e-b1f5-97b1d8635446@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 six additional commits since the last revision:

 - Move JImageHelper
 - Update wording on multi-hop.
 - Remove printStackTrace()
 - Fix comment. Stream.toList()
 - Use pattern matching for instanceof in JRTArchive::equals
 - Rename JLINK_PRODUCE_RUNTIME_LINK_JDK to JLINK_PRODUCE_LINKABLE_RUNTIME

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/0eb1e48d..b72648ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=29-30

  Stats: 28 lines in 10 files changed: 4 ins; 7 del; 17 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  Wed Jun  5 17:31:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Jun 2024 17:31:45 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <RDoTbqMFZmxaHTIzXrbjjUGb17GEV--wLyUz3dqM7kc=.727177ca-4ee1-45fd-be68-5ff200cc8d1f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>
 <6Qs2lLk0mJP0XdyH9ysENqcUT7P0KxsWU95fvRzA21Q=.09e661a3-d340-4fde-8030-77db94a2d353@github.com>
 <qiV8n1B2Y1ZZxiUhrtcFxIJuY3_H_fatkEi5u69GFnE=.0efcbe46-123e-4aa2-ad16-1decb65df142@github.com>
 <Ok6ibGzy9-6oa-c2Ie-lCulQXObKKkusvHP1QeR_WlE=.799e6764-c532-4647-b61c-e5a19aadbc1c@github.com>
 <IdAEjlP3knowCQ7zJCNpnbs-F_LneyOkbG5eFYlM2yo=.171ee88a-fb06-461e-9784-05394ca0b828@github.com>
 <RDoTbqMFZmxaHTIzXrbjjUGb17GEV--wLyUz3dqM7kc=.727177ca-4ee1-45fd-be68-5ff200cc8d1f@github.com>
Message-ID: <lJXuu3cmF8KFXYEbeQrvwqIY504xZLP6wAdYpah6aIA=.320961d0-df63-4140-8ea7-063cd8988c15@github.com>

On Tue, 4 Jun 2024 09:04:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> Does that proposal sound good?
>> 
>> That table is useful, I think it's right. No change to default behavior. If someone configures with --enable-runtime-image then they get a JDK run-time image that supports jlink (with some limitations) but is significantly small as it doesn't include the packaged modules.
>> 
>> I've read through most of the changes now. Overall I think it's looking good, just a few terminology and minor points that I'll add as comments.
>
>> Does that proposal sound good?
> 
> What you basically is saying is that the default value of `packaged-modules` should be `! runtime-link-image` (i.e. the inverse)?

@magicus @erikj79 Do you mind re-reviewing the build changes?

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

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

From asotona at openjdk.org  Wed Jun  5 17:32:14 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Jun 2024 17:32:14 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v14]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <tvEypYPXGZfoM1es0aO1UhlEj1vTg0X83djHx__oEQ0=.cd135114-c92c-4210-a4a0-499a2b2d57f9@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Attributes.java
 - fixed CodeBuilder use in j.l.invoke
 - Merge branch 'master' into JDK-8294960-invoke
 - Merge pull request #4 from cl4es/boxunbox_holder
   
   Only create box/unbox MethodRefEntries on request
 - Only create box/unbox MethodRefEntries on request
 - Merge pull request #3 from cl4es/minor_init_improvements
   
   Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
 - Remove stray MRE_LF_interpretWithArguments
 - Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
 - Deferred initialization of attributes map by moving into a holder class
   
   Co-authored-by: Claes Redestad <redestad at openjdk.org>
 - ... and 14 more: https://git.openjdk.org/jdk/compare/f73922b2...9360b0eb

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

Changes: https://git.openjdk.org/jdk/pull/17108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=13
  Stats: 2113 lines in 10 files changed: 422 ins; 861 del; 830 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

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

From naoto at openjdk.org  Wed Jun  5 17:48:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Jun 2024 17:48:25 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v9]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

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

  Removed unnecessary add-opens

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19315/files
  - new: https://git.openjdk.org/jdk/pull/19315/files/1c0ab8eb..c583c633

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

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

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

From almatvee at openjdk.org  Wed Jun  5 19:13:02 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 5 Jun 2024 19:13:02 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
 [v4]
In-Reply-To: <PW33nrTTqM99c4qzvrzG-lVanDURdtoBM2Zfiiafig4=.f13a9d74-838c-4301-9f4a-237114fe6eff@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <xbNenP7KZJS9jQYFOnMd_rCNOWmcUhneP5oYCX1MH2I=.75c0efc3-fa74-4e88-814d-071dbe6ae93e@github.com>
 <sjDT-FtOZJJm0hf7ckgTqiSWpbIV9AVzXfZNjDLFcos=.5e797275-f32c-49e7-b5f9-0e3e7408432d@github.com>
 <PW33nrTTqM99c4qzvrzG-lVanDURdtoBM2Zfiiafig4=.f13a9d74-838c-4301-9f4a-237114fe6eff@github.com>
Message-ID: <lIExZmUi1H5c5jlK3iga35hPtLUN0w33_d1hIWmEfQU=.5c64a152-e3a1-4abd-9b3d-143faf13a919@github.com>

On Wed, 5 Jun 2024 14:53:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 44:
>> 
>>> 42: resource.installdirnotemptydlg-wix-file=Not empty install directory dialog WiX project file
>>> 43: resource.launcher-as-service-wix-file=Service installer WiX project file
>>> 44: resource.wix-src-conv=XSLT stylesheet converting WiX sources from WiX v3 to WiX v4 format
>> 
>> WiX v4 -> WiX v4/v5
>
> The converter does exactly as described, it converts WiX v3 sources into WiX v4 **format** that can be used with WiX v4 and WiX v5. So I believe the description should remain unchanged.

Makes sense, but for `error.no-wix-tools` I think we should add v5, in case if users sees this message when only v5 is installed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19318#discussion_r1628308316

From jvernee at openjdk.org  Wed Jun  5 19:29:03 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Jun 2024 19:29:03 GMT
Subject: RFR: 8325984: 4 jcstress tests are failing in Tier6 4 times each
Message-ID: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>

These 4 tests were failing due to an incompatibility with jcstress. They were problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).

Now that jcstress has been updated (https://github.com/openjdk/jdk/pull/19332) with the relevant fix (https://github.com/openjdk/jcstress/pull/147), we can re-enable these tests.

Testing: I've verified that all 4 tests now pass on Linux-x64

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

Commit messages:
 - reenable jcstress tests

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

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

From almatvee at openjdk.org  Wed Jun  5 19:34:58 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 5 Jun 2024 19:34:58 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
In-Reply-To: <oBymKYvjhTzQUU-tqclGEF33jSagR0p926gyu2pFh_A=.847bd07c-70d8-45be-993a-65e7c16166d5@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <vl66GAw13fAcrDR25WKxWfgNoIcxfbF_YIYdSniGV7A=.779162bc-8465-454a-a256-33ad593a41b7@github.com>
 <MoUqz0AcISgDz8beoygDmh0hQt4360W1N1Cp3-eVIFo=.b524d976-4317-4743-9095-21b6b93dee90@github.com>
 <ul-uv7qR47M4w712xqL_58qj3Yv3pK2MooRhKpgOZKQ=.6d0232b7-4c24-4a22-a11b-d0e391bc6087@github.com>
 <oBymKYvjhTzQUU-tqclGEF33jSagR0p926gyu2pFh_A=.847bd07c-70d8-45be-993a-65e7c16166d5@github.com>
Message-ID: <zT-VP-bLc4fPJ-qN-dj2tKsV3ACFiiKiDfJF5cl6oso=.0c3000b3-0dbb-4faf-861e-c6fa39df3c2a@github.com>

On Tue, 4 Jun 2024 12:37:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> > I assume WiX5 will just work if installed instead of WiX4?
> 
> Correct.
> 
> > Do you think it will make sense to introduce Wix5 ToolsetType in case if we need to do something different between 4 and 5?
> 
> They claim WiX5 is backward compatible with WiX4, i.e. WiX4 code should work with WiX5 toolkit. So I don't see a reason to introduce Wix5 ToolsetType now.

jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed?

Do you know if there any benefits to use any features available in WiX5 if WiX5 toolkit is installed, instead of using only WiX4 features with WiX5 toolkit?

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2150809380

From lmesnik at openjdk.org  Wed Jun  5 21:11:18 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 5 Jun 2024 21:11:18 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed.
In-Reply-To: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
Message-ID: <txAYRh41YjA4x4TwsutpAhSFPDjrNDhd5vD4OgM74kQ=.6ffd5efd-764c-46d2-a834-a1e8acd27fec@github.com>

On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The solution proposed by Stefan K
> 
> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
> 
> The fix also move
> 'output = new OutputAnalyzer(this.process);'
> in method xrun() to be able to try to print them in waitFor is failed/interrupted.

Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/12751#issuecomment-1444608371

From erikj at openjdk.org  Wed Jun  5 21:25:23 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Jun 2024 21:25:23 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v31]
In-Reply-To: <XPFeBJ4pD_uV4sMSb41lBYGV5gVRLe3JZnB9iuOUicM=.1bca239e-b52c-4b5e-b1f5-97b1d8635446@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XPFeBJ4pD_uV4sMSb41lBYGV5gVRLe3JZnB9iuOUicM=.1bca239e-b52c-4b5e-b1f5-97b1d8635446@github.com>
Message-ID: <Qhy66MRbMr6oFRYdDnyDJu9x9UGVvJyj3s9j8ieOgfc=.7848bde2-fcb5-4432-9b1e-84ea505a1d0b@github.com>

On Wed, 5 Jun 2024 17:31:44 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 six additional commits since the last revision:
> 
>  - Move JImageHelper
>  - Update wording on multi-hop.
>  - Remove printStackTrace()
>  - Fix comment. Stream.toList()
>  - Use pattern matching for instanceof in JRTArchive::equals
>  - Rename JLINK_PRODUCE_RUNTIME_LINK_JDK to JLINK_PRODUCE_LINKABLE_RUNTIME

Build changes look good. Note that having a dynamic value for a DEFAULT makes it render the help text a bit weirdly. You may want to consider spelling out how the default changes in the help text. We have some of these issues with other configure options already though so no big deal I think.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2100313329

From joehw at openjdk.org  Thu Jun  6 00:04:44 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 6 Jun 2024 00:04:44 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v9]
In-Reply-To: <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>
Message-ID: <q7iNVQJfZaVQSRKN5NKHCXE16vf60p-JNIzMriv-xoE=.a295f608-b24b-4dc4-bd7b-780942c0676a@github.com>

On Wed, 5 Jun 2024 17:48:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary add-opens

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19315#pullrequestreview-2100486648

From jpai at openjdk.org  Thu Jun  6 06:14:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Jun 2024 06:14:44 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <68EGloykZoxV6IUFMEdsIas6LqJG0W4wjzfU-PmyTyY=.5a48c97b-7858-4321-804d-8e23fb9f0383@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
 <68EGloykZoxV6IUFMEdsIas6LqJG0W4wjzfU-PmyTyY=.5a48c97b-7858-4321-804d-8e23fb9f0383@github.com>
Message-ID: <sUrjOf5BHe3kPhtqd2CaTdVO2F2wXyTZMSgBl3CGW5Y=.924ca24c-1b7c-47e4-8dc1-f476525c757a@github.com>

On Thu, 9 May 2024 03:55:15 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Bug fix: add-exports was for wrong package
>
> Keep open. 
> 
> @JimLaskey it looks like you're the author of most of the surrounding code; can you please confirm that there's a rounding error in the existing implementation and that this PR will fix it? Or if the `git blame` logs are giving you more credit than you're willing to take, then could you please assign it to one ot the real authors or, if that's not possible, to someone else who's in a relevant role and can capable of reviewing and eventually merging this PR?

Hello Chris @Pr0methean, please keep this open. Some of us are checking if we can find someone experienced with this code to provide reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2151485139

From duke at openjdk.org  Thu Jun  6 06:45:45 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Jun 2024 06:45:45 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com>
Message-ID: <EoZKDKEF8v-9pVF0pnAAxRkl4qWuMljKqS0kvPYPGc8=.ea19b851-cfc2-41a9-a554-2efe116ac4db@github.com>

On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak <duke at openjdk.org> wrote:

>> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. 
>> 
>> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). 
>> 
>> Before:
>> 
>> Benchmark                         Mode  Cnt  Score   Error  Units
>> # Intel Skylake
>> MethodHashCode.benchmarkHashCode  avgt    5  1.843 ? 0.149  ns/op
>> # Arm Neoverse N1
>> MethodHashCode.benchmarkHashCode  avgt    5  2.363 ? 0.091  ns/op
>> 
>> 
>> 
>> After:
>> 
>> 
>> Benchmark                         Mode  Cnt  Score   Error  Units
>> # Intel Skylake
>> MethodHashCode.benchmarkHashCode  avgt    5  1.121 ? 1.189  ns/op
>> # Arm Neoverse N1
>> MethodHashCode.benchmarkHashCode  avgt    5  1.001 ? 0.001  ns/op
>
> Sean Gwizdak 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:
> 
>  - Remove trailing whitespace.
>  - Move hashCode benchmark into the newly created MethodBenchmark file
>  - Merge branch 'master' into method-hashcode-JDK-8332249
>  - Remove changes to JavaDoc per guidance.
>  - Fix whitespace issues pointed by the bot
>  - Micro-optimize Method.hashCode

src/java.base/share/classes/java/lang/reflect/Method.java line 392:

> 390:                 .hashCode();
> 391:         }
> 392:         return hc;

The?`hash`?field should probably somehow be?shared?with the?`Method.root`?instance, so?that it?doesn?t need to?be?recomputed when?different?code gets?a?`Method`?reference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1628860179

From duke at openjdk.org  Thu Jun  6 06:56:57 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Jun 2024 06:56:57 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v14]
In-Reply-To: <tvEypYPXGZfoM1es0aO1UhlEj1vTg0X83djHx__oEQ0=.cd135114-c92c-4210-a4a0-499a2b2d57f9@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <tvEypYPXGZfoM1es0aO1UhlEj1vTg0X83djHx__oEQ0=.cd135114-c92c-4210-a4a0-499a2b2d57f9@github.com>
Message-ID: <Re1F_qml5kyCjisxklFDdBHM-KZNVIJH6OF8yXkBjgc=.84eaa89e-7e9f-41aa-b546-5a16c34cdb46@github.com>

On Wed, 5 Jun 2024 17:32:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' into JDK-8294960-invoke
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>  - Merge branch 'master' into JDK-8294960-invoke
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/Attributes.java
>  - fixed CodeBuilder use in j.l.invoke
>  - Merge branch 'master' into JDK-8294960-invoke
>  - Merge pull request #4 from cl4es/boxunbox_holder
>    
>    Only create box/unbox MethodRefEntries on request
>  - Only create box/unbox MethodRefEntries on request
>  - Merge pull request #3 from cl4es/minor_init_improvements
>    
>    Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
>  - Remove stray MRE_LF_interpretWithArguments
>  - Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
>  - Deferred initialization of attributes map by moving into a holder class
>    
>    Co-authored-by: Claes Redestad <redestad at openjdk.org>
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/f73922b2...9360b0eb

These?can all?use `ReferenceClassDescImpl?::ofValidated(?)`:

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1259:

> 1257:             LONG_ARRAY_TYPE = referenceType(ClassDesc.ofDescriptor("[J")),
> 1258:             DOUBLE_ARRAY_TYPE = referenceType(ClassDesc.ofDescriptor("[D")),
> 1259:             FLOAT_ARRAY_TYPE = referenceType(ClassDesc.ofDescriptor("[F")),

Suggestion:

            INT_ARRAY_TYPE = referenceType(ReferenceClassDescImpl.ofValidated("[I")),
            BOOLEAN_ARRAY_TYPE = referenceType(ReferenceClassDescImpl.ofValidated("[Z")),
            BYTE_ARRAY_TYPE = referenceType(ReferenceClassDescImpl.ofValidated("[B")),
            CHAR_ARRAY_TYPE = referenceType(ReferenceClassDescImpl.ofValidated("[C")),
            SHORT_ARRAY_TYPE = referenceType(ReferenceClassDescImpl.ofValidated("[S")),
            LONG_ARRAY_TYPE = referenceType(ReferenceClassDescImpl.ofValidated("[J")),
            DOUBLE_ARRAY_TYPE = referenceType(ReferenceClassDescImpl.ofValidated("[D")),
            FLOAT_ARRAY_TYPE = referenceType(ReferenceClassDescImpl.ofValidated("[F")),

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1325:

> 1323: 
> 1324:         private static final ClassDesc CD_Cloneable = ClassDesc.ofDescriptor("Ljava/lang/Cloneable;");
> 1325:         private static final ClassDesc CD_Serializable = ClassDesc.ofDescriptor("Ljava/io/Serializable;");

Suggestion:

        private static final ClassDesc CD_Cloneable = ReferenceClassDescImpl.ofValidated("Ljava/lang/Cloneable;");
        private static final ClassDesc CD_Serializable = ReferenceClassDescImpl.ofValidated("Ljava/io/Serializable;");

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

PR Review: https://git.openjdk.org/jdk/pull/17108#pullrequestreview-2100944857
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1628870728
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1628871015

From duke at openjdk.org  Thu Jun  6 07:32:38 2024
From: duke at openjdk.org (MaxXing)
Date: Thu, 6 Jun 2024 07:32:38 GMT
Subject: RFR: 8333334: C2: Make result of `Node::dominates` more precise to
 enhance scalar replacement [v2]
In-Reply-To: <ARdyBPCqSDKlOM-u5kGZGqgOySxOT2MbznAiZaQMWx8=.21dfdc0c-1b92-4484-ad05-203e819a8569@github.com>
References: <ARdyBPCqSDKlOM-u5kGZGqgOySxOT2MbznAiZaQMWx8=.21dfdc0c-1b92-4484-ad05-203e819a8569@github.com>
Message-ID: <NSZeCeaaC3uEj-F9VJrs8ygO8q2GzJPg297XgUSrDBc=.b81a037d-a489-41fd-9fea-6c012c912449@github.com>

> This patch changes the algorithm of `Node::dominates` to make the result more precise, and allows the iterators of `ConcurrentHashMap` to be scalar replaced.
> 
> The previous algorithm will return a conservative result when encountering a dead control flow, and only try the first two input paths of a multi-input Region node, which may prevent the scalar replacement in some cases.
> 
> For example, with G1 GC enabled, C2 generates GC barriers for `ConcurrentHashMap` iteration operations at some early phases, and then eliminates them in a later IGVN, but `LoadNode` is also idealized in the same IGVN. This causes `LoadNode::Ideal` to see some dead barrier control flows, and refuse to split some instance field loads through Phi due to the conservative result of `Node::dominates`, and thus the scalar replacement can not be applied to iterators in the later macro elimination phase.
> 
> This patch allows `Node::dominates` to try other paths of the last multi-input Region node when the first path is dead, and makes `ConcurrentHashMap` iteration ~30% faster:
> 
> 
> Benchmark                            (nkeys)  Mode  Cnt        Score       Error  Units
> Maps.testConcurrentHashMapIterators    10000  avgt   15   414099.085 ? 33230.945  ns/op   # baseline
> Maps.testConcurrentHashMapIterators    10000  avgt   15   315490.281 ?  3037.056  ns/op   # patch
> 
> 
> Testing: tier1-4.

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

  Revert last commit, and push the `LoadNode` back to the worklist to wait for the dead code to be removed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19496/files
  - new: https://git.openjdk.org/jdk/pull/19496/files/e3330ece..b5db38dc

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

  Stats: 107 lines in 4 files changed: 39 ins; 34 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/19496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19496/head:pull/19496

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

From duke at openjdk.org  Thu Jun  6 07:32:39 2024
From: duke at openjdk.org (MaxXing)
Date: Thu, 6 Jun 2024 07:32:39 GMT
Subject: RFR: 8333334: C2: Make result of `Node::dominates` more precise to
 enhance scalar replacement [v2]
In-Reply-To: <HE_qrvaDSpsJIHRATebcLfERUFVNEM1gMpyVtIWf7w8=.cbe7aeab-1682-43c7-b4c3-b11ecf9d9131@github.com>
References: <ARdyBPCqSDKlOM-u5kGZGqgOySxOT2MbznAiZaQMWx8=.21dfdc0c-1b92-4484-ad05-203e819a8569@github.com>
 <HE_qrvaDSpsJIHRATebcLfERUFVNEM1gMpyVtIWf7w8=.cbe7aeab-1682-43c7-b4c3-b11ecf9d9131@github.com>
Message-ID: <4ch5Wd2SW4LvRD8lDW1UWuAnG0I50kwaXQB_1xW3eFQ=.1351c57b-cef7-4e2c-bf91-368dedf0a8b4@github.com>

On Wed, 5 Jun 2024 05:40:12 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> MaxXing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert last commit, and push the `LoadNode` back to the worklist to wait for the dead code to be removed.
>
> Impressive results! I haven't looked at the change yet but here are a few questions / requests:
> - Could you add a screenshot of the IR of the case you are describing?
> - Wouldn't it help to add the LoadNode back to the IGVN worklist and wait for the dead path to be removed?
> - Could you add an [IR framework](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/README.md) test that verifies that the optimization works as expected?
> 
> Thanks,
> Tobias

@TobiHartmann  Hi Tobias, thanks for your reply!

> Could you add a screenshot of the IR of the case you are describing?

Sure. Here's a simple example of iterating over the keys of `ConcurrentHashMap`:


public long sumMapKeys() {
  long sum = 0;
  Enumeration it = map.keys();
  while (it.hasMoreElements()) {
    sum += (Long) it.nextElement();
  }
  return sum;
}


And here's what `-XX:+PrintEscapeAnalysis -XX:+PrintEliminateAllocations` says:


JavaObject(6) NoEscape(NoEscape) [ 183F 189F 205F 196F 191F 179F 186F 202F 208F 233F 637F 1069F [ 104 109 ]]     92  Allocate  === 76 6 69 8 1 (90 89 24 1 1 1 22 1 1 43 77 87 ) [[ 93 94 95 102 103 104 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top, bool ) ConcurrentHashMap::keys @ bci:16 (line 2152) MyBenchmark::sumMapKeys @ bci:6 (line 105) !jvms: ConcurrentHashMap::keys @ bci:16 (line 2152) MyBenchmark::sumMapKeys @ bci:6 (line 105)
LocalVar(60) [ 92P [ 109 183b 189b 205b ]]    104  Proj  === 92  [[ 105 109 183 189 205 ]] #5 !jvms: ConcurrentHashMap::keys @ bci:16 (line 2152) MyBenchmark::sumMapKeys @ bci:6 (line 105)
LocalVar(103) [ 104 92P [ 196b 191b 179b 186b 202b 208b 233b 637b 1069b ]]    109  CheckCastPP  === 106 104  [[ 1801 1771 1754 1584 1503 1503 1490 1490 1466 1466 1451 1451 208 1393 1381 1381 179 179 186 186 208 196 191 191 196 202 202 228 297 233 233 1363 1363 1393 1321 1321 1311 637 637 648 648 998 988 1311 1301 477 477 487 487 497 497 569 1301 672 685 767 672 978 920 539 539 1069 1069 557 557 1128 569 631 1061 685 631 ]]  #java/util/concurrent/ConcurrentHashMap$KeyIterator (java/util/Iterator,java/util/Enumeration):NotNull:exact *  Oop:java/util/concurrent/ConcurrentHashMap$KeyIterator (java/util/Iterator,java/util/Enumeration):NotNull:exact * !jvms: ConcurrentHashMap::keys @ bci:16 (line 2152) MyBenchmark::sumMapKeys @ bci:6 (line 105)

NotScalar (Field load)  109  CheckCastPP  === 106 104  [[ 1801 1771 1754 1584 1503 1503 1490 1490 1128 569 1451 1451 208 1393 1381 1381 672 685 1069 1069 208 196 191 191 196 978 685 631 297 767 672 569 1301 1393 1321 1321 1311 557 557 631 1061 998 988 1311 1301 477 477 487 487 497 497 ]]  #java/util/concurrent/ConcurrentHashMap$KeyIterator (java/util/Iterator,java/util/Enumeration):NotNull:exact *,iid=92  Oop:java/util/concurrent/ConcurrentHashMap$KeyIterator (java/util/Iterator,java/util/Enumeration):NotNull:exact *,iid=92 !jvms: ConcurrentHashMap::keys @ bci:16 (line 2152) MyBenchmark::sumMapKeys @ bci:6 (line 105)
  >>>>  2186  LoadI  === _ 1973 191  [[ 2185 ]]  @java/util/concurrent/ConcurrentHashMap$Traverser+12 *, name=index, idx=9; #int !orig=[2178],[2171],[1373] !jvms: ConcurrentHashMap$Traverser::advance @ bci:51 (line 3369) ConcurrentHashMap$KeyIterator::next @ bci:28 (line 3468) ConcurrentHashMap$KeyIterator::nextElement @ bci:1 (line 3472) MyBenchmark::sumMapKeys @ bci:21 (line 107)


It shows that scalar replacement is aborted due to field load 2186:

<img width="909" alt="ir-diff" src="https://github.com/openjdk/jdk/assets/5129820/2e35769a-6e0f-4c8a-96ec-09923a5eb2c0">

As we can see its memory is a Phi, and it should be split by `LoadNode::split_through_phi` if its address `109 CheckCastPP` dominates the control flow of the Phi node `1330 Region`.

The control node of `CheckCastPP` is `106 Proj`:

<img width="360" alt="cast" src="https://github.com/openjdk/jdk/assets/5129820/ebf6f7f8-fcd1-4d83-8734-3f1864dcc946">

And it does dominate 1330, although not that obvious:

<img width="960" alt="cfg" src="https://github.com/openjdk/jdk/assets/5129820/e53b25de-c966-4f89-b30e-54ccc35f645b">

But `Node::dominates` think it doesn't because of the dead control flow.

> Wouldn't it help to add the LoadNode back to the IGVN worklist and wait for the dead path to be removed?

I tried to revert the change of main algorithm of `Node::dominates`, and just add some code to add the LoadNode back to the worklist if we met dead path. It works, still makes the iteration ~30% faster:


Benchmark                                  (nkeys)  Mode  Cnt        Score       Error  Units
Maps.testConcurrentHashMapIterators          10000  avgt   15   312720.415 ?  3255.500  ns/op


Thanks for pointing this out. I updated this PR, and the latest commit is passing test tier1-4.

> Could you add an [IR framework](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/README.md) test that verifies that the optimization works as expected?

I'm still trying to reproduce this case without using `ConcurrentHashMap`, but haven't found a way yet. Can I add an IR test that depends on `ConcurrentHashMap`? (It might need to be updated if the implementation of `ConcurrentHashMap` changes, I guess.)

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

PR Comment: https://git.openjdk.org/jdk/pull/19496#issuecomment-2151588662

From jpai at openjdk.org  Thu Jun  6 07:43:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Jun 2024 07:43:30 GMT
Subject: RFR: 8026127: Deflater/Inflater documentation
 incomplete/misleading [v2]
In-Reply-To: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>
References: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>
Message-ID: <V8fHQ8mHaWj82A4_zGNU7QmH9jGjM85FZHpMS0LAb28=.be5f52cc-c032-41f9-8c5b-6dde0b4f03e9@github.com>

> Can I please get a review of this doc-only change which proposes to improve the code snippet that's in `java.util.zip.Deflater` and `java.util.zip.Inflater` to better explain the usage of those classes? This addresses https://bugs.openjdk.org/browse/JDK-8026127.
> 
> The commit in the PR cleans up the snippet to correctly compress/decompress till the `Deflater` and `Inflater` are `finished()`.  Additionally, the snippet also shows that the `Deflater` and `Inflater` are expected to be closed when their usage it done, to release the resources held by those instances.
> 
> I've run `make docs-image` locally to verify that the generated snippet content as well as the link from `Inflater` work fine in the rendered javadoc HTML.

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

 - merge latest from master branch
 - 8026127: Deflater/Inflater documentation incomplete/misleading

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19507/files
  - new: https://git.openjdk.org/jdk/pull/19507/files/d8d86bcb..098212a6

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

  Stats: 19514 lines in 482 files changed: 12009 ins; 5593 del; 1912 mod
  Patch: https://git.openjdk.org/jdk/pull/19507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19507/head:pull/19507

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

From asotona at openjdk.org  Thu Jun  6 08:25:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 6 Jun 2024 08:25:15 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v15]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <F3I1iMTt3quotgHtudUI6oxr8xo0yHtfy4OtzRYhZSk=.754c4757-56b3-4dbf-bc13-9a2f46e203ee@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

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

  Apply suggestions from code review
  
  There are new possibilities with decoupled constants implementation, thank you for the reminder.
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/9360b0eb..019633bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=13-14

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

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

From asotona at openjdk.org  Thu Jun  6 08:34:21 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 6 Jun 2024 08:34:21 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v16]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <epb9_NQKrBu4pQGlbL9V6P-xySHjE4eZ_OLGmh-ggYo=.eb1c7669-0112-4f88-80a1-4c0c5edd2eb7@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

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

  fixed imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/019633bd..902b02ee

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

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

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

From duke at openjdk.org  Thu Jun  6 08:48:46 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 6 Jun 2024 08:48:46 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps
In-Reply-To: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
Message-ID: <qEjgRBlGQj-2an0tUBLggAp_HlxcU9pbIhCNZLUD6TA=.af905929-b96a-4b7e-9329-8aafea0b2d6d@github.com>

On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.

The?intermediate `Predicate`s and?`Supplier`s don?t?need to?be?fields, and?it?s?probably better for?them to?be?locals:

src/java.base/share/classes/java/util/stream/FindOps.java line 204:

> 202: 
> 203:             static final FindOp<?, ?> OP_FIND_ANY = new FindOp<>(false,
> 204:                     StreamShape.REFERENCE, Optional.empty(), IS_PRESENT, NEW);

Suggestion:

            static final TerminalOp<?, ?> OP_FIND_FIRST, OP_FIND_ANY;
            static {
                Predicate<Optional<Object>> isPresent = Optional::isPresent;
                Supplier<TerminalSink<Object, Optional<Object>>> newSink
                    = FindSink.OfRef::new;

                OP_FIND_FIRST = new FindOp<>(true, StreamShape.REFERENCE,
                    Optional.empty(), isPresent, newSink);

                OP_FIND_ANY = new FindOp<>(false, StreamShape.REFERENCE,
                    Optional.empty(), isPresent, newSink);
            }

src/java.base/share/classes/java/util/stream/FindOps.java line 227:

> 225:                     StreamShape.INT_VALUE, OptionalInt.empty(), IS_PRESENT, NEW);
> 226:             static final TerminalOp<Integer, OptionalInt> OP_FIND_ANY = new FindOp<>(false,
> 227:                     StreamShape.INT_VALUE, OptionalInt.empty(), IS_PRESENT, NEW);

Suggestion:

            static final TerminalOp<Integer, OptionalInt> OP_FIND_FIRST, OP_FIND_ANY;
            static {
                Predicate<OptionalInt> isPresent = OptionalInt::isPresent;
                Supplier<TerminalSink<Integer, OptionalInt> newSink
                    = FindSink.OfInt::new;

                OP_FIND_FIRST = new FindOp<>(true, StreamShape.INT_VALUE,
                    OptionalInt.empty(), isPresent, newSink);

                OP_FIND_ANY = new FindOp<>(false, StreamShape.INT_VALUE,
                    OptionalInt.empty(), isPresent, newSink);
            }

src/java.base/share/classes/java/util/stream/FindOps.java line 250:

> 248:                     StreamShape.LONG_VALUE, OptionalLong.empty(), IS_PRESENT, NEW);
> 249:             static final TerminalOp<Long, OptionalLong> OP_FIND_ANY = new FindOp<>(false,
> 250:                     StreamShape.LONG_VALUE, OptionalLong.empty(), IS_PRESENT, NEW);

Suggestion:

            static final TerminalOp<Long, OptionalLong> OP_FIND_FIRST, OP_FIND_ANY;
            static {
                Predicate<OptionalLong> isPresent = OptionalLong::isPresent;
                Supplier<TerminalSink<Long, OptionalLong> newSink
                    = FindSink.OfLong::new;

                OP_FIND_FIRST = new FindOp<>(true, StreamShape.LONG_VALUE,
                    OptionalLong.empty(), isPresent, newSink);

                OP_FIND_ANY = new FindOp<>(false, StreamShape.LONG_VALUE,
                    OptionalLong.empty(), isPresent, newSink);
            }

src/java.base/share/classes/java/util/stream/FindOps.java line 273:

> 271:                     StreamShape.DOUBLE_VALUE, OptionalDouble.empty(), IS_PRESENT, NEW);
> 272:             static final TerminalOp<Double, OptionalDouble> OP_FIND_ANY = new FindOp<>(false,
> 273:                     StreamShape.DOUBLE_VALUE, OptionalDouble.empty(), IS_PRESENT, NEW);

Suggestion:

            static final TerminalOp<Double, OptionalDouble> OP_FIND_FIRST, OP_FIND_ANY;
            static {
                Predicate<OptionalDouble> isPresent = OptionalDouble::isPresent;
                Supplier<TerminalSink<Double, OptionalLong> newSink
                    = FindSink.OfDouble::new;

                OP_FIND_FIRST = new FindOp<>(true, StreamShape.DOUBLE_VALUE,
                    OptionalDouble.empty(), isPresent, newSink);

                OP_FIND_ANY = new FindOp<>(false, StreamShape.DOUBLE_VALUE,
                    OptionalDouble.empty(), isPresent, newSink);
            }

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

PR Review: https://git.openjdk.org/jdk/pull/19477#pullrequestreview-2101252355
PR Review Comment: https://git.openjdk.org/jdk/pull/19477#discussion_r1629032905
PR Review Comment: https://git.openjdk.org/jdk/pull/19477#discussion_r1629035242
PR Review Comment: https://git.openjdk.org/jdk/pull/19477#discussion_r1629040800
PR Review Comment: https://git.openjdk.org/jdk/pull/19477#discussion_r1629043309

From ihse at openjdk.org  Thu Jun  6 09:37:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Jun 2024 09:37:05 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v31]
In-Reply-To: <XPFeBJ4pD_uV4sMSb41lBYGV5gVRLe3JZnB9iuOUicM=.1bca239e-b52c-4b5e-b1f5-97b1d8635446@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XPFeBJ4pD_uV4sMSb41lBYGV5gVRLe3JZnB9iuOUicM=.1bca239e-b52c-4b5e-b1f5-97b1d8635446@github.com>
Message-ID: <jaS3JoBIJ-bWsLNcImVOdtEf7qP8JnKzkwy_Fv4Ce1Q=.3511ac1c-d295-4641-9640-e4b6c0d9a5ed@github.com>

On Wed, 5 Jun 2024 17:31:44 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 six additional commits since the last revision:
> 
>  - Move JImageHelper
>  - Update wording on multi-hop.
>  - Remove printStackTrace()
>  - Fix comment. Stream.toList()
>  - Use pattern matching for instanceof in JRTArchive::equals
>  - Rename JLINK_PRODUCE_RUNTIME_LINK_JDK to JLINK_PRODUCE_LINKABLE_RUNTIME

As Erik says. You need to add something like: `DEFAULT_DESC: [the inverse of --enable-runtime-link-image]`.

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

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

From asotona at openjdk.org  Thu Jun  6 09:38:27 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 6 Jun 2024 09:38:27 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v17]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <jJ4fGLGnjPnE945ZpoEBQ4ehWzWlsm69sAbZpoFJkuI=.024f74c2-6f60-4c1e-8635-eae2f81e9ccc@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

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

  use of jdk.internal.constant to improve performance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/902b02ee..e814749a

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

  Stats: 113 lines in 6 files changed: 35 ins; 7 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

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

From sgehwolf at openjdk.org  Thu Jun  6 09:47:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 6 Jun 2024 09:47:30 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
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: <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@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 default description of keep-packaged-modules

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/b72648ba..7a8f839e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=30-31

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 Jun  6 09:47:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 6 Jun 2024 09:47:30 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v31]
In-Reply-To: <jaS3JoBIJ-bWsLNcImVOdtEf7qP8JnKzkwy_Fv4Ce1Q=.3511ac1c-d295-4641-9640-e4b6c0d9a5ed@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <XPFeBJ4pD_uV4sMSb41lBYGV5gVRLe3JZnB9iuOUicM=.1bca239e-b52c-4b5e-b1f5-97b1d8635446@github.com>
 <jaS3JoBIJ-bWsLNcImVOdtEf7qP8JnKzkwy_Fv4Ce1Q=.3511ac1c-d295-4641-9640-e4b6c0d9a5ed@github.com>
Message-ID: <7VabDem5bcwntO2OnnFjvHHp-PRoiqznwlS0biro1uw=.5728750d-7213-4edc-a6a4-0934a7976ffa@github.com>

On Thu, 6 Jun 2024 09:33:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As Erik says. You need to add something like: `DEFAULT_DESC: [the inverse of --enable-runtime-link-image]`.

https://github.com/openjdk/jdk/pull/14787/commits/7a8f839e55c5109deeb5022d2338b37387c95c85 does that. Sorry it clashed with your comment. It sets it to `enabled by default unless --enable-runtime-link-image is set`. Hopefully that is OK as well.

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

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

From ihse at openjdk.org  Thu Jun  6 09:52:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Jun 2024 09:52:57 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
In-Reply-To: <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
Message-ID: <ohn00lW44OmmQHrdo075YEywEEURvKjsadYpzntZTFg=.bb423327-4b07-441e-a1bd-a80edce14b5d@github.com>

On Thu, 6 Jun 2024 09:47:30 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 default description of keep-packaged-modules

Marked as reviewed by ihse (Reviewer).

The wording was much better than what I suggested. Thanks.

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

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2101492920
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2151870228

From asotona at openjdk.org  Thu Jun  6 10:16:14 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 6 Jun 2024 10:16:14 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - reverted static initialization of ConstantPoolBuilder and CP entries
 - fixed naming conventions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/e814749a..f870a8df

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

  Stats: 43 lines in 2 files changed: 7 ins; 13 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

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

From alanb at openjdk.org  Thu Jun  6 10:45:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Jun 2024 10:45:00 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
In-Reply-To: <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
Message-ID: <HSOGsybzH_P2stWyoTFWtKhSnAlJCgssUnfxMF-sEnc=.69e42221-f9d7-408f-9e29-dec4d143944a@github.com>

On Thu, 6 Jun 2024 09:47:30 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 default description of keep-packaged-modules

I've read through all src changes. I think Sundar is looking at the code changes too.

The overall design seems solid. I know it took a long time to get there but this is nature of a feature like this. At this point I regret that there isn't a JEP. A JEP would have captured the motivation, outlined the design, the reasoning for the restrictions, and document the design choices/directions that have been prototyped. If there isn't a JEP then I suppose it can come later if the feature is progressed and there is discussion about making it the default rather than opt-in at build configure time.

As cleanup, I think we will need to bring some consistency to the terminology and phrasing in documentation, code and comments. Right now there is "run-time linking", "linkable run-time", "run-time linkable JDK image", "linkable jimage".

Also as cleanup, I think the code needs more comments. There is no JEP right now with an authoritive description of the feature so anyone maintaining this code will have to figure out a lot of details. It feels like there should be somehting that documents the effect of --enable-runtime-link-image, how the diffs are generated and saved, and how they are used by jlink. There is also a lot of new code in ImageFileCreator and JlinkTask that is asking for some method descriptions so that anyone touching this code can quickly understand what these methods are doing. I don't want to get into code style issues now but I think it would be helpful for future maintainers to avoid more of the overfly long lines if possible (some of them are 150, 160, 170+ and really hard to look at code side-by-side).

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

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

From shade at openjdk.org  Thu Jun  6 10:51:44 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Jun 2024 10:51:44 GMT
Subject: RFR: 8325984: 4 jcstress tests are failing in Tier6 4 times each
In-Reply-To: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>
References: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>
Message-ID: <a8yn5cIHaEn6-LrdldgH0S-krpWuYIZkPgq2hEwfH0o=.82d900dd-7fd6-431c-bbf1-3f649fab13f5@github.com>

On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> These 4 tests were failing due to an incompatibility with jcstress. They were problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
> 
> Now that jcstress has been updated (https://github.com/openjdk/jdk/pull/19332) with the relevant fix (https://github.com/openjdk/jcstress/pull/147), we can re-enable these tests.
> 
> Testing: I've verified that all 4 tests now pass on Linux-x64

I think only Oracle CIs run these tests through jtreg wrappers? Anyway, this looks good to me.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19565#pullrequestreview-2101607822

From liach at openjdk.org  Thu Jun  6 11:46:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 11:46:46 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <EoZKDKEF8v-9pVF0pnAAxRkl4qWuMljKqS0kvPYPGc8=.ea19b851-cfc2-41a9-a554-2efe116ac4db@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com>
 <EoZKDKEF8v-9pVF0pnAAxRkl4qWuMljKqS0kvPYPGc8=.ea19b851-cfc2-41a9-a554-2efe116ac4db@github.com>
Message-ID: <9f9ETnR3ID7Ct5v2-jesnU-U-AlbHQF0fQjz5VFamvM=.6bc70cb4-2717-4895-ae4f-52f516603df7@github.com>

On Thu, 6 Jun 2024 06:41:48 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Sean Gwizdak 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:
>> 
>>  - Remove trailing whitespace.
>>  - Move hashCode benchmark into the newly created MethodBenchmark file
>>  - Merge branch 'master' into method-hashcode-JDK-8332249
>>  - Remove changes to JavaDoc per guidance.
>>  - Fix whitespace issues pointed by the bot
>>  - Micro-optimize Method.hashCode
>
> src/java.base/share/classes/java/lang/reflect/Method.java line 392:
> 
>> 390:                 .hashCode();
>> 391:         }
>> 392:         return hc;
> 
> The?`hash`?field should probably somehow be?shared?with the?`Method.root`?instance, so?that it?doesn?t need to?be?recomputed when?different?code gets?a?`Method`?reference.

Currently the hashCode computation is quite cheap. I think we can consider this delegation if it gets more complex, say if the hash code now considers parameters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1629365372

From sgehwolf at openjdk.org  Thu Jun  6 12:11:58 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 6 Jun 2024 12:11:58 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
In-Reply-To: <HSOGsybzH_P2stWyoTFWtKhSnAlJCgssUnfxMF-sEnc=.69e42221-f9d7-408f-9e29-dec4d143944a@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
 <HSOGsybzH_P2stWyoTFWtKhSnAlJCgssUnfxMF-sEnc=.69e42221-f9d7-408f-9e29-dec4d143944a@github.com>
Message-ID: <9hNjD7eheWnoeCUhjUFOLaWodK6xWr8ZEpVUpER2hcQ=.c021a63b-2a70-4433-ae36-644962d293ac@github.com>

On Thu, 6 Jun 2024 10:42:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix default description of keep-packaged-modules
>
> I've read through all src changes. I think Sundar is looking at the code changes too.
> 
> The overall design seems solid. I know it took a long time to get there but this is nature of a feature like this. At this point I regret that there isn't a JEP. A JEP would have captured the motivation, outlined the design, the reasoning for the restrictions, and document the design choices/directions that have been prototyped. If there isn't a JEP then I suppose it can come later if the feature is progressed and there is discussion about making it the default rather than opt-in at build configure time.
> 
> As cleanup, I think we will need to bring some consistency to the terminology and phrasing in documentation, code and comments. Right now there is "run-time linking", "linkable run-time", "run-time linkable JDK image", "linkable jimage".
> 
> Also as cleanup, I think the code needs more comments. There is no JEP right now with an authoritive description of the feature so anyone maintaining this code will have to figure out a lot of details. It feels like there should be somehting that documents the effect of --enable-runtime-link-image, how the diffs are generated and saved, and how they are used by jlink. There is also a lot of new code in ImageFileCreator and JlinkTask that is asking for some method descriptions so that anyone touching this code can quickly understand what these methods are doing. I don't want to get into code style issues now but I think it would be helpful for future maintainers to avoid more of the overfly long lines if possible (some of them are 150, 160, 170+ and really hard to look at code side-by-side).

@AlanBateman Sure, I appreciate the feedback. Do I understand it correctly that this won't get into JDK 23 then? If so, perhaps the better way would be to draft a JEP for JDK 24 and get that proposed early. What I'd like to avoid is for this change to don't see much movement for a long time between now and RDP 1 of JDK 24 and have a similar crunch when JDK 24 is close to forking. You mention clean-up a lot. Is that suggesting it *can* go into JDK 23 and clean-up in ramp-down? I'm confused...

Some clarity on how to best approach getting this integrated that would be acceptable for all involved would be appreciated. Thanks!

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

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

From asemenyuk at openjdk.org  Thu Jun  6 12:43:46 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Jun 2024 12:43:46 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
In-Reply-To: <zT-VP-bLc4fPJ-qN-dj2tKsV3ACFiiKiDfJF5cl6oso=.0c3000b3-0dbb-4faf-861e-c6fa39df3c2a@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <vl66GAw13fAcrDR25WKxWfgNoIcxfbF_YIYdSniGV7A=.779162bc-8465-454a-a256-33ad593a41b7@github.com>
 <MoUqz0AcISgDz8beoygDmh0hQt4360W1N1Cp3-eVIFo=.b524d976-4317-4743-9095-21b6b93dee90@github.com>
 <ul-uv7qR47M4w712xqL_58qj3Yv3pK2MooRhKpgOZKQ=.6d0232b7-4c24-4a22-a11b-d0e391bc6087@github.com>
 <oBymKYvjhTzQUU-tqclGEF33jSagR0p926gyu2pFh_A=.847bd07c-70d8-45be-993a-65e7c16166d5@github.com>
 <zT-VP-bLc4fPJ-qN-dj2tKsV3ACFiiKiDfJF5cl6oso=.0c3000b3-0dbb-4faf-861e-c6fa39df3c2a@github.com>
Message-ID: <I_tTaI5tDYf5pVDq0VAP6dluAXMvMczfYsR8e-rQH-k=.f911349b-31eb-4bd3-8479-92bb92e6e5ac@github.com>

On Wed, 5 Jun 2024 19:31:57 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed?

jpackage will detect the custom main.wxs is WiX4 format and pass it as is to `wix.exe`. I.e. custom WiX5 main.wxs will work with WiX5 toolkit.
However, it will fail if they try using custom main.wxs with WiX5-specific features with WiX4 toolkit. But this is out of the scope of jpackage.

> Do you know if there any benefits to use any features available in WiX5 if WiX5 toolkit is installed, instead of using only WiX4 features with WiX5 toolkit?

As far as I can tell from https://wixtoolset.org/docs/fivefour/, WiX5 reduces the redundancy of source files compared to WiX4. I can see how people handwriting sophisticated WiX source files can benefit from these improvements, not jpackage. The default main.wxs and two dialogs jpackage supplies are very basic and other sources are generated.

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

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2152309900

From duke at openjdk.org  Thu Jun  6 12:46:36 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 6 Jun 2024 12:46:36 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
Message-ID: <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>

> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
> 
> 
> After:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op

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

  Adding benchmarks for readObject

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19527/files
  - new: https://git.openjdk.org/jdk/pull/19527/files/9ab83c9d..b1920f7a

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

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

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

From asemenyuk at openjdk.org  Thu Jun  6 12:52:00 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Jun 2024 12:52:00 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
 [v5]
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <2w8qlUQQsvAFKylKWh2daqvBmuN_mOtUgn6Bqv0tpjc=.e3f5fc3c-ab83-49c9-a5f1-7e0b0b463e56@github.com>

> Add support for WiX4 and WiX5 in jpackage.
> 
> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

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

  Unify "switch(wixVersion) ..." expressions. Always throw IllegalArgumentException if "wixVersion" is not WixToolkit#Wix3 or WixToolkit#Wix4. When/If we add another value to WixToolkit enum this will help not to miss adjusting all WiX version-specific code.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19318/files
  - new: https://git.openjdk.org/jdk/pull/19318/files/af8fb680..899470e4

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

  Stats: 64 lines in 6 files changed: 46 ins; 12 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19318/head:pull/19318

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

From prappo at openjdk.org  Thu Jun  6 12:52:48 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jun 2024 12:52:48 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v9]
In-Reply-To: <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>
Message-ID: <Y4jjtM0LOUI_nwzOj_DLFrS16p0s16M2DI_PbbG3DKM=.249050f8-7752-4e75-be80-3a4f701f2e30@github.com>

On Wed, 5 Jun 2024 17:48:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary add-opens

This feels like a better, end-to-end test. Thank you for your perseverance. Below are some comments.

test/jdk/java/io/Console/RestoreEchoTest.java line 66:

> 64:         OutputAnalyzer output = ProcessTools.executeProcess(
> 65:                 "expect",
> 66:                 "-n",

What does `-n` do?

test/jdk/java/io/Console/RestoreEchoTest.java line 70:

> 68:                 initialEcho,
> 69:                 jdkDir + "/bin/java",
> 70:                 "--add-opens=java.base/jdk.internal.io=ALL-UNNAMED",

We don't seem to need `--add-opens`.

test/jdk/java/io/Console/RestoreEchoTest.java line 72:

> 70:                 "--add-opens=java.base/jdk.internal.io=ALL-UNNAMED",
> 71:                 "-Djdk.console=java.base",
> 72:                 "-classpath", testClasses,

Consider this. If we remove `-classpath` (and `var testClasses`), not only will nothing break, but we'll be also able to use JUnit assertions and assumptions in `main` instead of manual check-then-throw. This will work because the expect-process will inherit the environment, which captures `CLASSPATH` ( see https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ProcessBuilder.html#start() ).

Again, the above is just something to consider. For all I know, you might've considered it already and rejected.

test/jdk/java/io/Console/RestoreEchoTest.java line 78:

> 76:         if (eval != 0) {
> 77:             throw new RuntimeException("Test failed. Exit value from 'expect' command: " + eval);
> 78:         }

It could've been `assertEquals(0, output.getExitValue())`.

test/jdk/java/io/Console/RestoreEchoTest.java line 93:

> 91:         // testing readLine()
> 92:         String input = con.readLine("prompt: ");
> 93:         con.printf("input is %s\n", input);

I know that this test is only run on Linux and macOS, and yet `%n` would be better than `\n`. It's one of those cases where it's simpler to use a general solution than to use a less general one and explain why it still does the job.

test/jdk/java/io/Console/RestoreEchoTest.java line 97:

> 95:         // testing readPassword()
> 96:         input = String.valueOf(con.readPassword("password prompt: "));
> 97:         con.printf("password is %s\n", input);

Ditto on `%n`.

test/jdk/java/io/Console/restoreEcho.exp line 57:

> 55: test "$rpprompt" "$rpinput" "-echo" "$rpexpected"
> 56: # See if the initialEcho is restored with `stty -a`
> 57: expect " $initialEcho "

If you leave out those whitespace characters inside the quotes and `$initialEcho` expands to `-echo`, it will be treated as an option to `expect`, right? If so, consider this instead:

    expect -- $initialEcho

But more importantly: could a test match `echo` in `-echo` and therefore falsely pass?

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

PR Review: https://git.openjdk.org/jdk/pull/19315#pullrequestreview-2101329552
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629085477
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629331808
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629348345
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629359368
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629361442
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629361824
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629445000

From asemenyuk at openjdk.org  Thu Jun  6 12:58:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Jun 2024 12:58:59 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
 [v6]
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <By9S_mSNwK-pKYIY3yKsnWQgjaEqh1yluvZLKw3SZ9k=.213bfa41-c608-49b8-8c52-8e6e086ebf26@github.com>

> Add support for WiX4 and WiX5 in jpackage.
> 
> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

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

  Add WiX v5 to "error.no-wix-tools"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19318/files
  - new: https://git.openjdk.org/jdk/pull/19318/files/899470e4..d4469735

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

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

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

From jpai at openjdk.org  Thu Jun  6 13:13:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Jun 2024 13:13:21 GMT
Subject: RFR: 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL macro in
 java launcher
Message-ID: <NoAAbQZLfZe9g2rEGOX1U1S2rR0QE1lIZ229VfOnNT8=.c1b88267-e23d-48c3-9047-edffd19b2559@github.com>

Can I please get a review for this change which proposes to remove the `CHECK_EXCEPTION_NULL_FAIL` macro from the `java` launcher code?

This addresses https://bugs.openjdk.org/browse/JDK-8333714. As noted in that JBS issue, in a recent PR discussion, it was suggested https://github.com/openjdk/jdk/pull/18786#issuecomment-2147452633 that this macro should be removed and the failure of a JNI specified operation (the ones for which this macro is being used) should be determined based on a `NULL` value returned from that function. The commit in this PR removes this macros and updates the call sites to do a `NULL` check.

Given the nature of this change, no new tests have been added. tier1, tier2 and tier3 testing passed successfully with these changes.

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

Commit messages:
 - simplify function comments
 - 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL macro in java launcher

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

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

From prasad.velagapudi at servicenow.com  Thu Jun  6 13:14:51 2024
From: prasad.velagapudi at servicenow.com (Prasad Velagapudi)
Date: Thu, 6 Jun 2024 13:14:51 +0000
Subject: Lambda Classes reachability from GC roots  in JDK11 and JDK17
Message-ID: <IA3PR08MB102017B9054EB292C95BC790195FA2@IA3PR08MB10201.namprd08.prod.outlook.com>


Hello Lambda Experts,

I am looking for clarifications on the following questions.


  1.  I observed in my tests that lambda classes generated for inline lambda expressions (ex: LambdaUtil::print), are STRONGLY linked to defining class loader and never gets collected on GC. This behaviour is same in both JDK11 and JDK17. Can you please confirm is this accurate?
  2.  Also, I observed that the lambda classes generated for inline lambda expressions (ex: LambdaUtil::print) not adding additional overhead to Metaspace. Can you please confirm is this accurate?


Regards,
Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240606/3c2c9dd2/attachment-0001.htm>

From jpai at openjdk.org  Thu Jun  6 13:28:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Jun 2024 13:28:55 GMT
Subject: RFR: 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL
 macro in java launcher [v2]
In-Reply-To: <NoAAbQZLfZe9g2rEGOX1U1S2rR0QE1lIZ229VfOnNT8=.c1b88267-e23d-48c3-9047-edffd19b2559@github.com>
References: <NoAAbQZLfZe9g2rEGOX1U1S2rR0QE1lIZ229VfOnNT8=.c1b88267-e23d-48c3-9047-edffd19b2559@github.com>
Message-ID: <2ljA_wbHn-RLVyWR3VrIKme5JmvzdWnrCVEEtQVeok4=.d9486ad8-ca69-40ac-b25a-25a83ef1cb70@github.com>

> Can I please get a review for this change which proposes to remove the `CHECK_EXCEPTION_NULL_FAIL` macro from the `java` launcher code?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8333714. As noted in that JBS issue, in a recent PR discussion, it was suggested https://github.com/openjdk/jdk/pull/18786#issuecomment-2147452633 that this macro should be removed and the failure of a JNI specified operation (the ones for which this macro is being used) should be determined based on a `NULL` value returned from that function. The commit in this PR removes this macros and updates the call sites to do a `NULL` check.
> 
> Given the nature of this change, no new tests have been added. tier1, tier2 and tier3 testing passed successfully with these changes.

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

  improve comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19576/files
  - new: https://git.openjdk.org/jdk/pull/19576/files/1c2a3dfb..1b3d630a

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

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

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

From alanb at openjdk.org  Thu Jun  6 13:50:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Jun 2024 13:50:59 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
In-Reply-To: <HSOGsybzH_P2stWyoTFWtKhSnAlJCgssUnfxMF-sEnc=.69e42221-f9d7-408f-9e29-dec4d143944a@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
 <HSOGsybzH_P2stWyoTFWtKhSnAlJCgssUnfxMF-sEnc=.69e42221-f9d7-408f-9e29-dec4d143944a@github.com>
Message-ID: <k9w0LO2Zu8q596M8qmGyAgSCqGbY397V9maQQIOCI7U=.aa96e4a7-192d-43f5-b31e-ae519838cf74@github.com>

On Thu, 6 Jun 2024 10:42:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix default description of keep-packaged-modules
>
> I've read through all src changes. I think Sundar is looking at the code changes too.
> 
> The overall design seems solid. I know it took a long time to get there but this is nature of a feature like this. At this point I regret that there isn't a JEP. A JEP would have captured the motivation, outlined the design, the reasoning for the restrictions, and document the design choices/directions that have been prototyped. If there isn't a JEP then I suppose it can come later if the feature is progressed and there is discussion about making it the default rather than opt-in at build configure time.
> 
> As cleanup, I think we will need to bring some consistency to the terminology and phrasing in documentation, code and comments. Right now there is "run-time linking", "linkable run-time", "run-time linkable JDK image", "linkable jimage".
> 
> Also as cleanup, I think the code needs more comments. There is no JEP right now with an authoritive description of the feature so anyone maintaining this code will have to figure out a lot of details. It feels like there should be somehting that documents the effect of --enable-runtime-link-image, how the diffs are generated and saved, and how they are used by jlink. There is also a lot of new code in ImageFileCreator and JlinkTask that is asking for some method descriptions so that anyone touching this code can quickly understand what these methods are doing. I don't want to get into code style issues now but I think it would be helpful for future maintainers to avoid more of the overfly long lines if possible (some of them are 150, 160, 170+ and really hard to look at code side-by-side).

> @AlanBateman Sure, I appreciate the feedback. Do I understand it correctly that this won't get into JDK 23 then? If so, perhaps the better way would be to draft a JEP for JDK 24 and get that proposed early. What I'd like to avoid is for this change to don't see much movement for a long time between now and RDP 1 of JDK 24 and have a similar crunch when JDK 24 is close to forking. You mention clean-up a lot. Is that suggesting it _can_ go into JDK 23 and clean-up in ramp-down? I'm confused...
> 
> Some clarity on how to best approach getting this integrated that would be acceptable for all involved would be appreciated. Thanks!

The fork for JDK 23 is today so if I was running with this feature then I wouldn't integrate it today. If you are willing to put the time into writing a JEP then I think it's the right thing to do. We should probably have brought this up long before now. I'm happy to help review iterations. There is a lot to write down and this will be very valuable for future phases of this work. I assume future phases. We agreed some restrictions to reduce complexity for this first phase. Future phases may remove these and maybe there is confidence in the future to make it default.

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

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

From jpai at openjdk.org  Thu Jun  6 14:02:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Jun 2024 14:02:03 GMT
Subject: RFR: 8026127: Deflater/Inflater documentation
 incomplete/misleading [v3]
In-Reply-To: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>
References: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>
Message-ID: <5EcD6qP5xpBf57GZ0HXbmX2qEftWfIK9Ymj9Gz9qScM=.bae6d8ef-de5a-4a13-b5d9-9368d41b77a8@github.com>

> Can I please get a review of this doc-only change which proposes to improve the code snippet that's in `java.util.zip.Deflater` and `java.util.zip.Inflater` to better explain the usage of those classes? This addresses https://bugs.openjdk.org/browse/JDK-8026127.
> 
> The commit in the PR cleans up the snippet to correctly compress/decompress till the `Deflater` and `Inflater` are `finished()`.  Additionally, the snippet also shows that the `Deflater` and `Inflater` are expected to be closed when their usage it done, to release the resources held by those instances.
> 
> I've run `make docs-image` locally to verify that the generated snippet content as well as the link from `Inflater` work fine in the rendered javadoc HTML.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - minor change to the comment
 - move the snippet to an external snippet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19507/files
  - new: https://git.openjdk.org/jdk/pull/19507/files/098212a6..7a72a760

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

  Stats: 158 lines in 3 files changed: 97 ins; 58 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19507/head:pull/19507

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

From shade at openjdk.org  Thu Jun  6 14:32:47 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Jun 2024 14:32:47 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <PnqP1oYl3XPasxoTTBUla6Qqh1r-tyZ6a2b0BGlVbe4=.8e2c4622-afb4-4d92-b729-23a1faf4b0ef@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <ZRFgnMzbNR_9odHGXWQrPWFaNmHq6MJPd5Q1GSM3ANA=.f4de435c-b62f-4671-9b76-c3993fc69309@github.com>
 <HDp4qCud6rEnlGBPnfnKbL34Fi24xyJd3q5fMpr81yk=.f9c5181a-8d5e-4995-8d10-c913d53a716d@github.com>
 <OoFXXPNbdWXcwXwloq28EK5chYINYYEN6nLLM81Pdwo=.8cba479e-ad7f-4f78-8d89-304ea61f7434@github.com>
 <PnqP1oYl3XPasxoTTBUla6Qqh1r-tyZ6a2b0BGlVbe4=.8e2c4622-afb4-4d92-b729-23a1faf4b0ef@github.com>
Message-ID: <DyAsw4Up2tbmn5npDKosQuoWFKmmuo4daOnsDGBnFeA=.27f1bdb3-ba69-4967-992d-e5f20e347e8e@github.com>

On Wed, 5 Jun 2024 14:56:26 GMT, jengebr <duke at openjdk.org> wrote:

> clone() performs a shallow copy, so there is currently no Object[] allocated and therefore nothing to optimize.

Yes, I believe so.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1629666551

From shade at openjdk.org  Thu Jun  6 14:38:47 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Jun 2024 14:38:47 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
Message-ID: <trxMQi-gYVRnU3OYbO_6kqiNsY_q92qj-PEHD-76xS4=.2390d0ec-1187-410f-8503-c6c766ccd117@github.com>

On Thu, 6 Jun 2024 12:46:36 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2625.125 ? 71.802  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2607.447 ? 46.400  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2615.500 ? 30.771  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2583.892 ? 62.086  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding benchmarks for readObject

I think this is good. I'll let Doug and Viktor to confirm their comments were addressed.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19527#pullrequestreview-2102178280

From prasad.velagapudi at servicenow.com  Thu Jun  6 14:40:04 2024
From: prasad.velagapudi at servicenow.com (Prasad Velagapudi)
Date: Thu, 6 Jun 2024 14:40:04 +0000
Subject: Lambda Classes reachability from GC roots  in JDK11 and JDK17
In-Reply-To: <IA3PR08MB102017B9054EB292C95BC790195FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
References: <IA3PR08MB102017B9054EB292C95BC790195FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
Message-ID: <IA3PR08MB10201E03DC19654D6D44E300D95FA2@IA3PR08MB10201.namprd08.prod.outlook.com>

Hello Lambda Experts,

I am looking for clarifications on the following questions.


  1.  I observed in my tests that lambda classes generated for inline lambda expressions (ex: LambdaUtil::print), are STRONGLY linked to defining class loader and never gets collected on GC. This behaviour is same in both JDK11 and JDK17. Can you please confirm is this accurate?
  2.  Also, I observed that the lambda classes generated for inline lambda expressions (ex: LambdaUtil::print) not adding additional overhead to Metaspace in JDK17 compared to that of JDK11 . Can you please confirm is this accurate?


Regards,
Prasad



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

From dl at openjdk.org  Thu Jun  6 14:48:55 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 6 Jun 2024 14:48:55 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
Message-ID: <ukgheT8eiOsZauaSMX9Lkxv4UkRKAcX-Gh4rJ7ztIvU=.12ef03f1-8bf6-4fdd-9fa0-1824f69942e0@github.com>

On Thu, 6 Jun 2024 12:46:36 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2625.125 ? 71.802  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2607.447 ? 46.400  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2615.500 ? 30.771  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2583.892 ? 62.086  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding benchmarks for readObject

Yes, I think this is now OK (and maybe barely worth doing).

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

PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2152726032

From jvernee at openjdk.org  Thu Jun  6 15:21:45 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Jun 2024 15:21:45 GMT
Subject: RFR: 8325984: 4 jcstress tests are failing in Tier6 4 times each
In-Reply-To: <a8yn5cIHaEn6-LrdldgH0S-krpWuYIZkPgq2hEwfH0o=.82d900dd-7fd6-431c-bbf1-3f649fab13f5@github.com>
References: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>
 <a8yn5cIHaEn6-LrdldgH0S-krpWuYIZkPgq2hEwfH0o=.82d900dd-7fd6-431c-bbf1-3f649fab13f5@github.com>
Message-ID: <SZyNG-Ghkz-o7ZccZN1-h2ZPmepoPz0nQSpjlxfhGpI=.ba4e45cc-4e9b-4261-b36a-10299c0566a0@github.com>

On Thu, 6 Jun 2024 10:48:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think only Oracle CIs run these tests through jtreg wrappers?

We do run them in our CI. Not sure who else runs them that way.

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

PR Comment: https://git.openjdk.org/jdk/pull/19565#issuecomment-2152799029

From dfuchs at openjdk.org  Thu Jun  6 15:22:51 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Jun 2024 15:22:51 GMT
Subject: Integrated: 8333270: HandlersOnComplexResetUpdate and
 HandlersOnComplexUpdate tests fail with "Unexpected reference" if
 timeoutFactor is less than 1/3
In-Reply-To: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>
References: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>
Message-ID: <PjBNUtIM8i-rcBZnWUusOjGKgKi_dnbROeQQ5zKkA74=.565dffab-916d-4fab-a27e-47bfcf3dcd0e@github.com>

On Fri, 31 May 2024 14:55:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that loggers are GC'ed (or not GC'ed) after a reset or an update. For that they poll a ReferenceQueue in a loop. The number of iteration is adjusted according to the jtreg timeout factor. However, the logic in the test did not expect that the timeout might be less than 1.
> 
> This fix does two things:
> 
> 1. fix the adjustCount logic - so that the number of iteration can only be increased
> 2. use remove(timeout) instead of poll() in order to minimize the waiting time.

This pull request has now been integrated.

Changeset: d02cb742
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d02cb742f79e88c6438ca58a6357fe432fb286cb
Stats:     16 lines in 2 files changed: 0 ins; 2 del; 14 mod

8333270: HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests fail with "Unexpected reference" if timeoutFactor is less than 1/3

Reviewed-by: jpai

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

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

From sgehwolf at openjdk.org  Thu Jun  6 15:38:06 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 6 Jun 2024 15:38:06 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
In-Reply-To: <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
Message-ID: <Jd1IjGY4f5x21FEtT-G0v8Bz8E5Ufg4HoZvLK5C1q04=.bb931989-1eff-4e8c-8798-6d25bf36c211@github.com>

On Thu, 6 Jun 2024 09:47:30 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 default description of keep-packaged-modules

OK. I'm aware about the timelines for JDK 23. Thanks for bringing clarity to this. My aim will be to bring this into JDK 24 with a JEP then. Hopefully we can bring this to a successful conclusion that way.

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

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

From duke at openjdk.org  Thu Jun  6 15:56:07 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 6 Jun 2024 15:56:07 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
Message-ID: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>

### Summary
This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 

Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 

**Testing**
- Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
- tier1

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

Commit messages:
 - Prevent undefined behaviour when calling isspace.

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

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

From darcy at openjdk.org  Thu Jun  6 16:04:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Jun 2024 16:04:56 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <zvPepcUjjlzXf4oeagWHU5bC9dQaGuJlLvItYoII88U=.4f3b844f-261c-4bdc-b94e-f5074ec11a87@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

This pull request has now been integrated.

Changeset: 75dc2f85
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75dc2f8518d0adea30f7065d6732b807c0220756
Stats:     2083 lines in 50 files changed: 2019 ins; 7 del; 57 mod

8330182: Start of release updates for JDK 24
8330183: Add SourceVersion.RELEASE_24
8330184: Add source 24 and target 24 to javac

Reviewed-by: iris, vromero, asotona, dholmes

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

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

From acobbs at openjdk.org  Thu Jun  6 17:03:57 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 6 Jun 2024 17:03:57 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v5]
In-Reply-To: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
Message-ID: <kk1RctKbQMBX9Ymtmr7m_E4P-fbu7plmwLiP54yHkjY=.4d885993-7c39-4455-989d-3ec15737e153@github.com>

> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
> 
> There are several issues with this:
> 
> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
> 
> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
> 
> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Bump @since from 23 to 24.
 - Merge branch 'master' into JDK-8322256
 - Relabel "trailing garbage" as "extra bytes" to sound less accusatory.
 - Simplify code by eliminating an impossible case.
 - Field name change and Javadoc wording tweaks.
 - Merge branch 'master' into JDK-8322256
 - Javadoc wording tweaks.
 - Merge branch 'master' into JDK-8322256
 - Clarify exceptions: sometimes ZipException, sometimes EOFException.
 - Merge branch 'master' into JDK-8322256
 - ... and 2 more: https://git.openjdk.org/jdk/compare/75dc2f85...f845a75b

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

Changes: https://git.openjdk.org/jdk/pull/18385/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=04
  Stats: 318 lines in 2 files changed: 292 ins; 13 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385

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

From naoto at openjdk.org  Thu Jun  6 17:08:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jun 2024 17:08:03 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v10]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <4FMfXMA9-RY8ewee8ONkJX5dJk_Q9VDx_1d8r1QPoQ4=.27afd79b-5125-4725-a5ba-2c28a08a1225@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

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/19315/files
  - new: https://git.openjdk.org/jdk/pull/19315/files/c583c633..0e72fe46

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

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

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

From naoto at openjdk.org  Thu Jun  6 17:11:47 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jun 2024 17:11:47 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v9]
In-Reply-To: <Y4jjtM0LOUI_nwzOj_DLFrS16p0s16M2DI_PbbG3DKM=.249050f8-7752-4e75-be80-3a4f701f2e30@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>
 <Y4jjtM0LOUI_nwzOj_DLFrS16p0s16M2DI_PbbG3DKM=.249050f8-7752-4e75-be80-3a4f701f2e30@github.com>
Message-ID: <W3f84RflTWyk3NLujQfIoSwc5_qtbvMZbgYwO2WNpx8=.426b3a0f-41ae-4717-9bad-169c9b214bb6@github.com>

On Thu, 6 Jun 2024 09:05:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unnecessary add-opens
>
> test/jdk/java/io/Console/RestoreEchoTest.java line 66:
> 
>> 64:         OutputAnalyzer output = ProcessTools.executeProcess(
>> 65:                 "expect",
>> 66:                 "-n",
> 
> What does `-n` do?

It is for not reading the user's expect settings (`~/.expect.rc` if any)

> test/jdk/java/io/Console/RestoreEchoTest.java line 72:
> 
>> 70:                 "--add-opens=java.base/jdk.internal.io=ALL-UNNAMED",
>> 71:                 "-Djdk.console=java.base",
>> 72:                 "-classpath", testClasses,
> 
> Consider this. If we remove `-classpath` (and `var testClasses`), not only will nothing break, but we'll be also able to use JUnit assertions and assumptions in `main` instead of manual check-then-throw. This will work because the expect-process will inherit the environment, which captures `CLASSPATH` ( see https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ProcessBuilder.html#start() ).
> 
> Again, the above is just something to consider. For all I know, you might've considered it already and rejected.

I haven't considered that. Removed.

> test/jdk/java/io/Console/restoreEcho.exp line 57:
> 
>> 55: test "$rpprompt" "$rpinput" "-echo" "$rpexpected"
>> 56: # See if the initialEcho is restored with `stty -a`
>> 57: expect " $initialEcho "
> 
> If you leave out those whitespace characters inside the quotes and `$initialEcho` expands to `-echo`, it will be treated as an option to `expect`, right? If so, consider this instead:
> 
>     expect -- $initialEcho
> 
> But more importantly: could a test match `echo` in `-echo` and therefore falsely pass?

The spaces before/after `$initialEcho` are exactly to distinguish "echo" from "-echo", otherwise the test falsely succeeds as you pointed out. Although the test works as expected as it is, adding `--` would be safer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629915235
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629915623
PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629915890

From david.lloyd at redhat.com  Thu Jun  6 17:37:25 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 6 Jun 2024 12:37:25 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
Message-ID: <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>

Just bumping this one more time. I intend to start by opening a JIRA to add
the two proposed methods to `ReflectionFactory`, and go from there. I guess
that we might need a JEP for the proposed serialization restrictions, which
is going to be considerably more involved, so I'm putting that off as a
second step for now, pending further discussion.

On Wed, May 15, 2024 at 9:00?PM - <liangchenblue at gmail.com> wrote:

> Indeed, ReflectionFactory. newConstructorForSerialization can be used to
> access otherwise-private constructors. Before JDK-8315810, it could even
> allocate one class and call the constructor of another class.
>
> I strongly support your proposal to restrict ReflectionFactory.
>
> Regards, Chen
>
> On Wed, May 15, 2024 at 6:23?PM David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>>
>>
>> On Tue, May 14, 2024 at 10:01?AM David Lloyd <david.lloyd at redhat.com>
>> wrote:
>>
>>> (Moving to core-libs-dev)
>>>
>>> On Tue, May 14, 2024 at 9:40?AM Alan Bateman <Alan.Bateman at oracle.com>
>>> wrote:
>>>
>>>> On 14/05/2024 14:42, David Lloyd wrote:
>>>>
>>>> ReflectionFactory allows access to serialization facilities without any
>>>> access checking (other than the defunct SecurityManager checks). Perhaps
>>>> this class could gain some more methods, like this:
>>>>
>>>> * `newGetterForSerialization(Field field)` - includes ability to access
>>>> `objectStreamFields` and `serialVersionUID`, or these could be separate
>>>> methods
>>>> * `newSetterForSerialziation(Field field)`
>>>>
>>>> Does this seem workable?
>>>>
>>>> The intention with ReflectionFactory is that serialization libraries go
>>>> through the readObject/writeObject and other magic methods, to avoid field
>>>> access.
>>>>
>>>> Probably best to being this to core-libs-dev for further discussion.
>>>>
>>>
>>> This doesn't match my recollection. The `readObject` and `writeObject`
>>> methods are optional private methods which serializable classes *may*
>>> provide when they want a bespoke serialization strategy (and the other
>>> methods that are accessed via this special class are similar in this
>>> regard). They are not in any way magical in that they do not provide the
>>> means to perform this part of the serialization process, and thus they are
>>> not a substitute for field access in serialization. According to
>>> JDK-8164908, these methods were added because at the time, Unsafe was still
>>> state of the art for custom serialization and IIOP to access fields (with
>>> libraries using Field actively moving to Unsafe instead). However Unsafe
>>> did not and does not provide access to methods, so in order to avoid the
>>> aforementioned `add-opens` explosion, these methods were added as a
>>> compromise. Now that Unsafe is being deprecated, it is my opinion that this
>>> does need to be revisited because at the time, Unsafe was the recommended
>>> approach.
>>>
>>> [1] https://bugs.openjdk.org/browse/JDK-8164908
>>>
>> It seems to me that it might be a good idea (as part of 8305968
>> (Integrity by default)) to put the `ReflectionFactory` API behind a
>> restricted method call somehow, even considered separately from the changes
>> suggested above. Maybe in conjunction with a non-standard switch that works
>> similarly to `--enable-native-access`, e.g.
>> `--enable-serialization=org.serial.framework`? That would also somewhat
>> mitigate the security risk of adding the aforementioned methods or
>> something like them to this class.
>>
>> Should I open a bug for either (or both) of these suggestions? Or perhaps
>> there is a better way to proceed?
>>
>> --
>> - DML ? he/him
>>
>

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240606/311a4c2f/attachment.htm>

From sgibbons at openjdk.org  Thu Jun  6 17:44:05 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 6 Jun 2024 17:44:05 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v52]
In-Reply-To: <jFq_cE058-ZI-yhw7-CylWUxkUkPOP2Xu9-w1pQvY0s=.ff6a8cd0-0e1d-417a-83cd-e49d293f43dc@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jFq_cE058-ZI-yhw7-CylWUxkUkPOP2Xu9-w1pQvY0s=.ff6a8cd0-0e1d-417a-83cd-e49d293f43dc@github.com>
Message-ID: <OykcpgP4z5C1E3Fb3GaW-bhLw7gK1fC9rX3yo4Dt7d0=.e8582720-b42f-4c0c-a7f1-d09dab1014b8@github.com>

On Thu, 30 May 2024 16:16:45 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:
> 
>   Fix copyright & a couple of comment typos

Hi, everyone.  I see that JDK 23 has now been forked, and new commits go into the JDK 24 branch.  I would like to get this in as soon as possible to have as much time with fuzzers, etc. for everyone to be confident in the code.

I have 3 positive reviews on this PR and would like to integrate.  Please reply as soon as you reasonably can with objections or approval and I will integrate.  Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2153072708

From liach at openjdk.org  Thu Jun  6 17:51:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 17:51:44 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <LgJ6vo5urfqtMvgVKEIvWq_C8ZEGBtVtJ4T4FRb-Nls=.4c1438d7-2f22-430c-be6c-8c6ca6b6e38b@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

Changes requested by liach (Author).

test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:

> 1: #

This file change is dubious:
1. It does not have any trailing whitespace that can fail the skara checks.
2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles)

Recommended actions: Either
1. Revert changes in this file;
2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line.

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

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2102735910
PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1629981196

From naoto at openjdk.org  Thu Jun  6 17:54:45 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jun 2024 17:54:45 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v9]
In-Reply-To: <W3f84RflTWyk3NLujQfIoSwc5_qtbvMZbgYwO2WNpx8=.426b3a0f-41ae-4717-9bad-169c9b214bb6@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>
 <Y4jjtM0LOUI_nwzOj_DLFrS16p0s16M2DI_PbbG3DKM=.249050f8-7752-4e75-be80-3a4f701f2e30@github.com>
 <W3f84RflTWyk3NLujQfIoSwc5_qtbvMZbgYwO2WNpx8=.426b3a0f-41ae-4717-9bad-169c9b214bb6@github.com>
Message-ID: <ywRvL-4RGkJ2AoxQcqT5gfZEVl7NWSaQerMVahIKeh4=.4a7ea74d-94d3-4861-bbc1-b9b671581258@github.com>

On Thu, 6 Jun 2024 17:08:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/io/Console/RestoreEchoTest.java line 72:
>> 
>>> 70:                 "--add-opens=java.base/jdk.internal.io=ALL-UNNAMED",
>>> 71:                 "-Djdk.console=java.base",
>>> 72:                 "-classpath", testClasses,
>> 
>> Consider this. If we remove `-classpath` (and `var testClasses`), not only will nothing break, but we'll be also able to use JUnit assertions and assumptions in `main` instead of manual check-then-throw. This will work because the expect-process will inherit the environment, which captures `CLASSPATH` ( see https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ProcessBuilder.html#start() ).
>> 
>> Again, the above is just something to consider. For all I know, you might've considered it already and rejected.
>
> I haven't considered that. Removed.

Turned out that removing the classpath ends up not finding the test class:

Error: Could not find or load main class RestoreEchoTest
Caused by: java.lang.ClassNotFoundException: RestoreEchoTest
];

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1629984403

From lancea at openjdk.org  Thu Jun  6 18:02:43 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Jun 2024 18:02:43 GMT
Subject: RFR: 8026127: Deflater/Inflater documentation
 incomplete/misleading [v3]
In-Reply-To: <5EcD6qP5xpBf57GZ0HXbmX2qEftWfIK9Ymj9Gz9qScM=.bae6d8ef-de5a-4a13-b5d9-9368d41b77a8@github.com>
References: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>
 <5EcD6qP5xpBf57GZ0HXbmX2qEftWfIK9Ymj9Gz9qScM=.bae6d8ef-de5a-4a13-b5d9-9368d41b77a8@github.com>
Message-ID: <lZ5ZiODzk0IbVHVA89NpQCfHmyiuAFeTPNDXDn_BVFI=.c63d019c-a016-42db-ae29-7b910e9496e8@github.com>

On Thu, 6 Jun 2024 14:02:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to improve the code snippet that's in `java.util.zip.Deflater` and `java.util.zip.Inflater` to better explain the usage of those classes? This addresses https://bugs.openjdk.org/browse/JDK-8026127.
>> 
>> The commit in the PR cleans up the snippet to correctly compress/decompress till the `Deflater` and `Inflater` are `finished()`.  Additionally, the snippet also shows that the `Deflater` and `Inflater` are expected to be closed when their usage it done, to release the resources held by those instances.
>> 
>> I've run `make docs-image` locally to verify that the generated snippet content as well as the link from `Inflater` work fine in the rendered javadoc HTML.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - minor change to the comment
>  - move the snippet to an external snippet

thank you for converting the examples to take advantage of an external snippet

Looks good Jai and thank you

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19507#pullrequestreview-2102777897

From rgiulietti at openjdk.org  Thu Jun  6 18:21:04 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Jun 2024 18:21:04 GMT
Subject: RFR: 8333599: Improve description of \b matcher in j.u.r.Pattern
Message-ID: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>

A documentation-only change to match the original intent and the implemented behavior.

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

Commit messages:
 - 8333599: Improve description of \b matcher in j.u.r.Pattern

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

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

From kvn at openjdk.org  Thu Jun  6 18:28:07 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 6 Jun 2024 18:28:07 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v52]
In-Reply-To: <jFq_cE058-ZI-yhw7-CylWUxkUkPOP2Xu9-w1pQvY0s=.ff6a8cd0-0e1d-417a-83cd-e49d293f43dc@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jFq_cE058-ZI-yhw7-CylWUxkUkPOP2Xu9-w1pQvY0s=.ff6a8cd0-0e1d-417a-83cd-e49d293f43dc@github.com>
Message-ID: <P3eSyCdI_8Hpcm3aX8mJGqf54aeJdEh2q984Irt3lbc=.907c596e-2c06-46fd-b291-795dd7ef68e5@github.com>

On Thu, 30 May 2024 16:16:45 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:
> 
>   Fix copyright & a couple of comment typos

Let me do quick testing with latest mainline (JDK 24 now).

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2153142794

From naoto at openjdk.org  Thu Jun  6 18:34:59 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jun 2024 18:34:59 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v11]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <RN6h9d7NhVynCRcmWNZbx66jzjxZ0GO3KvvDSrso39U=.6979fdad-b3a5-41df-8411-edce79b9e0a9@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

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

  Restored classpath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19315/files
  - new: https://git.openjdk.org/jdk/pull/19315/files/0e72fe46..c6476270

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

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

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

From liach at openjdk.org  Thu Jun  6 18:40:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 18:40:04 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
Message-ID: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>

In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.

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

Commit messages:
 - Missed license header
 - Consolidate class/mt to desc operations

Changes: https://git.openjdk.org/jdk/pull/19585/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333749
  Stats: 160 lines in 8 files changed: 71 ins; 31 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/19585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19585/head:pull/19585

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

From liach at openjdk.org  Thu Jun  6 18:48:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 18:48:58 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
 [v2]
In-Reply-To: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
Message-ID: <KNW3RT0O2GNm36Gx8XkpAjI4vUtbBI1WqyDafW9gUSk=.bdf41809-790f-41ad-9f0c-25259ba1e18f@github.com>

> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
> 
> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Remove redundant try-catch in getEnclosingMethod/Constructor
 - Merge branch 'test/signature-error' into feature/new-generic-info
 - Fix everything
 - Fixxes
 - Stage
 - Stage new tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - ... and 6 more: https://git.openjdk.org/jdk/compare/2a37764e...19ee8797

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

Changes: https://git.openjdk.org/jdk/pull/19281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19281&range=01
  Stats: 4605 lines in 66 files changed: 1027 ins; 3483 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/19281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19281/head:pull/19281

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

From duke at openjdk.org  Thu Jun  6 18:53:48 2024
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 6 Jun 2024 18:53:48 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
Message-ID: <qFUjGguM_HcFyTIiUGQKjOxlsz_UQwnfwodCGukCXt4=.c6ba5b24-4611-47f7-bdaf-60aae2e93009@github.com>

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2153184927

From redestad at openjdk.org  Thu Jun  6 19:11:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 6 Jun 2024 19:11:44 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
In-Reply-To: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
Message-ID: <zzQUqqp1re7Ogtlfh1E1BA4dwWcbi9SzS1b358EZr4U=.131b33a8-6414-4fe4-b0e9-70523e255725@github.com>

On Thu, 6 Jun 2024 18:35:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.

Looks good to me. Probably should get someone to OK changes in foreign/abi (@JornVernee perhaps?).

There are some pre-existing places where we call `ReferenceClassDescImpl.ofValidated` directly that could probably be switched over to `ConstantUtils.classDesc` for slightly nicer code. Or - if it matters - add a `referenceClassDesc` which avoids the `type.isPrimitive` test.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 256:

> 254:             // the field name holding the method handle for this method
> 255:             String fieldName = "m" + count++;
> 256:             var mt = methodDesc(m.getReturnType(), JLRA.getExecutableSharedParameterTypes(m));

Suggestion:

            var md = methodDesc(m.getReturnType(), JLRA.getExecutableSharedParameterTypes(m));

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

> 467:                             // o instanceof Wrapped(float)
> 468:                             cb.aload(SELECTOR_OBJ);
> 469:                             cb.instanceOf(classDesc(Wrapper.forBasicType(classLabel)

I have a patch somewhere to cache the wrapper class desc in `sun.invoke.util.Wrapper`, both as a micro-optimization and to help disambigutate the unfortunately named (my bad) `Wrapper::classDescriptor` method. Maybe we can roll that into this..?

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 471:

> 469:                 case Allocate allocate           -> emitAllocBuffer(allocate);
> 470:                 case BoxAddress boxAddress       -> emitBoxAddress(boxAddress);
> 471:                 case SegmentBase _               -> emitSegmentBase();

Seem a bit too far detached from the changes at hand for a drive-by code cleanup?

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19585#pullrequestreview-2102953208
PR Review Comment: https://git.openjdk.org/jdk/pull/19585#discussion_r1630049028
PR Review Comment: https://git.openjdk.org/jdk/pull/19585#discussion_r1630061889
PR Review Comment: https://git.openjdk.org/jdk/pull/19585#discussion_r1630074187

From liach at openjdk.org  Thu Jun  6 19:14:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 19:14:44 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
In-Reply-To: <zzQUqqp1re7Ogtlfh1E1BA4dwWcbi9SzS1b358EZr4U=.131b33a8-6414-4fe4-b0e9-70523e255725@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <zzQUqqp1re7Ogtlfh1E1BA4dwWcbi9SzS1b358EZr4U=.131b33a8-6414-4fe4-b0e9-70523e255725@github.com>
Message-ID: <kLh90WtwM-AIyr1cTZ9MR_XoxeYB8qqhTSCqkvLFHgM=.3d2e4788-a4dd-43f5-bf3d-257de2256cd1@github.com>

On Thu, 6 Jun 2024 18:56:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 469:
> 
>> 467:                             // o instanceof Wrapped(float)
>> 468:                             cb.aload(SELECTOR_OBJ);
>> 469:                             cb.instanceOf(classDesc(Wrapper.forBasicType(classLabel)
> 
> I have a patch somewhere to cache the wrapper class desc in `sun.invoke.util.Wrapper`, both as a micro-optimization and to help disambigutate the unfortunately named (my bad) `Wrapper::classDescriptor` method. Maybe we can roll that into this..?

Feel free, or you can get your patch merged first and then I base off yours if yours is ready.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19585#discussion_r1630091038

From liach at openjdk.org  Thu Jun  6 19:24:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 19:24:14 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v2]
In-Reply-To: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
Message-ID: <Qg4RW1lFYGMclw5yos1cvYdfhit_vOJiazlxD-Yonjg=.1b4ef5fd-c00f-4676-8802-9c656ef0b300@github.com>

> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.

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

  mt -> md (desc)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19585/files
  - new: https://git.openjdk.org/jdk/pull/19585/files/cb4f6d13..3e28306f

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

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

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

From liach at openjdk.org  Thu Jun  6 19:24:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 19:24:14 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v2]
In-Reply-To: <zzQUqqp1re7Ogtlfh1E1BA4dwWcbi9SzS1b358EZr4U=.131b33a8-6414-4fe4-b0e9-70523e255725@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <zzQUqqp1re7Ogtlfh1E1BA4dwWcbi9SzS1b358EZr4U=.131b33a8-6414-4fe4-b0e9-70523e255725@github.com>
Message-ID: <SSLSM4q2UCF_k7wC-cFqyqGXxyDVJVIdDTX7MYKXeUw=.68c63c4a-125b-40f7-a17a-2ad2bb506ae6@github.com>

On Thu, 6 Jun 2024 19:01:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mt -> md (desc)
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 471:
> 
>> 469:                 case Allocate allocate           -> emitAllocBuffer(allocate);
>> 470:                 case BoxAddress boxAddress       -> emitBoxAddress(boxAddress);
>> 471:                 case SegmentBase _               -> emitSegmentBase();
> 
> Seem a bit too far detached from the changes at hand for a drive-by code cleanup?

My uncontrollable urges to fix these minor IDE warnings... Please allow these fixes, as I have similar changes in ProxyGenerator as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19585#discussion_r1630100819

From jvernee at openjdk.org  Thu Jun  6 19:42:44 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Jun 2024 19:42:44 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v2]
In-Reply-To: <Qg4RW1lFYGMclw5yos1cvYdfhit_vOJiazlxD-Yonjg=.1b4ef5fd-c00f-4676-8802-9c656ef0b300@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <Qg4RW1lFYGMclw5yos1cvYdfhit_vOJiazlxD-Yonjg=.1b4ef5fd-c00f-4676-8802-9c656ef0b300@github.com>
Message-ID: <dVYXJ4a1xp6sAJ_PQoR7T4dTvdHoFnnQ1i2Iztc_SJ4=.6ad0a9ca-e80c-4a52-be18-d9ec796fae22@github.com>

On Thu, 6 Jun 2024 19:24:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mt -> md (desc)

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 76:

> 74:      * type and parameter types can be described nominally.
> 75:      */
> 76:     public static MethodTypeDesc methodDesc(MethodType type) {

Please name these methods `methodTypeDesc`, since we also have the `Method` type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19585#discussion_r1630114413

From liach at openjdk.org  Thu Jun  6 19:46:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 19:46:47 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v2]
In-Reply-To: <zzQUqqp1re7Ogtlfh1E1BA4dwWcbi9SzS1b358EZr4U=.131b33a8-6414-4fe4-b0e9-70523e255725@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <zzQUqqp1re7Ogtlfh1E1BA4dwWcbi9SzS1b358EZr4U=.131b33a8-6414-4fe4-b0e9-70523e255725@github.com>
Message-ID: <lO70j5qO6QHB4xLOa3_fcKycI01lp8i9kovJzrue0o8=.969940da-d07c-480a-b7f3-d6a4a12a4523@github.com>

On Thu, 6 Jun 2024 19:09:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There are some pre-existing places where we call `ReferenceClassDescImpl.ofValidated` directly that could probably be switched over to `ConstantUtils.classDesc` for slightly nicer code. Or - if it matters - add a `referenceClassDesc` which avoids the `type.isPrimitive` test.

I think the main advantage of `ofValidated` is that it avoids descriptor string computation from class objects and should be kept in performance-sensitive code.

`referenceClassDesc` would be feasible for less performance-demanding code's initialization and known safe conversions (a few APIs in CF API expects non-primitive CDs already). But should its implementation be `ofValidated` or `ofValidatedBinaryName` (same question for ClassDesc)? We used `ofValidatedBinaryName` here instead of a `toClassDesc` (which calls `ofValidated` via `descriptorString`)

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

PR Comment: https://git.openjdk.org/jdk/pull/19585#issuecomment-2153281690

From smarks at openjdk.org  Thu Jun  6 19:53:32 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 6 Jun 2024 19:53:32 GMT
Subject: RFR: 8333599: Improve description of \b matcher in j.u.r.Pattern
In-Reply-To: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
References: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
Message-ID: <dnZaR6S3QpqRL0tosiRbpN8VHYV0YKpYxk03DWLsdFA=.bd28b378-3688-4713-badf-3e0c0cfacdc4@github.com>

On Thu, 6 Jun 2024 18:16:14 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A documentation-only change to match the original intent and the implemented behavior.

Looks good. The old version with the lookahead and lookbehind was hard to understand and it was inaccurate as well. The descriptive text is easier to understand and more accurate.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19583#pullrequestreview-2103079803

From prappo at openjdk.org  Thu Jun  6 20:36:12 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jun 2024 20:36:12 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v9]
In-Reply-To: <ywRvL-4RGkJ2AoxQcqT5gfZEVl7NWSaQerMVahIKeh4=.4a7ea74d-94d3-4861-bbc1-b9b671581258@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>
 <Y4jjtM0LOUI_nwzOj_DLFrS16p0s16M2DI_PbbG3DKM=.249050f8-7752-4e75-be80-3a4f701f2e30@github.com>
 <W3f84RflTWyk3NLujQfIoSwc5_qtbvMZbgYwO2WNpx8=.426b3a0f-41ae-4717-9bad-169c9b214bb6@github.com>
 <ywRvL-4RGkJ2AoxQcqT5gfZEVl7NWSaQerMVahIKeh4=.4a7ea74d-94d3-4861-bbc1-b9b671581258@github.com>
Message-ID: <ELKkLUL8Xwfy8rzY04B55p82u1glEx5PaYdwmctg_Xc=.ec716827-3b75-4c31-a267-7208c68e84a7@github.com>

On Thu, 6 Jun 2024 17:51:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Turned out that removing the classpath ends up not finding the test class:
> 
> ```
> Error: Could not find or load main class RestoreEchoTest
> Caused by: java.lang.ClassNotFoundException: RestoreEchoTest
> ];
> ```

Hm... this is surprising. On my machine, `testSrc` expands to the `JTwork/classes/0/java/io/Console/RestoreEchoTest.d` directory, which is included in `CLASSPATH` and which contains `RestoreEchoTest.class`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1630200122

From jlu at openjdk.org  Thu Jun  6 20:37:16 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Jun 2024 20:37:16 GMT
Subject: Integrated: 8333456: CompactNumberFormat integer parsing fails when
 string has no suffix
In-Reply-To: <Yz_-c-Nr6p86TFltSwsjZyjOUh_k-xEFo-s52Fczkew=.4357fab6-4ba7-4051-be91-3c9245426008@github.com>
References: <Yz_-c-Nr6p86TFltSwsjZyjOUh_k-xEFo-s52Fczkew=.4357fab6-4ba7-4051-be91-3c9245426008@github.com>
Message-ID: <nZnTRSGsqdcEgDjT9xbHhZF05JXjudqErsrs0tqd388=.348d0757-0702-4afe-9e74-12af2d314856@github.com>

On Mon, 3 Jun 2024 22:32:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which handles incorrect CompactNumberFormat integer only parsing when there is no suffix.
> 
> See the following snippet,
> 
> 
> var fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT)
> fmt.setParseIntegerOnly(true)
> fmt.parse("5K") // returns 5000
> fmt.parse("50.00") // returns 50
> fmt.parse("5") // unexpectedly throws StringIndexOutOfBoundsException 
> fmt.parse("5 ") // returns 5
> 
> 
> Within the `parse` method, there is code that advances `position` past the fractional portion to find the suffix when `parseIntegerOnly()` is true. However, if a valid string input is given with no suffix, `DecimalFormat.subparseNumber()` will fully iterate through the string and `position` will be equal to the length of the string, throwing StringIndexOutOfBoundsException when `charAt` is invoked (line 1740).
> 
> We should check to make sure position does not exceed the string length before deciding to check for a decimal symbol.

This pull request has now been integrated.

Changeset: 6238bc8d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6238bc8da2abe7a1f0cdd98c0af01e9ba1869ec3
Stats:     26 lines in 2 files changed: 24 ins; 0 del; 2 mod

8333456: CompactNumberFormat integer parsing fails when string has no suffix

Reviewed-by: naoto

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

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

From kvn at openjdk.org  Thu Jun  6 20:40:28 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 6 Jun 2024 20:40:28 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v52]
In-Reply-To: <OykcpgP4z5C1E3Fb3GaW-bhLw7gK1fC9rX3yo4Dt7d0=.e8582720-b42f-4c0c-a7f1-d09dab1014b8@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jFq_cE058-ZI-yhw7-CylWUxkUkPOP2Xu9-w1pQvY0s=.ff6a8cd0-0e1d-417a-83cd-e49d293f43dc@github.com>
 <OykcpgP4z5C1E3Fb3GaW-bhLw7gK1fC9rX3yo4Dt7d0=.e8582720-b42f-4c0c-a7f1-d09dab1014b8@github.com>
Message-ID: <xCaO5cO6pBHoFtOBRFWfFV0uwuUqIvbhcrrL3oXb4x8=.d1dbdd49-a15e-4e16-a154-310b531f9528@github.com>

On Thu, 6 Jun 2024 17:41:20 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright & a couple of comment typos
>
> Hi, everyone.  I see that JDK 23 has now been forked, and new commits go into the JDK 24 branch.  I would like to get this in as soon as possible to have as much time with fuzzers, etc. for everyone to be confident in the code.
> 
> I have 3 positive reviews on this PR and would like to integrate.  Please reply as soon as you reasonably can with objections or approval and I will integrate.  Thanks.

@asgibbons, my testing almost finished. No new failures. I think this can be pushed now. Thank you for waiting!

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2153366787

From prappo at openjdk.org  Thu Jun  6 20:57:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jun 2024 20:57:14 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v9]
In-Reply-To: <W3f84RflTWyk3NLujQfIoSwc5_qtbvMZbgYwO2WNpx8=.426b3a0f-41ae-4717-9bad-169c9b214bb6@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <kHDqMrg4idQX1IbDVC51wBVLroHYtfq2Aepz0lwGkgM=.5c6239cc-2673-4833-abf2-db4e85ce7e07@github.com>
 <Y4jjtM0LOUI_nwzOj_DLFrS16p0s16M2DI_PbbG3DKM=.249050f8-7752-4e75-be80-3a4f701f2e30@github.com>
 <W3f84RflTWyk3NLujQfIoSwc5_qtbvMZbgYwO2WNpx8=.426b3a0f-41ae-4717-9bad-169c9b214bb6@github.com>
Message-ID: <9Tt4sIajoljcLVF53TpgvjcXn6lVaRw_LVtf63bdDhk=.8ca22c8d-1cd7-4910-a027-d2599905c1fb@github.com>

On Thu, 6 Jun 2024 17:08:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/io/Console/restoreEcho.exp line 57:
>> 
>>> 55: test "$rpprompt" "$rpinput" "-echo" "$rpexpected"
>>> 56: # See if the initialEcho is restored with `stty -a`
>>> 57: expect " $initialEcho "
>> 
>> If you leave out those whitespace characters inside the quotes and `$initialEcho` expands to `-echo`, it will be treated as an option to `expect`, right? If so, consider this instead:
>> 
>>     expect -- $initialEcho
>> 
>> But more importantly: could a test match `echo` in `-echo` and therefore falsely pass?
>
> The spaces before/after `$initialEcho` are exactly to distinguish "echo" from "-echo", otherwise the test falsely succeeds as you pointed out. Although the test works as expected as it is, adding `--` would be safer.

It's clever. However, we now depend on `(-)echo` being in the middle of the line, no? If `stty -a` format (IEEE Std 1003.2) allows `(-)echo` to appear in an arbitrary position of a line, our check won't work.

If `(-)echo` appears in a leading position, it might be preceded by a TAB (similarly to `-echoprt` below). If `(-)echo` appears in a trailing position, it is followed by newline (similarly to `echoctl` below).


lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl$
^I-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo$
^I-extproc$


But I guess, it's good enough and certainly much better than the initially proposed unit test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19315#discussion_r1630230512

From dholmes at openjdk.org  Thu Jun  6 21:24:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Jun 2024 21:24:12 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
Message-ID: <XyahJbeJea0_HAaB2Lwow5sKeu4qDRhx6FAmpHot3Oo=.fff570b0-39ac-482c-99ac-b6bcf50f1f6d@github.com>

On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary
> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
> 
> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
> 
> **Testing**
> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
> - tier1

Sorry I think this is well-intentioned but unnecessary in nearly all cases. If you pass a char there is no potential problem. Only passing an actual int could be a problem.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 664:

> 662:     char after_key = line[key_len];
> 663:     if (strncmp(line, key, key_len) == 0
> 664:           && os::is_space(after_key) != 0

I think this is excessive. The value is a char so cannot be a problem. The only calls to isspace that need checking are those that actually pass an int, and even then there could be adequate safeguards in place.

src/hotspot/os/linux/os_linux.cpp line 1356:

> 1354:       if (s) {
> 1355:         // Skip blank chars
> 1356:         do { s++; } while (s && os::is_space(*s));

Again not needed.

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

PR Review: https://git.openjdk.org/jdk/pull/19567#pullrequestreview-2103234054
PR Review Comment: https://git.openjdk.org/jdk/pull/19567#discussion_r1630265925
PR Review Comment: https://git.openjdk.org/jdk/pull/19567#discussion_r1630266490

From liach at openjdk.org  Thu Jun  6 21:44:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 21:44:59 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v3]
In-Reply-To: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
Message-ID: <1IFJQFo8lSETZiScFUYARY8anru4CF5rHm_nZGId4eA=.f398ca15-0427-477f-ad0f-31a5d6e66b61@github.com>

> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.

Chen Liang 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' of https://github.com/openjdk/jdk into cleanup/consolidate-todesc
 - Add referenceClassDesc, move ReferenceClassDescImpl.ofValidatedBinaryName to ConstantUtils.binaryNameToDesc
 - mt -> md (desc)
 - Missed license header
 - Consolidate class/mt to desc operations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19585/files
  - new: https://git.openjdk.org/jdk/pull/19585/files/3e28306f..89bc5d8d

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

  Stats: 2350 lines in 73 files changed: 2189 ins; 26 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/19585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19585/head:pull/19585

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

From sgibbons at openjdk.org  Thu Jun  6 21:47:26 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 6 Jun 2024 21:47:26 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <9Gep5o1EEF96gprsHB1vDiw8KSQON-c6uh_9gBJyq9c=.43962158-2f23-4929-9e72-d4827a4fa5e8@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
 <4ZM8wZFYPZjIbjb_O6n6DNAlpYOa2EHfmhSZHVUAXNA=.b923e319-f143-4a4c-9916-face36f337db@github.com>
 <SjGmgmsLi6a72FuK8VxeKwplUzGWvPdNdtlthjqN1-Q=.b3293fa4-9a29-4b56-85ec-15c634332b42@github.com>
 <u_pbdNB9toaq3YQx8J9a7KqaFhZL2-5tGEyetJWwF1I=.fba7dc85-e0e8-441f-becb-a521df24f63d@github.com>
 <9Gep5o1EEF96gprsHB1vDiw8KSQON-c6uh_9gBJyq9c=.43962158-2f23-4929-9e72-d4827a4fa5e8@github.com>
Message-ID: <8kmAaqEcZiqqRB0MSsNG2jbHkgQ-9p3DH_AHBZsBwr0=.be5d30cd-03b4-4446-8105-1d694cd3d7e4@github.com>

On Thu, 30 May 2024 16:20:02 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @vnkozlov OK.  I'll defer to you all.  I've contacted the author of the fuzzer to see what I can do to set up a local instance.  Would this be sufficient to increase confidence for future submissions?  We can run it perpetually on fixes (provided I can set it up).  Had I done that, we could have had 6 months of fuzzing on top of our tests.  Would that have alleviated this concern?
>
> @asgibbons I generally just stop pushing ANY RFE's a week or two before the fork. Even if you did run the fuzzer with it - there are often last-minute changes. And your code here is rather large, so even if you are confident, there must be at least one bug hiding.
> 
> Running the fuzzer is nice as pre-integration, but it mostly only catches things post-integration.

@eme64 Are you OK with me integrating?

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2153456076

From naoto at openjdk.org  Thu Jun  6 21:49:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jun 2024 21:49:35 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v12]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <5ac8-ZK1FeJdtdZsG8WQRFkdOFHD1Q_aT1rKYZ19lQ4=.3205fa59-10a5-4a14-b49c-98410b82cb6d@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

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

  Loosening the timeout value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19315/files
  - new: https://git.openjdk.org/jdk/pull/19315/files/c6476270..df5f8f91

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

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

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

From liach at openjdk.org  Thu Jun  6 21:56:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Jun 2024 21:56:15 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v2]
In-Reply-To: <dVYXJ4a1xp6sAJ_PQoR7T4dTvdHoFnnQ1i2Iztc_SJ4=.6ad0a9ca-e80c-4a52-be18-d9ec796fae22@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <Qg4RW1lFYGMclw5yos1cvYdfhit_vOJiazlxD-Yonjg=.1b4ef5fd-c00f-4676-8802-9c656ef0b300@github.com>
 <dVYXJ4a1xp6sAJ_PQoR7T4dTvdHoFnnQ1i2Iztc_SJ4=.6ad0a9ca-e80c-4a52-be18-d9ec796fae22@github.com>
Message-ID: <yD8sOGf42L1PHECUsckyZ8NKh4BfKqOc-02lnRXH7bI=.1995dc5b-4e16-4b61-bc8e-6410b1beb4cf@github.com>

On Thu, 6 Jun 2024 19:30:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mt -> md (desc)
>
> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 76:
> 
>> 74:      * type and parameter types can be described nominally.
>> 75:      */
>> 76:     public static MethodTypeDesc methodDesc(MethodType type) {
> 
> Please name these methods `methodTypeDesc`, since we also have the `Method` type.

Thanks for the suggestion. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19585#discussion_r1630306158

From smarks at openjdk.org  Fri Jun  7 00:26:11 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 7 Jun 2024 00:26:11 GMT
Subject: RFR: 8333599: Improve description of \b matcher in j.u.r.Pattern
In-Reply-To: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
References: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
Message-ID: <FaW49XsLOLK1ZgfEJesSyGRzkFJpN-PiGoC0y5m0pho=.7b4bd81b-c893-4f40-96d9-df9857c31748@github.com>

On Thu, 6 Jun 2024 18:16:14 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A documentation-only change to match the original intent and the implemented behavior.

Oh, this needs a CSR too, since it's a change to a normative assertion. Should be pretty simple though.

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

PR Comment: https://git.openjdk.org/jdk/pull/19583#issuecomment-2153628785

From jpai at openjdk.org  Fri Jun  7 00:38:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Jun 2024 00:38:23 GMT
Subject: RFR: 8026127: Deflater/Inflater documentation
 incomplete/misleading [v3]
In-Reply-To: <5EcD6qP5xpBf57GZ0HXbmX2qEftWfIK9Ymj9Gz9qScM=.bae6d8ef-de5a-4a13-b5d9-9368d41b77a8@github.com>
References: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>
 <5EcD6qP5xpBf57GZ0HXbmX2qEftWfIK9Ymj9Gz9qScM=.bae6d8ef-de5a-4a13-b5d9-9368d41b77a8@github.com>
Message-ID: <7xoQEr5Ooli93ufrumtVK5GcZIPTryVuCNT0u7L07MQ=.511c7f67-2322-45b2-8e17-405c8e92bbac@github.com>

On Thu, 6 Jun 2024 14:02:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to improve the code snippet that's in `java.util.zip.Deflater` and `java.util.zip.Inflater` to better explain the usage of those classes? This addresses https://bugs.openjdk.org/browse/JDK-8026127.
>> 
>> The commit in the PR cleans up the snippet to correctly compress/decompress till the `Deflater` and `Inflater` are `finished()`.  Additionally, the snippet also shows that the `Deflater` and `Inflater` are expected to be closed when their usage it done, to release the resources held by those instances.
>> 
>> I've run `make docs-image` locally to verify that the generated snippet content as well as the link from `Inflater` work fine in the rendered javadoc HTML.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - minor change to the comment
>  - move the snippet to an external snippet

Thank you Lance for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19507#issuecomment-2153639493

From jpai at openjdk.org  Fri Jun  7 00:38:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Jun 2024 00:38:24 GMT
Subject: Integrated: 8026127: Deflater/Inflater documentation
 incomplete/misleading
In-Reply-To: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>
References: <7Iu3kTwrw2DX_FgG7f3H6N5Q-FLKNU4-mS07HcPyMTY=.f1a9c247-c49d-4513-9bde-485bc1f8e357@github.com>
Message-ID: <IyEJl8BDRKEoH-qTcNXpQ99MhoiHkOso65obR82La_w=.d7d9c2d6-1767-4277-ac78-f78249d1a1ea@github.com>

On Sat, 1 Jun 2024 04:33:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to improve the code snippet that's in `java.util.zip.Deflater` and `java.util.zip.Inflater` to better explain the usage of those classes? This addresses https://bugs.openjdk.org/browse/JDK-8026127.
> 
> The commit in the PR cleans up the snippet to correctly compress/decompress till the `Deflater` and `Inflater` are `finished()`.  Additionally, the snippet also shows that the `Deflater` and `Inflater` are expected to be closed when their usage it done, to release the resources held by those instances.
> 
> I've run `make docs-image` locally to verify that the generated snippet content as well as the link from `Inflater` work fine in the rendered javadoc HTML.

This pull request has now been integrated.

Changeset: d8af5894
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8af58941b5dedb9774c0971895c4924e57ac28b
Stats:     155 lines in 3 files changed: 96 ins; 57 del; 2 mod

8026127: Deflater/Inflater documentation incomplete/misleading

Reviewed-by: lancea

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

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

From denis.gauthier at oracle.com  Fri Jun  7 02:10:55 2024
From: denis.gauthier at oracle.com (Denis Gauthier)
Date: Fri, 7 Jun 2024 02:10:55 +0000
Subject: [External] : Status of project "Brisbane"?
In-Reply-To: <CA+3eh10N_hMYTJ9Nn4JAiznhd6NdbDjmEgHL0_R3n4sA3KnYag@mail.gmail.com>
References: <CA+3eh10N_hMYTJ9Nn4JAiznhd6NdbDjmEgHL0_R3n4sA3KnYag@mail.gmail.com>
Message-ID: <IA1PR10MB7239FDC911CD77C545AF8F04E9FB2@IA1PR10MB7239.namprd10.prod.outlook.com>

Thanks for asking, Volker.

At this stage we're still bootstrapping the project and going through internal processes to publish its OpenJDK repositories with code. We?re also juggling other projects. I can let you know once the mailing list and repository are available. In the meantime, feel free to ping me again if you don't hear anything in the next couple of months.

Best regards,

Denis

From: Volker Simonis <volker.simonis at gmail.com>
Date: Tuesday, 4 June 2024 at 1:03?AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>, security-dev <security-dev at openjdk.java.net>, Denis Gauthier <denis.gauthier at oracle.com>
Subject: [External] : Status of project "Brisbane"?
Hi,

What's the status of Project Brisbane? According to [1], the Project
was approved two month ago on April 4th, but until now I can't find it
listed on openjdk.org nor can I find a corresponding mailing list?

Best regards,
Volker

[1] https://mail.openjdk.org/pipermail/announce/2024-April/000350.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240607/37e6752e/attachment-0001.htm>

From darcy at openjdk.org  Fri Jun  7 04:53:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 7 Jun 2024 04:53:36 GMT
Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double}
Message-ID: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>

Misc small doc updates and addition of `@Overrides` annotations.

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

Commit messages:
 - JDK-8333768: Minor doc updates to java.lang.{Float, Double}

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

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

From alanb at openjdk.org  Fri Jun  7 04:58:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Jun 2024 04:58:11 GMT
Subject: RFR: 8333599: Improve description of \b matcher in j.u.r.Pattern
In-Reply-To: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
References: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
Message-ID: <qyzs7Nv-44azg_NL3GtpkvhHK11rAU4kltt4hJXFyAQ=.2bce3581-2253-4d4d-a3c6-3c0fa4f84d52@github.com>

On Thu, 6 Jun 2024 18:16:14 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A documentation-only change to match the original intent and the implemented behavior.

Yes, this one needs a CSR.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19583#pullrequestreview-2103635744

From epeter at openjdk.org  Fri Jun  7 05:08:26 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 7 Jun 2024 05:08:26 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <8kmAaqEcZiqqRB0MSsNG2jbHkgQ-9p3DH_AHBZsBwr0=.be5d30cd-03b4-4446-8105-1d694cd3d7e4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
 <4ZM8wZFYPZjIbjb_O6n6DNAlpYOa2EHfmhSZHVUAXNA=.b923e319-f143-4a4c-9916-face36f337db@github.com>
 <SjGmgmsLi6a72FuK8VxeKwplUzGWvPdNdtlthjqN1-Q=.b3293fa4-9a29-4b56-85ec-15c634332b42@github.com>
 <u_pbdNB9toaq3YQx8J9a7KqaFhZL2-5tGEyetJWwF1I=.fba7dc85-e0e8-441f-becb-a521df24f63d@github.com>
 <9Gep5o1EEF96gprsHB1vDiw8KSQON-c6uh_9gBJyq9c=.43962158-2f23-4929-9e72-d4827a4fa5e8@github.com>
 <8kmAaqEcZiqqRB0MSsNG2jbHkgQ-9p3DH_AHBZsBwr0=.be5d30cd-03b4-4446-8105-1d694cd3d7e4@github.com>
Message-ID: <0XVuJ7gECpxt76s5lju6aMOqcZK9MJ07dtlumvonwZw=.3f199acf-047c-4aee-bcc6-e3fa9f4f4bf5@github.com>

On Thu, 6 Jun 2024 21:44:44 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> @asgibbons I generally just stop pushing ANY RFE's a week or two before the fork. Even if you did run the fuzzer with it - there are often last-minute changes. And your code here is rather large, so even if you are confident, there must be at least one bug hiding.
>> 
>> Running the fuzzer is nice as pre-integration, but it mostly only catches things post-integration.
>
> @eme64 Are you OK with me integrating?

@asgibbons yes, ship it! ? 
Thanks for waiting!

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2154015592

From stuefe at openjdk.org  Fri Jun  7 06:10:12 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Jun 2024 06:10:12 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <XyahJbeJea0_HAaB2Lwow5sKeu4qDRhx6FAmpHot3Oo=.fff570b0-39ac-482c-99ac-b6bcf50f1f6d@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
 <XyahJbeJea0_HAaB2Lwow5sKeu4qDRhx6FAmpHot3Oo=.fff570b0-39ac-482c-99ac-b6bcf50f1f6d@github.com>
Message-ID: <aWrsSzJbcXI8EqFgSCctoyvzfovBHxXNEgXPy4hSaDY=.da28399d-9aee-41b9-8c04-ef43c1943919@github.com>

On Thu, 6 Jun 2024 21:21:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ### Summary
>> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
>> 
>> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
>> 
>> **Testing**
>> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
>> - tier1
>
> Sorry I think this is well-intentioned but unnecessary in nearly all cases. If you pass a char there is no potential problem. Only passing an actual int could be a problem.

@dholmes-ora 

> Sorry I think this is well-intentioned but unnecessary in nearly all cases. If you pass a char there is no potential problem. Only passing an actual int could be a problem.

Note that the issue was motivated by an Oracle engineer complaining about me using isspace on a char. That caused me to look up its behavior. Recently, we seem intent on eliminating UB, so why not.

That said, I agree that we probably don't need the wrapper. And casting to int feels awkward. I propose
- input from trusted sources, e.g. proc fs, don't need casting
- input from other sources should be casted to unsigned char (see recommendation here: https://en.cppreference.com/w/cpp/string/byte/isspace "To use these functions safely with plain chars (or signed chars), the argument should first be converted to unsigned char")

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

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2154146793

From syan at openjdk.org  Fri Jun  7 07:29:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 07:29:39 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

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

  delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19537/files
  - new: https://git.openjdk.org/jdk/pull/19537/files/0d2be363..e80b98da

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

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

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

From syan at openjdk.org  Fri Jun  7 07:29:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 07:29:39 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <LgJ6vo5urfqtMvgVKEIvWq_C8ZEGBtVtJ4T4FRb-Nls=.4c1438d7-2f22-430c-be6c-8c6ca6b6e38b@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <LgJ6vo5urfqtMvgVKEIvWq_C8ZEGBtVtJ4T4FRb-Nls=.4c1438d7-2f22-430c-be6c-8c6ca6b6e38b@github.com>
Message-ID: <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com>

On Thu, 6 Jun 2024 17:49:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile
>
> test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:
> 
>> 1: #
> 
> This file change is dubious:
> 1. It does not have any trailing whitespace that can fail the skara checks.
> 2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles)
> 
> Recommended actions: Either
> 1. Revert changes in this file;
> 2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line.

Thanks for the suggestion, the trailing blank line of `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1630767547

From redestad at openjdk.org  Fri Jun  7 08:12:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 08:12:15 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v3]
In-Reply-To: <kLh90WtwM-AIyr1cTZ9MR_XoxeYB8qqhTSCqkvLFHgM=.3d2e4788-a4dd-43f5-bf3d-257de2256cd1@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <zzQUqqp1re7Ogtlfh1E1BA4dwWcbi9SzS1b358EZr4U=.131b33a8-6414-4fe4-b0e9-70523e255725@github.com>
 <kLh90WtwM-AIyr1cTZ9MR_XoxeYB8qqhTSCqkvLFHgM=.3d2e4788-a4dd-43f5-bf3d-257de2256cd1@github.com>
Message-ID: <vxshb6fTXcvJBWRVFYYjriE5za9Ee-0KecCESXLBlt8=.b5e2889f-fb47-44c8-b0ff-eacf4c2ca0cc@github.com>

On Thu, 6 Jun 2024 19:12:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 469:
>> 
>>> 467:                             // o instanceof Wrapped(float)
>>> 468:                             cb.aload(SELECTOR_OBJ);
>>> 469:                             cb.instanceOf(classDesc(Wrapper.forBasicType(classLabel)
>> 
>> I have a patch somewhere to cache the wrapper class desc in `sun.invoke.util.Wrapper`, both as a micro-optimization and to help disambigutate the unfortunately named (my bad) `Wrapper::classDescriptor` method. Maybe we can roll that into this..?
>
> Feel free, or you can get your patch merged first and then I base off yours if yours is ready.

Created a PR you could fold into this, if you'd like: https://github.com/liachmodded/jdk/pull/1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19585#discussion_r1630816783

From redestad at openjdk.org  Fri Jun  7 08:27:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 08:27:36 GMT
Subject: RFR: 8333774: Avoid eagerly loading various EmptySpliterator classes
Message-ID: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>

Trivially move a few private static finals to their respective source type to avoid eagerly loading a few small classes.

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

Commit messages:
 - 8333774: Avoid eagerly loading various EmptySpliterator classes

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

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

From redestad at openjdk.org  Fri Jun  7 08:52:18 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 08:52:18 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v19]
In-Reply-To: <krL64OfLLSEiJPDW47dGavUERSp0t_uoqi69Mvl2VJg=.d2869909-0e08-40f8-a1a7-561e6727d209@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <UKJU_B4W3rurHvVqDbEHhwE9WPSJjjucqtfxGbyjbQA=.b519092d-09c2-4ca4-b6cd-1cdc9de9021a@github.com>
 <krL64OfLLSEiJPDW47dGavUERSp0t_uoqi69Mvl2VJg=.d2869909-0e08-40f8-a1a7-561e6727d209@github.com>
Message-ID: <kM8RGLQqJ6izNAxyLuJIAXz-PRQAdr6i7g1jHWo11is=.b8dfe19d-332d-4bba-8171-70174f3dfa7b@github.com>

On Wed, 5 Jun 2024 12:39:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   An assortment of potential improvements
>>   
>>   Co-authored-by: Claes Redestad <redestad at openjdk.org>
>
> src/java.base/share/classes/java/lang/constant/ConstantDescs.java line 356:
> 
>> 354:         ClassDesc[] fullParamTypes = new ClassDesc[paramTypes.length + prefixLen];
>> 355:         System.arraycopy(INDY_BOOTSTRAP_ARGS, 0, fullParamTypes, 0, prefixLen);
>> 356:         System.arraycopy(paramTypes, 0, fullParamTypes, prefixLen, paramTypes.length);
> 
> I'm thinking about creating a basic MethodTypeDesc like `INDY_BOOTSTRAP_TYPE = MethodTypeDesc.ofValidated(CD_Object, INDY_BOOTSTRAP_ARGS)`, and we derive bsm with 
> 
> INDY_BOOTSTRAP_TYPE
>     .insertParameterTypes(INDY_BOOTSTRAP_TYPE.parameterCount(), paramTypes)
>     .changeReturnType(returnType)
> 
> which creates two MTD wrappers but they share the same parameter array

That'd arguably be a bit cleaner. Might allocate an extra MTD (unless/until EA kicks in), but that might not matter really.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1630868455

From duke at openjdk.org  Fri Jun  7 09:29:15 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Jun 2024 09:29:15 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v3]
In-Reply-To: <1IFJQFo8lSETZiScFUYARY8anru4CF5rHm_nZGId4eA=.f398ca15-0427-477f-ad0f-31a5d6e66b61@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <1IFJQFo8lSETZiScFUYARY8anru4CF5rHm_nZGId4eA=.f398ca15-0427-477f-ad0f-31a5d6e66b61@github.com>
Message-ID: <hG_jK3MkDhAmwZY3-Re563D9t3lzBzXsomk0pAnM-Tw=.711dedce-3b34-4393-8f9b-f2aa2e1ddeef@github.com>

On Thu, 6 Jun 2024 21:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.
>
> Chen Liang 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' of https://github.com/openjdk/jdk into cleanup/consolidate-todesc
>  - Add referenceClassDesc, move ReferenceClassDescImpl.ofValidatedBinaryName to ConstantUtils.binaryNameToDesc
>  - mt -> md (desc)
>  - Missed license header
>  - Consolidate class/mt to desc operations

This?could probably also?update `Class?::describeConstable()` to use `ReferenceClassDesc?::ofValidated?(String)` for?non?hidden reference?types:
https://github.com/openjdk/jdk/blob/40b2fbd8207404961d3d23375b288cceafc3f902/src/java.base/share/classes/java/lang/Class.java#L4709-L4713

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

PR Comment: https://git.openjdk.org/jdk/pull/19585#issuecomment-2154453685

From djelinski at openjdk.org  Fri Jun  7 09:48:21 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Jun 2024 09:48:21 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
Message-ID: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>

`GetExitCodeProcess` method is not reliable for checking if a process exited already; it returns 259 (STILL_ACTIVE) if the process hasn't exited yet, but the same value is returned when the process exited with code 259. In order to check if the process exited, we need to check if its handle is in a signaled state using one of the wait methods.

This PR fixes the onExit, exitValue, isAlive, and waitFor(timeout) methods to correctly handle the problematic exit code.

I haven't fixed the ProcessImpl.toString method. I'm not sure the problem is important enough to justify an extra JNI call in the (probably typical) still-alive case.

Tier1-3 testing clean. I modified the existing OnExitTest to cover this case.

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

Commit messages:
 - More precise comment
 - exit waitForProcessExit on interrupt
 - Exclude test for exit code 259 on non-Windows systems
 - Fix waitFor
 - Fix onExit, exitValue and isProcessAlive

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

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

From liach at openjdk.org  Fri Jun  7 10:58:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 10:58:13 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <k5_jdRCvW-tujrtWjh0pDwEyw-WvLHgWWjbAFMUD9eg=.a7147486-6f7c-4b41-a497-f7c9dbbff9d1@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Thank you for the fix.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104241367

From liach at openjdk.org  Fri Jun  7 11:08:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 11:08:12 GMT
Subject: RFR: 8333774: Avoid eagerly loading various EmptySpliterator
 classes
In-Reply-To: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
References: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
Message-ID: <0_iPVvtwiBJaxQDiwpeFhkT1oykyzzdTfHst0ZKxBHU=.ac88927b-b9e8-4064-8ca6-5a6cfe99651a@github.com>

On Fri, 7 Jun 2024 08:21:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially move a few private static finals to their respective source type to avoid eagerly loading a few small classes.

Remember to update the copyright year.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/19591#pullrequestreview-2104267610

From redestad at openjdk.org  Fri Jun  7 11:34:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 11:34:16 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <sppH9ncvDF5_5dBBXP0hiDrhQzQb2EfoIQ3fANqrsow=.274e6dff-5d00-456f-acd4-e1c760d7f7d7@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <68bP4OaEhjeBisrD5wDLvmOBykXE4J_UlxO9BcFSZl8=.455e75dd-1983-4989-92cf-9101c3ff1696@github.com>
 <RmVBj_5UwgheR-GF78Hf-0PcXMnEskhhOJCt5BoSfRc=.e91d44ce-8629-46b8-b26f-ee4017108f87@github.com>
 <e2ypna3AumYuZ17RHAjCCvwDINMZLFAFUq9qATiZtAU=.f232b73e-0f01-42ef-85a5-66799a84b62a@github.com>
 <xO7_Ps9ijurfuxvXH2boY69b3-WTs45qNvX5KX3gD4o=.609c6e8b-9d47-4496-af7f-7630fc1bfd7d@github.com>
 <-iZhTXSd9kx0Eg5DOq1bAfhCKapEWykLJfft8Te4rb0=.d87c8953-599e-4b47-bfb8-a93aa1ecf38f@github.com>
 <sppH9ncvDF5_5dBBXP0hiDrhQzQb2EfoIQ3fANqrsow=.274e6dff-5d00-456f-acd4-e1c760d7f7d7@github.com>
Message-ID: <IeEWoACJPTEHP1DpGLEFjionXQn4wZeO-teF2mzXoe8=.a2838933-7bc8-49fe-9931-175fb7e4bcce@github.com>

On Wed, 5 Jun 2024 13:45:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As a note, If we would have access to the contemplated `StableValue` and `hash` was declared even as an _instance variable_ `StableValue<Integer>` in a regular class, then it would be trusted and would be eligible for constant folding due to the VM will have special rules for  fields of StableValue type.
>
> Ahh. There was a benchmark in the initial message. Sorry.

We think this is caused by the membars being conservatively emitted at method exit, and more precis membar control should help ARM. Filed: https://bugs.openjdk.org/browse/JDK-8333791

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1631071572

From prappo at openjdk.org  Fri Jun  7 12:15:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 7 Jun 2024 12:15:18 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v12]
In-Reply-To: <5ac8-ZK1FeJdtdZsG8WQRFkdOFHD1Q_aT1rKYZ19lQ4=.3205fa59-10a5-4a14-b49c-98410b82cb6d@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <5ac8-ZK1FeJdtdZsG8WQRFkdOFHD1Q_aT1rKYZ19lQ4=.3205fa59-10a5-4a14-b49c-98410b82cb6d@github.com>
Message-ID: <pgKlY6ACDXMY1j2jVFmSPtfxFUChBw_cwASIHnL46f0=.8c5fb72f-eee4-4a35-9302-06027e2f5b32@github.com>

On Thu, 6 Jun 2024 21:49:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Loosening the timeout value

Thanks for having done it, Naoto.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19315#pullrequestreview-2104391962

From redestad at openjdk.org  Fri Jun  7 12:17:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 12:17:23 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for ConstantBootstraps
 and ProxyGenerator
Message-ID: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>

This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)

I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 

Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):

Name             Cnt           Base          Error            Test          Error         Unit  Change
Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
  :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
  :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
  :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
  * = significant

Number of classes loaded drops from 1096 to 1092

Running the micro regularly shows no significant difference:

Name                              Cnt   Base   Error    Test   Error  Unit  Change
ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
  * = significant

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

Commit messages:
 - Rename microbenchmark
 - Ensure proxying for hashCode etc is 'implemented'
 - Ensure proxying for hashCode etc is 'implemented'
 - Change ProxyGenBench to provoke proxy condy
 - Improve BootstrapMethodInvoker for ConstantBootstraps and ProxyGenerator

Changes: https://git.openjdk.org/jdk/pull/19598/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19598&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333793
  Stats: 89 lines in 2 files changed: 35 ins; 24 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/19598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19598/head:pull/19598

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

From liach at openjdk.org  Fri Jun  7 12:24:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 12:24:23 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v4]
In-Reply-To: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
Message-ID: <W8NSsURgKRzYTnzDBTWW0_4J14U94brtcIsoiWO61aY=.d369d3ab-083a-411e-b2ad-5630a736b8f5@github.com>

> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.

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

  Wrapper.basic/wrapperClassDescriptor (#1)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19585/files
  - new: https://git.openjdk.org/jdk/pull/19585/files/89bc5d8d..69af091a

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

  Stats: 49 lines in 4 files changed: 17 ins; 2 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/19585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19585/head:pull/19585

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

From syan at openjdk.org  Fri Jun  7 12:31:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 12:31:13 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <oEh0z9DjI4IHMferIILJAekOzpvwEXgYdmSDj5OpXKE=.02ff3130-9015-461d-a667-11d09cf281bb@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2154735598

From liach at openjdk.org  Fri Jun  7 12:35:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 12:35:37 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v5]
In-Reply-To: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
Message-ID: <iM2icu0CbP9gSQ4YeFISoNPjpPNFG5dCH69dhMcT4QM=.3cdac156-9f3b-4b92-9511-d2e2184b65a6@github.com>

> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.

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

  One other place can use wrapperClassDescriptor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19585/files
  - new: https://git.openjdk.org/jdk/pull/19585/files/69af091a..e9ddc398

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

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

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

From redestad at openjdk.org  Fri Jun  7 12:38:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 12:38:24 GMT
Subject: RFR: 8333774: Avoid eagerly loading various EmptySpliterator
 classes [v2]
In-Reply-To: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
References: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
Message-ID: <VRHWUcd1fCKgeQiQVTDLQy4nDX1HeOtQV0wbJhXcvTo=.fb52a593-60bf-4af5-a7ae-c744dc4f17e0@github.com>

> Trivially move a few private static finals to their respective source type to avoid eagerly loading a few small classes.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - revert typo
 - Copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19591/files
  - new: https://git.openjdk.org/jdk/pull/19591/files/5eb2ddd8..9d19bbe1

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

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

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

From jwaters at openjdk.org  Fri Jun  7 12:40:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Jun 2024 12:40:13 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Marked as reviewed by jwaters (Committer).

test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50:

> 48: clean:
> 49: 	rm -f *.class .classes
> 50: 

Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet

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

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104439647
PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631140418

From jwaters at openjdk.org  Fri Jun  7 12:40:14 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Jun 2024 12:40:14 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <LgJ6vo5urfqtMvgVKEIvWq_C8ZEGBtVtJ4T4FRb-Nls=.4c1438d7-2f22-430c-be6c-8c6ca6b6e38b@github.com>
 <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com>
Message-ID: <Q9QgDVZGYXfSPaFlXOiuD6Z4x8dO840HcLH35TsCp1w=.331c4558-f7e6-4f1e-826d-d97cba13ca9c@github.com>

On Fri, 7 Jun 2024 07:26:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:
>> 
>>> 1: #
>> 
>> This file change is dubious:
>> 1. It does not have any trailing whitespace that can fail the skara checks.
>> 2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles)
>> 
>> Recommended actions: Either
>> 1. Revert changes in this file;
>> 2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line.
>
> Thanks for the suggestion, the trailing blank line of `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` has been removed.

Hmm, I'm inclined to keep the newlines at the EOF for both, what do the rest of you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631140457

From erikj at openjdk.org  Fri Jun  7 12:51:16 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 7 Jun 2024 12:51:16 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <_nZVUUX4_1rgtwNp8seD0YoqxnZLtORfjVz9m0VFNrQ=.315a1692-b84c-4eed-95db-3843f438431a@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104463763

From erikj at openjdk.org  Fri Jun  7 12:51:17 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 7 Jun 2024 12:51:17 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
Message-ID: <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>

On Fri, 7 Jun 2024 12:37:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile
>
> test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50:
> 
>> 48: clean:
>> 49: 	rm -f *.class .classes
>> 50: 
> 
> Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet

No, it's an extra newline. A file should end with a newline but one is enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631152127

From liach at openjdk.org  Fri Jun  7 12:56:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 12:56:19 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
Message-ID: <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>

On Fri, 7 Jun 2024 12:47:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50:
>> 
>>> 48: clean:
>>> 49: 	rm -f *.class .classes
>>> 50: 
>> 
>> Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet
>
> No, it's an extra newline. A file should end with a newline but one is enough.

As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631159094

From liach at openjdk.org  Fri Jun  7 12:58:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 12:58:16 GMT
Subject: RFR: 8333774: Avoid eagerly loading various EmptySpliterator
 classes [v2]
In-Reply-To: <VRHWUcd1fCKgeQiQVTDLQy4nDX1HeOtQV0wbJhXcvTo=.fb52a593-60bf-4af5-a7ae-c744dc4f17e0@github.com>
References: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
 <VRHWUcd1fCKgeQiQVTDLQy4nDX1HeOtQV0wbJhXcvTo=.fb52a593-60bf-4af5-a7ae-c744dc4f17e0@github.com>
Message-ID: <ugg0te0Rx_ongIX6QoKGqeUBkBrZv-l1u8_-HePQjxE=.cf8529ce-caf7-4a11-9332-f3a21c2c45a1@github.com>

On Fri, 7 Jun 2024 12:38:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Trivially move a few private static finals to their respective source type to avoid eagerly loading a few small classes.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert typo
>  - Copyright

Marked as reviewed by liach (Author).

src/java.base/share/classes/java/util/Spliterators.java line 89:

> 87:     }
> 88: 
> 89: 

Suggestion:


Bikeshedding to the extreme (yes, I looked for why the deletion had one less line)

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

PR Review: https://git.openjdk.org/jdk/pull/19591#pullrequestreview-2104476389
PR Review Comment: https://git.openjdk.org/jdk/pull/19591#discussion_r1631160491

From sgehwolf at openjdk.org  Fri Jun  7 12:59:26 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Jun 2024 12:59:26 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v4]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <lMFT7CaN3OM9H4id1PrbMfXZgAEdKWmiDxFAYsWdJpA=.4d825564-347e-4b48-970a-e48d9af8f5a9@github.com>

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

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

 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Add doc for mountinfo scanning.
 - Unify naming of variables
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - jcheck fixes
 - Fix tests
 - Implement Metrics.isContainerized()
 - Some clean-up
 - Drop cgroups testing on plain Linux
 - ... and 3 more: https://git.openjdk.org/jdk/compare/40b2fbd8...02884c70

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

Changes: https://git.openjdk.org/jdk/pull/18201/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=03
  Stats: 406 lines in 19 files changed: 301 ins; 78 del; 27 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 syan at openjdk.org  Fri Jun  7 13:04:18 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 13:04:18 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
 <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
Message-ID: <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>

On Fri, 7 Jun 2024 12:53:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> No, it's an extra newline. A file should end with a newline but one is enough.
>
> As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin.

I find the extra trailing newlines through below shell command:

for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i | grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done


There are only two files has been found:

./test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile
./test/jdk/java/rmi/reliability/benchmark/bench/Makefile

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631168243

From rgiulietti at openjdk.org  Fri Jun  7 13:06:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 7 Jun 2024 13:06:14 GMT
Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double}
In-Reply-To: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
References: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
Message-ID: <MXM5kghdAA5XLbPx-IooCLAqWE2tMhB-D7ay8OHlPaA=.70d72aa8-a1dc-4cff-ba6d-a4e4209be124@github.com>

On Fri, 7 Jun 2024 04:47:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Misc small doc updates and addition of `@Overrides` annotations.

src/java.base/share/classes/java/lang/Double.java line 595:

> 593:      * This method corresponds to the convertToDecimalCharacter
> 594:      * operation defined in IEEE 754.
> 595:      *

Does it?

IEEE 754 `convertToDecimalCharacter` takes a 2nd argument, the `conversionSpecification` which "specifies the precision and formatting of the _decimalCharacterSequence_ result". There's no such flexibility here.

Moreover, there seems to be no way to have a `conversionSpecification` that ensures the "shortest decimal" semantics of this method.

Finally, IEEE 754 requires to signal inexact exceptions.

Suggestion:

     * This method vaguely corresponds to the convertToDecimalCharacter


The same holds for the other additional `@apiNote`s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19590#discussion_r1631153540

From redestad at openjdk.org  Fri Jun  7 13:08:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 13:08:24 GMT
Subject: RFR: 8333774: Avoid eagerly loading various EmptySpliterator
 classes [v3]
In-Reply-To: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
References: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
Message-ID: <8nDWWM7n_ROj39uC3vEV6aa-c8aaKHfJtos6gQnI9gI=.71ae9a2f-0c95-46d4-aa73-ed80e2c39401@github.com>

> Trivially move a few private static finals to their respective source type to avoid eagerly loading a few small classes.

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

  Update src/java.base/share/classes/java/util/Spliterators.java
  
  Co-authored-by: Chen Liang <liangchenblue at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19591/files
  - new: https://git.openjdk.org/jdk/pull/19591/files/9d19bbe1..10611afd

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

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

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

From jvernee at openjdk.org  Fri Jun  7 13:23:13 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Jun 2024 13:23:13 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v5]
In-Reply-To: <iM2icu0CbP9gSQ4YeFISoNPjpPNFG5dCH69dhMcT4QM=.3cdac156-9f3b-4b92-9511-d2e2184b65a6@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <iM2icu0CbP9gSQ4YeFISoNPjpPNFG5dCH69dhMcT4QM=.3cdac156-9f3b-4b92-9511-d2e2184b65a6@github.com>
Message-ID: <VQrFGPuA1EYSPsp5YtwQYYKaZNI03_DZUC3rKMB5LVw=.6d200697-332f-450b-90fd-3c4036f75cba@github.com>

On Fri, 7 Jun 2024 12:35:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One other place can use wrapperClassDescriptor

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19585#pullrequestreview-2104537265

From jvernee at openjdk.org  Fri Jun  7 13:35:15 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Jun 2024 13:35:15 GMT
Subject: RFR: 8325984: 4 jcstress tests are failing in Tier6 4 times each
In-Reply-To: <a8yn5cIHaEn6-LrdldgH0S-krpWuYIZkPgq2hEwfH0o=.82d900dd-7fd6-431c-bbf1-3f649fab13f5@github.com>
References: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>
 <a8yn5cIHaEn6-LrdldgH0S-krpWuYIZkPgq2hEwfH0o=.82d900dd-7fd6-431c-bbf1-3f649fab13f5@github.com>
Message-ID: <jIflh3jfw0QXd_lbKpt-qDsS819XJvWjQYA10kP9PyU=.8f82fa3c-2f18-42cf-9af4-b9c4b449479a@github.com>

On Thu, 6 Jun 2024 10:48:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> These 4 tests were failing due to an incompatibility with jcstress. They were problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>> 
>> Now that jcstress has been updated (https://github.com/openjdk/jdk/pull/19332) with the relevant fix (https://github.com/openjdk/jcstress/pull/147), we can re-enable these tests.
>> 
>> Testing: I've verified that all 4 tests now pass on Linux-x64
>
> I think only Oracle CIs run these tests through jtreg wrappers? Anyway, this looks good to me.

@shipilev Do you think this is trivial enough for one reviewer?

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

PR Comment: https://git.openjdk.org/jdk/pull/19565#issuecomment-2154849759

From jwaters at openjdk.org  Fri Jun  7 13:39:19 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Jun 2024 13:39:19 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
 <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
 <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>
Message-ID: <Imr43NIlLR5rtSR9afHcUyS-oWMBu5IIUxwlRbYPMzM=.316722a5-4548-427b-bc60-f4dd35207770@github.com>

On Fri, 7 Jun 2024 13:01:15 GMT, SendaoYan <syan at openjdk.org> wrote:

>> As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin.
>
> I find the extra trailing newlines through below shell command:
> 
> for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i | grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done
> 
> 
> There are only two files has been found:
> 
> ./test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile
> ./test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Ah, I had not realized that there was more than 1 newline. GitHub's UI confused me here, so we're good to go

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631213656

From syan at openjdk.org  Fri Jun  7 13:39:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 13:39:20 GMT
Subject: Integrated: 8333477: Delete extra empty spaces in Makefiles
In-Reply-To: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
Message-ID: <oBMcuOe20h03DkwKknWriimnsZdPja6FQ6Ez2PKqS24=.2dcbde79-a11f-42b9-9255-5b1fe7e0c542@github.com>

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
> 
> Thanks.

This pull request has now been integrated.

Changeset: d130d2f4
Author:    SendaoYan <syan at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d130d2f4f46d37a2b924343de19d012c129b0a55
Stats:     11 lines in 5 files changed: 0 ins; 2 del; 9 mod

8333477: Delete extra empty spaces in Makefiles

Reviewed-by: erikj, chagedorn, liach, jwaters

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

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

From jvernee at openjdk.org  Fri Jun  7 13:46:18 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Jun 2024 13:46:18 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator
In-Reply-To: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
Message-ID: <NFQ8rb0MeO2T-hHDCey_TOOL8G9cKZrtC6SzGcp_3bs=.8fc9df10-7586-473d-bc83-120be67c01e8@github.com>

On Fri, 7 Jun 2024 12:12:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
> 
> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
> 
> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
> 
> Name             Cnt           Base          Error            Test          Error         Unit  Change
> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>   * = significant
> 
> Number of classes loaded drops from 1096 to 1092
> 
> Running the micro regularly shows no significant difference:
> 
> Name                              Cnt   Base   Error    Test   Error  Unit  Change
> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>   * = significant

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 145:

> 143:                             .invokeExact(caller, name, (MethodType)type, (MethodType)argv[0],
> 144:                                     (MethodHandle)argv[1], (MethodType)argv[2]);
> 145:                 } else if (argv.length >= 1 && bsmType == SCF_MT) {

It seems that these `argv.length` comparisons were here for cases where the wrong number of arguments are passed to a bootstrap method?

I don't see why check `argv.length > 1` is still required here... Some of the other cases are also happy to just access `argv`, (which we also do here on the next line).

If you don't think this extract check is needed, please remove this source of confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19598#discussion_r1631232730

From jvernee at openjdk.org  Fri Jun  7 13:49:12 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Jun 2024 13:49:12 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator
In-Reply-To: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
Message-ID: <fNRgestaKEj_L1jLqktsF2iX0wP6raoJ8-aisA5WGQ8=.3356f468-28e4-48a4-a701-9b80689c4b76@github.com>

On Fri, 7 Jun 2024 12:12:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
> 
> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
> 
> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
> 
> Name             Cnt           Base          Error            Test          Error         Unit  Change
> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>   * = significant
> 
> Number of classes loaded drops from 1096 to 1092
> 
> Running the micro regularly shows no significant difference:
> 
> Name                              Cnt   Base   Error    Test   Error  Unit  Change
> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>   * = significant

As an aside: I suppose we pre-generate all the linkers that get spun up for these `invokeExact`calls already. But, we might still get a little bit of mileage out of switching to `invokeBasic`, which bypasses the linkers altogether. With the caveat that we have to be very careful that the call site type is correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/19598#issuecomment-2154881850

From pminborg at openjdk.org  Fri Jun  7 13:51:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 7 Jun 2024 13:51:13 GMT
Subject: RFR: 8333774: Avoid eagerly loading various EmptySpliterator
 classes [v3]
In-Reply-To: <8nDWWM7n_ROj39uC3vEV6aa-c8aaKHfJtos6gQnI9gI=.71ae9a2f-0c95-46d4-aa73-ed80e2c39401@github.com>
References: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
 <8nDWWM7n_ROj39uC3vEV6aa-c8aaKHfJtos6gQnI9gI=.71ae9a2f-0c95-46d4-aa73-ed80e2c39401@github.com>
Message-ID: <koOPv6BPbgpU_GOsaUONv6I1yCwywWSTj2iD30BvNU8=.8ff0d24e-55c7-4e75-b10d-7fa23b16deba@github.com>

On Fri, 7 Jun 2024 13:08:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Trivially move a few private static finals to their respective source type to avoid eagerly loading a few small classes.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/Spliterators.java
>   
>   Co-authored-by: Chen Liang <liangchenblue at gmail.com>

Looks good to me. Nice observation, the laziness was for free as existing classes could be reused.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19591#pullrequestreview-2104630412

From liach at openjdk.org  Fri Jun  7 13:53:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 13:53:12 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator
In-Reply-To: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
Message-ID: <RskhXCeZBEhNRL3wOct49686NTkllUkpy9o8ARThHnM=.9b22a8fc-7c7e-43f6-b078-2e58e9d3318e@github.com>

On Fri, 7 Jun 2024 12:12:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
> 
> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
> 
> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
> 
> Name             Cnt           Base          Error            Test          Error         Unit  Change
> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>   * = significant
> 
> Number of classes loaded drops from 1096 to 1092
> 
> Running the micro regularly shows no significant difference:
> 
> Name                              Cnt   Base   Error    Test   Error  Unit  Change
> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>   * = significant

I recommend considering the `MethodHandle, Object[]` signature used by `ConstantBootstrap.invoke`: There had been previous proposals to use any method as a bootstrap method, and that API in particular can bridge that gap.

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 289:

> 287:      * bootstrap method.
> 288:      */
> 289:     private static final MethodType CONDY_GET_STATIC_FINAL_MT = MethodType.methodType(Object.class,

This type should just be called `CONDY_NO_ARG` as it's the most common form of condy that doesn't take any arg (`nullConstant` `primitiveClass` etc.)

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 296:

> 294:      * bootstrap method.
> 295:      */
> 296:     private static final MethodType CONDY_GET_STATIC_FINAL_CLASS_MT = MethodType.methodType(Object.class,

I recommend calling this `CONDY_EXTRA_CLASS`, as this is the type of `arrayVarHandle`.

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

PR Review: https://git.openjdk.org/jdk/pull/19598#pullrequestreview-2104617832
PR Review Comment: https://git.openjdk.org/jdk/pull/19598#discussion_r1631241317
PR Review Comment: https://git.openjdk.org/jdk/pull/19598#discussion_r1631250689

From liach at openjdk.org  Fri Jun  7 13:56:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 13:56:24 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v6]
In-Reply-To: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
Message-ID: <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>

> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.

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

  ExE-Boss review, go through validated path in Class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19585/files
  - new: https://git.openjdk.org/jdk/pull/19585/files/e9ddc398..d3938b4b

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

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

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

From redestad at openjdk.org  Fri Jun  7 14:14:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 14:14:13 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v6]
In-Reply-To: <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>
Message-ID: <PYRLwS_MDzw1zz_AOTzMAvqYT430bwF0fTwkfhqmJsI=.aef1dbdc-cf66-454e-ad34-61d5c2cd68ec@github.com>

On Fri, 7 Jun 2024 13:56:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ExE-Boss review, go through validated path in Class

Good incremental improvements.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19585#pullrequestreview-2104694382

From syan at openjdk.org  Fri Jun  7 14:17:19 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Jun 2024 14:17:19 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
Message-ID: <5PwXrAonDGIth_VkfWPZMDl-XFCPTLAIRunMUPsp_4g=.45fa1560-bcfb-4ac0-9bd7-03734547b09d@github.com>

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile

Thanks all for the review and sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2154937099

From shade at openjdk.org  Fri Jun  7 14:31:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 7 Jun 2024 14:31:14 GMT
Subject: RFR: 8325984: 4 jcstress tests are failing in Tier6 4 times each
In-Reply-To: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>
References: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>
Message-ID: <_uQZcxrXOnPXBMLzSk9K2itTY0HTrWILaXe_Knl1EVU=.4775cf80-a348-406c-a2ba-39350315cad8@github.com>

On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> These 4 tests were failing due to an incompatibility with jcstress. They were problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
> 
> Now that jcstress has been updated (https://github.com/openjdk/jdk/pull/19332) with the relevant fix (https://github.com/openjdk/jcstress/pull/147), we can re-enable these tests.
> 
> Testing: I've verified that all 4 tests now pass on Linux-x64

I think this is fine and trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/19565#issuecomment-2154964073

From redestad at openjdk.org  Fri Jun  7 14:53:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 14:53:16 GMT
Subject: Integrated: 8333774: Avoid eagerly loading various EmptySpliterator
 classes
In-Reply-To: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
References: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
Message-ID: <149Q3yDBfPvL3DCQIcqxzds3yV1pDLbkBhcYvjethKw=.915ca76a-970f-4629-8943-3f826f40a368@github.com>

On Fri, 7 Jun 2024 08:21:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially move a few private static finals to their respective source type to avoid eagerly loading a few small classes.

This pull request has now been integrated.

Changeset: d744059b
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d744059b5b3e944bee53536de6f404666e45e8e5
Stats:     33 lines in 1 file changed: 12 ins; 12 del; 9 mod

8333774: Avoid eagerly loading various EmptySpliterator classes

Reviewed-by: liach, pminborg

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

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

From redestad at openjdk.org  Fri Jun  7 14:53:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 14:53:15 GMT
Subject: RFR: 8333774: Avoid eagerly loading various EmptySpliterator
 classes [v3]
In-Reply-To: <8nDWWM7n_ROj39uC3vEV6aa-c8aaKHfJtos6gQnI9gI=.71ae9a2f-0c95-46d4-aa73-ed80e2c39401@github.com>
References: <4Fe9imJ4KWHoEnbAkOW53q8gGtHTUJfeu6Kr1YFUONM=.91de28a6-af33-4bfc-a3da-8a55d97bc515@github.com>
 <8nDWWM7n_ROj39uC3vEV6aa-c8aaKHfJtos6gQnI9gI=.71ae9a2f-0c95-46d4-aa73-ed80e2c39401@github.com>
Message-ID: <8rV5KPlG-P5CMzwAHEykuTeXABr26N05wrDhUEp00q0=.8c51767c-2463-4bfc-a516-a23950031b92@github.com>

On Fri, 7 Jun 2024 13:08:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Trivially move a few private static finals to their respective source type to avoid eagerly loading a few small classes.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/Spliterators.java
>   
>   Co-authored-by: Chen Liang <liangchenblue at gmail.com>

Thanks! Yes, the best holder for a singleton is typically the class itself ?

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

PR Comment: https://git.openjdk.org/jdk/pull/19591#issuecomment-2155003099

From rriggs at openjdk.org  Fri Jun  7 15:01:15 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jun 2024 15:01:15 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
Message-ID: <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>

On Thu, 6 Jun 2024 18:40:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `GetExitCodeProcess` method is not reliable for checking if a process exited already; it returns 259 (STILL_ACTIVE) if the process hasn't exited yet, but the same value is returned when the process exited with code 259. In order to check if the process exited, we need to check if its handle is in a signaled state using one of the wait methods.
> 
> This PR fixes the onExit, exitValue, isAlive, and waitFor(timeout) methods to correctly handle the problematic exit code.
> 
> I haven't fixed the ProcessImpl.toString method. I'm not sure the problem is important enough to justify an extra JNI call in the (probably typical) still-alive case.
> 
> Tier1-3 testing clean. I modified the existing OnExitTest to cover this case.

src/java.base/windows/native/libjava/ProcessHandleImpl_win.c line 128:

> 126:             JNU_ThrowByNameWithLastError(env,
> 127:                 "java/lang/RuntimeException", "WaitForMultipleObjects");
> 128:         } else if (!GetExitCodeProcess(handle, &exitValue)) {

This can return STILL_ACTIVE if there is a spurious thread interrupt.
The interrupt is presumably present to keep the thread from being stuck in a blocking windows os call.

The calling code in ProcessHandleImpl is agnostic to platform and would report the process had exited.

Can the risk of incorrectly reporting the process exit be mitigated?

If the Thread is legitimately been interrupted, Thread.interrupted() would be true and the reaper could exit.
If false, it could retry the waitForProcessExit().

src/java.base/windows/native/libjava/ProcessImpl_md.c line 471:

> 469: {
> 470:     return WaitForSingleObject((HANDLE) handle, 0) /* don't wait */
> 471:                        == WAIT_TIMEOUT;

Would this be better as `isProcessAlive(handle)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631346916
PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631322282

From jvernee at openjdk.org  Fri Jun  7 15:44:16 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 7 Jun 2024 15:44:16 GMT
Subject: Integrated: 8325984: 4 jcstress tests are failing in Tier6 4 times
 each
In-Reply-To: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>
References: <c_XMAxoym8xLDqHSLpgdLh6c9dKIFI5FoRWTL74woRw=.3a2842c2-3b63-4e4d-b41f-ade279cb8af6@github.com>
Message-ID: <FhLusMaHqvFFAUZJocX9PuvDoC2OoE86wNs6cN3RSxc=.363b0e34-dd04-4fbc-b3dc-1ecb7b57ce05@github.com>

On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> These 4 tests were failing due to an incompatibility with jcstress. They were problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
> 
> Now that jcstress has been updated (https://github.com/openjdk/jdk/pull/19332) with the relevant fix (https://github.com/openjdk/jcstress/pull/147), we can re-enable these tests.
> 
> Testing: I've verified that all 4 tests now pass on Linux-x64

This pull request has now been integrated.

Changeset: ee82346b
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee82346bd5ecf3024d6dc7b7529598099483a42c
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8325984: 4 jcstress tests are failing in Tier6 4 times each

Reviewed-by: shade

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

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

From djelinski at openjdk.org  Fri Jun  7 16:09:15 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Jun 2024 16:09:15 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
Message-ID: <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>

On Fri, 7 Jun 2024 14:58:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> `GetExitCodeProcess` method is not reliable for checking if a process exited already; it returns 259 (STILL_ACTIVE) if the process hasn't exited yet, but the same value is returned when the process exited with code 259. In order to check if the process exited, we need to check if its handle is in a signaled state using one of the wait methods.
>> 
>> This PR fixes the onExit, exitValue, isAlive, and waitFor(timeout) methods to correctly handle the problematic exit code.
>> 
>> I haven't fixed the ProcessImpl.toString method. I'm not sure the problem is important enough to justify an extra JNI call in the (probably typical) still-alive case.
>> 
>> Tier1-3 testing clean. I modified the existing OnExitTest to cover this case.
>
> src/java.base/windows/native/libjava/ProcessHandleImpl_win.c line 128:
> 
>> 126:             JNU_ThrowByNameWithLastError(env,
>> 127:                 "java/lang/RuntimeException", "WaitForMultipleObjects");
>> 128:         } else if (!GetExitCodeProcess(handle, &exitValue)) {
> 
> This can return STILL_ACTIVE if there is a spurious thread interrupt.
> The interrupt is presumably present to keep the thread from being stuck in a blocking windows os call.
> 
> The calling code in ProcessHandleImpl is agnostic to platform and would report the process had exited.
> 
> Can the risk of incorrectly reporting the process exit be mitigated?
> 
> If the Thread is legitimately been interrupted, Thread.interrupted() would be true and the reaper could exit.
> If false, it could retry the waitForProcessExit().

I only left it here because the wait for interrupt event was already present. Is being stuck in a blocking os call a bad thing? If not, I can drop the interrupt event, and wait on the process handle only.

> src/java.base/windows/native/libjava/ProcessImpl_md.c line 471:
> 
>> 469: {
>> 470:     return WaitForSingleObject((HANDLE) handle, 0) /* don't wait */
>> 471:                        == WAIT_TIMEOUT;
> 
> Would this be better as `isProcessAlive(handle)`?

I don't follow. Could you explain?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631423597
PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631424662

From naoto at openjdk.org  Fri Jun  7 16:24:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Jun 2024 16:24:23 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v12]
In-Reply-To: <5ac8-ZK1FeJdtdZsG8WQRFkdOFHD1Q_aT1rKYZ19lQ4=.3205fa59-10a5-4a14-b49c-98410b82cb6d@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <5ac8-ZK1FeJdtdZsG8WQRFkdOFHD1Q_aT1rKYZ19lQ4=.3205fa59-10a5-4a14-b49c-98410b82cb6d@github.com>
Message-ID: <a8F9S2CpV2xYq9rlPI29F7F9rnu9K8dDJrW_irgHXpM=.51bd0c8a-de71-4c69-ad51-cadb2c61edf0@github.com>

On Thu, 6 Jun 2024 21:49:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Loosening the timeout value

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/19315#issuecomment-2155153612

From naoto at openjdk.org  Fri Jun  7 16:24:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Jun 2024 16:24:25 GMT
Subject: Integrated: 8332161: Test restoring echo in the Console implementation
 (java.base)
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <gsj6dxkeDuh3Xl319o9XWe9Qwhp-ffJNCm9UaNepppo=.1211e4d2-d68e-43ab-9f46-eebf0d2b0e5e@github.com>

On Mon, 20 May 2024 18:08:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

This pull request has now been integrated.

Changeset: 25ad8623
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25ad86234a7cd6e606b273f3e63351aa07c567a3
Stats:     154 lines in 2 files changed: 154 ins; 0 del; 0 mod

8332161: Test restoring echo in the Console implementation (java.base)

Reviewed-by: joehw, prappo

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

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

From sgibbons at openjdk.org  Fri Jun  7 17:05:33 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 7 Jun 2024 17:05:33 GMT
Subject: Integrated: 8320448: Accelerate IndexOf using AVX2
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: <lvsHX8fHl68kfJLphrzsKaYlgVtyzx50ck7kne3HrMc=.1e71ec7a-5bd3-469a-b464-a28c3b913c2b@github.com>

On Tue, 21 Nov 2023 00:06:19 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

This pull request has now been integrated.

Changeset: 8e72d7cf
Author:    Scott Gibbons <sgibbons at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e72d7cf8e7dfc7eb9e66bc562f125f947e37f49
Stats:     3906 lines in 16 files changed: 3876 ins; 0 del; 30 mod

8320448: Accelerate IndexOf using AVX2

Reviewed-by: epeter, kvn, sviswanathan

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

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

From ron.pressler at oracle.com  Fri Jun  7 18:19:06 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 7 Jun 2024 18:19:06 +0000
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
Message-ID: <EC28C797-4E09-4086-9D2F-200AED65B4BD@oracle.com>


> On 6 Jun 2024, at 18:37, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> Just bumping this one more time. I intend to start by opening a JIRA to add the two proposed methods to `ReflectionFactory`, and go from there. I guess that we might need a JEP for the proposed serialization restrictions, which is going to be considerably more involved, so I'm putting that off as a second step for now, pending further discussion.


Hi. 

Seven years before the upcoming delivery of JEP 471 we [announced that the world of accessing JDK internals would be coming to an end](https://openjdk.org/jeps/260). Four years later, the JDK [started enforcing that](https://openjdk.org/jeps/403), but to give extra time to laggards who have not yet adapted to either refraining from accessing internals or instructing their users on the proper configuration of the JDK to allow doing so, we left some unsupported mechanisms in place to temporarily allow hacking around the restrictions until they can properly adapt. Now, three years later, we're starting the process of removing the temporary hacks, although we don't yet know how long the process should last.

My first question is, how many more years do you think we should wait for libraries to finish the process by which they either refrain from accessing internals or instruct their users on the proper configuration that allows them to do so? Knowing how long we should wait for the libraries that have not yet finished their adaptation in the past seven years, and how far along they are in the process, could help inform how long we should wait until the actual removal of Unsafe.

My second question has to do with the consideration that any serialization procedure should no longer bypass constructors (at least not without `--add-opens`, that is). I'd be interested to know about the difficulties serialization libraries have encountered in their process of migrating away from accessing internals and toward custom serializers for JDK classes, such as what public constructors are missing. This would help us identify what constructors we should add to support serialization that doesn't violate integrity.

? Ron

From duke at openjdk.org  Fri Jun  7 18:30:14 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Jun 2024 18:30:14 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v6]
In-Reply-To: <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>
Message-ID: <5HOOm-feUCYEaq-1D08UZSMraZ7VPH-qNKnZHXu3D_E=.e3cdcf7c-08a4-45d1-b3c3-05f72f0e6f0d@github.com>

On Fri, 7 Jun 2024 13:56:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ExE-Boss review, go through validated path in Class

`ClassDesc?::of?(String)`, `ClassDesc?::of?(String, String)`, and?`ClassDesc?::ofInternalName?(String)` can?probably call?`ReferenceClassDescImpl?::ofValidated?(String)`?directly as?those?methods already?perform?validation before?forwarding to?`ClassDesc?::ofDescriptor?(String)`.

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

PR Comment: https://git.openjdk.org/jdk/pull/19585#issuecomment-2155321459

From duke at openjdk.org  Fri Jun  7 18:42:12 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Jun 2024 18:42:12 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator
In-Reply-To: <RskhXCeZBEhNRL3wOct49686NTkllUkpy9o8ARThHnM=.9b22a8fc-7c7e-43f6-b078-2e58e9d3318e@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <RskhXCeZBEhNRL3wOct49686NTkllUkpy9o8ARThHnM=.9b22a8fc-7c7e-43f6-b078-2e58e9d3318e@github.com>
Message-ID: <oAJzwiawaRcj6H6Z-Xvl16whWDTCnnRIUri7iAno7r0=.77589ef3-4fd4-4a82-9ef3-8135f16508bd@github.com>

On Fri, 7 Jun 2024 13:45:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
>> 
>> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
>> 
>> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
>> 
>> Name             Cnt           Base          Error            Test          Error         Unit  Change
>> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>>   * = significant
>> 
>> Number of classes loaded drops from 1096 to 1092
>> 
>> Running the micro regularly shows no significant difference:
>> 
>> Name                              Cnt   Base   Error    Test   Error  Unit  Change
>> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>>   * = significant
>
> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 289:
> 
>> 287:      * bootstrap method.
>> 288:      */
>> 289:     private static final MethodType CONDY_GET_STATIC_FINAL_MT = MethodType.methodType(Object.class,
> 
> This type should just be called `CONDY_NO_ARG` as it's the most common form of condy that doesn't take any arg (`nullConstant` `primitiveClass` etc.)

Note?that [`ConstantBootstraps?::primitiveClass?(Lookup, String, Class)`] has?a?static return?type of?`Class?<???>`, so?the?following is?also?needed:

/**
 * Exact type used of the {@link ConstantBootstraps#primitiveClass(Lookup, String, Class)}
 * bootstrap method.
 */
private static final MethodType CONDY_CLASS_NO_ARG_MT
	= CONDY_GET_STATIC_FINAL_MT.changeReturnType(Class.class);


[`ConstantBootstraps?::primitiveClass?(Lookup, String, Class)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/invoke/ConstantBootstraps.html#primitiveClass(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19598#discussion_r1631570980

From duke at openjdk.org  Fri Jun  7 18:43:25 2024
From: duke at openjdk.org (duke)
Date: Fri, 7 Jun 2024 18:43:25 GMT
Subject: Withdrawn: 8324573: HashMap::putAll add notes for conservative
 resizing
In-Reply-To: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
References: <b1hnHt8ZU_Nxlc-otSzZN30JA5oT02q5WOucSb-kUS4=.c06b285d-5e46-4376-aa59-a8c4cd0a9485@github.com>
Message-ID: <Xtqkac_vibf3n81G7iIlV_JnOOSHSfFs7TH59lIs-8Y=.0e31551b-3996-47ca-8ffc-935cd0f1949b@github.com>

On Wed, 24 Jan 2024 00:26:09 GMT, Joshua Cao <duke at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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

From redestad at openjdk.org  Fri Jun  7 18:50:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 18:50:11 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator
In-Reply-To: <oAJzwiawaRcj6H6Z-Xvl16whWDTCnnRIUri7iAno7r0=.77589ef3-4fd4-4a82-9ef3-8135f16508bd@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <RskhXCeZBEhNRL3wOct49686NTkllUkpy9o8ARThHnM=.9b22a8fc-7c7e-43f6-b078-2e58e9d3318e@github.com>
 <oAJzwiawaRcj6H6Z-Xvl16whWDTCnnRIUri7iAno7r0=.77589ef3-4fd4-4a82-9ef3-8135f16508bd@github.com>
Message-ID: <oXR_uPYJ610MZId3VvTrAeneyhKq3VnOj3KgG1NdN9Q=.62c05776-b9c0-4f97-9d66-731c3fbc599c@github.com>

On Fri, 7 Jun 2024 18:38:52 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 289:
>> 
>>> 287:      * bootstrap method.
>>> 288:      */
>>> 289:     private static final MethodType CONDY_GET_STATIC_FINAL_MT = MethodType.methodType(Object.class,
>> 
>> This type should just be called `CONDY_NO_ARG` as it's the most common form of condy that doesn't take any arg (`nullConstant` `primitiveClass` etc.)
>
> Note?that [`ConstantBootstraps?::primitiveClass?(Lookup, String, Class)`] has?a?static return?type of?`Class?<???>`, so?the?following is?also?needed:
> 
> /**
>  * Exact type used of the {@link ConstantBootstraps#primitiveClass(Lookup, String, Class)}
>  * bootstrap method.
>  */
> private static final MethodType CONDY_CLASS_NO_ARG_MT
> 	= CONDY_GET_STATIC_FINAL_MT.changeReturnType(Class.class);
> 
> 
> [`ConstantBootstraps?::primitiveClass?(Lookup, String, Class)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/invoke/ConstantBootstraps.html#primitiveClass(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)

It's not the intent of this PR to exhaustively enumerate all methods in `ConstantBootstraps`, primarily those shown to be bootstrap sensitive in some app. I've so far never seen a use of `primitiveClass` (and I admit being ignorant as to why this even exists as a BSM) so I don't have any reason to believe special-casing it will carry its own weight.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19598#discussion_r1631578674

From redestad at openjdk.org  Fri Jun  7 18:58:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 18:58:36 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
Message-ID: <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>

> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
> 
> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
> 
> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
> 
> Name             Cnt           Base          Error            Test          Error         Unit  Change
> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>   * = significant
> 
> Number of classes loaded drops from 1096 to 1092
> 
> Running the micro regularly shows no significant difference:
> 
> Name                              Cnt   Base   Error    Test   Error  Unit  Change
> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>   * = significant

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

  Adress review comments, add ConstantBootstraps#invoke to list of recognized type signatures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19598/files
  - new: https://git.openjdk.org/jdk/pull/19598/files/21f945b5..532966a4

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

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

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

From redestad at openjdk.org  Fri Jun  7 18:58:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 7 Jun 2024 18:58:36 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator
In-Reply-To: <fNRgestaKEj_L1jLqktsF2iX0wP6raoJ8-aisA5WGQ8=.3356f468-28e4-48a4-a701-9b80689c4b76@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <fNRgestaKEj_L1jLqktsF2iX0wP6raoJ8-aisA5WGQ8=.3356f468-28e4-48a4-a701-9b80689c4b76@github.com>
Message-ID: <LcT3wY7ZrjrSKXSi2rW0EM0PONjquroUUIL05F0Woo8=.977e6aab-30c6-468e-bfaa-4a0182acf846@github.com>

On Fri, 7 Jun 2024 13:46:22 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As an aside: I suppose we pre-generate all the linkers that get spun up for these `invokeExact`calls already. But, we might still get a little bit of mileage out of switching to `invokeBasic`, which bypasses the linkers altogether. With the caveat that we have to be very careful that the call site type is correct.

I'm not sure I see what linkers you're alluding to here in profiles (and I don't think we have code pre-generating all of them), and I don't see how to use `invokeBasic` here instead. Care to elaborate?

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

PR Comment: https://git.openjdk.org/jdk/pull/19598#issuecomment-2155357245

From liach at openjdk.org  Fri Jun  7 19:21:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 19:21:15 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v6]
In-Reply-To: <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>
Message-ID: <VAR8b1YI7VFW9Q64iW8xDwhJz6-DwU-HO79E-jssQwQ=.c543dc74-4877-4de7-80b2-9d8df52ab4cf@github.com>

On Fri, 7 Jun 2024 13:56:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ExE-Boss review, go through validated path in Class

No: they are missing checks against initial, trailing, or consecutive . or / separators. We can do that in a future patch, with proper test additions.

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

PR Comment: https://git.openjdk.org/jdk/pull/19585#issuecomment-2155386076

From liach at openjdk.org  Fri Jun  7 19:25:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 19:25:13 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <oXR_uPYJ610MZId3VvTrAeneyhKq3VnOj3KgG1NdN9Q=.62c05776-b9c0-4f97-9d66-731c3fbc599c@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <RskhXCeZBEhNRL3wOct49686NTkllUkpy9o8ARThHnM=.9b22a8fc-7c7e-43f6-b078-2e58e9d3318e@github.com>
 <oAJzwiawaRcj6H6Z-Xvl16whWDTCnnRIUri7iAno7r0=.77589ef3-4fd4-4a82-9ef3-8135f16508bd@github.com>
 <oXR_uPYJ610MZId3VvTrAeneyhKq3VnOj3KgG1NdN9Q=.62c05776-b9c0-4f97-9d66-731c3fbc599c@github.com>
Message-ID: <oH_E3Vg_jbecrGU9_zSaOj40NQGy1Al8zz1cLphi7cg=.f9c0028a-da71-4bf6-af34-8fc4d45cb2b4@github.com>

On Fri, 7 Jun 2024 18:47:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Note?that [`ConstantBootstraps?::primitiveClass?(Lookup, String, Class)`] has?a?static return?type of?`Class?<???>`, so?the?following is?also?needed:
>> 
>> /**
>>  * Exact type used of the {@link ConstantBootstraps#primitiveClass(Lookup, String, Class)}
>>  * bootstrap method.
>>  */
>> private static final MethodType CONDY_CLASS_NO_ARG_MT
>> 	= CONDY_GET_STATIC_FINAL_MT.changeReturnType(Class.class);
>> 
>> 
>> [`ConstantBootstraps?::primitiveClass?(Lookup, String, Class)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/invoke/ConstantBootstraps.html#primitiveClass(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)
>
> It's not the intent of this PR to exhaustively enumerate all methods in `ConstantBootstraps`, primarily those shown to be bootstrap sensitive in some app. I've so far never seen a use of `primitiveClass` (and I admit being ignorant as to why this even exists as a BSM) so I don't have any reason to believe special-casing it will carry its own weight.

For its existence, I think it was the same as null, that they weren't representable by cp entries for bootstrap method args. They are now backed by PrimitiveClassDescImpl, a type of condy, and ClassFile API currently writes loadConstant(primitiveCd) as a condy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19598#discussion_r1631606873

From rriggs at openjdk.org  Fri Jun  7 20:39:15 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jun 2024 20:39:15 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
 <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
Message-ID: <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>

On Fri, 7 Jun 2024 16:05:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/windows/native/libjava/ProcessHandleImpl_win.c line 128:
>> 
>>> 126:             JNU_ThrowByNameWithLastError(env,
>>> 127:                 "java/lang/RuntimeException", "WaitForMultipleObjects");
>>> 128:         } else if (!GetExitCodeProcess(handle, &exitValue)) {
>> 
>> This can return STILL_ACTIVE if there is a spurious thread interrupt.
>> The interrupt is presumably present to keep the thread from being stuck in a blocking windows os call.
>> 
>> The calling code in ProcessHandleImpl is agnostic to platform and would report the process had exited.
>> 
>> Can the risk of incorrectly reporting the process exit be mitigated?
>> 
>> If the Thread is legitimately been interrupted, Thread.interrupted() would be true and the reaper could exit.
>> If false, it could retry the waitForProcessExit().
>
> I only left it here because the wait for interrupt event was already present. Is being stuck in a blocking os call a bad thing? If not, I can drop the interrupt event, and wait on the process handle only.

I think waiting on JVM_GetThreadInterruptEvent() is necessary during VM shutdown to allow the blocked thread to exit cleanly.

>> src/java.base/windows/native/libjava/ProcessImpl_md.c line 471:
>> 
>>> 469: {
>>> 470:     return WaitForSingleObject((HANDLE) handle, 0) /* don't wait */
>>> 471:                        == WAIT_TIMEOUT;
>> 
>> Would this be better as `isProcessAlive(handle)`?
>
> I don't follow. Could you explain?

The `WaitForSingleObject(handle, 0)` seems like an indirect way to determine if the process is alive.
Whereas `isProcessAlive(handle)` seems to directly answer the question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631664185
PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631662973

From djelinski at openjdk.org  Fri Jun  7 20:55:12 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Jun 2024 20:55:12 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
 <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
 <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
Message-ID: <BQWdPgm5klDn6cfNGKPy91dO4Tq-wo5tWfgEySD0lTo=.358fb59e-216b-46f3-a692-6376286ec961@github.com>

On Fri, 7 Jun 2024 20:35:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I don't follow. Could you explain?
>
> The `WaitForSingleObject(handle, 0)` seems like an indirect way to determine if the process is alive.
> Whereas `isProcessAlive(handle)` seems to directly answer the question.

sorry, I still don't get it. Are you telling me that I should use isProcessAlive to implement isProcessAlive? Because it doesn't look like a WinAPI function name,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631676183

From djelinski at openjdk.org  Fri Jun  7 20:59:11 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Jun 2024 20:59:11 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
 <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
 <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
Message-ID: <6FHMmdtAGyWE8HqW4etXrG0VSKrTektVEUXgJ2TXqs4=.bbaf0570-12eb-440a-848d-41674e8d29c6@github.com>

On Fri, 7 Jun 2024 20:36:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I only left it here because the wait for interrupt event was already present. Is being stuck in a blocking os call a bad thing? If not, I can drop the interrupt event, and wait on the process handle only.
>
> I think waiting on JVM_GetThreadInterruptEvent() is necessary during VM shutdown to allow the blocked thread to exit cleanly.

Interesting. Could you point me to a related bug / documentation / evidence? I tested the WaitForSingleObject version (commit 6524747a5ebc51c760b14e90309c5f18b58b20e2) on Windows 11, and I didn't observe any problems with shutting down the VM

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631678678

From rriggs at openjdk.org  Fri Jun  7 21:03:11 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jun 2024 21:03:11 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <BQWdPgm5klDn6cfNGKPy91dO4Tq-wo5tWfgEySD0lTo=.358fb59e-216b-46f3-a692-6376286ec961@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
 <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
 <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
 <BQWdPgm5klDn6cfNGKPy91dO4Tq-wo5tWfgEySD0lTo=.358fb59e-216b-46f3-a692-6376286ec961@github.com>
Message-ID: <QocJYpYvjMGCsURWJNXRsQ9lKxVCTS0z_wioWJhx5Zo=.5d133f6d-eb77-4d81-9f17-c6f5081763cc@github.com>

On Fri, 7 Jun 2024 20:52:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> The `WaitForSingleObject(handle, 0)` seems like an indirect way to determine if the process is alive.
>> Whereas `isProcessAlive(handle)` seems to directly answer the question.
>
> sorry, I still don't get it. Are you telling me that I should use isProcessAlive to implement isProcessAlive? Because it doesn't look like a WinAPI function name,

I take it back.
It was just wishful thinking that Windows had the obvious API.
And I've intermingled Java methods for native methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631681720

From darcy at openjdk.org  Fri Jun  7 21:10:22 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 7 Jun 2024 21:10:22 GMT
Subject: RFR: 8333828: Use value javadoc tag in java.lang.{Float, Double}
Message-ID: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>

Use the value tag to make the javadoc for various format-related constants more informative to readers. Currently the information is available by following the "Constant Field Values" link.

I'll reflow the paragraphs before a push.

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

Commit messages:
 - JDK-8333828: Use value javadoc tag in java.lang.{Float, Double}

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

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

From rriggs at openjdk.org  Fri Jun  7 21:16:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Jun 2024 21:16:13 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <6FHMmdtAGyWE8HqW4etXrG0VSKrTektVEUXgJ2TXqs4=.bbaf0570-12eb-440a-848d-41674e8d29c6@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
 <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
 <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
 <6FHMmdtAGyWE8HqW4etXrG0VSKrTektVEUXgJ2TXqs4=.bbaf0570-12eb-440a-848d-41674e8d29c6@github.com>
Message-ID: <t1kt8CwjhkTbcmm_zMN1Snm51vm43q1___6Dase4cNE=.a5ffde16-91a6-47e6-b4e0-77d516e0494e@github.com>

On Fri, 7 Jun 2024 20:56:03 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I think waiting on JVM_GetThreadInterruptEvent() is necessary during VM shutdown to allow the blocked thread to exit cleanly.
>
> Interesting. Could you point me to a related bug / documentation / evidence? I tested the WaitForSingleObject version (commit 6524747a5ebc51c760b14e90309c5f18b58b20e2) on Windows 11, and I didn't observe any problems with shutting down the VM

I don't have a test or counter example and don't have a detailed understanding of the blocking needs of Hotspot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1631701117

From jjg at openjdk.org  Fri Jun  7 22:03:12 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 7 Jun 2024 22:03:12 GMT
Subject: RFR: 8333828: Use value javadoc tag in java.lang.{Float, Double}
In-Reply-To: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
References: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
Message-ID: <zcI2svYGPTrY5YMPeHjjZE7y23tLLnhD2jqXPfWFlp8=.f8501e1d-01e8-4ed3-8063-0c84b960e60b@github.com>

On Fri, 7 Jun 2024 21:05:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use the value tag to make the javadoc for various format-related constants more informative to readers. Currently the information is available by following the "Constant Field Values" link.
> 
> I'll reflow the paragraphs before a push.

You can omit the field name from a `{@value ...}` tag if the tag is in the doc comment for that field.   Thus, in most if not all the cases here, you can simplify all tags to just `{@value}`.

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

PR Review: https://git.openjdk.org/jdk/pull/19607#pullrequestreview-2105442388

From liach at openjdk.org  Fri Jun  7 22:03:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 22:03:12 GMT
Subject: RFR: 8333828: Use value javadoc tag in java.lang.{Float, Double}
In-Reply-To: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
References: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
Message-ID: <Xd1yAgVjIRg9TP3Cip3FmP79UEbEJr_dr4bATwB4LQc=.325f89a4-d005-45aa-bbbb-a902ee048de5@github.com>

On Fri, 7 Jun 2024 21:05:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use the value tag to make the javadoc for various format-related constants more informative to readers. Currently the information is available by following the "Constant Field Values" link.
> 
> I'll reflow the paragraphs before a push.

Since you are using the value tag on the field themselves to display their own value, I believe a `{@value}` suffices. See the example in java.lang.constant.ConstantDescs: https://github.com/openjdk/jdk/blob/cf677c901e70d98404ec9cc3d75a93926e02fcd2/src/java.base/share/classes/java/lang/constant/ConstantDescs.java#L307
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/constant/ConstantDescs.html#INIT_NAME

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

PR Comment: https://git.openjdk.org/jdk/pull/19607#issuecomment-2155627548

From liach at openjdk.org  Fri Jun  7 22:06:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 22:06:17 GMT
Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base
 [v6]
In-Reply-To: <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
 <Ankdv_rE80DyUN75ei6-5iKayHKQwG1807zOb-N76fs=.409f14e6-1455-4094-afa9-ea9a5aadf66c@github.com>
Message-ID: <NqZOdB1fACOMTdch7L0W720oUaf3AUmNHF3LU8foJN4=.8579a04c-d79b-44ae-b9ba-90792ca0b8a8@github.com>

On Fri, 7 Jun 2024 13:56:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ExE-Boss review, go through validated path in Class

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/19585#issuecomment-2155630141

From darcy at openjdk.org  Fri Jun  7 22:16:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 7 Jun 2024 22:16:36 GMT
Subject: RFR: 8333828: Use value javadoc tag in java.lang.{Float,
 Double} [v2]
In-Reply-To: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
References: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
Message-ID: <8EttkjTur6Og1vappqkT2az4EOh5G4FU2nA_b1anHYw=.80dd6f49-5182-4146-8e04-6f31e212b3aa@github.com>

> Use the value tag to make the javadoc for various format-related constants more informative to readers. Currently the information is available by following the "Constant Field Values" link.
> 
> I'll reflow the paragraphs before a push.

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/19607/files
  - new: https://git.openjdk.org/jdk/pull/19607/files/ab3b9e38..ea23aaf0

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

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

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

From liach at openjdk.org  Fri Jun  7 22:24:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Jun 2024 22:24:26 GMT
Subject: RFR: 8333828: Use value javadoc tag in java.lang.{Float,
 Double} [v2]
In-Reply-To: <8EttkjTur6Og1vappqkT2az4EOh5G4FU2nA_b1anHYw=.80dd6f49-5182-4146-8e04-6f31e212b3aa@github.com>
References: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
 <8EttkjTur6Og1vappqkT2az4EOh5G4FU2nA_b1anHYw=.80dd6f49-5182-4146-8e04-6f31e212b3aa@github.com>
Message-ID: <9x1mwCraK3PlFykkeK1M_ZijoktK_8c9pEhq7aHYM90=.6f5968d4-e013-4759-b91f-061b6fb3a475@github.com>

On Fri, 7 Jun 2024 22:16:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Use the value tag to make the javadoc for various format-related constants more informative to readers. Currently the information is available by following the "Constant Field Values" link.
>> 
>> I'll reflow the paragraphs before a push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

Thanks for this simplification!

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/19607#pullrequestreview-2105458016

From duke at openjdk.org  Sat Jun  8 02:52:41 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 8 Jun 2024 02:52:41 GMT
Subject: RFR: 8327791: UUID toString removes the use of ByteArrayLittleEndian
Message-ID: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>

After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

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

Commit messages:
 - optimization for UUID toString

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

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

From duke at openjdk.org  Sat Jun  8 02:52:41 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 8 Jun 2024 02:52:41 GMT
Subject: RFR: 8327791: UUID toString removes the use of
 ByteArrayLittleEndian
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <n051qzp8_UCdWkPA0D0q-XrLsKGAhmAbHrJb_kYtrPs=.5a8775a2-9bfe-4905-88f8-7a05bdb63cc8@github.com>

On Sat, 8 Jun 2024 00:19:55 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

The performance numbers under MacBookPro M1 Max are as follows: 


-Benchmark           (size)   Mode  Cnt    Score   Error   Units (#master 8ffc35d117846a7a2aa08afed662273d2f887770 )
-UUIDBench.toString   20000  thrpt   15  103.904 ? 0.772  ops/us

+Benchmark           (size)   Mode  Cnt    Score   Error   Units (# current 30373b81fddbf7e82340e466cf6425a5252399d2 )
+UUIDBench.toString   20000  thrpt   15  109.529 ? 1.156  ops/us + 5.41%

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2155757438

From liach at openjdk.org  Sat Jun  8 06:03:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Jun 2024 06:03:17 GMT
Subject: RFR: 8327791: UUID toString removes the use of
 ByteArrayLittleEndian
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <XBOleVYSdqDomB6Zgaa1Kmo6pCb09xrvVP2W9wsvE3E=.defd7d7b-4542-4cb3-9afa-6d29447bc1ef@github.com>

On Sat, 8 Jun 2024 00:19:55 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

I think you mean bug ID 8333833, right?

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 123:

> 121:      */
> 122:     public static void putHex(byte[] buffer, int off, int i) {
> 123:         int v = (DIGITS[i & 0xff] << 16) | DIGITS[(i >> 8) & 0xff];

Looking at the comments in #16245, it's said that the int must be computed beforehand so it will be a write of a 4-byte instead of 2 write of 2-bytes. Is that understanding correct?

If my understanding is correct, I recommend to leave a comment explaining why we compact the value into an int, like

// Prepare an int value so C2 generates a 4-byte write instead of two 2-byte writes

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

PR Review: https://git.openjdk.org/jdk/pull/19610#pullrequestreview-2105776831
PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1631885732

From duke at openjdk.org  Sat Jun  8 06:40:39 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 8 Jun 2024 06:40:39 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

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

  add comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19610/files
  - new: https://git.openjdk.org/jdk/pull/19610/files/30373b81..ace7a9f6

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

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

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

From duke at openjdk.org  Sat Jun  8 12:28:11 2024
From: duke at openjdk.org (Sunmisc Unsafe)
Date: Sat, 8 Jun 2024 12:28:11 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
Message-ID: <2ZsyLWBqAF4daDjtkpfOaVNk6UsRuexVlZM5bKPxezc=.b4b3ec9b-6402-40ad-b19c-7cb3a461dac0@github.com>

On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

As far as I know, ByteArrayLittleEndian uses the VarHandle mechanism, which more efficiently writes different primitives into the array, unlike the basic

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2156018093

From redestad at openjdk.org  Sat Jun  8 13:06:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 8 Jun 2024 13:06:13 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <oH_E3Vg_jbecrGU9_zSaOj40NQGy1Al8zz1cLphi7cg=.f9c0028a-da71-4bf6-af34-8fc4d45cb2b4@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <RskhXCeZBEhNRL3wOct49686NTkllUkpy9o8ARThHnM=.9b22a8fc-7c7e-43f6-b078-2e58e9d3318e@github.com>
 <oAJzwiawaRcj6H6Z-Xvl16whWDTCnnRIUri7iAno7r0=.77589ef3-4fd4-4a82-9ef3-8135f16508bd@github.com>
 <oXR_uPYJ610MZId3VvTrAeneyhKq3VnOj3KgG1NdN9Q=.62c05776-b9c0-4f97-9d66-731c3fbc599c@github.com>
 <oH_E3Vg_jbecrGU9_zSaOj40NQGy1Al8zz1cLphi7cg=.f9c0028a-da71-4bf6-af34-8fc4d45cb2b4@github.com>
Message-ID: <hlkgZ68QB65fLQDvflNMHSZbs9sNH1B9YY2Ymf4yJeM=.8ca4c09a-49b3-4ca8-a117-13849e579f0b@github.com>

On Fri, 7 Jun 2024 19:22:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> It's not the intent of this PR to exhaustively enumerate all methods in `ConstantBootstraps`, primarily those shown to be bootstrap sensitive in some app. I've so far never seen a use of `primitiveClass` (and I admit being ignorant as to why this even exists as a BSM) so I don't have any reason to believe special-casing it will carry its own weight.
>
> For its existence, I think it was the same as null, that they weren't representable by cp entries for bootstrap method args. They are now backed by PrimitiveClassDescImpl, a type of condy, and ClassFile API currently writes loadConstant(primitiveCd) as a condy.

I am sure there's a perfectly good explanation why we've done it like that rather than translating things like javac would (AFAICT a load from `Integer/Short/Byte/...TYPE`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19598#discussion_r1632041009

From liach at openjdk.org  Sat Jun  8 13:08:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Jun 2024 13:08:16 GMT
Subject: Integrated: 8333749: Consolidate ConstantDesc conversion in java.base
In-Reply-To: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
References: <fpYXoor5kgYZBsIZx7slct4GgTaeknJrZcy9rwyXvqI=.df8d058d-002e-4f75-9125-61e8f6dda106@github.com>
Message-ID: <zIoXm_Ib_YcXrhZQUwm9MlBFq3DV5_HhcMDgLXS8cL8=.593c193a-18be-464c-b3a2-03e3ceb3fb6a@github.com>

On Thu, 6 Jun 2024 18:35:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance.

This pull request has now been integrated.

Changeset: 8d2f9e57
Author:    Chen Liang <liach at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d2f9e57c3797c01c84df007f4d2bfdcd645d0c0
Stats:     255 lines in 13 files changed: 113 ins; 47 del; 95 mod

8333749: Consolidate ConstantDesc conversion in java.base

Co-authored-by: Claes Redestad <redestad at openjdk.org>
Reviewed-by: redestad, jvernee

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

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

From liach at openjdk.org  Sat Jun  8 13:18:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Jun 2024 13:18:13 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
Message-ID: <Dz_4oWHZb0OVu-tqt2JhPfA3s1OADyHHqvPmXj2GJQk=.436429aa-6c9c-447c-9c36-0aa54537d6cb@github.com>

On Fri, 7 Jun 2024 18:58:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
>> 
>> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
>> 
>> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
>> 
>> Name             Cnt           Base          Error            Test          Error         Unit  Change
>> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>>   * = significant
>> 
>> Number of classes loaded drops from 1096 to 1092
>> 
>> Running the micro regularly shows no significant difference:
>> 
>> Name                              Cnt   Base   Error    Test   Error  Unit  Change
>> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adress review comments, add ConstantBootstraps#invoke to list of recognized type signatures

I think Jorn is recommending to use invokeBasic with erased types as how LambdaForm does it. We can try that approach, but we need new tests to verify that bootstrap method type mismatches throw the same exceptions, so that should be another RFE.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/19598#pullrequestreview-2105846859

From liach at openjdk.org  Sat Jun  8 13:26:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Jun 2024 13:26:11 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <2ZsyLWBqAF4daDjtkpfOaVNk6UsRuexVlZM5bKPxezc=.b4b3ec9b-6402-40ad-b19c-7cb3a461dac0@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
 <2ZsyLWBqAF4daDjtkpfOaVNk6UsRuexVlZM5bKPxezc=.b4b3ec9b-6402-40ad-b19c-7cb3a461dac0@github.com>
Message-ID: <EwqLWq0h3kPxmt9DdOtq_wT0v1be22DMQbyXBt4dBL0=.82346089-a2dd-4f1c-8226-9967b72073d4@github.com>

On Sat, 8 Jun 2024 12:25:54 GMT, Sunmisc Unsafe <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comments
>
> As far as I know, ByteArrayLittleEndian uses the VarHandle mechanism, which more efficiently writes different primitives into the array, unlike the basic

@sunmisc BALE uses byte array view VH which still uses Unsafe: https://github.com/openjdk/jdk/blob/8d2f9e57c3797c01c84df007f4d2bfdcd645d0c0/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L141

Please take a look at #16245; you will see that C2 now JIT compiles these compatible "different primitives" like Unsafe would do, yet there's a bit of requirement on code shape. Thus I recommended the comment for wenshao, so future changes won't accidentally destroy the code shape and the optimization.

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2156036174

From duke at openjdk.org  Sat Jun  8 13:42:15 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 8 Jun 2024 13:42:15 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
Message-ID: <r4bnvRUPhS960a5_EBCp3EcllDBHbmcd5KV78ouQdRs=.d10246b1-abc8-40e0-92bd-8f4e7a1df066@github.com>

On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

The C2 optimization brought by PR #16245 makes many of the previous performance improvement techniques based on VarHandle/ByteArray/Unsafe no longer meaningful, and many optimizations based on this need to be changed back.

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2156040853

From liach at openjdk.org  Sat Jun  8 13:52:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Jun 2024 13:52:13 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
Message-ID: <1B01zmFFNBVQKAUnXm63jdTUjD9PcuDLE6aUKijDmxU=.2cfb18fa-5933-4ba8-80c4-40ef0b3ddbaa@github.com>

On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

And in addition, VarHandle is not initialized unless it's necessary; thus, programs that use UUIDs but not VarHandle no longer need to initialize VarHandle. See #15386 where JDK startup has a performance degradation because it had to initialize VarHandle after using BALE.

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2156044329

From liach at openjdk.org  Sat Jun  8 14:27:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Jun 2024 14:27:12 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
Message-ID: <jti0TFDXcjyCSPE3yK093PiyAD4xJ8s0_0tRUU4DWzY=.aca2976c-589f-4c10-90c5-f87b72208205@github.com>

On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/19610#pullrequestreview-2105860441

From duke at openjdk.org  Sat Jun  8 14:51:11 2024
From: duke at openjdk.org (Glavo)
Date: Sat, 8 Jun 2024 14:51:11 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
Message-ID: <TN7v8R9-6tLoUyrZdnJfoTssu3kicnXcrVwJiRDNvds=.bd989977-e982-4a92-9e68-20d5c11528ae@github.com>

On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

I think we don't need to change them back everywhere, but only need to rewrite `ByteArrayLittleEndian` and `ByteArray` so that they no longer use `VarHandle`. 

Maybe I should rewrite https://github.com/openjdk/jdk/pull/14636 without using `Unsafe`, so more people might agree with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2156063742

From duke at openjdk.org  Sat Jun  8 15:54:15 2024
From: duke at openjdk.org (Brett Okken)
Date: Sat, 8 Jun 2024 15:54:15 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
Message-ID: <VdleqtbcjVgDyKpUmObuu26syLiUgdqRcU0yRETzy2Y=.d5bbff2d-1feb-4dd0-a118-052ce22cabe2@github.com>

On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 117:

> 115: 
> 116:     /**
> 117:      * Insert the int into the buffer as 4 hexadecimal digits

4 hex digits is 2 bytes, right? 
should this take a short instead?
At a minimum, seems documentation should be clear as to which 2 bytes are used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632064197

From duke at openjdk.org  Sat Jun  8 16:23:16 2024
From: duke at openjdk.org (Brett Okken)
Date: Sat, 8 Jun 2024 16:23:16 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
Message-ID: <XcdxHMM3yTjBgdh4IN9_G2BHfc2IqP3dTJEF9r2phqU=.584eea36-4b99-4d62-855e-8e46a66ca58c@github.com>

On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 122:

> 120:      * @param value to convert
> 121:      */
> 122:     public static void putHex(byte[] buffer, int off, int i) {

Should there be 2 methods - for 2 and 4 bytes respectively?
Does c2 optimize 8 byte writes as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632068305

From duke at openjdk.org  Sat Jun  8 17:26:20 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Sat, 8 Jun 2024 17:26:20 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
Message-ID: <TMdrOfjafQ1yYfmDdAimmkIbTAaIeue4mXq02o8Bx0Q=.9e01ac95-eb85-4c5a-872f-ca857e2148c1@github.com>

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @SuppressWarnings (serial)

Version for other data types is being prepared

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2156111460

From liach at openjdk.org  Sat Jun  8 18:04:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Jun 2024 18:04:13 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <VdleqtbcjVgDyKpUmObuu26syLiUgdqRcU0yRETzy2Y=.d5bbff2d-1feb-4dd0-a118-052ce22cabe2@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
 <VdleqtbcjVgDyKpUmObuu26syLiUgdqRcU0yRETzy2Y=.d5bbff2d-1feb-4dd0-a118-052ce22cabe2@github.com>
Message-ID: <mXgNtDUnWGAlQ53rM7NdUVtrfHAjjJ0qlNqM4I2H_xU=.b08249d3-e595-405f-8e2b-cb5b2e4fb4e8@github.com>

On Sat, 8 Jun 2024 15:51:13 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comments
>
> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 117:
> 
>> 115: 
>> 116:     /**
>> 117:      * Insert the int into the buffer as 4 hexadecimal digits
> 
> 4 hex digits is 2 bytes, right? 
> should this take a short instead?
> At a minimum, seems documentation should be clear as to which 2 bytes are used.

Yes, 4 hex digits requires 2 bytes of input integer; we always take the least significant bytes. I think taking an int is better than taking a short, as subint types are int in bytecode, and short's signedness may be bug-prone.

> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 122:
> 
>> 120:      * @param value to convert
>> 121:      */
>> 122:     public static void putHex(byte[] buffer, int off, int i) {
> 
> Should there be 2 methods - for 2 and 4 bytes respectively?
> Does c2 optimize 8 byte writes as well?

The 4-byte unsigned int input for 8-byte write sounds plausible, I personally am fine either with or without it.

> Does c2 optimize 8 byte writes as well?

>From the first few lines of #16245:

> Merging multiple consecutive small stores (e.g. 8 byte stores) into larger stores (e.g. one long store) can lead to speedup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632081700
PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632082369

From duke at openjdk.org  Sat Jun  8 20:40:13 2024
From: duke at openjdk.org (Bernd)
Date: Sat, 8 Jun 2024 20:40:13 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
Message-ID: <SMZT6Zk6kvs2kdRU0pE9wALBUrdgnSPq2Z0rKtC9JwE=.0404db1b-0e44-4180-af66-f235267fc16b@github.com>

On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Changes requested by ecki at github.com (no known OpenJDK username).

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 120:

> 118:      * @param buffer byte buffer to copy into
> 119:      * @param off insert point
> 120:      * @param value to convert

The parameter is called i. Maybe also add "Only least significant 16 bits are used." Even when it's only a internal api.

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

PR Review: https://git.openjdk.org/jdk/pull/19610#pullrequestreview-2105936973
PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632105594

From duke at openjdk.org  Sat Jun  8 23:30:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 8 Jun 2024 23:30:38 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v3]
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <SGJTRkp9vkcwzVhR3PZcrdVJcGPmR7ZWYsuHBowO1rI=.7cefe22f-4eba-4b3c-9135-e20748ac4b20@github.com>

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

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

  change method name, putHex -> putHex4, and fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19610/files
  - new: https://git.openjdk.org/jdk/pull/19610/files/ace7a9f6..d6b4ed25

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

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

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

From duke at openjdk.org  Sat Jun  8 23:52:12 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 8 Jun 2024 23:52:12 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v2]
In-Reply-To: <mXgNtDUnWGAlQ53rM7NdUVtrfHAjjJ0qlNqM4I2H_xU=.b08249d3-e595-405f-8e2b-cb5b2e4fb4e8@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <d_Fpu953tJkZa7zbLFX5WT0NqfYSwLoNOd6aXWQLt9I=.946b6361-f91a-4130-9f16-2cd27a9696c5@github.com>
 <VdleqtbcjVgDyKpUmObuu26syLiUgdqRcU0yRETzy2Y=.d5bbff2d-1feb-4dd0-a118-052ce22cabe2@github.com>
 <mXgNtDUnWGAlQ53rM7NdUVtrfHAjjJ0qlNqM4I2H_xU=.b08249d3-e595-405f-8e2b-cb5b2e4fb4e8@github.com>
Message-ID: <ip3_KiFHORu3PzQcf7JwwHGuDnuurWnwhNuorlalYK4=.fc4997fb-1de5-48cb-a5e0-de0956c887b5@github.com>

On Sat, 8 Jun 2024 18:00:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 122:
>> 
>>> 120:      * @param value to convert
>>> 121:      */
>>> 122:     public static void putHex(byte[] buffer, int off, int i) {
>> 
>> Should there be 2 methods - for 2 and 4 bytes respectively?
>> Does c2 optimize 8 byte writes as well?
>
> The 4-byte unsigned int input for 8-byte write sounds plausible, I personally am fine either with or without it.
> 
>> Does c2 optimize 8 byte writes as well?
> 
> From the first few lines of #16245:
> 
>> Merging multiple consecutive small stores (e.g. 8 byte stores) into larger stores (e.g. one long store) can lead to speedup.

8-byte writing requires converting int to long. The performance is similar to the current version, but an additional method putHex8 needs to be added. The current version has less code.

The following is the code for writing 8 bytes:

class UUID {
     @Override
    public String toString() {
        byte[] buf = new byte[36];
        HexDigits.putHex8(buf, 0, (int) (mostSigBits >> 32));
        HexDigits.putHex10(buf, 8, (int) mostSigBits);
        HexDigits.putHex10(buf, 18, (int) (leastSigBits >> 32));
        HexDigits.putHex8(buf, 28, (int) leastSigBits);
        try {
            return jla.newStringNoRepl(buf, StandardCharsets.ISO_8859_1);
        } catch (CharacterCodingException cce) {
            throw new AssertionError(cce);
        }
    }
}

class HexDigits {
    public static void putHex8(byte[] bytes, int off, int i) {
        long v =  (((long) DIGITS[(i >> 16) & 0xff]) << 48)
                | (((long) DIGITS[(i >> 24) & 0xff]) << 32)
                | (        DIGITS[ i        & 0xff]  << 16)
                | (        DIGITS[(i >> 8 ) & 0xff]);
        bytes[off]     = (byte)  v;
        bytes[off + 1] = (byte) (v >> 8);
        bytes[off + 2] = (byte) (v >> 16);
        bytes[off + 3] = (byte) (v >> 24);
        bytes[off + 4] = (byte) (v >> 32);
        bytes[off + 5] = (byte) (v >> 40);
        bytes[off + 6] = (byte) (v >> 48);
        bytes[off + 7] = (byte) (v >> 56);
    }

    public static void putHex10(byte[] bytes, int off, int i) {
        int v0 = (DIGITS[(i >> 16) & 0xff] << 16)
                | DIGITS[(i >> 24) & 0xff];
        int v1 = (DIGITS[i         & 0xff] << 16)
                | DIGITS[(i >> 8 ) & 0xff];
        bytes[off]     = '-';
        bytes[off + 1] = (byte)  v0;
        bytes[off + 2] = (byte) (v0 >> 8);
        bytes[off + 3] = (byte) (v0 >> 16);
        bytes[off + 4] = (byte) (v0 >> 24);
        bytes[off + 5] = '-';
        bytes[off + 6] = (byte)  v1;
        bytes[off + 7] = (byte) (v1 >> 8);
        bytes[off + 8] = (byte) (v1 >> 16);
        bytes[off + 9] = (byte) (v1 >> 24);
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632133853

From duke at openjdk.org  Sun Jun  9 01:19:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 9 Jun 2024 01:19:13 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v3]
In-Reply-To: <SGJTRkp9vkcwzVhR3PZcrdVJcGPmR7ZWYsuHBowO1rI=.7cefe22f-4eba-4b3c-9135-e20748ac4b20@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <SGJTRkp9vkcwzVhR3PZcrdVJcGPmR7ZWYsuHBowO1rI=.7cefe22f-4eba-4b3c-9135-e20748ac4b20@github.com>
Message-ID: <QxjZRqvNq3eIb9YcGrHJN7YMMYybga45dIVJl990H0U=.37e4ed9d-a4e1-4367-a5f4-ea52e9104b0c@github.com>

On Sat, 8 Jun 2024 23:30:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change method name, putHex -> putHex4, and fix comments

> I think we don't need to change them back everywhere, but only need to rewrite `ByteArrayLittleEndian` and `ByteArray` so that they no longer use `VarHandle`.
> 
> Maybe I should rewrite #14636 without using `Unsafe`, so more people might agree with it.

You are right, ByteArray and ByteArrayLittleEndian have good performance after removing Unsafe. This is similar to the previous version of java.io.Bits


class ByteArrayLittleEndian {
    public static void setInt(byte[] array, int offset, int value) {
        array[offset    ] = (byte)  value;
        array[offset + 1] = (byte) (value >> 8);
        array[offset + 2] = (byte) (value >> 16);
        array[offset + 3] = (byte) (value >> 24);
    }
}

class HexDigits {
    public static void putHex4(byte[] array, int offset, int value) {
        // Prepare an int value so C2 generates a 4-byte write instead of two 2-byte writes
        ByteArrayLittleEndian.setInt(
                array,
                offset,
                (DIGITS[value & 0xff] << 16) | DIGITS[(value >> 8) & 0xff]);
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2156255748

From duke at openjdk.org  Sun Jun  9 04:30:23 2024
From: duke at openjdk.org (Glavo)
Date: Sun, 9 Jun 2024 04:30:23 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v3]
In-Reply-To: <QxjZRqvNq3eIb9YcGrHJN7YMMYybga45dIVJl990H0U=.37e4ed9d-a4e1-4367-a5f4-ea52e9104b0c@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <SGJTRkp9vkcwzVhR3PZcrdVJcGPmR7ZWYsuHBowO1rI=.7cefe22f-4eba-4b3c-9135-e20748ac4b20@github.com>
 <QxjZRqvNq3eIb9YcGrHJN7YMMYybga45dIVJl990H0U=.37e4ed9d-a4e1-4367-a5f4-ea52e9104b0c@github.com>
Message-ID: <1tSdi5opwr0s0mk55mnpmWXeUmtuBU8WVMKeDIn1pPo=.4cfb4d4a-168e-4865-a673-86389965e014@github.com>

On Sun, 9 Jun 2024 01:16:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> You are right, ByteArray and ByteArrayLittleEndian have good performance after removing Unsafe. This is similar to the previous version of java.io.Bits

Do you have evidence that `VarHandle` affects startup time? If there is good evidence to support this, I would go ahead and rewrite https://github.com/openjdk/jdk/pull/14636.

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2156311883

From duke at openjdk.org  Sun Jun  9 05:47:17 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 9 Jun 2024 05:47:17 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v3]
In-Reply-To: <SGJTRkp9vkcwzVhR3PZcrdVJcGPmR7ZWYsuHBowO1rI=.7cefe22f-4eba-4b3c-9135-e20748ac4b20@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <SGJTRkp9vkcwzVhR3PZcrdVJcGPmR7ZWYsuHBowO1rI=.7cefe22f-4eba-4b3c-9135-e20748ac4b20@github.com>
Message-ID: <odnBdRrdlrqaZl4K4Wb0iCnymhRhgTjrR9UC0xI9O1w=.06b050ef-6643-45d3-9ff9-55aa460cadeb@github.com>

On Sat, 8 Jun 2024 23:30:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change method name, putHex -> putHex4, and fix comments

> > You are right, ByteArray and ByteArrayLittleEndian have good performance after removing Unsafe. This is similar to the previous version of java.io.Bits
> 
> Do you have evidence that `VarHandle` affects startup time? If there is good evidence to support this, I would go ahead and rewrite #14636.

@cl4es has fixed startup regression issues, such as this https://github.com/openjdk/jdk/pull/15836

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2156332130

From liach at openjdk.org  Sun Jun  9 07:03:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 9 Jun 2024 07:03:18 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v3]
In-Reply-To: <SGJTRkp9vkcwzVhR3PZcrdVJcGPmR7ZWYsuHBowO1rI=.7cefe22f-4eba-4b3c-9135-e20748ac4b20@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <SGJTRkp9vkcwzVhR3PZcrdVJcGPmR7ZWYsuHBowO1rI=.7cefe22f-4eba-4b3c-9135-e20748ac4b20@github.com>
Message-ID: <RA1oIpAnz5WDf1Rl-_DqvJoCqKOf9sG9zT7_F4ieF_g=.d223e8a2-d540-42bc-976b-aee2fd093680@github.com>

On Sat, 8 Jun 2024 23:30:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change method name, putHex -> putHex4, and fix comments

src/java.base/share/classes/java/util/UUID.java line 1:

> 1: /*

We can update copyright year to 2024

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 1:

> 1: /*

We can update copyright header to `Copyright (c) 2023, 2024, Oracle ...`

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 118:

> 116:     /**
> 117:      * Insert the unsigned 2-byte integer into the buffer as 4 hexadecimal digit ASCII bytes,
> 118:      * {@code i} only least significant 16 bits are used.

Suggestion:

     * only least significant 16 bits of {@code i} are used.

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 123:

> 121:      * @param i to convert
> 122:      */
> 123:     public static void putHex4(byte[] buffer, int off, int i) {

I recommend the name `put4`. `Hex` is redundant within the context of `HexDigits`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632187884
PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632187984
PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632187743
PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632187666

From duke at openjdk.org  Sun Jun  9 07:15:43 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 9 Jun 2024 07:15:43 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v4]
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <NSoehR3WExidM0c2IttiWNZYaNNozvj7A-3rQ47NmzU=.456e67dd-eeb4-4f7d-879a-8b8d3136d5ba@github.com>

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

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

  Update src/java.base/share/classes/jdk/internal/util/HexDigits.java
  
  Co-authored-by: Chen Liang <liangchenblue at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19610/files
  - new: https://git.openjdk.org/jdk/pull/19610/files/d6b4ed25..7628536f

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

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

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

From duke at openjdk.org  Sun Jun  9 07:22:39 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 9 Jun 2024 07:22:39 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v5]
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <-LkwuSJsiVDstrSYOytzcy2LNwWPl8rpO8AUb73BjLc=.89ec9667-03fe-4785-838f-2e29f790d44c@github.com>

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - rename putHex4 to put4
 - update copy right year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19610/files
  - new: https://git.openjdk.org/jdk/pull/19610/files/7628536f..5696288f

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

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

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

From redestad at openjdk.org  Sun Jun  9 20:00:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 9 Jun 2024 20:00:13 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v5]
In-Reply-To: <-LkwuSJsiVDstrSYOytzcy2LNwWPl8rpO8AUb73BjLc=.89ec9667-03fe-4785-838f-2e29f790d44c@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <-LkwuSJsiVDstrSYOytzcy2LNwWPl8rpO8AUb73BjLc=.89ec9667-03fe-4785-838f-2e29f790d44c@github.com>
Message-ID: <CLPngLkAIcHNQcfk_uN5nE61rU_tSQCEva3VewxSctM=.f7a9ff95-5a42-462b-a2c1-bbbc53bf029b@github.com>

On Sun, 9 Jun 2024 07:22:39 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename putHex4 to put4
>  - update copy right year

Glad to see #16245 in action, enabling simpler code with equal or better performance.

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 123:

> 121:      * @param i to convert
> 122:      */
> 123:     public static void put4(byte[] buffer, int off, int i) {

Perhaps `index` and `value` are better names than `off` and `i`, respectively.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19610#pullrequestreview-2106355754
PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632380045

From duke at openjdk.org  Sun Jun  9 22:45:26 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 9 Jun 2024 22:45:26 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v6]
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <cBGbXUSxt4oYcCuogBccnwAJxAjZsSu-iyXEaZccP8s=.64901889-dc68-46dc-80f2-6877306f3490@github.com>

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

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

  better parameter names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19610/files
  - new: https://git.openjdk.org/jdk/pull/19610/files/5696288f..035a07ab

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

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

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

From liach at openjdk.org  Sun Jun  9 22:51:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 9 Jun 2024 22:51:16 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v6]
In-Reply-To: <cBGbXUSxt4oYcCuogBccnwAJxAjZsSu-iyXEaZccP8s=.64901889-dc68-46dc-80f2-6877306f3490@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <cBGbXUSxt4oYcCuogBccnwAJxAjZsSu-iyXEaZccP8s=.64901889-dc68-46dc-80f2-6877306f3490@github.com>
Message-ID: <ExSGmTSlWv6qGv8rqKFJu-xgCIAzeJVIPnUP1UKz5gA=.b209b7e1-6db6-4568-94a9-5bb5ed9025a1@github.com>

On Sun, 9 Jun 2024 22:45:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better parameter names

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/19610#pullrequestreview-2106382827

From liach at openjdk.org  Mon Jun 10 01:37:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Jun 2024 01:37:43 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
Message-ID: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>

Please review this patch that fixes a critical issue that breaks some Proxy usages.

CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.

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

Commit messages:
 - Minor cleanup
 - 8333854: IllegalAccessError with proxies after JDK-8332457

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

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

From duke at openjdk.org  Mon Jun 10 02:16:18 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 10 Jun 2024 02:16:18 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v6]
In-Reply-To: <cBGbXUSxt4oYcCuogBccnwAJxAjZsSu-iyXEaZccP8s=.64901889-dc68-46dc-80f2-6877306f3490@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <cBGbXUSxt4oYcCuogBccnwAJxAjZsSu-iyXEaZccP8s=.64901889-dc68-46dc-80f2-6877306f3490@github.com>
Message-ID: <xdW8paOYgI8tQEog69D2TSQS6-rym9hOQ5oUVVgJnN8=.b4717e83-8d1d-4c08-b421-acea3eb632ed@github.com>

On Sun, 9 Jun 2024 22:45:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better parameter names

I opened https://github.com/openjdk/jdk/pull/19616, let's continue the unfinished discussion in https://github.com/openjdk/jdk/pull/14636 there.

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2157056267

From duke at openjdk.org  Mon Jun 10 02:17:25 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 10 Jun 2024 02:17:25 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe
Message-ID: <NTuestJIqqBcmJg7R1xSWxUjeGPQdeXthA0GaIzPiBY=.ab21a23d-7be4-4bfd-8336-4584e6f3b342@github.com>

Things have changed since https://github.com/openjdk/jdk/pull/14636 was closed, so let me reopen it.

https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE caused a startup regression. In order to not have any more revert patches, it makes sense to optimize BALE.

The optimization of https://github.com/openjdk/jdk/pull/16245 allows the traditional expression to have good performance, but BA and BALE save us from having to copy these lengthy expressions everywhere. So it makes sense to keep them.

Now here's the question, should I rewrite this PR without `Unsafe`? I'll do some research (e.g. does `Unsafe` have better performance during warmup?), but I'd also like to take some advice.

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

Commit messages:
 - 8310843: Reimplement ByteArray and ByteArrayLittleEndian with Unsafe

Changes: https://git.openjdk.org/jdk/pull/19616/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19616&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310843
  Stats: 683 lines in 3 files changed: 444 ins; 95 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/19616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19616/head:pull/19616

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

From dholmes at openjdk.org  Mon Jun 10 02:38:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 02:38:25 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
Message-ID: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>

Sets the version to 24/24-ea and the copyright year to 2025.

Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.

This initial generation also picks up the unpublished changes from: 

- JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
- JDK-8284500: Typo in Supported Named Extensions - BasicContraints
- JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class

Thanks

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

Commit messages:
 - 8330205: Initial troff manpage generation for JDK 24

Changes: https://git.openjdk.org/jdk/pull/19617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330205
  Stats: 66 lines in 28 files changed: 12 ins; 13 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/19617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617

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

From liach at openjdk.org  Mon Jun 10 03:25:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Jun 2024 03:25:17 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe
In-Reply-To: <NTuestJIqqBcmJg7R1xSWxUjeGPQdeXthA0GaIzPiBY=.ab21a23d-7be4-4bfd-8336-4584e6f3b342@github.com>
References: <NTuestJIqqBcmJg7R1xSWxUjeGPQdeXthA0GaIzPiBY=.ab21a23d-7be4-4bfd-8336-4584e6f3b342@github.com>
Message-ID: <71JH0aiLOdX0-ChyOphMiFlmfH9gOMuw9_-8g6xuX4Y=.de414522-b6f9-4792-aa7c-60af27871efb@github.com>

On Mon, 10 Jun 2024 02:12:11 GMT, Glavo <duke at openjdk.org> wrote:

> Things have changed since https://github.com/openjdk/jdk/pull/14636 was closed, so let me reopen it.
> 
> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE caused a startup regression. In order to not have any more revert patches, it makes sense to optimize BALE.
> 
> The optimization of https://github.com/openjdk/jdk/pull/16245 allows the traditional expression to have good performance, but BA and BALE save us from having to copy these lengthy expressions everywhere. So it makes sense to keep them.
> 
> Now here's the question, should I rewrite this PR without `Unsafe`? I'll do some research (e.g. does `Unsafe` have better performance during warmup?), but I'd also like to take some advice.

No matter if we use unsafe or not, keeping multi-byte write and read operations all to one class so we can update them altogether sounds like a good idea. The only risk is that some operations will happen in early startup, such as ClassFile processing, which prohibits some implementations like VarHandle.

Also feel free to choose another title for this patch, I will update the JBS issue for you.

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

PR Comment: https://git.openjdk.org/jdk/pull/19616#issuecomment-2157121539

From duke at openjdk.org  Mon Jun 10 03:51:40 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 10 Jun 2024 03:51:40 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v2]
In-Reply-To: <NTuestJIqqBcmJg7R1xSWxUjeGPQdeXthA0GaIzPiBY=.ab21a23d-7be4-4bfd-8336-4584e6f3b342@github.com>
References: <NTuestJIqqBcmJg7R1xSWxUjeGPQdeXthA0GaIzPiBY=.ab21a23d-7be4-4bfd-8336-4584e6f3b342@github.com>
Message-ID: <GqClPnYoe_m09iMqUkGge5KXTcILeop4NmBhZPKEPxc=.4917ae11-3cad-40d0-a09d-d025e6391532@github.com>

> Things have changed since https://github.com/openjdk/jdk/pull/14636 was closed, so let me reopen it.
> 
> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE caused a startup regression. In order to not have any more revert patches, it makes sense to optimize BALE.
> 
> The optimization of https://github.com/openjdk/jdk/pull/16245 allows the traditional expression to have good performance, but BA and BALE save us from having to copy these lengthy expressions everywhere. So it makes sense to keep them.
> 
> Now here's the question, should I rewrite this PR without `Unsafe`? I'll do some research (e.g. does `Unsafe` have better performance during warmup?), but I'd also like to take some advice.

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

  update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19616/files
  - new: https://git.openjdk.org/jdk/pull/19616/files/b3920c86..332bb270

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

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

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

From liach at openjdk.org  Mon Jun 10 04:08:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Jun 2024 04:08:41 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v2]
In-Reply-To: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
Message-ID: <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>

> Please review this patch that fixes a critical issue that breaks some Proxy usages.
> 
> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.

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

  Obtain classloader in security manager friendly code path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19615/files
  - new: https://git.openjdk.org/jdk/pull/19615/files/8e8dcdd0..8448db2a

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

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

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

From pminborg at openjdk.org  Mon Jun 10 07:03:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 07:03:11 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v2]
In-Reply-To: <GqClPnYoe_m09iMqUkGge5KXTcILeop4NmBhZPKEPxc=.4917ae11-3cad-40d0-a09d-d025e6391532@github.com>
References: <NTuestJIqqBcmJg7R1xSWxUjeGPQdeXthA0GaIzPiBY=.ab21a23d-7be4-4bfd-8336-4584e6f3b342@github.com>
 <GqClPnYoe_m09iMqUkGge5KXTcILeop4NmBhZPKEPxc=.4917ae11-3cad-40d0-a09d-d025e6391532@github.com>
Message-ID: <h7addAPoDa_5cOdfd2lUNhMq7sUm7kzqKbZmIhYU2JY=.74cefb9c-8362-47d3-92dc-9e2d8e70fea4@github.com>

On Mon, 10 Jun 2024 03:51:40 GMT, Glavo <duke at openjdk.org> wrote:

>> Things have changed since https://github.com/openjdk/jdk/pull/14636 was closed, so let me reopen it.
>> 
>> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE caused a startup regression. In order to not have any more revert patches, it makes sense to optimize BALE.
>> 
>> The optimization of https://github.com/openjdk/jdk/pull/16245 allows the traditional expression to have good performance, but BA and BALE save us from having to copy these lengthy expressions everywhere. So it makes sense to keep them.
>> 
>> Now here's the question, should I rewrite this PR without `Unsafe`? I'll do some research (e.g. does `Unsafe` have better performance during warmup?), but I'd also like to take some advice.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

Would it be possible to add a benchmark for some of the methods here so we can see if there is a difference? Also, it would be interesting to see if startup performance is impacted.

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

PR Comment: https://git.openjdk.org/jdk/pull/19616#issuecomment-2157489839

From alanb at openjdk.org  Mon Jun 10 07:18:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 07:18:11 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118

From duke at openjdk.org  Mon Jun 10 07:32:26 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 10 Jun 2024 07:32:26 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v7]
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <Y_btkkFfkJpGmmdVn32iTieFQRko0_cngHnC9ZnQ70M=.90085e20-59fc-4eb9-8e5b-f92dea65617c@github.com>

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

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

  Update src/java.base/share/classes/jdk/internal/util/HexDigits.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19610/files
  - new: https://git.openjdk.org/jdk/pull/19610/files/035a07ab..780abdf1

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

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

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

From redestad at openjdk.org  Mon Jun 10 07:32:27 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 07:32:27 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v6]
In-Reply-To: <cBGbXUSxt4oYcCuogBccnwAJxAjZsSu-iyXEaZccP8s=.64901889-dc68-46dc-80f2-6877306f3490@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <cBGbXUSxt4oYcCuogBccnwAJxAjZsSu-iyXEaZccP8s=.64901889-dc68-46dc-80f2-6877306f3490@github.com>
Message-ID: <zNFTKcPKQ8LzzbcVtcGuH9cYmY2cdWRLPoELhqok7hM=.b98a608f-e303-4242-8442-721bf6618b6c@github.com>

On Sun, 9 Jun 2024 22:45:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better parameter names

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 118:

> 116:     /**
> 117:      * Insert the unsigned 2-byte integer into the buffer as 4 hexadecimal digit ASCII bytes,
> 118:      * only least significant 16 bits of {@code i} are used.

Suggestion:

     * only least significant 16 bits of {@code value} are used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632711983

From redestad at openjdk.org  Mon Jun 10 07:51:14 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 07:51:14 GMT
Subject: RFR: 8333833: UUID toString removes the use of
 ByteArrayLittleEndian [v7]
In-Reply-To: <Y_btkkFfkJpGmmdVn32iTieFQRko0_cngHnC9ZnQ70M=.90085e20-59fc-4eb9-8e5b-f92dea65617c@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <Y_btkkFfkJpGmmdVn32iTieFQRko0_cngHnC9ZnQ70M=.90085e20-59fc-4eb9-8e5b-f92dea65617c@github.com>
Message-ID: <NzqbzmL8B7mTxp20auS7dzyBQ1WcboKcA3iDW8mrXWw=.9ddf11f0-12af-4da5-a981-5c0cb71e456f@github.com>

On Mon, 10 Jun 2024 07:32:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/util/HexDigits.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

Thanks. I hate to nitpick, but is it OK if I rename the RFE as "Remove the use of ByteArrayLittleEndian from UUID::toString" (the PR need to follow suit). I think the current name might be read as doing something completely different.

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2157580938

From redestad at openjdk.org  Mon Jun 10 07:58:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 07:58:12 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
Message-ID: <zLnrhG0l6Yicncqrtg7DOLpaKEF9PlmicSXwh36mSio=.7f629785-9804-414a-86ea-2433a2924e86@github.com>

On Fri, 7 Jun 2024 18:58:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
>> 
>> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
>> 
>> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
>> 
>> Name             Cnt           Base          Error            Test          Error         Unit  Change
>> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>>   * = significant
>> 
>> Number of classes loaded drops from 1096 to 1092
>> 
>> Running the micro regularly shows no significant difference:
>> 
>> Name                              Cnt   Base   Error    Test   Error  Unit  Change
>> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adress review comments, add ConstantBootstraps#invoke to list of recognized type signatures

Sure. If you can show how you'd do that I'd be happy to test it. Maybe there are excess native linkers I'm not seeing from using `invokeExact`, but AFAICT there are no linkers being spun when the type match is made exact via static casts (which is what these exact matches in BMI achieves). So I remain a bit confused about what we would be able to improve.

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/19598#issuecomment-2157595699

From dholmes at openjdk.org  Mon Jun 10 08:04:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 08:04:12 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
 <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
Message-ID: <G-MYWkkw506r9DLMCcme6orMWiD3hu1Wn6nRJuSIG_c=.94373b8a-b647-4e59-9a3e-053c012032aa@github.com>

On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sets the version to 24/24-ea and the copyright year to 2025.
>> 
>> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>> 
>> This initial generation also picks up the unpublished changes from: 
>> 
>> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
>> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
>> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>> 
>> Thanks
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2157606095

From redestad at openjdk.org  Mon Jun 10 08:14:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 08:14:13 GMT
Subject: RFR: 8333833: Remove the use of ByteArrayLittleEndian from
 UUID::toString [v7]
In-Reply-To: <Y_btkkFfkJpGmmdVn32iTieFQRko0_cngHnC9ZnQ70M=.90085e20-59fc-4eb9-8e5b-f92dea65617c@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
 <Y_btkkFfkJpGmmdVn32iTieFQRko0_cngHnC9ZnQ70M=.90085e20-59fc-4eb9-8e5b-f92dea65617c@github.com>
Message-ID: <N_TKYO_rYycwhbT_aHvNnRRIL3yguSX_M08dXIjwmcs=.b9c5daa2-57f5-4a09-8fae-92bb78da0e29@github.com>

On Mon, 10 Jun 2024 07:32:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/util/HexDigits.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

Great, go ahead and /integrate again and I'll sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/19610#issuecomment-2157627942

From duke at openjdk.org  Mon Jun 10 08:21:22 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 10 Jun 2024 08:21:22 GMT
Subject: Integrated: 8333833: Remove the use of ByteArrayLittleEndian from
 UUID::toString
In-Reply-To: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
References: <PdPvmV60-lECNEqjtSRrsazTJU1cOJiLZUYiReOpYLA=.cbb226a5-8fb9-48a5-8528-8198c77a6b6f@github.com>
Message-ID: <l7dNRH21L-0JiSoVuSBCOcOO1bEo7YeQO-z6tOzCFvo=.112bda7e-830f-4ed5-921a-dc30d347729a@github.com>

On Sat, 8 Jun 2024 00:19:55 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> After PR #16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. In the UUID.toString method, ByteArrayLittleEndian can be removed, making the code more elegant and faster.

This pull request has now been integrated.

Changeset: 8aa35cac
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8aa35cacfcc94d261de102b628eb954c71eae98e
Stats:     52 lines in 2 files changed: 5 ins; 25 del; 22 mod

8333833: Remove the use of ByteArrayLittleEndian from UUID::toString

Reviewed-by: liach, redestad

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

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

From dholmes at openjdk.org  Mon Jun 10 08:23:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 08:23:13 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <aWrsSzJbcXI8EqFgSCctoyvzfovBHxXNEgXPy4hSaDY=.da28399d-9aee-41b9-8c04-ef43c1943919@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
 <XyahJbeJea0_HAaB2Lwow5sKeu4qDRhx6FAmpHot3Oo=.fff570b0-39ac-482c-99ac-b6bcf50f1f6d@github.com>
 <aWrsSzJbcXI8EqFgSCctoyvzfovBHxXNEgXPy4hSaDY=.da28399d-9aee-41b9-8c04-ef43c1943919@github.com>
Message-ID: <vPVl_MayYPBJDj5J4AIlkDUQ75fmO9k3VXEyrW66WLs=.3233eab3-3f9f-4deb-a754-c386d79d8b0d@github.com>

On Fri, 7 Jun 2024 06:07:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> "To use these functions safely with plain chars (or signed chars), the argument should first be converted to unsigned char"

@tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't actually do anything. Every char is "representable" as an unsigned char because it holds a bit pattern between 0x00 and 0xff i.e. the function is well defined if the incoming int is either EOF (int -1) or else in the range 0x00 to 0xff. But I did a bit of searching and it seems it comes down to potential arithmetic operations on the "char" the might behave differently depending on the signed-ness. :(

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

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2157677944

From redestad at openjdk.org  Mon Jun 10 08:35:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 08:35:33 GMT
Subject: RFR: 8333824: Unused ClassValue in VarHandles
Message-ID: <6KN_iIs0lFWMqTfprFbMOoDiaIdxjLY47EY94ZV3OJ0=.e8368989-634e-45d6-9e06-d8cb959eadfc@github.com>

Trivially removing the a leftover, unused `ClassValue` from `java.lang.invoke.VarHandle`

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

Commit messages:
 - 8333824: Unused ClassValue in VarHandles

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

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

From stuefe at openjdk.org  Mon Jun 10 08:38:13 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 10 Jun 2024 08:38:13 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <vPVl_MayYPBJDj5J4AIlkDUQ75fmO9k3VXEyrW66WLs=.3233eab3-3f9f-4deb-a754-c386d79d8b0d@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
 <XyahJbeJea0_HAaB2Lwow5sKeu4qDRhx6FAmpHot3Oo=.fff570b0-39ac-482c-99ac-b6bcf50f1f6d@github.com>
 <aWrsSzJbcXI8EqFgSCctoyvzfovBHxXNEgXPy4hSaDY=.da28399d-9aee-41b9-8c04-ef43c1943919@github.com>
 <vPVl_MayYPBJDj5J4AIlkDUQ75fmO9k3VXEyrW66WLs=.3233eab3-3f9f-4deb-a754-c386d79d8b0d@github.com>
Message-ID: <2wSWEMk4oW4U2wYJQZq5AXgxIrCqAtuEt11kVDVTJ2E=.4e61e441-ef51-4e5d-b286-952174312e2e@github.com>

On Mon, 10 Jun 2024 08:20:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > "To use these functions safely with plain chars (or signed chars), the argument should first be converted to unsigned char"
> 
> @tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't actually do anything. Every char is "representable" as an unsigned char because it holds a bit pattern between 0x00 and 0xff i.e. the function is well defined if the incoming int is either EOF (int -1) or else in the range 0x00 to 0xff. But I did a bit of searching and it seems it comes down to potential arithmetic operations on the "char" the might behave differently depending on the signed-ness. :(

I was surprised as well. Turns out you can use something for 20+ years and not notice :)

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

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2157711653

From mcimadamore at openjdk.org  Mon Jun 10 09:00:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 10 Jun 2024 09:00:14 GMT
Subject: RFR: 8333824: Unused ClassValue in VarHandles
In-Reply-To: <6KN_iIs0lFWMqTfprFbMOoDiaIdxjLY47EY94ZV3OJ0=.e8368989-634e-45d6-9e06-d8cb959eadfc@github.com>
References: <6KN_iIs0lFWMqTfprFbMOoDiaIdxjLY47EY94ZV3OJ0=.e8368989-634e-45d6-9e06-d8cb959eadfc@github.com>
Message-ID: <y1VtvtTaHEFP16JH5RBx000GDczOTtJKICjvd45gjz0=.53348bb6-88f0-4f3f-9fcf-b88667dc2a95@github.com>

On Mon, 10 Jun 2024 08:30:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially removing the a leftover, unused `ClassValue` from `java.lang.invoke.VarHandle`

Good catch!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19620#pullrequestreview-2107142866

From jsjolen at openjdk.org  Mon Jun 10 09:05:13 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Jun 2024 09:05:13 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
Message-ID: <-yrsMojgotrB89wb1ePgtP_iqPDbLCp3VhMhpaDWGh0=.55afc438-1f30-4ac7-9ed2-ffebc35a5083@github.com>

On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary
> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
> 
> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
> 
> **Testing**
> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
> - tier1

Hi Robert,

Here's a third opinion:

The wrapper is fine, but it should mimic the name of the function it wraps exactly: `os::isspace`. It's also good that it does the range check as regular code as opposed to an assert, as this function is used to parse external input. It's fine to be excessive when parsing strings as those parts of the code are not really performance critical.

All the best,
Johan

src/hotspot/share/runtime/os.cpp line 96:

> 94: DEBUG_ONLY(bool os::_mutex_init_done = false;)
> 95: 
> 96: int os::is_space(int c) {

`os::isspace`

test/hotspot/gtest/runtime/test_os.cpp line 43:

> 41: 
> 42: # include <stdio.h>
> 43: 

Not necessary.

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

PR Review: https://git.openjdk.org/jdk/pull/19567#pullrequestreview-2107152152
PR Review Comment: https://git.openjdk.org/jdk/pull/19567#discussion_r1632873691
PR Review Comment: https://git.openjdk.org/jdk/pull/19567#discussion_r1632873309

From jvernee at openjdk.org  Mon Jun 10 09:40:13 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jun 2024 09:40:13 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <zLnrhG0l6Yicncqrtg7DOLpaKEF9PlmicSXwh36mSio=.7f629785-9804-414a-86ea-2433a2924e86@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
 <zLnrhG0l6Yicncqrtg7DOLpaKEF9PlmicSXwh36mSio=.7f629785-9804-414a-86ea-2433a2924e86@github.com>
Message-ID: <zxUSUe36gH5ndWHfvO3Tm2KONN5hSR9AzrZZ8pR93hg=.50dd6d46-8af2-4860-ab7c-e2934f8d8384@github.com>

On Mon, 10 Jun 2024 07:56:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adress review comments, add ConstantBootstraps#invoke to list of recognized type signatures
>
> Sure. If you can show how you'd do that I'd be happy to test it. Maybe there are excess native linkers I'm not seeing from using `invokeExact`, but AFAICT there are no linkers being spun when the type match is made exact via static casts (which is what these exact matches in BMI achieves). So I remain a bit confused about what we would be able to improve.
> 
> Thanks for reviewing!

@cl4es I'm talking about the linker being spun in `Invokers::invokeHandleForm`. When either `invoke` or `invokeExact` is called, the VM calls `MethodHandleNatives::linkMethod` and we eventually end up there. That code creates a new `LambdaForm` that has the type check (for `invokeExact`) and customization check, and then forwards the arguments to `invokeBasic`.

The idea would be to call `invokeBasic` directly instead of `invokeExact` (similar to what we do in `VarHandleGuards`)

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

PR Comment: https://git.openjdk.org/jdk/pull/19598#issuecomment-2157839857

From jvernee at openjdk.org  Mon Jun 10 09:40:14 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jun 2024 09:40:14 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
Message-ID: <nitX1VraWPhSDLyt7VShwm5qvkLfBTvtZuZnMGs5NbM=.16bc6fac-8c73-4372-839f-8cc945eb8eb0@github.com>

On Fri, 7 Jun 2024 18:58:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
>> 
>> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
>> 
>> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
>> 
>> Name             Cnt           Base          Error            Test          Error         Unit  Change
>> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>>   * = significant
>> 
>> Number of classes loaded drops from 1096 to 1092
>> 
>> Running the micro regularly shows no significant difference:
>> 
>> Name                              Cnt   Base   Error    Test   Error  Unit  Change
>> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adress review comments, add ConstantBootstraps#invoke to list of recognized type signatures

But any way, if you don't see those linkers being spun in profiles, maybe it's not important, and the extra safety is more worthwhile.

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

PR Comment: https://git.openjdk.org/jdk/pull/19598#issuecomment-2157852363

From jvernee at openjdk.org  Mon Jun 10 09:47:17 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jun 2024 09:47:17 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
Message-ID: <y-pnD4-YLvKH4pTNJQSrmLUajixk8og0Ee-NjxXeFwA=.70a1fa27-0f79-4345-b647-56ade1defc9a@github.com>

On Fri, 7 Jun 2024 18:58:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
>> 
>> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
>> 
>> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
>> 
>> Name             Cnt           Base          Error            Test          Error         Unit  Change
>> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>>   * = significant
>> 
>> Number of classes loaded drops from 1096 to 1092
>> 
>> Running the micro regularly shows no significant difference:
>> 
>> Name                              Cnt   Base   Error    Test   Error  Unit  Change
>> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adress review comments, add ConstantBootstraps#invoke to list of recognized type signatures

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19598#pullrequestreview-2107307077

From redestad at openjdk.org  Mon Jun 10 10:08:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 10:08:16 GMT
Subject: RFR: 8333824: Unused ClassValue in VarHandles
In-Reply-To: <y1VtvtTaHEFP16JH5RBx000GDczOTtJKICjvd45gjz0=.53348bb6-88f0-4f3f-9fcf-b88667dc2a95@github.com>
References: <6KN_iIs0lFWMqTfprFbMOoDiaIdxjLY47EY94ZV3OJ0=.e8368989-634e-45d6-9e06-d8cb959eadfc@github.com>
 <y1VtvtTaHEFP16JH5RBx000GDczOTtJKICjvd45gjz0=.53348bb6-88f0-4f3f-9fcf-b88667dc2a95@github.com>
Message-ID: <Dc817cjSQ74xM0XHiRjirLQp5DtiF8JZ8wgCHozxg5Q=.b091880b-2133-40a1-8ba0-6646ad07f98e@github.com>

On Mon, 10 Jun 2024 08:57:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Good catch!

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/19620#issuecomment-2157910277

From redestad at openjdk.org  Mon Jun 10 10:08:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 10:08:17 GMT
Subject: Integrated: 8333824: Unused ClassValue in VarHandles
In-Reply-To: <6KN_iIs0lFWMqTfprFbMOoDiaIdxjLY47EY94ZV3OJ0=.e8368989-634e-45d6-9e06-d8cb959eadfc@github.com>
References: <6KN_iIs0lFWMqTfprFbMOoDiaIdxjLY47EY94ZV3OJ0=.e8368989-634e-45d6-9e06-d8cb959eadfc@github.com>
Message-ID: <TK_oi_YIbz4ButpQaQGOiO2a05yJiVOYXoW4gdDGFug=.92b12f01-397d-4255-84cc-e0120267abf9@github.com>

On Mon, 10 Jun 2024 08:30:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially removing the a leftover, unused `ClassValue` from `java.lang.invoke.VarHandle`

This pull request has now been integrated.

Changeset: 7b43a8cd
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b43a8cd7c663facbe490f889838d7ead0eba0f9
Stats:     10 lines in 1 file changed: 0 ins; 10 del; 0 mod

8333824: Unused ClassValue in VarHandles

Reviewed-by: mcimadamore

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

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

From redestad at openjdk.org  Mon Jun 10 10:09:38 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 10:09:38 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v3]
In-Reply-To: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
Message-ID: <QF6We-mvzM73X-Ib_LENQe_lqACvlaOCXrg-IDpmAn0=.e0331e4c-06ce-4f14-be66-332020f4053c@github.com>

> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
> 
> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
> 
> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
> 
> Name             Cnt           Base          Error            Test          Error         Unit  Change
> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>   * = significant
> 
> Number of classes loaded drops from 1096 to 1092
> 
> Running the micro regularly shows no significant difference:
> 
> Name                              Cnt   Base   Error    Test   Error  Unit  Change
> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>   * = significant

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

  Copy-paste error; CONDY_INVOKE returns Object. Fixes TestDynamicConstant.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19598/files
  - new: https://git.openjdk.org/jdk/pull/19598/files/532966a4..2d64ae1c

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

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

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

From redestad at openjdk.org  Mon Jun 10 10:09:38 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 10:09:38 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v2]
In-Reply-To: <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <YgJNJ9WErSufyYOMh9s85zJNKdCMyqVNWYarJNMEzYA=.a8389562-c4da-49fd-adc9-2aee4f8820fe@github.com>
Message-ID: <_GJeL6RYoPjD_uoK-i_o3dUjIXf7kJR-MFn8RogLz0c=.2c5caefe-0c0e-4aab-b5bc-50a3a16cf1af@github.com>

On Fri, 7 Jun 2024 18:58:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR refactors type matching in BootstrapMethodInvoker and adds a few types, seeking to improve bootstrap overheads of some ConstantBootstraps and in particular the ProxyGenerator condys generated for e.g. annotation proxies since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457)
>> 
>> I've adjusted the micro-benchmark added by JDK-8332457 to not only generate a proxy but also call into one of the proxied methodt (`Object::hashCode`). 
>> 
>> Running org.openjdk.bench.java.lang.reflect.ProxyGenBench as a one-off startup benchmark sees significant improvement (-9% instructions, -6% cycles):
>> 
>> Name             Cnt           Base          Error            Test          Error         Unit  Change
>> Perfstartup-JMH   20        154,000 ?        8,165         148,000 ?       23,164        ms/op   1,04x (p = 0,352 )
>>   :.cycles            925335973,200 ? 47147600,262   842221278,800 ? 46836254,964       cycles   0,91x (p = 0,000*)
>>   :.instructions     2101588857,600 ? 81105850,361  1966307798,400 ? 22011043,908 instructions   0,94x (p = 0,000*)
>>   :.taskclock               291,500 ?       16,494         262,000 ?       15,328           ms   0,90x (p = 0,000*)
>>   * = significant
>> 
>> Number of classes loaded drops from 1096 to 1092
>> 
>> Running the micro regularly shows no significant difference:
>> 
>> Name                              Cnt   Base   Error    Test   Error  Unit  Change
>> ProxyGenBench.generateAndProxy100  10 26,827 ? 8,954  26,855 ? 7,531 ms/op   1,00x (p = 0,991 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adress review comments, add ConstantBootstraps#invoke to list of recognized type signatures

Thanks, I'll see if I can get that working and if it has any effect as a follow-up. 

Testing caught a bug introduced by a copy-paste error in 532966a, re-running a few more tests now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19598#issuecomment-2157922124

From jpai at openjdk.org  Mon Jun 10 11:14:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Jun 2024 11:14:27 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v7]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <vRTF-YeLxAuQ_zwhVZotNb64x3ld0LZmuNgEBlflQeQ=.5ea15bbd-ad0f-43c7-a967-0c227a5ce0d5@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - merge latest from master branch
 - merge latest from master branch
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - merge latest from master branch
 - convert the new test to junit
 - merge latest from master branch
 - Lance's review - include tests for --extract long form option
 - cleanup after each test
 - Adjust test for new error messages
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7b43a8cd...2bd13ece

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

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=06
  Stats: 569 lines in 4 files changed: 558 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

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

From pminborg at openjdk.org  Mon Jun 10 11:55:29 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 11:55:29 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v20]
In-Reply-To: <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
Message-ID: <THb-1nb8iu0Rn1a6oAZxlDCSnarlUT7sQiqsL6IpEhI=.2c992ff6-baec-4b83-aaad-7b5229c066d7@github.com>

On Fri, 17 May 2024 09:31:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add benchmarks for memoized IntFunction and Function
>  - Add benchmark for memoized supplier

A new PR will be made available shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2158140833

From pminborg at openjdk.org  Mon Jun 10 11:55:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 11:55:30 GMT
Subject: Withdrawn: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <mZNB0rvxezShE80zD9eTTFcL77_f8TaR_y2yVVLqF9Q=.49c75db1-2359-4e51-a40f-7e70cfea02c1@github.com>

On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

This pull request has been closed without being integrated.

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

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

From vklang at openjdk.org  Mon Jun 10 12:00:16 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 10 Jun 2024 12:00:16 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <DyAsw4Up2tbmn5npDKosQuoWFKmmuo4daOnsDGBnFeA=.27f1bdb3-ba69-4967-992d-e5f20e347e8e@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <ZRFgnMzbNR_9odHGXWQrPWFaNmHq6MJPd5Q1GSM3ANA=.f4de435c-b62f-4671-9b76-c3993fc69309@github.com>
 <HDp4qCud6rEnlGBPnfnKbL34Fi24xyJd3q5fMpr81yk=.f9c5181a-8d5e-4995-8d10-c913d53a716d@github.com>
 <OoFXXPNbdWXcwXwloq28EK5chYINYYEN6nLLM81Pdwo=.8cba479e-ad7f-4f78-8d89-304ea61f7434@github.com>
 <PnqP1oYl3XPasxoTTBUla6Qqh1r-tyZ6a2b0BGlVbe4=.8e2c4622-afb4-4d92-b729-23a1faf4b0ef@github.com>
 <DyAsw4Up2tbmn5npDKosQuoWFKmmuo4daOnsDGBnFeA=.27f1bdb3-ba69-4967-992d-e5f20e347e8e@github.com>
Message-ID: <07xy6VKJPhEQMoj2jx5F63pWeIYbzU8O_GsnIqOD70I=.3bce6a0b-fdab-4efd-bc99-9ca95e612038@github.com>

On Thu, 6 Jun 2024 14:29:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `clone()` performs a shallow copy, so there is currently no `Object[]` allocated and therefore nothing to optimize.  I don't think there's any work to do here.
>> 
>> @DougLea @viktorklang-ora can you confirm?
>
>> clone() performs a shallow copy, so there is currently no Object[] allocated and therefore nothing to optimize.
> 
> Yes, I believe so.

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1633127845

From vklang at openjdk.org  Mon Jun 10 12:14:11 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 10 Jun 2024 12:14:11 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
Message-ID: <wCAuuFotiAxRX0Fsxn_gAlFatGRByB3SkcI2UhRYNYA=.7f6c8a76-e1a1-40eb-b064-027e84be1b85@github.com>

On Thu, 6 Jun 2024 12:46:36 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2625.125 ? 71.802  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2607.447 ? 46.400  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2615.500 ? 30.771  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2583.892 ? 62.086  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding benchmarks for readObject

I think this one looks OK now. @AlanBateman might want to provide his take on this.

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

PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2158177971

From redestad at openjdk.org  Mon Jun 10 12:19:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 12:19:11 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v2]
In-Reply-To: <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
Message-ID: <XXXr56c-2-PQmX262zo5ksSNvyDXvkKeWRdvZtNAyJo=.a89b56d6-8090-4860-a37a-63259fdefb76@github.com>

On Mon, 10 Jun 2024 04:08:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obtain classloader in security manager friendly code path

Original code did all the classloading in the `<clinit>` - should we do that here, too?

Can you explain the need to `getPlatformClassLoader` when `classEntry.getClassLoader == null`? Pre-JDK-8332457 did no such thing.

I'll park #19598 until this stabilizes.

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

PR Comment: https://git.openjdk.org/jdk/pull/19615#issuecomment-2158189721

From liach at openjdk.org  Mon Jun 10 12:33:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Jun 2024 12:33:12 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v2]
In-Reply-To: <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
Message-ID: <wKbL34FAR31KapLNaLMU5qDWY2n0ahXHci0w2o06Spk=.cd0cff1a-0e59-4c22-95ef-fd3d88dabbf4@github.com>

On Mon, 10 Jun 2024 04:08:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obtain classloader in security manager friendly code path

The condy bootstrap is not trusted by SecurityManager, therefore it cannot use the `null` ClassLoader to parse method descriptors. https://github.com/openjdk/jdk/blob/7b43a8cd7c663facbe490f889838d7ead0eba0f9/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1193
Meanwhile, condy bootstrap cannot take MethodType or Class, as those constants cannot resolve a package private type appearing in method descriptors.

Thus, my approach is to obtain a valid non-null ClassLoader in `<clinit>`, which is called from `Proxy` so there's no SecurityManager problems. Then I use that ClassLoader to perform actual resolution lazily in the condy. The call to `getPlatformClassLoader` emulates the same call in `MethodType.fromMethodDescriptorString`, which resolves classes in the bootstrap loader.

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

PR Comment: https://git.openjdk.org/jdk/pull/19615#issuecomment-2158217420

From prappo at openjdk.org  Mon Jun 10 12:34:23 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 10 Jun 2024 12:34:23 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently
Message-ID: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>

Please review this fix for an intermittent test failure.

On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.

Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.

I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.

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

Commit messages:
 - Initial commit

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

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

From redestad at openjdk.org  Mon Jun 10 13:00:14 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 13:00:14 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v2]
In-Reply-To: <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
Message-ID: <72NZyUHvjomdSsVM3aJ4T3ZWvxCgk4UzA5m-R-74w4s=.1930a514-e11b-4e14-9875-3c7849054366@github.com>

On Mon, 10 Jun 2024 04:08:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obtain classloader in security manager friendly code path

I'm wary about the subtle semantic differences that might result from that and would be more comfortable reverting this behavior to what we did before JDK-8332457. Perhaps even backing that one out and re-examine the changes with less urgency.

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

PR Comment: https://git.openjdk.org/jdk/pull/19615#issuecomment-2158280708

From jwaters at openjdk.org  Mon Jun 10 13:07:48 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Jun 2024 13:07:48 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v3]
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <eFBd2ftEoEu8r2e0jDG1fk36c_ow-7sM-5_rms60AcA=.c1e5c7d4-1611-450e-80d1-8caa3aae816e@github.com>

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

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

 - Capstone Support
 - Add check for compiler in configure
 - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18915/files
  - new: https://git.openjdk.org/jdk/pull/18915/files/09fb3d65..b0b088e9

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

  Stats: 121745 lines in 2137 files changed: 85534 ins; 24227 del; 11984 mod
  Patch: https://git.openjdk.org/jdk/pull/18915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915

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

From pminborg at openjdk.org  Mon Jun 10 13:24:35 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 13:24:35 GMT
Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only property
Message-ID: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>

This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called.

Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state.

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

Commit messages:
 - Make reinterpret retain read-only state

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

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

From duke at openjdk.org  Mon Jun 10 13:39:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 10 Jun 2024 13:39:13 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
Message-ID: <4AzGl1zKsp5sPygdzdbG1WFTgsdNBJrF4FLSUxuhcQQ=.50d7ebb8-fd74-43db-9b4c-4cb02f82f2f0@github.com>

On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary
> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
> 
> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
> 
> **Testing**
> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
> - tier1

Thanks for the feedback everyone! 

> But I did a bit of searching and it seems it comes down to potential arithmetic operations on the "char" the might behave differently depending on the signed-ness. :(

Ok, so it seems like we ought to cast to unsigned char whenever char is passed, even if the representable range is the same. 

One more argument in favor of the current wrapper approach is that it makes it easy to at-a-glance confirm `isspace` is being used correctly everywhere.

However, I am fine with just using casts wherever there is char and removing the wrapper. This is simpler and also avoids the cast to int. But what about when an int is passed to `isspace`? Maybe having the range check here would be better than casting to unsigned char or leaving as is?

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

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2158401790

From david.lloyd at redhat.com  Mon Jun 10 13:40:12 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 10 Jun 2024 08:40:12 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <EC28C797-4E09-4086-9D2F-200AED65B4BD@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <EC28C797-4E09-4086-9D2F-200AED65B4BD@oracle.com>
Message-ID: <CANghgrQESg-WBhs9mcNBuGTHxa8ZKcOF-fBPG1Qdg-GM9OhgDg@mail.gmail.com>

On Fri, Jun 7, 2024 at 1:19?PM Ron Pressler <ron.pressler at oracle.com> wrote:

>
> > On 6 Jun 2024, at 18:37, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> > Just bumping this one more time. I intend to start by opening a JIRA to
> add the two proposed methods to `ReflectionFactory`, and go from there. I
> guess that we might need a JEP for the proposed serialization restrictions,
> which is going to be considerably more involved, so I'm putting that off as
> a second step for now, pending further discussion.
>
>
> Hi.
>
> Seven years before the upcoming delivery of JEP 471 we [announced that the
> world of accessing JDK internals would be coming to an end](
> https://openjdk.org/jeps/260). Four years later, the JDK [started
> enforcing that](https://openjdk.org/jeps/403), but to give extra time to
> laggards who have not yet adapted to either refraining from accessing
> internals or instructing their users on the proper configuration of the JDK
> to allow doing so, we left some unsupported mechanisms in place to
> temporarily allow hacking around the restrictions until they can properly
> adapt. Now, three years later, we're starting the process of removing the
> temporary hacks, although we don't yet know how long the process should
> last.
>
> My first question is, how many more years do you think we should wait for
> libraries to finish the process by which they either refrain from accessing
> internals or instruct their users on the proper configuration that allows
> them to do so? Knowing how long we should wait for the libraries that have
> not yet finished their adaptation in the past seven years, and how far
> along they are in the process, could help inform how long we should wait
> until the actual removal of Unsafe.
>
> My second question has to do with the consideration that any serialization
> procedure should no longer bypass constructors (at least not without
> `--add-opens`, that is). I'd be interested to know about the difficulties
> serialization libraries have encountered in their process of migrating away
> from accessing internals and toward custom serializers for JDK classes,
> such as what public constructors are missing. This would help us identify
> what constructors we should add to support serialization that doesn't
> violate integrity.
>

The first thing to understand is that, unlike APIs in the JDK which may
only be implemented *in* the JDK, serialization is governed by a
specification [1]. This specification is still implemented by multiple
external libraries (including the OpenJDK ORB) as well as the JDK itself.
We aren't talking about libraries which invent some arbitrary kind of
serialization that requires unsafe object creation. We're talking about
libraries which conform to some or all of the serialization specification.

If you look back at the history of the discussion of serialization support
with regards to the JDK (which is referenced in the history of this email
thread), it was determined at the time of Java 9 that serialization would
be considered an exception to the rule of reflection restrictions, for
purely pragmatic reasons. Brian Goetz has talked frequently about the
limitations of existing serialization and how this impacts the platform in
various ways. He's also hinted at a future where some alternative
serialization mechanism exists which would presumably avoid the need for
the things we find in `ReflectionFactory`.

However we don't live in that world just yet. So, to answer your first
question ("How many more years...") I would start by modifying the
question. It's not about waiting for libraries; I think this greatly
mischaracterizes the problem. It's about waiting for OpenJDK to have a new
serialization mechanism. Until then, there is no replacement, so we're in a
holding pattern, like it or not. At best we're talking about small,
monotonic improvements which bring the platform closer to the goal of
integrity.

And so the answer to the first question is, "however many years it takes
for there to be an alternative, blessed OpenJDK serialization mechanism",
which presumably will involve both language and core library modifications.

For your second question, serialization *must*, by specification, bypass
constructors in the bottom part of the serializable class's type hierarchy
which correspond to serializable classes (most frequently this means
everything other than `Object` itself, but occasionally there are more
levels involved). If the platform were to drop that support, then all
serialization libraries would break, including the OpenJDK ORB, and the
specification would be unimplementable.

The serialization specification is not deprecated. Nor are the classes
which support serialization in the JDK. So in my opinion it would not yet
be appropriate to break these things. In order to tackle this particular
corner of platform integrity, those two problems must be addressed first
and foremost, and such an action would necessarily involve a deprecation
cycle on serialization as a whole.

I would also like to be very clear that I am not proposing adding a
mechanism to bypass constructors. Such a mechanism already exists on
ReflectionFactory, and has not been deprecated. I am proposing that any
caller which already has permission to do such a thing (and the other
integrity-bypassing things already provided by this existing API) should
also have permission to implement the remainder of the specification as
well (reading and writing fields), and to do so using this same API, rather
than Unsafe. In my view this is absolutely a monotonic step in the right
direction (i.e. towards platform integrity), since we're putting all of the
"offenders" into one bucket based on use case.

It might be shocking to discover the existence of these APIs if one wasn't
already aware of them. Presently, these APIs have essentially no
restrictions (ignoring security manager). They're even easier to access
than Unsafe, in fact. Therefore, I would suggest that another monotonic
improvement would be to restrict these APIs under a command-line switch,
like FFM is. In this way, we've unambiguously moved towards platform
integrity, at least as far as it is currently possible to do so. Nothing
would be enabled that isn't already possible, and some things that are now
possible would be unambiguously restricted.

Requiring `--add-opens` for ORBs/serialization probably isn't practical. It
is important to note that in addition to user classes, a large number of
JDK classes are serializable, spanning many packages. The burden on users
would be extremely high in this case. Is it really better for users to have
to list every package containing a serializable class, than to opt in
wholesale to saying "I want serialization to be allowed for module X"? We
don't (and wouldn't) do the same for native access for example, even though
a similar level of access is given. In fact one *could* use native access
to achieve the same thing, though this would be unfortunate on several
levels.

Another reason that requiring `--add-opens` would be inadequate is that
ReflectionFactory allows bypassing not just access restrictions, but also
certain provisions of the language and JVM specifications. Do we really
want any open package to be accessible in this way? Do we really want this
API to remain unrestricted? I would think that we would all agree that we
do not. Yet, deprecation is not yet indicated for the reasons given above.
I think restriction is the only answer here. And if this API is already
restricted, why not let the implicit contract of that restriction carry the
user's intent to grant serialization access to certain modules? Surely it
could be made clear what such access entails, much as we do for FFM which
has similar risks (and more).

[1]
https://docs.oracle.com/en/java/javase/22/docs/specs/serialization/index.html

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240610/a3ba7656/attachment.htm>

From duke at openjdk.org  Mon Jun 10 13:47:22 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 10 Jun 2024 13:47:22 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
Message-ID: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>

After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.

This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

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

Commit messages:
 - Optimization for StringBuilder append(boolean) & appendNull

Changes: https://git.openjdk.org/jdk/pull/19626/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333893
  Stats: 137 lines in 5 files changed: 54 ins; 41 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

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

From duke at openjdk.org  Mon Jun 10 13:47:22 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 10 Jun 2024 13:47:22 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>

On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

# 1.  Compare with the master branch
1. master (`a6fc2f8`) https://github.com/wenshao/jdk/tree/upstream_master_a6fc2f8
2. current (`5e815`) https://github.com/wenshao/jdk/tree/optim_str_builder_append_202406

# 2. Benchmark Commands

make test TEST="micro:java.lang.StringBuilders.toStringCharWithBool8"
make test TEST="micro:java.lang.StringBuilders.toStringCharWithNull8"


# 3. Benchmark Numbers
The performance numbers under MacBookPro M1 Pro are as follows:


-Benchmark                                   Mode  Cnt  Score   Error  Units #master (a6fc2f8)
-StringBuilders.toStringCharWithBool8Latin1  avgt   15  7.371 ? 0.003  ns/op
-StringBuilders.toStringCharWithBool8Utf16   avgt   15  9.613 ? 0.018  ns/op
-StringBuilders.toStringCharWithNull8Latin1  avgt   15  7.071 ? 0.003  ns/op
-StringBuilders.toStringCharWithNull8Utf16   avgt   15  9.296 ? 0.016  ns/op

+Benchmark                                   Mode  Cnt  Score   Error  Units #current (5e815)
+StringBuilders.toStringCharWithBool8Latin1  avgt   15  6.515 ? 0.121  ns/op +11.61%
+StringBuilders.toStringCharWithBool8Utf16   avgt   15  8.654 ? 0.035  ns/op +9.97%
+StringBuilders.toStringCharWithNull8Latin1  avgt   15  5.550 ? 0.010  ns/op +21.51%
+StringBuilders.toStringCharWithNull8Utf16   avgt   15  8.108 ? 0.041  ns/op +12.77%

# 1. Compare with unsafe branch

1. current (`5e815`) https://github.com/wenshao/jdk/tree/optim_str_builder_append_202406
2. unsafe (`adc220`) https://github.com/wenshao/jdk/tree/optim_str_builder_append_202406_unsafe

I think the performance of the Unsafe branch may be the best data for the C2 optimizer. @eme64 can help me see if C2 can do it?

# 2. Benchmark Commands

make test TEST="micro:java.lang.StringBuilders.toStringCharWithBool8"
make test TEST="micro:java.lang.StringBuilders.toStringCharWithNull8"


# 3. Implementation of Unsafe Branch

class AbstractStringBuilder {
    static final Unsafe UNSAFE = Unsafe.getUnsafe();

    static final int NULL_LATIN1;
    static final int TRUE_LATIN1;
    static final int FALS_LATIN1;

    static final long NULL_UTF16;
    static final long TRUE_UTF16;
    static final long FALS_UTF16;

    static {
        byte[] bytes4 = new byte[4];
        byte[] bytes8 = new byte[8];

        bytes4[0] = 'n';
        bytes4[1] = 'u';
        bytes4[2] = 'l';
        bytes4[3] = 'l';
        NULL_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
        StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
        NULL_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);

        bytes4[0] = 't';
        bytes4[1] = 'r';
        bytes4[2] = 'u';
        bytes4[3] = 'e';
        TRUE_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
        StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
        TRUE_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);

        bytes4[0] = 'f';
        bytes4[1] = 'a';
        bytes4[2] = 'l';
        bytes4[3] = 's';
        FALS_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
        StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
        FALS_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);
    }

    private AbstractStringBuilder appendNull() {
        ensureCapacityInternal(count + 4);
        int count = this.count;
        byte[] val = this.value;
        if (isLatin1()) {
            UNSAFE.putInt(
                    val,
                    Unsafe.ARRAY_BYTE_BASE_OFFSET + count,
                    NULL_LATIN1);
        } else {
            UNSAFE.putLong(
                    val,
                    Unsafe.ARRAY_BYTE_BASE_OFFSET + (count << 1),
                    NULL_UTF16);
        }
        this.count = count + 4;
        return this;
    }

    public AbstractStringBuilder append(boolean b) {
        int count = this.count;
        int spaceNeeded = count + (b ? 4 : 5);
        ensureCapacityInternal(spaceNeeded);
        byte[] val = this.value;
        if (isLatin1()) {
            UNSAFE.putInt(
                    val,
                    Unsafe.ARRAY_BYTE_BASE_OFFSET + count,
                    b ? TRUE_LATIN1 : FALS_LATIN1);
            if (!b) {
                val[count + 4] = 'e';
            }
        } else {
            UNSAFE.putLong(
                    val,
                    Unsafe.ARRAY_BYTE_BASE_OFFSET + (count << 1),
                    b ? TRUE_UTF16 : FALS_UTF16);
            if (!b) {
                StringUTF16.putChar(val, count + 4, 'e');
            }
        }
        this.count = spaceNeeded;
        return this;
    }
}


# 4. Benchmark Numbers
The performance numbers under MacBookPro M1 Pro are as follows:


-Benchmark                                   Mode  Cnt  Score   Error  Units # unsafe (adc220)
-StringBuilders.toStringCharWithBool8Latin1  avgt   15  6.415 ? 0.061  ns/op
-StringBuilders.toStringCharWithBool8Utf16   avgt   15  7.307 ? 0.013  ns/op
-StringBuilders.toStringCharWithNull8Latin1  avgt   15  5.443 ? 0.011  ns/op
-StringBuilders.toStringCharWithNull8Utf16   avgt   15  6.944 ? 0.102  ns/op

+Benchmark                                   Mode  Cnt  Score   Error  Units #current (5e815)
+StringBuilders.toStringCharWithBool8Latin1  avgt   15  6.515 ? 0.121  ns/op -1.55%
+StringBuilders.toStringCharWithBool8Utf16   avgt   15  8.654 ? 0.035  ns/op -18.44%
+StringBuilders.toStringCharWithNull8Latin1  avgt   15  5.550 ? 0.010  ns/op -1.96%
+StringBuilders.toStringCharWithNull8Utf16   avgt   15  8.108 ? 0.041  ns/op -16.76%

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

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2158201904
PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2158296234

From mcimadamore at openjdk.org  Mon Jun 10 13:48:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 10 Jun 2024 13:48:14 GMT
Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only
 property
In-Reply-To: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
References: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
Message-ID: <yzp88FxXV5SXhwCqSzHyqSXATLiAwuWvwKW5QNDxfvI=.1bb3fa1b-e5ef-42de-9790-40fdc55712cd@github.com>

On Mon, 10 Jun 2024 13:18:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called.
> 
> Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state.

Note that `asSlice` methods also lacks a similar guarantee on read-only (but the impl works fine there)

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 708:

> 706:     /**
> 707:      * Returns a new memory segment that has the same address, scope, and
> 708:      * read-only state as this segment, but with the provided size.

In other parts of the javadoc we say something like this:


* If the buffer is {@linkplain Buffer#isReadOnly() read-only}, the resulting segment
     * is also {@linkplain ByteBuffer#isReadOnly() read-only}


I think this is better, as read-only is a bit of info that is not IMHO worth spelling out in the method javadoc first para,

Also, the term "read-only state" does not appear anywhere else in the FFM javadoc, so I'd recommend against using it. We can just say "if this segment is (link) read-only, the returned segment is read-only", or something like that.

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

PR Review: https://git.openjdk.org/jdk/pull/19629#pullrequestreview-2107854767
PR Review Comment: https://git.openjdk.org/jdk/pull/19629#discussion_r1633280123

From rriggs at openjdk.org  Mon Jun 10 13:51:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Jun 2024 13:51:13 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <t1kt8CwjhkTbcmm_zMN1Snm51vm43q1___6Dase4cNE=.a5ffde16-91a6-47e6-b4e0-77d516e0494e@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
 <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
 <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
 <6FHMmdtAGyWE8HqW4etXrG0VSKrTektVEUXgJ2TXqs4=.bbaf0570-12eb-440a-848d-41674e8d29c6@github.com>
 <t1kt8CwjhkTbcmm_zMN1Snm51vm43q1___6Dase4cNE=.a5ffde16-91a6-47e6-b4e0-77d516e0494e@github.com>
Message-ID: <h2mkBfGEMeilfspqk45VPAhf2QsfqqwecbRgK_Ch618=.73a99ae0-e063-4f0b-8dbd-4fed7796111c@github.com>

On Fri, 7 Jun 2024 21:13:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Interesting. Could you point me to a related bug / documentation / evidence? I tested the WaitForSingleObject version (commit 6524747a5ebc51c760b14e90309c5f18b58b20e2) on Windows 11, and I didn't observe any problems with shutting down the VM
>
> I don't have a test or counter example and don't have a detailed understanding of the blocking needs of Hotspot.

Another reason to retain the checking of GetThreadInterruptEvent is to be belt and suspenders against the Java code changing and opening up a potential error. At the moment, the reaper thread is encapsulated and not likely to get an interrupt, but that might not always be the case and someone changing the Java code might be unaware of the native code details.  $.02

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1633285990

From duke at openjdk.org  Mon Jun 10 13:58:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 10 Jun 2024 13:58:13 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v2]
In-Reply-To: <GqClPnYoe_m09iMqUkGge5KXTcILeop4NmBhZPKEPxc=.4917ae11-3cad-40d0-a09d-d025e6391532@github.com>
References: <NTuestJIqqBcmJg7R1xSWxUjeGPQdeXthA0GaIzPiBY=.ab21a23d-7be4-4bfd-8336-4584e6f3b342@github.com>
 <GqClPnYoe_m09iMqUkGge5KXTcILeop4NmBhZPKEPxc=.4917ae11-3cad-40d0-a09d-d025e6391532@github.com>
Message-ID: <NzUlb4DwpxDfYNPcIU3WalW3u71gEMRYvhrEhvqPzW4=.0ea0522f-6a0b-425c-8033-653fb0565ca1@github.com>

On Mon, 10 Jun 2024 03:51:40 GMT, Glavo <duke at openjdk.org> wrote:

>> Things have changed since https://github.com/openjdk/jdk/pull/14636 was closed, so let me reopen it.
>> 
>> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE caused a startup regression. In order to not have any more revert patches, it makes sense to optimize BALE.
>> 
>> The optimization of https://github.com/openjdk/jdk/pull/16245 allows the traditional expression to have good performance, but BA and BALE save us from having to copy these lengthy expressions everywhere. So it makes sense to keep them.
>> 
>> Now here's the question, should I rewrite this PR without `Unsafe`? I'll do some research (e.g. does `Unsafe` have better performance during warmup?), but I'd also like to take some advice.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

#16245 combining values ??into larger store, Instead of using Unsafe, can we implement it as follows, similar to the early versions of java.nio.Bits?


class ByteArrayLittleEndian {
    // ...
    public static void setInt(byte[] array, int offset, int value) {
        array[offset    ] = (byte)  value;
        array[offset + 1] = (byte) (value >> 8);
        array[offset + 2] = (byte) (value >> 16);
        array[offset + 3] = (byte) (value >> 24);
    }

	public static void setLong(byte[] bytes, int off, long value) {
        array[offset]     = (byte)  value;
        array[offset + 1] = (byte) (value >> 8);
        array[offset + 2] = (byte) (value >> 16);
        array[offset + 3] = (byte) (value >> 24);
        array[offset + 4] = (byte) (value >> 32);
        array[offset + 5] = (byte) (value >> 40);
        array[offset + 6] = (byte) (value >> 48);
        array[offset + 7] = (byte) (value >> 56);
    }
    // ...
}

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

PR Comment: https://git.openjdk.org/jdk/pull/19616#issuecomment-2158447800

From liach at openjdk.org  Mon Jun 10 14:22:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Jun 2024 14:22:11 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <Hnlr3yq2rjqWf-FusVY9EVu8h42xkhJniVC1Lqbch2k=.614aa4c3-5723-4f0e-8656-4a6e48d6ae3e@github.com>

On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

I think for that C2 JIT to work, we need to merge the `'t' 'r' 'u' 'e'` ascii bytes into an int constant. Same for `false`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2158504397

From kevinw at openjdk.org  Mon Jun 10 14:28:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Jun 2024 14:28:34 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed
Message-ID: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>

JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.

Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

-------------

Commit messages:
 - Additional test combination, old getSubject call with sm=allow
 - Test updates
 - whitespace
 - Merge remote-tracking branch 'upstream/master' into 8333344_JMX_Subject
 - 8333344: JMX attaching of Subject does not work when security manager not allowed

Changes: https://git.openjdk.org/jdk/pull/19624/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333344
  Stats: 160 lines in 19 files changed: 109 ins; 10 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Mon Jun 10 14:28:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Jun 2024 14:28:34 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <SBjBDVRRebfJYnmP6rseRU7_gkPR7mIqzn03UlnLNTE=.a841c253-b66f-4ffa-bb64-746fc3dda266@github.com>

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

When SecurityManager is not permitted, which is the default, use the Subject.current() call.
If SM is permitted, due to -Djava.security.manager=allow then the old Subject.getSubject(AccessController.getContext()) call is used.

Tests are updated to not require -Djava.security.manager=allow and will test with and without that setting.

Also additionally update tests to use Subject.current(), but also have a setting to test the old Subject.getSubject(AccessController.getContext()) call with -Djava.security.manager=allow (see ThreadPoolAccTest and test/jdk/javax/management/remote/mandatory/passwordAuthenticator).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2158515271

From alanb at openjdk.org  Mon Jun 10 14:31:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 14:31:12 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com>

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1634:

> 1632:                 } else {
> 1633:                     // We have ACC therefore SM is permitted, and Subject must be non-null:
> 1634:                     return Subject.doAs(subject, (PrivilegedExceptionAction<T>) () -> AccessController.doPrivileged((PrivilegedExceptionAction<T>) () -> wrappedClass.cast(mo.get()), acc));

This is not readable. If you create the PAEs explicitly then the casts will go away and it will be much easier to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633351429

From epeter at openjdk.org  Mon Jun 10 14:35:13 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 10 Jun 2024 14:35:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>
Message-ID: <9_OMKYvdx-xW6KC3sKovIYawgaRZfkKyvU97jcuskzM=.484f62c9-521c-47b5-a68a-6abc89c0e768@github.com>

On Mon, 10 Jun 2024 13:04:08 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> # 1. Compare with unsafe branch
> 
> 1. current (`5e815`) https://github.com/wenshao/jdk/tree/optim_str_builder_append_202406
> 2. unsafe (`adc220`) https://github.com/wenshao/jdk/tree/optim_str_builder_append_202406_unsafe
> 
> I think the performance of the Unsafe branch may be the best data for the C2 optimizer. @eme64 can help me see if C2 can do it?
> 
> # 2. Benchmark Commands
> 
> make test TEST="micro:java.lang.StringBuilders.toStringCharWithBool8"
> make test TEST="micro:java.lang.StringBuilders.toStringCharWithNull8"
> 
> 
> # 3. Implementation of Unsafe Branch
> 
> class AbstractStringBuilder {
>     static final Unsafe UNSAFE = Unsafe.getUnsafe();
> 
>     static final int NULL_LATIN1;
>     static final int TRUE_LATIN1;
>     static final int FALS_LATIN1;
> 
>     static final long NULL_UTF16;
>     static final long TRUE_UTF16;
>     static final long FALS_UTF16;
> 
>     static {
>         byte[] bytes4 = new byte[4];
>         byte[] bytes8 = new byte[8];
> 
>         bytes4[0] = 'n';
>         bytes4[1] = 'u';
>         bytes4[2] = 'l';
>         bytes4[3] = 'l';
>         NULL_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>         StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
>         NULL_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);
> 
>         bytes4[0] = 't';
>         bytes4[1] = 'r';
>         bytes4[2] = 'u';
>         bytes4[3] = 'e';
>         TRUE_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>         StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
>         TRUE_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);
> 
>         bytes4[0] = 'f';
>         bytes4[1] = 'a';
>         bytes4[2] = 'l';
>         bytes4[3] = 's';
>         FALS_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>         StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
>         FALS_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>     }
> 
>     private AbstractStringBuilder appendNull() {
>         ensureCapacityInternal(count + 4);
>         int count = this.count;
>         byte[] val = this.value;
>         if (isLatin1()) {
>             UNSAFE.putInt(
>                     val,
>                     Unsafe.ARRAY_BYTE_BASE_OFFSET + count,
>                     NULL_LATIN1);
>         } else {
>             UNSAFE.putLong(
>                     val,
>                     Unsafe.ARRAY_BYTE_BASE_OFFSET + (count << 1),
>                     NULL_UTF16);
>         }
>         this.count = count + 4;
>         return this;
>     }
> 
>     public AbstractStringBuilder append(boolean b) {
>         int count = th...

@wenshao 
> I think the performance of the Unsafe branch may be the best data for the C2 optimizer. @eme64 can help me see if C2 can do it?

Have you tried to see if the optimization actually was done/taken? You can use the `TraceMergeStores,` flag. Can you present the generated assembly code of the benchmarks, and explain the difference based on the generated assembly code? You can run JMH penchmarks with `perf`. These two blogs may help you:

http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html
https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_jmh_prof_perfasm

@liach I don't think it makes a difference if it is `int` or `byte` constants. Or what exactly is the code change you are proposing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2158533469

From pminborg at openjdk.org  Mon Jun 10 14:59:42 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 14:59:42 GMT
Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only
 property [v2]
In-Reply-To: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
References: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
Message-ID: <YL5fkBpw3beR9vV6w7Kahv4AfMtTNLlOgPlD6_Ow6vs=.8474c5ce-e09d-49c4-8202-a9ff2fac3d1e@github.com>

> This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called.
> 
> Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19629/files
  - new: https://git.openjdk.org/jdk/pull/19629/files/acebad9b..538eb2ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19629&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19629&range=00-01

  Stats: 29 lines in 1 file changed: 9 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/19629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19629/head:pull/19629

PR: https://git.openjdk.org/jdk/pull/19629

From mcimadamore at openjdk.org  Mon Jun 10 15:09:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 10 Jun 2024 15:09:13 GMT
Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only
 property [v2]
In-Reply-To: <YL5fkBpw3beR9vV6w7Kahv4AfMtTNLlOgPlD6_Ow6vs=.8474c5ce-e09d-49c4-8202-a9ff2fac3d1e@github.com>
References: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
 <YL5fkBpw3beR9vV6w7Kahv4AfMtTNLlOgPlD6_Ow6vs=.8474c5ce-e09d-49c4-8202-a9ff2fac3d1e@github.com>
Message-ID: <UzGZMavM9CnCrte0bxAuHvWrcPCJ6_94oTT2A7ObOjg=.eff28890-6b70-46bd-9bac-19db22ac7b5c@github.com>

On Mon, 10 Jun 2024 14:59:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called.
>> 
>> Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework docs

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 710:

> 708:      * but with the provided size.
> 709:      * <p>
> 710:      * If, and only if, this segment is {@linkplain MemorySegment#isReadOnly() read-only},

Correct, but the `, and only if, ` seems a tad too pedantic? I'll leave that to your consideration, not a strong feeling.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19629#pullrequestreview-2108075180
PR Review Comment: https://git.openjdk.org/jdk/pull/19629#discussion_r1633412181

From pminborg at openjdk.org  Mon Jun 10 15:17:12 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 15:17:12 GMT
Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only
 property [v2]
In-Reply-To: <yzp88FxXV5SXhwCqSzHyqSXATLiAwuWvwKW5QNDxfvI=.1bb3fa1b-e5ef-42de-9790-40fdc55712cd@github.com>
References: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
 <yzp88FxXV5SXhwCqSzHyqSXATLiAwuWvwKW5QNDxfvI=.1bb3fa1b-e5ef-42de-9790-40fdc55712cd@github.com>
Message-ID: <PRm7VSuHCctYNClAYXpwARn1buBz9iCQOgsBGQHOCY4=.fcd89874-8ad5-4002-a2b7-713fab6899e6@github.com>

On Mon, 10 Jun 2024 13:45:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Note that `asSlice` methods also lacks a similar guarantee on read-only (but the impl works fine there)

Even though not mentioned in the original issue, we could add documentation for this here as well. Or maybe via https://bugs.openjdk.org/browse/JDK-8333886 ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19629#issuecomment-2158628430

From mcimadamore at openjdk.org  Mon Jun 10 15:21:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 10 Jun 2024 15:21:12 GMT
Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only
 property [v2]
In-Reply-To: <PRm7VSuHCctYNClAYXpwARn1buBz9iCQOgsBGQHOCY4=.fcd89874-8ad5-4002-a2b7-713fab6899e6@github.com>
References: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
 <yzp88FxXV5SXhwCqSzHyqSXATLiAwuWvwKW5QNDxfvI=.1bb3fa1b-e5ef-42de-9790-40fdc55712cd@github.com>
 <PRm7VSuHCctYNClAYXpwARn1buBz9iCQOgsBGQHOCY4=.fcd89874-8ad5-4002-a2b7-713fab6899e6@github.com>
Message-ID: <Q-NqE_gDMJIDqsThI0VQfrtbpqhcBGE0MngS7TbQP8w=.bd0fff78-5854-44e7-bc90-a254277353d4@github.com>

On Mon, 10 Jun 2024 15:12:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> > Note that `asSlice` methods also lacks a similar guarantee on read-only (but the impl works fine there)
> 
> Even though not mentioned in the original issue, we could add documentation for this here as well. Or maybe via https://bugs.openjdk.org/browse/JDK-8333886 ?

Or a new issue - I'm fine with both approaches. Whatever requires less work. Since you are already adding these "if this segment is read-only...  ", maybe it would be simpler to review as part of this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19629#issuecomment-2158641151

From pminborg at openjdk.org  Mon Jun 10 15:30:39 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 15:30:39 GMT
Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only
 property [v3]
In-Reply-To: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
References: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
Message-ID: <7H7M_D7ts36-xW-fmIJoPutBunL8DChqAmBeFmLXqFs=.2c5fdc63-24d2-45af-b261-c84ddff16118@github.com>

> This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called.
> 
> Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add read-only comment on asSegment too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19629/files
  - new: https://git.openjdk.org/jdk/pull/19629/files/538eb2ed..bc0ade8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19629&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19629&range=01-02

  Stats: 19 lines in 1 file changed: 13 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19629/head:pull/19629

PR: https://git.openjdk.org/jdk/pull/19629

From rgiulietti at openjdk.org  Mon Jun 10 15:31:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 10 Jun 2024 15:31:15 GMT
Subject: RFR: 8333599: Improve description of \b matcher in j.u.r.Pattern
In-Reply-To: <FaW49XsLOLK1ZgfEJesSyGRzkFJpN-PiGoC0y5m0pho=.7b4bd81b-c893-4f40-96d9-df9857c31748@github.com>
References: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
 <FaW49XsLOLK1ZgfEJesSyGRzkFJpN-PiGoC0y5m0pho=.7b4bd81b-c893-4f40-96d9-df9857c31748@github.com>
Message-ID: <OoJoYj3u3u12EW8yNbyuTrBvuLcZzsghqpJm70Lfxbg=.31460335-d829-4c06-9016-698bd47f99fb@github.com>

On Fri, 7 Jun 2024 00:23:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> A documentation-only change to match the original intent and the implemented behavior.
>
> Oh, this needs a CSR too, since it's a change to a normative assertion. Should be pretty simple though.

@stuart-marks A [CSR](https://bugs.openjdk.org/browse/JDK-8333782) has been added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19583#issuecomment-2158661490

From kevinw at openjdk.org  Mon Jun 10 15:37:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Jun 2024 15:37:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed
In-Reply-To: <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com>
Message-ID: <M1wScbpaNcD94838eWSIjN2YM9oNEkES-ibFtdTu8fc=.ae6538fc-9d69-478e-9f6b-7734e2af9d69@github.com>

On Mon, 10 Jun 2024 14:28:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1634:
> 
>> 1632:                 } else {
>> 1633:                     // We have ACC therefore SM is permitted, and Subject must be non-null:
>> 1634:                     return Subject.doAs(subject, (PrivilegedExceptionAction<T>) () -> AccessController.doPrivileged((PrivilegedExceptionAction<T>) () -> wrappedClass.cast(mo.get()), acc));
> 
> This is not readable. If you create the PAEs explicitly then the casts will go away and it will be much easier to read.

Yes will simplify this!
This style was actually from the idea of moving to Subject.callAs, and nesting calls to keep the doPrivileged, but I don't think it will be necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633455244

From pminborg at openjdk.org  Mon Jun 10 15:49:18 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 15:49:18 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret return a
 memory segment backed by the same region of memory.
Message-ID: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>

This PR proposes to explicitly state that returned segments form the `asSlice` and `reinterpret` method share memory regions with `this` memory segment.

Note: The term "subset"  means a true subset or the same set.

-------------

Commit messages:
 - Add segments share the same backing store in docs

Changes: https://git.openjdk.org/jdk/pull/19633/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333886
  Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19633/head:pull/19633

PR: https://git.openjdk.org/jdk/pull/19633

From liach at openjdk.org  Mon Jun 10 15:59:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Jun 2024 15:59:11 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <iOSvXQHSMSZeG1gYYH7lZSu-XfNdpuN-IzIpfQ1AfOw=.c5b23a57-33b8-41e3-aedb-8d23ba1d6b66@github.com>

On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

You are right, I was thinking about the case where you have 2 short variables, you should combine them into a long explicitly for C2 to generate a 4-byte write, otherwise it would be 2 2-bytes. Omitted the constant part which already eliminates this restriction.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2158743190

From djelinski at openjdk.org  Mon Jun 10 16:28:39 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Jun 2024 16:28:39 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259 [v2]
In-Reply-To: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
Message-ID: <faV2NZicxH3cJYJKal1JECuMIV7KeFsYqGf1ioku-2Q=.97c49a3a-03a5-4d53-b40d-a653786bace3@github.com>

> `GetExitCodeProcess` method is not reliable for checking if a process exited already; it returns 259 (STILL_ACTIVE) if the process hasn't exited yet, but the same value is returned when the process exited with code 259. In order to check if the process exited, we need to check if its handle is in a signaled state using one of the wait methods.
> 
> This PR fixes the onExit, exitValue, isAlive, and waitFor(timeout) methods to correctly handle the problematic exit code.
> 
> I haven't fixed the ProcessImpl.toString method. I'm not sure the problem is important enough to justify an extra JNI call in the (probably typical) still-alive case.
> 
> Tier1-3 testing clean. I modified the existing OnExitTest to cover this case.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  waitForProcessExit0 should ignore interrupts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19586/files
  - new: https://git.openjdk.org/jdk/pull/19586/files/e2b457bf..4ff37ced

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19586&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19586&range=00-01

  Stats: 11 lines in 1 file changed: 0 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19586.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19586/head:pull/19586

PR: https://git.openjdk.org/jdk/pull/19586

From djelinski at openjdk.org  Mon Jun 10 16:28:39 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Jun 2024 16:28:39 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259 [v2]
In-Reply-To: <h2mkBfGEMeilfspqk45VPAhf2QsfqqwecbRgK_Ch618=.73a99ae0-e063-4f0b-8dbd-4fed7796111c@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
 <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
 <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
 <6FHMmdtAGyWE8HqW4etXrG0VSKrTektVEUXgJ2TXqs4=.bbaf0570-12eb-440a-848d-41674e8d29c6@github.com>
 <t1kt8CwjhkTbcmm_zMN1Snm51vm43q1___6Dase4cNE=.a5ffde16-91a6-47e6-b4e0-77d516e0494e@github.com>
 <h2mkBfGEMeilfspqk45VPAhf2QsfqqwecbRgK_Ch618=.73a99ae0-e063-4f0b-8dbd-4fed7796111c@github.com>
Message-ID: <pzBtu3ujtLSnx5-qwIUpph8qwCRcs3HPKl31S3pXoVQ=.a537df98-4ce6-4ea9-acf1-de49d3077657@github.com>

On Mon, 10 Jun 2024 13:48:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I don't have a test or counter example and don't have a detailed understanding of the blocking needs of Hotspot.
>
> Another reason to retain the checking of GetThreadInterruptEvent is to be belt and suspenders against the Java code changing and opening up a potential error. At the moment, the reaper thread is encapsulated and not likely to get an interrupt, but that might not always be the case and someone changing the Java code might be unaware of the native code details.  $.02

I did some research, and now I'm pretty confident that WaitForSingleObject is the right option:
- the thread involved here is a daemon thread, i.e. it doesn't prevent JVM exit
- the Unix version of `waitForProcessExit0` ignores interrupts and signals, it only ends when the wait succeeds or fails
- I didn't observe any problems with exiting the JVM while waiting on a process handle
- it's not clear to me what action we would take if the thread was cancelled; completing a CompletableFuture with an InterruptedException doesn't feel right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1633522031

From pminborg at openjdk.org  Mon Jun 10 16:41:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Jun 2024 16:41:30 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: <fZPFiiPxnf9NRK1VsVa-M1S2wvFW2WGItajqNvJN6bI=.d54311e7-0091-4e7b-8392-1dbc2cb49158@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

Keep alive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-2158838349

From kevinw at openjdk.org  Mon Jun 10 16:52:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Jun 2024 16:52:26 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v2]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <KSfvEpU3M549RiJQk2XxvhO9YygBORGTxOz4S-uyG18=.413cd464-0762-4490-8597-7d78baaede7d@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  More consistent style of calls and comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/22424a8e..d43f9a34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=00-01

  Stats: 12 lines in 1 file changed: 5 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From jvernee at openjdk.org  Mon Jun 10 17:04:15 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jun 2024 17:04:15 GMT
Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only
 property [v3]
In-Reply-To: <7H7M_D7ts36-xW-fmIJoPutBunL8DChqAmBeFmLXqFs=.2c5fdc63-24d2-45af-b261-c84ddff16118@github.com>
References: <zfhRfAA88I3JQabbNq1mvhdrM05---QaBE1KdbrDkng=.a7218f61-f1e7-487b-819f-50f139820da0@github.com>
 <7H7M_D7ts36-xW-fmIJoPutBunL8DChqAmBeFmLXqFs=.2c5fdc63-24d2-45af-b261-c84ddff16118@github.com>
Message-ID: <dZrpahEEFn2bwE3j-7Mqh4sF1Vpgo6-61wnhqAj_Ejk=.c116d42f-bc72-4a56-b8dd-ff42aa8a8100@github.com>

On Mon, 10 Jun 2024 15:30:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called.
>> 
>> Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add read-only comment on asSegment too

Marked as reviewed by jvernee (Reviewer).

Thanks for fixing!

-------------

PR Review: https://git.openjdk.org/jdk/pull/19629#pullrequestreview-2108320145
PR Comment: https://git.openjdk.org/jdk/pull/19629#issuecomment-2158879695

From rgiulietti at openjdk.org  Mon Jun 10 17:05:12 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 10 Jun 2024 17:05:12 GMT
Subject: RFR: 8333828: Use value javadoc tag in java.lang.{Float,
 Double} [v2]
In-Reply-To: <8EttkjTur6Og1vappqkT2az4EOh5G4FU2nA_b1anHYw=.80dd6f49-5182-4146-8e04-6f31e212b3aa@github.com>
References: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
 <8EttkjTur6Og1vappqkT2az4EOh5G4FU2nA_b1anHYw=.80dd6f49-5182-4146-8e04-6f31e212b3aa@github.com>
Message-ID: <BOQR7vdeo3E1AK9Xb6V4d_IIUfhZLJHCQloy98NI8bY=.ef4ec849-7c38-44a9-825f-a580cac6afb5@github.com>

On Fri, 7 Jun 2024 22:16:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Use the value tag to make the javadoc for various format-related constants more informative to readers. Currently the information is available by following the "Constant Field Values" link.
>> 
>> I'll reflow the paragraphs before a push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

LGTM

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19607#pullrequestreview-2108321549

From darcy at openjdk.org  Mon Jun 10 17:12:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jun 2024 17:12:24 GMT
Subject: RFR: 8333828: Use value javadoc tag in java.lang.{Float,
 Double} [v3]
In-Reply-To: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
References: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
Message-ID: <VAIvwepcalbuyW8b8i4yARqe4C4kNuuWCsayOnOmV_s=.b5d1ebbc-45cc-4023-8b3f-802f8884d3ee@github.com>

> Use the value tag to make the javadoc for various format-related constants more informative to readers. Currently the information is available by following the "Constant Field Values" link.
> 
> I'll reflow the paragraphs before a push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Reflow paragraphs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19607/files
  - new: https://git.openjdk.org/jdk/pull/19607/files/ea23aaf0..5d140fb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19607&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19607&range=01-02

  Stats: 23 lines in 2 files changed: 4 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/19607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19607/head:pull/19607

PR: https://git.openjdk.org/jdk/pull/19607

From jvernee at openjdk.org  Mon Jun 10 17:14:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jun 2024 17:14:11 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory.
In-Reply-To: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
Message-ID: <YhVgwZFkIjVvyaKmfWZh2qfOFZP2p7gKpcAiwvXfuc0=.b5de19ad-20d0-4421-96f6-b29fc9a628fb@github.com>

On Mon, 10 Jun 2024 15:45:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to explicitly state that returned segments form the `asSlice` and `reinterpret` method share memory regions with `this` memory segment.
> 
> Note: The term "subset"  means a true subset or the same set.

The term 'subset' doesn't feel right to me here, since we're only talking about a single memory region (not a set of memory region**s**). I suggest 'sub-region' instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19633#issuecomment-2158892356

From jvernee at openjdk.org  Mon Jun 10 17:14:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 10 Jun 2024 17:14:11 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory.
In-Reply-To: <YhVgwZFkIjVvyaKmfWZh2qfOFZP2p7gKpcAiwvXfuc0=.b5de19ad-20d0-4421-96f6-b29fc9a628fb@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
 <YhVgwZFkIjVvyaKmfWZh2qfOFZP2p7gKpcAiwvXfuc0=.b5de19ad-20d0-4421-96f6-b29fc9a628fb@github.com>
Message-ID: <1jySJvszszWTPX_IaMEu8EhbDHqkvY7BtDMcSiFI-l4=.83375e41-0c48-4b66-9e82-f073cc5df933@github.com>

On Mon, 10 Jun 2024 17:09:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The term 'subset' doesn't feel right to me here, since we're only talking about a single memory region (not a set of memory region**s**). I suggest 'sub-region' instead.

Actually, nvm, that doesn't work for `reinterpret` since the returned segment can also cover a larger region of memory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19633#issuecomment-2158895439

From darcy at openjdk.org  Mon Jun 10 17:18:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jun 2024 17:18:15 GMT
Subject: Integrated: 8333828: Use value javadoc tag in java.lang.{Float,
 Double}
In-Reply-To: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
References: <fK00P2tTX9PLup8MMP0iQsE2SPJkBEfjoJwtpiPgFp4=.a3074d63-4351-4ea7-a8f9-35ed92bedec9@github.com>
Message-ID: <J9WXX4nbxGtI1j_8xqJo3AZBd8n0uYFOlPXslmpYrLM=.810fc370-db7c-46b1-9e19-481fee03f606@github.com>

On Fri, 7 Jun 2024 21:05:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use the value tag to make the javadoc for various format-related constants more informative to readers. Currently the information is available by following the "Constant Field Values" link.
> 
> I'll reflow the paragraphs before a push.

This pull request has now been integrated.

Changeset: 13642cb4
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13642cb4b8895ad07b2249c9e215a6a037e5cf71
Stats:     23 lines in 2 files changed: 4 ins; 0 del; 19 mod

8333828: Use value javadoc tag in java.lang.{Float, Double}

Reviewed-by: liach, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/19607

From iris at openjdk.org  Mon Jun 10 17:30:15 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Jun 2024 17:30:15 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2108383696

From darcy at openjdk.org  Mon Jun 10 17:42:27 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jun 2024 17:42:27 GMT
Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v2]
In-Reply-To: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
References: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
Message-ID: <mffZ0ed64cMZfhIgwhytkyq8VVRsvSRnxuXiS84WKdA=.4824f5d9-6055-44c9-97c2-b2dbcee7b63c@github.com>

> Misc small doc updates and addition of `@Overrides` annotations.

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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8333768
 - JDK-8333768: Minor doc updates to java.lang.{Float, Double}

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19590/files
  - new: https://git.openjdk.org/jdk/pull/19590/files/99f1ade0..cfe77e62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19590&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19590&range=00-01

  Stats: 8759 lines in 137 files changed: 7210 ins; 936 del; 613 mod
  Patch: https://git.openjdk.org/jdk/pull/19590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19590/head:pull/19590

PR: https://git.openjdk.org/jdk/pull/19590

From rriggs at openjdk.org  Mon Jun 10 19:48:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Jun 2024 19:48:13 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259 [v2]
In-Reply-To: <faV2NZicxH3cJYJKal1JECuMIV7KeFsYqGf1ioku-2Q=.97c49a3a-03a5-4d53-b40d-a653786bace3@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <faV2NZicxH3cJYJKal1JECuMIV7KeFsYqGf1ioku-2Q=.97c49a3a-03a5-4d53-b40d-a653786bace3@github.com>
Message-ID: <L0uSCSfa9S9XwlT2IXi9L-PDL_1uVtKYTmez1dwbdGY=.f598cd57-45ac-4b8f-9382-b00d0e9a6bb7@github.com>

On Mon, 10 Jun 2024 16:28:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> `GetExitCodeProcess` method is not reliable for checking if a process exited already; it returns 259 (STILL_ACTIVE) if the process hasn't exited yet, but the same value is returned when the process exited with code 259. In order to check if the process exited, we need to check if its handle is in a signaled state using one of the wait methods.
>> 
>> This PR fixes the onExit, exitValue, isAlive, and waitFor(timeout) methods to correctly handle the problematic exit code.
>> 
>> I haven't fixed the ProcessImpl.toString method. I'm not sure the problem is important enough to justify an extra JNI call in the (probably typical) still-alive case.
>> 
>> Tier1-3 testing clean. I modified the existing OnExitTest to cover this case.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   waitForProcessExit0 should ignore interrupts

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19586#pullrequestreview-2108626204

From rriggs at openjdk.org  Mon Jun 10 19:48:14 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Jun 2024 19:48:14 GMT
Subject: RFR: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259 [v2]
In-Reply-To: <pzBtu3ujtLSnx5-qwIUpph8qwCRcs3HPKl31S3pXoVQ=.a537df98-4ce6-4ea9-acf1-de49d3077657@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
 <UdE6GbWQuSgr_6rq62_s-r5p3PggXxKopH9YWoCMKCc=.07fced0b-e5ad-44a5-85e2-928c221b7ee2@github.com>
 <R0cixkfhvwW-OU6XRdFlhmehgyIVoWpUY83_JxUihlY=.093f143f-8e12-4217-a777-a591da4f19df@github.com>
 <dEbQ6_0CahhaSB4D7ZqLdZzbKBPyC81Wx37xoBQbreU=.4516c760-d16e-4eea-b2ab-e5a1867e3124@github.com>
 <6FHMmdtAGyWE8HqW4etXrG0VSKrTektVEUXgJ2TXqs4=.bbaf0570-12eb-440a-848d-41674e8d29c6@github.com>
 <t1kt8CwjhkTbcmm_zMN1Snm51vm43q1___6Dase4cNE=.a5ffde16-91a6-47e6-b4e0-77d516e0494e@github.com>
 <h2mkBfGEMeilfspqk45VPAhf2QsfqqwecbRgK_Ch618=.73a99ae0-e063-4f0b-8dbd-4fed7796111c@github.com>
 <pzBtu3ujtLSnx5-qwIUpph8qwCRcs3HPKl31S3pXoVQ=.a537df98-4ce6-4ea9-acf1-de49d3077657@github.com>
Message-ID: <t0pkD628XA_agQyr8KG8voa7L79rGNdZoolXGh7dGFA=.b846e30d-bc65-4a5e-b9a9-43a73d8071ac@github.com>

On Mon, 10 Jun 2024 16:24:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Another reason to retain the checking of GetThreadInterruptEvent is to be belt and suspenders against the Java code changing and opening up a potential error. At the moment, the reaper thread is encapsulated and not likely to get an interrupt, but that might not always be the case and someone changing the Java code might be unaware of the native code details.  $.02
>
> I did some research, and now I'm pretty confident that WaitForSingleObject is the right option:
> - the thread involved here is a daemon thread, i.e. it doesn't prevent JVM exit
> - the Unix version of `waitForProcessExit0` ignores interrupts and signals, it only ends when the wait succeeds or fails
> - I didn't observe any problems with exiting the JVM while waiting on a process handle
> - it's not clear to me what action we would take if the thread was cancelled; completing a CompletableFuture with an InterruptedException doesn't feel right.

ok, I'll buy that argument

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19586#discussion_r1633748785

From naoto at openjdk.org  Mon Jun 10 19:49:15 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Jun 2024 19:49:15 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently
In-Reply-To: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
Message-ID: <krNjf_En7JPZTRKkTnQRcM8lSYAco9DwGQATO7NGVbY=.33cc7647-0c40-453d-9fdd-a347f121a21e@github.com>

On Mon, 10 Jun 2024 12:29:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this fix for an intermittent test failure.
> 
> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
> 
> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
> 
> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.

LGTM

test/jdk/java/io/IO/IO.java line 190:

> 188: 
> 189: 
> 190:     // adapted from https://raw.githubusercontent.com/junit-team/junit5/main/documentation/src/test/java/example/timing/TimingExtension.java

Probably better to refer to the user guide on the web (https://junit.org/junit5/docs/snapshot/user-guide/#extensions-lifecycle-callbacks-before-after-execution)

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19627#pullrequestreview-2108625709
PR Review Comment: https://git.openjdk.org/jdk/pull/19627#discussion_r1633749196

From dnguyen at openjdk.org  Mon Jun 10 20:05:33 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
Message-ID: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.

The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.

Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
https://cr.openjdk.org/~dnguyen/output2/

-------------

Commit messages:
 - Review comment edits
 - Initial localization changes

Changes: https://git.openjdk.org/jdk/pull/19609/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333827
  Stats: 239 lines in 39 files changed: 133 ins; 57 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/19609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609

PR: https://git.openjdk.org/jdk/pull/19609

From achung at openjdk.org  Mon Jun 10 20:05:33 2024
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <b6aneCOmBcnk_v0W_sl89B94wwIeT12Zf2GwtSaG99A=.5d32dade-5b56-4179-9bbe-f07eb0352cfb@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Just a question about the reverted translations, otherwise LGTM

> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.

Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2105526180
PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2155723513

From jlu at openjdk.org  Mon Jun 10 20:05:33 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Cannot speak to the translations themselves, but in general the changes LGTM pending the comments.

src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1:

> 1: #

It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions.

src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66:

> 64: label.size=??(&Z):
> 65: label.source=??(&C):
> 66: label.outputbins=????(&P)?

Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278:

> 276:         UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}".
> 277:         UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden.
> 278:         ENTITYFailedInitializeGrammar =  ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t

It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool.

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 285:

> 283: VIRTUAL_MACHINE=Virtuelle Maschine
> 284: VM_ARGUMENTS=VM-Argumente
> 285: VMINTERNAL_FRAME_ACCESSIBLE_DESCRIPTION=Innerer Frame f?r das Monitoring einer Java Virtual Machine

This one-off change is consistent with the change in _src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java_.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:

> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
> 182: 
> 183: help.usage = Verwendung:   jshell <option>... <load-file>...\nM?gliche Optionen:\n    --class-path <path>   Gibt an, wo die Benutzerklassendateien gespeichert sind\n    --module-path <path>  Gibt an, wo die Anwendungsmodule gespeichert sind\n    --add-modules <module>(,<module>)*\n                          Gibt aufzul?sende Module oder alle Module im\n                            Modulpfad an, wenn <module> ALL-MODULE-PATHs lautet\n    --enable-native-access\n                          Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n    --enable-preview      Code kann Vorschaufeatures in diesem Release nutzen\n    --startup <Datei>      Ersetzung der Startdefinitionen mit einer Ausf?hrung\n    --no-startup          Startdefinitionen werden nicht ausgef?hrt\n    --feedback <Modus>     Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n                            vordefiniert (Silent, Concise, Normal oder Verbose) oder\n                            v
 orab benutzerdefiniert sein\n    -q                    Stilles Feedback. Identisch mit: --feedback concise\n    -s                    ?u?erst stilles Feedback. Identisch mit: --feedback silent\n    -v                    Verbose-Feedback. Identisch mit: --feedback verbose\n    -J<flag>              ?bergibt <flag> an das Laufzeitsystem, hat aber keine Auswirkungen\n                            auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n                            die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n                            -R<flag>. Verwenden Sie alternativ dazu -J<flag> mit\n                            --execution local.\n    -R<flag>              ?bergibt <flag> nur dann an das Laufzeitsystem, wenn\n                            Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n                            bedeutet, dass die Ausf?hrung des Snippets\n                            System.getProperty("foo") "bar" zur?ckgi
 bt.\n    -C<flag>              ?bergibt <flag> an den Java-Compiler in JShell.\n                            Beispiel: -C-Xlint aktiviert alle empfohlenen\n                            LINT-Warnungen, und -C--release=<N> kompiliert f?r\n                            Java SE N, wie wenn --release N angegeben wird.\n                            Verwenden Sie ein -C pro Compiler-Kennzeichen oder Kennzeichenargument\n    --version             Gibt Versionsinformationen aus und beendet den Vorgang\n    --show-version        Gibt Versionsinformationen aus und setzt den Vorgang fort\n    --help, -?, -h        Gibt diese Zusammenfassung der Standardoptionen aus und beendet den Vorgang\n    --help-extra, -X      Gibt Hilfetext zu Nicht-Standardoptionen aus und beendet den Vorgang\n\nEin Dateiargument kann ein Dateiname oder einer der vordefinierten Dateinamen sein: DEFAULT,\nPRINTING, TOOLING oder JAVASE.\nEine Ladedatei kann auch "-" zur Angabe einer Standardeingabe ohne interaktiven I/O sein.
 \n\nWeitere Informationen zu den Auswertungskontextoptionen (--class-path,\n--module-path und --add-modules) finden Sie unter:\n\t/help context\n\nEin Pfad listet die zu durchsuchenden Verzeichnisse und Archive auf. Verwenden Sie unter Windows ein\nSemikolon (;), um Elemente im Pfad zu trennen. Verwenden Sie auf anderen Plattformen einen\nDoppelpunkt (:), um Elemente zu trennen.\n

> Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated?

@alisenchung While these command line options are untranslated, which initially may seem confusing, it appears to be the translation tool standardizing the definitions with the Japanese and Chinese localized definitions. We should leave them untranslated.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2106349441
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632407907
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632376640
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632375726
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632377328
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632373349

From dnguyen at openjdk.org  Mon Jun 10 20:05:33 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
Message-ID: <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>

On Sun, 9 Jun 2024 22:49:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1:
> 
>> 1: #
> 
> It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions.

Right, the source file has the copyright year of 2019, and these translated files reflect that, so I believe this is OK.

> src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66:
> 
>> 64: label.size=??(&Z):
>> 65: label.source=??(&C):
>> 66: label.outputbins=????(&P)?
> 
> Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool.

Right, I agree. I'm OK with either decision too, but I'm leaning towards reverting this to standardize the colons since the rest are (U+003A). Maybe a reviewer from desktop can chime in once this PR is undrafted.

> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278:
> 
>> 276:         UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}".
>> 277:         UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden.
>> 278:         ENTITYFailedInitializeGrammar =  ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t
> 
> It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool.

Yeah, I believe you're right. Noted as something else to file against the translation tool.

> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:
> 
>> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
>> 182: 
>> 183: help.usage = Verwendung:   jshell <option>... <load-file>...\nM?gliche Optionen:\n    --class-path <path>   Gibt an, wo die Benutzerklassendateien gespeichert sind\n    --module-path <path>  Gibt an, wo die Anwendungsmodule gespeichert sind\n    --add-modules <module>(,<module>)*\n                          Gibt aufzul?sende Module oder alle Module im\n                            Modulpfad an, wenn <module> ALL-MODULE-PATHs lautet\n    --enable-native-access\n                          Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n    --enable-preview      Code kann Vorschaufeatures in diesem Release nutzen\n    --startup <Datei>      Ersetzung der Startdefinitionen mit einer Ausf?hrung\n    --no-startup          Startdefinitionen werden nicht ausgef?hrt\n    --feedback <Modus>     Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n                            vordefiniert (Silent, Concise, Normal oder Verbose) oder\n                            
 vorab benutzerdefiniert sein\n    -q                    Stilles Feedback. Identisch mit: --feedback concise\n    -s                    ?u?erst stilles Feedback. Identisch mit: --feedback silent\n    -v                    Verbose-Feedback. Identisch mit: --feedback verbose\n    -J<flag>              ?bergibt <flag> an das Laufzeitsystem, hat aber keine Auswirkungen\n                            auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n                            die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n                            -R<flag>. Verwenden Sie alternativ dazu -J<flag> mit\n                            --execution local.\n    -R<flag>              ?bergibt <flag> nur dann an das Laufzeitsystem, wenn\n                            Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n                            bedeutet, dass die Ausf?hrung des Snippets\n                            System.getProperty("foo") "bar" zur?ckg
 ibt.\n    -C<flag>              ?bergibt <flag> an den Java-Compiler in JShell.\n                            Beispiel: -C-Xlint aktiviert alle empfohlenen\n                           ...

This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633762275
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632401147
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633748812
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632401256

From jjg at openjdk.org  Mon Jun 10 20:15:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 20:15:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
Message-ID: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>

On Sun, 9 Jun 2024 22:07:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:
>> 
>>> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
>>> 182: 
>>> 183: help.usage = Verwendung:   jshell <option>... <load-file>...\nM?gliche Optionen:\n    --class-path <path>   Gibt an, wo die Benutzerklassendateien gespeichert sind\n    --module-path <path>  Gibt an, wo die Anwendungsmodule gespeichert sind\n    --add-modules <module>(,<module>)*\n                          Gibt aufzul?sende Module oder alle Module im\n                            Modulpfad an, wenn <module> ALL-MODULE-PATHs lautet\n    --enable-native-access\n                          Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n    --enable-preview      Code kann Vorschaufeatures in diesem Release nutzen\n    --startup <Datei>      Ersetzung der Startdefinitionen mit einer Ausf?hrung\n    --no-startup          Startdefinitionen werden nicht ausgef?hrt\n    --feedback <Modus>     Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n                            vordefiniert (Silent, Concise, Normal oder Verbose) oder\n                           
  vorab benutzerdefiniert sein\n    -q                    Stilles Feedback. Identisch mit: --feedback concise\n    -s                    ?u?erst stilles Feedback. Identisch mit: --feedback silent\n    -v                    Verbose-Feedback. Identisch mit: --feedback verbose\n    -J<flag>              ?bergibt <flag> an das Laufzeitsystem, hat aber keine Auswirkungen\n                            auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n                            die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n                            -R<flag>. Verwenden Sie alternativ dazu -J<flag> mit\n                            --execution local.\n    -R<flag>              ?bergibt <flag> nur dann an das Laufzeitsystem, wenn\n                            Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n                            bedeutet, dass die Ausf?hrung des Snippets\n                            System.getProperty("foo") "bar" zur?ck
 gibt.\n    -C<flag>              ?bergibt <flag> an den Java-Compiler in JShell.\n                            Beispiel: -C-Xlint aktiviert alle empfohlenen\n                    ...
>
> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.

While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, `<args>`, `<class-path>`.

This change seems to be going backwards.

Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633774912

From prr at openjdk.org  Mon Jun 10 20:23:22 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Jun 2024 20:23:22 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 66:

> 64: label.size=G&r??e:
> 65: label.source=&Quelle:
> 66: label.outputbins=A&usgabef?cher:

How confident are we in this ?
google translate says that the old text referred to 'compartments' and the new one to 'areas' and I wonder why that is better ?

https://translate.google.com/?sl=auto&tl=en&text=Ausgabebereiche%0AAusgebefacher&op=translate

src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 32:

> 30: border.jobattributes=????
> 31: border.media=??
> 32: border.output=??

What triggered this ? Just someone noticing it and deciding there's a better translation ?
What does it say ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633781646
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633782742

From jjg at openjdk.org  Mon Jun 10 20:23:23 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 20:23:23 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <SjpwOVwkqCFBlC_Vj1rv4JwgHdgqnpiz8xrDTE98eOc=.c90d5753-0206-48e9-bfb4-8e6bc67c616a@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 409:

> 407: compiler.err.unconditional.pattern.and.default=Switch umfasst sowohl ein nicht bedingtes Muster als auch ein Standardlabel
> 408: 
> 409: compiler.err.unconditional.pattern.and.both.boolean.values=Switch umfasst sowohl boolesche Werte als auch ein nicht bedingtes Muster

Here and elsewhere in this file and other translations, I'm surprised `switch` is not being translated, and is being capitalized. In the English form, it is not being used as a keyword, although could maybe be seen as a short form of `switch' statement, in which case `switch` should be treated as a keyword and not translated or capitalized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633782242

From dnguyen at openjdk.org  Mon Jun 10 20:37:13 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:37:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <SjpwOVwkqCFBlC_Vj1rv4JwgHdgqnpiz8xrDTE98eOc=.c90d5753-0206-48e9-bfb4-8e6bc67c616a@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <SjpwOVwkqCFBlC_Vj1rv4JwgHdgqnpiz8xrDTE98eOc=.c90d5753-0206-48e9-bfb4-8e6bc67c616a@github.com>
Message-ID: <2-SMv3j3Eqrv7LVV6CbkZVEb3KFcahQR1_8AiJErDAQ=.07538bd6-9b25-45ed-b47f-8e9102ea8af9@github.com>

On Mon, 10 Jun 2024 20:20:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 409:
> 
>> 407: compiler.err.unconditional.pattern.and.default=Switch umfasst sowohl ein nicht bedingtes Muster als auch ein Standardlabel
>> 408: 
>> 409: compiler.err.unconditional.pattern.and.both.boolean.values=Switch umfasst sowohl boolesche Werte als auch ein nicht bedingtes Muster
> 
> Here and elsewhere in this file and other translations, I'm surprised `switch` is not being translated, and is being capitalized. In the English form, it is not being used as a keyword, although could maybe be seen as a short form of `switch' statement, in which case `switch` should be treated as a keyword and not translated or capitalized.

Good catch. Seems to be across all files and I'm assuming it's for the reason you suggested. I'll bring this up to the go team. I have no way to fix this since I can't rely on google translate. This can be caught in a future update if the go team can successfully differentiate the difference between the word `switch` and a `switch keyword`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633796771

From dnguyen at openjdk.org  Mon Jun 10 20:37:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:37:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
Message-ID: <P4mDp3QdSzjC6Fdj2ZmhOdNl5GcRrEb6PexlIZYYHpI=.9b384ebb-9dee-4b33-8fc2-370818ac80a3@github.com>

On Mon, 10 Jun 2024 20:12:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.
>
> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, `<args>`, `<class-path>`.
> 
> This change seems to be going backwards.
> 
> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.

The go translation team dictates which of these segments within a file actually get updated. I can manually revert the segments if preferred, but these changes will continue appearing for future drops with the current system. 

I can potentially try to communicate to the other team to differentiate between keywords & option names versus some of these other words, but let me know how you'd like me to proceed with this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633794362

From dnguyen at openjdk.org  Mon Jun 10 20:40:15 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:40:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
Message-ID: <0xmUIRy1V_ts7yyfm1kMaQfbzU5YoJSWAzD3QDNLY7U=.8e0e163e-d0c6-4f22-a92d-79de8c58e8f6@github.com>

On Mon, 10 Jun 2024 20:20:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 32:
> 
>> 30: border.jobattributes=????
>> 31: border.media=??
>> 32: border.output=??
> 
> What triggered this ? Just someone noticing it and deciding there's a better translation ?
> What does it say ?

In the past, it was brought up in review that some of the words were translated to localized words that didn't exactly mean what the original English word meant. I believe Weijun Wang caught some of these in Chinese files in the past.  I'm assuming these are cases where the go team is improving the translation, but I also can't exactly tell. We do suggest changes to the go team, so maybe this is evidence of them improving their tool.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633801033

From naoto at openjdk.org  Mon Jun 10 20:49:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Jun 2024 20:49:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Did not look at each for translation accuracy (did some for Japanese), but looks good overall.
It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2108722631

From dnguyen at openjdk.org  Mon Jun 10 21:45:13 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:45:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
Message-ID: <ib1NQFG8TW7Wr6ZMzxxxF5JreiZiVPHoyTHn--6ad2k=.f01f7a8c-49cc-42fc-84f3-16a6afc5b8fc@github.com>

On Mon, 10 Jun 2024 20:46:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Did not look at each for translation accuracy (did some for Japanese), but looks good overall. It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!

Justin's tool is responsible for this. Made the process quicker/simpler as well once everything was setup properly and working.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2159331304

From dnguyen at openjdk.org  Mon Jun 10 21:45:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:45:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
Message-ID: <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>

On Mon, 10 Jun 2024 20:12:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.
>
> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, `<args>`, `<class-path>`.
> 
> This change seems to be going backwards.
> 
> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.

@jonathan-gibbons I just realized that this change to the German file matches the file with the Japanese and Chinese localized files. By that I mean the "backwards" translations are also present for the Japanese and Chinese files.

However, the previous versions of the Japanese and Chinese files don't have these bits translated. So in summary, I can revert the German file back to German but the Japanese and Chinese files will still be English for these parts because I wouldn't know what to revert them to in their local language.

As a result, I actually think it might be better to change this German file as shown in the current version of the PR just to remain consistent with the other localized versions of this file. We can still bring this up to the go team as an issue, but I think this is the best solution now for this drop at least.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633859027

From joehw at openjdk.org  Mon Jun 10 21:54:14 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 10 Jun 2024 21:54:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <ADcUl2k8pnbEDcAvLsEOBA05LjviX8HmX3OAlGEK5Mw=.05eee615-de93-4792-a8d8-5c2ea8a0dabe@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

One minor comment, otherwise the java.xml changes look good.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331:

> 329: 
> 330: # Implementation Property DTD
> 331:         JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary.

either drop the double quote in "Ablehnen" or use the literal without translation, that is, "deny".

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2108813421
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633870136

From dnguyen at openjdk.org  Mon Jun 10 21:58:29 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:58:29 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Remove double quotes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19609/files
  - new: https://git.openjdk.org/jdk/pull/19609/files/9125337b..32d69e89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609

PR: https://git.openjdk.org/jdk/pull/19609

From cjplummer at openjdk.org  Mon Jun 10 22:27:15 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 10 Jun 2024 22:27:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
Message-ID: <ivxoCg1QhjwpzbGR6T6rHreTkqv-NVFo7jZYwNL0LiM=.c10bee70-9ca8-4db5-89b1-ee7682729e3d@github.com>

On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double quotes

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 325:

> 323:         {"Unexpected event type", "Unerwarteter Ereignistyp: {0}"},
> 324:         {"unknown", "unbekannt"},
> 325:         {"Unmonitoring", "Monitoring von {0} aufheben"},

The English entry is:

        {"Unmonitoring", "Unmonitoring {0} "},

But the German entry now says "Monitoring". I'm  sure what the original "\u00DCberwachung" translates to, other than berwachung is monitoring. Now this resource is partly in English, and is the incorrect English.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633902362

From dnguyen at openjdk.org  Mon Jun 10 22:51:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 22:51:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <ivxoCg1QhjwpzbGR6T6rHreTkqv-NVFo7jZYwNL0LiM=.c10bee70-9ca8-4db5-89b1-ee7682729e3d@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
 <ivxoCg1QhjwpzbGR6T6rHreTkqv-NVFo7jZYwNL0LiM=.c10bee70-9ca8-4db5-89b1-ee7682729e3d@github.com>
Message-ID: <iJZMTs0UUdFqw07uiMXQrkv3QBeyv70VQyyVZtFy5k4=.22762511-49c4-4ad6-a198-38d2be8ac4f6@github.com>

On Mon, 10 Jun 2024 22:19:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove double quotes
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 325:
> 
>> 323:         {"Unexpected event type", "Unerwarteter Ereignistyp: {0}"},
>> 324:         {"unknown", "unbekannt"},
>> 325:         {"Unmonitoring", "Monitoring von {0} aufheben"},
> 
> The English entry is:
> 
>         {"Unmonitoring", "Unmonitoring {0} "},
> 
> But the German entry now says "Monitoring". I'm  sure what the original "\u00DCberwachung" translates to, other than berwachung is monitoring. Now this resource is partly in English, and is the incorrect English.

I don't know German, but when plugging `"Monitoring von {0} aufheben"` into google translate, I get `Unmonitoring` as well. Maybe `Monitoring` is a word that could also be used in German? No clue. The translation tool decided to make this change.

@sormuras do you have any input on this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633925334

From duke at openjdk.org  Mon Jun 10 23:13:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 10 Jun 2024 23:13:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <9_OMKYvdx-xW6KC3sKovIYawgaRZfkKyvU97jcuskzM=.484f62c9-521c-47b5-a68a-6abc89c0e768@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>
 <9_OMKYvdx-xW6KC3sKovIYawgaRZfkKyvU97jcuskzM=.484f62c9-521c-47b5-a68a-6abc89c0e768@github.com>
Message-ID: <IM4whi_rK2qmJJfMCziFoep3XRyO1vuHugTkm8IUqtc=.a23c747f-e2c3-40fd-90d3-f7bfb01bb96b@github.com>

On Mon, 10 Jun 2024 14:32:46 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> # 1. Compare with unsafe branch
>> 
>> 1. current (`5e815`) https://github.com/wenshao/jdk/tree/optim_str_builder_append_202406
>> 2. unsafe (`adc220`) https://github.com/wenshao/jdk/tree/optim_str_builder_append_202406_unsafe
>> 
>> I think the performance of the Unsafe branch may be the best data for the C2 optimizer. @eme64 can help me see if C2 can do it?
>> 
>> # 2. Benchmark Commands
>> 
>> make test TEST="micro:java.lang.StringBuilders.toStringCharWithBool8"
>> make test TEST="micro:java.lang.StringBuilders.toStringCharWithNull8"
>> 
>> 
>> # 3. Implementation of Unsafe Branch
>> 
>> class AbstractStringBuilder {
>>     static final Unsafe UNSAFE = Unsafe.getUnsafe();
>> 
>>     static final int NULL_LATIN1;
>>     static final int TRUE_LATIN1;
>>     static final int FALS_LATIN1;
>> 
>>     static final long NULL_UTF16;
>>     static final long TRUE_UTF16;
>>     static final long FALS_UTF16;
>> 
>>     static {
>>         byte[] bytes4 = new byte[4];
>>         byte[] bytes8 = new byte[8];
>> 
>>         bytes4[0] = 'n';
>>         bytes4[1] = 'u';
>>         bytes4[2] = 'l';
>>         bytes4[3] = 'l';
>>         NULL_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>>         StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
>>         NULL_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>> 
>>         bytes4[0] = 't';
>>         bytes4[1] = 'r';
>>         bytes4[2] = 'u';
>>         bytes4[3] = 'e';
>>         TRUE_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>>         StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
>>         TRUE_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>> 
>>         bytes4[0] = 'f';
>>         bytes4[1] = 'a';
>>         bytes4[2] = 'l';
>>         bytes4[3] = 's';
>>         FALS_LATIN1 = UNSAFE.getInt(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>>         StringUTF16.inflate(bytes4, 0, bytes8, 0, 4);
>>         FALS_UTF16 = UNSAFE.getLong(bytes8, Unsafe.ARRAY_BYTE_BASE_OFFSET);
>>     }
>> 
>>     private AbstractStringBuilder appendNull() {
>>         ensureCapacityInternal(count + 4);
>>         int count = this.count;
>>         byte[] val = this.value;
>>         if (isLatin1()) {
>>             UNSAFE.putInt(
>>                     val,
>>                     Unsafe.ARRAY_BYTE_BASE_OFFSET + count,
>>                     NULL_LATIN1);
>>         } else {
>>             UNSAFE.putLong(
>>                     val,
>>                     Unsafe.ARRAY_BYTE_BASE_OFFSET + (count << 1),
>>                     NULL_UTF16);
>>      ...
>
> @wenshao 
>> I think the performance of the Unsafe branch may be the best data for the C2 optimizer. @eme64 can help me see if C2 can do it?
> 
> Have you tried to see if the optimization actually was done/taken? You can use the `TraceMergeStores,` flag. Can you present the generated assembly code of the benchmarks, and explain the difference based on the generated assembly code? You can run JMH penchmarks with `perf`. These two blogs may help you:
> 
> http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html
> https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_jmh_prof_perfasm
> 
> @liach I don't think it makes a difference if it is `int` or `byte` constants. Or what exactly is the code change you are proposing?

@eme64 It seems that when the following code uses StringUTF16.putChar, C2's optimization is not as good as the manual merging and storage effect.

class AbstractStringBuilder {
    private AbstractStringBuilder appendNull() {
    	// ...
		StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
		// ...
	}

	public AbstractStringBuilder append(boolean b) {
	    // ...
		StringUTF16.putCharsAt(val, count, 't', 'r', 'u', 'e');
		// ...
		StringUTF16.putCharsAt(val, count, 'f', 'a', 'l', 's', 'e');
		// ...
	}
}

class StringUTF16 {
   public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
    }

    @IntrinsicCandidate
    // intrinsic performs no bounds checks
    static void putChar(byte[] val, int index, int c) {
        assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
        index <<= 1;
        val[index++] = (byte)(c >> HI_BYTE_SHIFT);
        val[index]   = (byte)(c >> LO_BYTE_SHIFT);
    }
}


The code for manually merging storage is as follows, without using Unsafe:

class AbstractStringBuilder {
    static final long NULL_UTF16;
    static final long TRUE_UTF16;
    static final long FALS_UTF16;

    static {
        byte[] bytes = new byte[8];

        StringUTF16.putCharsAt(bytes, 0, 'n', 'u', 'l', 'l');
        NULL_UTF16 = getLong(bytes, 0);

        StringUTF16.putCharsAt(bytes, 0, 't', 'r', 'u', 'e');
        TRUE_UTF16 = getLong(bytes, 0);

        StringUTF16.putCharsAt(bytes, 0, 'f', 'a', 'l', 's');
        FALS_UTF16 = getLong(bytes, 0);
    }

    private static long getLong(byte[] bytes, int offset) {
        return (((long)bytes[offset    ] & 0xff)      ) |
               (((long)bytes[offset + 1] & 0xff) <<  8) |
               (((long)bytes[offset + 2] & 0xff) << 16) |
               (((long)bytes[offset + 3] & 0xff) << 24) |
               (((long)bytes[offset + 4] & 0xff) << 32) |
               (((long)bytes[offset + 5] & 0xff) << 40) |
               (((long)bytes[offset + 6] & 0xff) << 48) |
               (((long)bytes[offset + 7] & 0xff) << 56);
    }

    private static void setLong(byte[] array, int offset, long value) {
        array[offset]     = (byte)  value;
        array[offset + 1] = (byte) (value >> 8);
        array[offset + 2] = (byte) (value >> 16);
        array[offset + 3] = (byte) (value >> 24);
        array[offset + 4] = (byte) (value >> 32);
        array[offset + 5] = (byte) (value >> 40);
        array[offset + 6] = (byte) (value >> 48);
        array[offset + 7] = (byte) (value >> 56);
    }

    private AbstractStringBuilder appendNull() {
        int count = this.count;
        ensureCapacityInternal(count + 4);
        byte[] val = this.value;
        if (isLatin1()) {
            val[count    ] = 'n';
            val[count + 1] = 'u';
            val[count + 2] = 'l';
            val[count + 3] = 'l';
        } else {
            setLong(val, count, NULL_UTF16);
        }
        this.count = count + 4;
        return this;
    }

    public AbstractStringBuilder append(boolean b) {
        int count = this.count;
        int spaceNeeded = count + (b ? 4 : 5);
        ensureCapacityInternal(spaceNeeded);
        byte[] val = this.value;
        if (isLatin1()) {
            if (b) {
                val[count    ] = 't';
                val[count + 1] = 'r';
                val[count + 2] = 'u';
                val[count + 3] = 'e';
            } else {
                val[count    ] = 'f';
                val[count + 1] = 'a';
                val[count + 2] = 'l';
                val[count + 3] = 's';
                val[count + 4] = 'e';
            }
        } else {
            setLong(val, count, b ? TRUE_UTF16 : FALS_UTF16);
            if (!b) {
                StringUTF16.putChar(val, count + 4, 'e');
            }
        }
        this.count = spaceNeeded;
        return this;
    }
}


The getLong/setLong methods here can be optimized and merged by C2. Maybe we need a public class that does not use Unsafe to implement these methods. They are needed in many places. Maybe it is appropriate to improve them based on ByteArray/ByteArrayLittleEndian.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2159458425

From jjg at openjdk.org  Mon Jun 10 23:13:15 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 23:13:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
 <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
Message-ID: <Ss1KZ4NwolVYPiXv46jXJ05_pDMCkOY4GHYlq5stnCc=.135e6f50-206b-4f75-acf4-4574eaf84951@github.com>

On Mon, 10 Jun 2024 21:38:18 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, `<args>`, `<class-path>`.
>> 
>> This change seems to be going backwards.
>> 
>> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.
>
> @jonathan-gibbons I just realized that this change to the German file matches the file with the Japanese and Chinese localized files. By that I mean the "backwards" translations are also present for the Japanese and Chinese files.
> 
> However, the previous versions of the Japanese and Chinese files don't have these bits translated. So in summary, I can revert the German file back to German but the Japanese and Chinese files will still be English for these parts because I wouldn't know what to revert them to in their local language.
> 
> As a result, I actually think it might be better to change this German file as shown in the current version of the PR just to remain consistent with the other localized versions of this file. We can still bring this up to the go team as an issue, but I think this is the best solution now for this drop at least.

No one else except people reading this PR will spot inconsistencies between translations in different languages. So inconsistencies across languages will not be obvious to end users.

But anyone (end-user) using the tool in any one of these languages is likely to spot inconsistencies in the translations for that one language.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633937355

From dlong at openjdk.org  Mon Jun 10 23:40:12 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 10 Jun 2024 23:40:12 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <rw-wTIfrmyWpLKQeIsQuZP10lpFTD9nFA_wchCAKAhM=.3936e062-16b9-4e5a-82c4-d389b9a3910c@github.com>

On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

>From a compiler point of view, it might be better to enhance the 8318446 optimization so that it recognizes code patterns that use increment.
For a libraries point of view, this proposed change probably needs some comments, so it doesn't get accidentally changed in the future in a way that breaks the optimization.  How would we prevent that?  The situation seems fragile to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2159497549

From redestad at openjdk.org  Mon Jun 10 23:52:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 10 Jun 2024 23:52:20 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <_I5gARYyMcHy0DQVI8GnU9teGHji53iythE75m1XCmw=.d16ab969-2a5a-4e38-b628-0218db353950@github.com>

On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Whether increments are handled or not, I think the `StringUTF16.putChar` intrinsic might be getting in the way here and prevent merging consecutive "char" stores into 4 or 8 byte stores. It would be interesting to get numbers for the `putChar` version with the intrinsic disabled (`-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_putCharStringU`).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2159509806

From jwaters at openjdk.org  Tue Jun 11 00:25:21 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Jun 2024 00:25:21 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v4]
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <-S2J6qqQ78p9lK6hSpIZWqeJaUpLRRl6KgSkiWiUeXA=.c55da5f4-50be-4ec6-b31b-b3c61ce7a06f@github.com>

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Capstone Support
 - Add check for compiler in configure
 - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

-------------

Changes: https://git.openjdk.org/jdk/pull/18915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=03
  Stats: 395 lines in 19 files changed: 201 ins; 41 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/18915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915

PR: https://git.openjdk.org/jdk/pull/18915

From dholmes at openjdk.org  Tue Jun 11 00:50:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 00:50:28 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v2]
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <aepA-ImIyckFwPaf4cS2pizlON3SYyrfc5BK9Y1SJwU=.50de780d-25c0-4da3-9066-52b1a472b8de@github.com>

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge
 - 8330205: Initial troff manpage generation for JDK 24

-------------

Changes: https://git.openjdk.org/jdk/pull/19617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=01
  Stats: 53 lines in 28 files changed: 12 ins; 3 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/19617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617

PR: https://git.openjdk.org/jdk/pull/19617

From dholmes at openjdk.org  Tue Jun 11 01:02:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:02:39 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <fxPYBQ2lvXomy6ZaWwe2l7ucWeyV5Yd9dl7b7lZl5ho=.e8c4eae1-cf24-42e2-a86a-f5e3e0f6163c@github.com>

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Regenerated after merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19617/files
  - new: https://git.openjdk.org/jdk/pull/19617/files/8472c47d..e7563087

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=01-02

  Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617

PR: https://git.openjdk.org/jdk/pull/19617

From dholmes at openjdk.org  Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To: <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
 <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>
Message-ID: <7aiYPjUq_qkJuy1jRAFfZTpNoCwaw9scrgKJkkbp6UA=.dcdfae3e-05c5-45af-81b4-8a434b2774ba@github.com>

On Mon, 10 Jun 2024 17:27:18 GMT, Iris Clark <iris at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Regenerated after merge
>
> Marked as reviewed by iris (Reviewer).

Thanks for the review @irisclark .

I've merged in the latest updates that also brought in part of the missing changes. If anything goes wrong I have another PR in preparation that also updates java.1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2159577044

From dholmes at openjdk.org  Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: Integrated: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <rZfMnH59MoMxA4EjbTMjwJ6Wv7_aU6tAALkPzROcOSM=.d0ee9e97-4348-4441-9c5c-5ab4d834e2bc@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - ~~JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC~~ (covered by merge)
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

This pull request has now been integrated.

Changeset: 3a01b47a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a01b47ac97714608356ce3faf797c37dc63e9af
Stats:     43 lines in 28 files changed: 2 ins; 3 del; 38 mod

8330205: Initial troff manpage generation for JDK 24

Reviewed-by: alanb, iris

-------------

PR: https://git.openjdk.org/jdk/pull/19617

From dholmes at openjdk.org  Tue Jun 11 01:19:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:19:12 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <4AzGl1zKsp5sPygdzdbG1WFTgsdNBJrF4FLSUxuhcQQ=.50d7ebb8-fd74-43db-9b4c-4cb02f82f2f0@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
 <4AzGl1zKsp5sPygdzdbG1WFTgsdNBJrF4FLSUxuhcQQ=.50d7ebb8-fd74-43db-9b4c-4cb02f82f2f0@github.com>
Message-ID: <RHIIxy2nGVZJ6j37ieRvzQ4k-kbNiEq6RHByH-AaxwA=.72b37a64-ef89-4024-ac06-f43b59a4dc06@github.com>

On Mon, 10 Jun 2024 13:36:06 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> But what about when an int is passed to isspace?

The current casts to int are incorrect as a negative value would be sign-extended and then fail the range check. I think we have to cast to unsigned char in all cases in the caller, which renders the wrapper and range-check obsolete AFAICS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2159586765

From duke at openjdk.org  Tue Jun 11 02:23:36 2024
From: duke at openjdk.org (MaxXing)
Date: Tue, 11 Jun 2024 02:23:36 GMT
Subject: RFR: 8333334: C2: Make result of `Node::dominates` more precise to
 enhance scalar replacement [v3]
In-Reply-To: <ARdyBPCqSDKlOM-u5kGZGqgOySxOT2MbznAiZaQMWx8=.21dfdc0c-1b92-4484-ad05-203e819a8569@github.com>
References: <ARdyBPCqSDKlOM-u5kGZGqgOySxOT2MbznAiZaQMWx8=.21dfdc0c-1b92-4484-ad05-203e819a8569@github.com>
Message-ID: <91EuDDDAZwL7PXXD3FBIV1FGwErjydcgIXM3vP7kQpY=.692ec6dc-fe66-4d9f-930a-e782b7aabf29@github.com>

> This patch changes the algorithm of `Node::dominates` to make the result more precise, and allows the iterators of `ConcurrentHashMap` to be scalar replaced.
> 
> The previous algorithm will return a conservative result when encountering a dead control flow, and only try the first two input paths of a multi-input Region node, which may prevent the scalar replacement in some cases.
> 
> For example, with G1 GC enabled, C2 generates GC barriers for `ConcurrentHashMap` iteration operations at some early phases, and then eliminates them in a later IGVN, but `LoadNode` is also idealized in the same IGVN. This causes `LoadNode::Ideal` to see some dead barrier control flows, and refuse to split some instance field loads through Phi due to the conservative result of `Node::dominates`, and thus the scalar replacement can not be applied to iterators in the later macro elimination phase.
> 
> This patch allows `Node::dominates` to try other paths of the last multi-input Region node when the first path is dead, and makes `ConcurrentHashMap` iteration ~30% faster:
> 
> 
> Benchmark                            (nkeys)  Mode  Cnt        Score       Error  Units
> Maps.testConcurrentHashMapIterators    10000  avgt   15   414099.085 ? 33230.945  ns/op   # baseline
> Maps.testConcurrentHashMapIterators    10000  avgt   15   315490.281 ?  3037.056  ns/op   # patch
> 
> 
> Testing: tier1-4.

MaxXing has updated the pull request incrementally with one additional commit since the last revision:

  Add IR test and update copyright.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19496/files
  - new: https://git.openjdk.org/jdk/pull/19496/files/b5db38dc..f2e5506e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19496&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19496&range=01-02

  Stats: 116 lines in 2 files changed: 115 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19496/head:pull/19496

PR: https://git.openjdk.org/jdk/pull/19496

From duke at openjdk.org  Tue Jun 11 05:25:39 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 11 Jun 2024 05:25:39 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v2]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <qI8At9V_fTPSyeSVBvaxDbfAyuPmZkD-iKCyySRGh_0=.25958b1a-8852-4dfc-ad5d-7d1bbf03f3ca@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimize to combining values into larger stores

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/5e815b63..0cbaa5ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=00-01

  Stats: 16 lines in 1 file changed: 7 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From duke at openjdk.org  Tue Jun 11 05:42:27 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 11 Jun 2024 05:42:27 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v3]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <O8qE6Q52X9n2dUuj-sbcg22kFkpO6oFlkP84z0F3vMI=.4f06d485-f3f7-4a8b-a537-a816405ce18c@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/0cbaa5ac..f96cde4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=01-02

  Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From cstein at openjdk.org  Tue Jun 11 05:46:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 05:46:16 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
Message-ID: <rxc7-Mprc8iDuw1jhUolYiMoV7l6QxCSbsgnnZ35n1U=.02728f1d-1099-4ec7-a855-1eefe95f90f3@github.com>

On Mon, 10 Jun 2024 20:19:51 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove double quotes
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 66:
> 
>> 64: label.size=G&r??e:
>> 65: label.source=&Quelle:
>> 66: label.outputbins=A&usgabef?cher:
> 
> How confident are we in this ?
> google translate says that the old text referred to 'compartments' and the new one to 'areas' and I wonder why that is better ?
> 
> https://translate.google.com/?sl=auto&tl=en&text=Ausgabebereiche%0AAusgebefacher&op=translate

"Ausgabef?cher" is the best German translation here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634221518

From cstein at openjdk.org  Tue Jun 11 05:58:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 05:58:16 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <iJZMTs0UUdFqw07uiMXQrkv3QBeyv70VQyyVZtFy5k4=.22762511-49c4-4ad6-a198-38d2be8ac4f6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
 <ivxoCg1QhjwpzbGR6T6rHreTkqv-NVFo7jZYwNL0LiM=.c10bee70-9ca8-4db5-89b1-ee7682729e3d@github.com>
 <iJZMTs0UUdFqw07uiMXQrkv3QBeyv70VQyyVZtFy5k4=.22762511-49c4-4ad6-a198-38d2be8ac4f6@github.com>
Message-ID: <Fb3AmUHDf5U2lnnok2LqxzKxUuXMQia6Ui9uU-eoqlY=.416d5ef4-d6ca-4aa3-a248-891d0e4b509e@github.com>

On Mon, 10 Jun 2024 22:48:13 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 325:
>> 
>>> 323:         {"Unexpected event type", "Unerwarteter Ereignistyp: {0}"},
>>> 324:         {"unknown", "unbekannt"},
>>> 325:         {"Unmonitoring", "Monitoring von {0} aufheben"},
>> 
>> The English entry is:
>> 
>>         {"Unmonitoring", "Unmonitoring {0} "},
>> 
>> But the German entry now says "Monitoring". I'm  sure what the original "\u00DCberwachung" translates to, other than berwachung is monitoring. Now this resource is partly in English, and is the incorrect English.
>
> I don't know German, but when plugging `"Monitoring von {0} aufheben"` into google translate, I get `Unmonitoring` as well. Maybe `Monitoring` is a word that could also be used in German? No clue. The translation tool decided to make this change.
> 
> @sormuras do you have any input on this?

It's correct.

The "Un" of "Unmonitoring" is moved to the associated verb in German: "aufheben". which in this context translates to "cancel" or "revoke". This seems to be one of the few cases where there's no commonly used single word in German for "Unmonitoring".

> Now this resource is partly in English, and is the incorrect English.

That's how Tech-German often works - take a word from English and use it as-is, sometimes missing the original meaning. Such words or phrases are then referred to as: Denglisch.

In this case "?berwachung" was German, "Monitoring" is Denglisch. I'd revert that to `\u00DCberwachung` - but both are okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634236406

From cstein at openjdk.org  Tue Jun 11 06:03:20 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 06:03:20 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <rxc7-Mprc8iDuw1jhUolYiMoV7l6QxCSbsgnnZ35n1U=.02728f1d-1099-4ec7-a855-1eefe95f90f3@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
 <rxc7-Mprc8iDuw1jhUolYiMoV7l6QxCSbsgnnZ35n1U=.02728f1d-1099-4ec7-a855-1eefe95f90f3@github.com>
Message-ID: <fjDM8CLc7UlLywSpW23R_oXriwUiQu6lPv9zulRvfUs=.3d7a5920-67d3-4270-a366-79df33e241ae@github.com>

On Tue, 11 Jun 2024 05:43:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 66:
>> 
>>> 64: label.size=G&r??e:
>>> 65: label.source=&Quelle:
>>> 66: label.outputbins=A&usgabef?cher:
>> 
>> How confident are we in this ?
>> google translate says that the old text referred to 'compartments' and the new one to 'areas' and I wonder why that is better ?
>> 
>> https://translate.google.com/?sl=auto&tl=en&text=Ausgabebereiche%0AAusgebefacher&op=translate
>
> "Ausgabef?cher" is the best German translation here.

The reason for going with "Bereich (area)" instead of "Fach (compartment)" is that an area is more general compared to a compartment. At least in German: every "Fach" is a "Bereich", but every "Bereich" is NOT a "Fach".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634240847

From cstein at openjdk.org  Tue Jun 11 06:07:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 06:07:16 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <2-SMv3j3Eqrv7LVV6CbkZVEb3KFcahQR1_8AiJErDAQ=.07538bd6-9b25-45ed-b47f-8e9102ea8af9@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <SjpwOVwkqCFBlC_Vj1rv4JwgHdgqnpiz8xrDTE98eOc=.c90d5753-0206-48e9-bfb4-8e6bc67c616a@github.com>
 <2-SMv3j3Eqrv7LVV6CbkZVEb3KFcahQR1_8AiJErDAQ=.07538bd6-9b25-45ed-b47f-8e9102ea8af9@github.com>
Message-ID: <CouuebhtcqMA6bHarrhzi4OkzoYr9fc13nWk21wQjZQ=.00f0f569-3215-4f99-8f00-59d1e7314c44@github.com>

On Mon, 10 Jun 2024 20:34:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 409:
>> 
>>> 407: compiler.err.unconditional.pattern.and.default=Switch umfasst sowohl ein nicht bedingtes Muster als auch ein Standardlabel
>>> 408: 
>>> 409: compiler.err.unconditional.pattern.and.both.boolean.values=Switch umfasst sowohl boolesche Werte als auch ein nicht bedingtes Muster
>> 
>> Here and elsewhere in this file and other translations, I'm surprised `switch` is not being translated, and is being capitalized. In the English form, it is not being used as a keyword, although could maybe be seen as a short form of `switch' statement, in which case `switch` should be treated as a keyword and not translated or capitalized.
>
> Good catch. Seems to be across all files and I'm assuming it's for the reason you suggested. I'll bring this up to the go team. I have no way to fix this since I can't rely on google translate. This can be caught in a future update if the go team can successfully differentiate the difference between the word `switch` and a `switch keyword`.

Yes. "Switch ..." is the short form for "Das Switch-Statement ..." or "Das `switch` Statement ..." and all other longer forms that match the context.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634244985

From cstein at openjdk.org  Tue Jun 11 06:13:24 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 06:13:24 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
Message-ID: <oF6N81khTgiBZPXZgBwJUPmJYlcJZF_DD6eIHaTW-Ng=.25effa3a-097e-41a0-bb03-d520fe0013d2@github.com>

On Sun, 9 Jun 2024 19:35:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove double quotes
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 285:
> 
>> 283: VIRTUAL_MACHINE=Virtuelle Maschine
>> 284: VM_ARGUMENTS=VM-Argumente
>> 285: VMINTERNAL_FRAME_ACCESSIBLE_DESCRIPTION=Innerer Frame f?r das Monitoring einer Java Virtual Machine
> 
> This one-off change is consistent with the change in _src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java_.

Consistently changed to be "[Denglisch](https://en.wikipedia.org/wiki/Denglisch)" instead of German.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634249847

From epeter at openjdk.org  Tue Jun 11 06:30:13 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 11 Jun 2024 06:30:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <IM4whi_rK2qmJJfMCziFoep3XRyO1vuHugTkm8IUqtc=.a23c747f-e2c3-40fd-90d3-f7bfb01bb96b@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>
 <9_OMKYvdx-xW6KC3sKovIYawgaRZfkKyvU97jcuskzM=.484f62c9-521c-47b5-a68a-6abc89c0e768@github.com>
 <IM4whi_rK2qmJJfMCziFoep3XRyO1vuHugTkm8IUqtc=.a23c747f-e2c3-40fd-90d3-f7bfb01bb96b@github.com>
Message-ID: <lNywbhbLV4eOITvagu4FwP6PWuFE7_F7XYJf0eK275E=.3d554081-7fdf-48d1-94b0-393590290492@github.com>

On Mon, 10 Jun 2024 23:10:05 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> @wenshao 
>>> I think the performance of the Unsafe branch may be the best data for the C2 optimizer. @eme64 can help me see if C2 can do it?
>> 
>> Have you tried to see if the optimization actually was done/taken? You can use the `TraceMergeStores,` flag. Can you present the generated assembly code of the benchmarks, and explain the difference based on the generated assembly code? You can run JMH penchmarks with `perf`. These two blogs may help you:
>> 
>> http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html
>> https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_jmh_prof_perfasm
>> 
>> @liach I don't think it makes a difference if it is `int` or `byte` constants. Or what exactly is the code change you are proposing?
>
> @eme64 It seems that when the following code uses StringUTF16.putChar, C2's optimization is not as good as the manual merging and storage effect.
> 
> class AbstractStringBuilder {
>     private AbstractStringBuilder appendNull() {
>     	// ...
> 		StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
> 		// ...
> 	}
> 
> 	public AbstractStringBuilder append(boolean b) {
> 	    // ...
> 		StringUTF16.putCharsAt(val, count, 't', 'r', 'u', 'e');
> 		// ...
> 		StringUTF16.putCharsAt(val, count, 'f', 'a', 'l', 's', 'e');
> 		// ...
> 	}
> }
> 
> class StringUTF16 {
>    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>         putChar(value, i    , c1);
>         putChar(value, i + 1, c2);
>         putChar(value, i + 2, c3);
>         putChar(value, i + 3, c4);
>     }
> 
>     @IntrinsicCandidate
>     // intrinsic performs no bounds checks
>     static void putChar(byte[] val, int index, int c) {
>         assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
>         index <<= 1;
>         val[index++] = (byte)(c >> HI_BYTE_SHIFT);
>         val[index]   = (byte)(c >> LO_BYTE_SHIFT);
>     }
> }
> 
> 
> The code for manually merging storage is as follows, without using Unsafe:
> 
> class AbstractStringBuilder {
>     static final long NULL_UTF16;
>     static final long TRUE_UTF16;
>     static final long FALS_UTF16;
> 
>     static {
>         byte[] bytes = new byte[8];
> 
>         StringUTF16.putCharsAt(bytes, 0, 'n', 'u', 'l', 'l');
>         NULL_UTF16 = getLong(bytes, 0);
> 
>         StringUTF16.putCharsAt(bytes, 0, 't', 'r', 'u', 'e');
>         TRUE_UTF16 = getLong(bytes, 0);
> 
>         StringUTF16.putCharsAt(bytes, 0, 'f', 'a', 'l', 's');
>         FALS_UTF16 = getLong(bytes, 0);
>     }
> 
>     private static long getLong(byte[] bytes, int offset) {
>         return (((long)bytes[offset    ] & 0xff)      ) |
>                (((long)bytes[offset + 1] & 0xff) <<  8) |
>                (((long)bytes[offset + 2] & 0xff) << 16) |
>                (((long)bytes[offset + 3] & 0xff) << 24) |
>                (((long)bytes[offset + 4] & 0xff) << 32) |
>                (((long)bytes[offset + 5] & 0xff) << 40) |
>                (((long)bytes[offset + 6] & 0xff) << 48) |
>                (((long)bytes[offset + 7] & 0xff) << 56);
>     }
> 
>     private static void setLong(byte[] array, int offset, long value) {
>         array[offset]     = (byte)  value;
>         array[offset + 1] = (byte) (value >> 8);
>         array[offset + 2] = (byte) (value >> 16);
>         array[offset + 3] = (byte) (value >> 24);
>         arra...

@wenshao 
> @eme64 It seems that when the following code uses StringUTF16.putChar, C2's optimization is not as good as the manual merging and storage effect.

As I asked above, you will need to provide some evidence / generated assembly / perf data, and logs from `TraceMergeStores`. I currently do not have time to produce these myself, and I think they would be crucial to determine where the missing performance has gone. See my earlier comment:
https://github.com/openjdk/jdk/pull/19626#issuecomment-2158533469

And please also try @cl4es advide here:
https://github.com/openjdk/jdk/pull/19626#issuecomment-2159509806

And sure, maybe you need some public API for setting multiple bytes at once, which the `MergeStores` optimization can optimize. I'm a C2 engineer, so I leave that up to the library folks ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2159895757

From ayang at openjdk.org  Tue Jun 11 08:24:39 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 11 Jun 2024 08:24:39 GMT
Subject: RFR: 8333962: Obsolete OldSize
Message-ID: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>

Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.

-------------

Commit messages:
 - obsolete-old-size

Changes: https://git.openjdk.org/jdk/pull/19647/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19647&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333962
  Stats: 193 lines in 15 files changed: 8 ins; 168 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/19647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19647/head:pull/19647

PR: https://git.openjdk.org/jdk/pull/19647

From duke at openjdk.org  Tue Jun 11 08:27:20 2024
From: duke at openjdk.org (Brandon Kolesar)
Date: Tue, 11 Jun 2024 08:27:20 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory.
In-Reply-To: <1jySJvszszWTPX_IaMEu8EhbDHqkvY7BtDMcSiFI-l4=.83375e41-0c48-4b66-9e82-f073cc5df933@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
 <YhVgwZFkIjVvyaKmfWZh2qfOFZP2p7gKpcAiwvXfuc0=.b5de19ad-20d0-4421-96f6-b29fc9a628fb@github.com>
 <1jySJvszszWTPX_IaMEu8EhbDHqkvY7BtDMcSiFI-l4=.83375e41-0c48-4b66-9e82-f073cc5df933@github.com>
Message-ID: <cOUmcpCBdHzUJPeHCw97tIdQ8h5tXmbX6iMs-1T0CY4=.b2478985-9f67-4f3d-bd54-6d6595e86d37@github.com>

On Mon, 10 Jun 2024 17:11:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > The term 'subset' doesn't feel right to me here, since we're only talking about a single memory region (not a set of memory region**s**). I suggest 'sub-region' instead.
> 
> Actually, nvm, that doesn't work for `reinterpret` since the returned segment can also cover a larger region of memory.

In my opinion, any 'sub' terminology is misleading since, as you pointed out, one can (and often will) `reinterpret` to a *larger* size. Wouldn't something like, "The returned memory segment is backed by the same region of memory that backs this memory segment", be sufficiently accurate? Could even append, "No memory will be allocated or deallocated", to really hammer the point home.

Using 'subset' for `asSlice` makes sense. Though possibly unnecessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19633#issuecomment-2160083878

From shade at openjdk.org  Tue Jun 11 09:01:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Jun 2024 09:01:26 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com>
Message-ID: <iyNQU7ioNYmj176TO7PvVgQwwZdwwkiNtuxTL5zTIAw=.592e7b2e-b067-4c86-8ede-5fd313968003@github.com>

On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak <duke at openjdk.org> wrote:

>> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. 
>> 
>> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). 
>> 
>> Before:
>> 
>> Benchmark                         Mode  Cnt  Score   Error  Units
>> # Intel Skylake
>> MethodHashCode.benchmarkHashCode  avgt    5  1.843 ? 0.149  ns/op
>> # Arm Neoverse N1
>> MethodHashCode.benchmarkHashCode  avgt    5  2.363 ? 0.091  ns/op
>> 
>> 
>> 
>> After:
>> 
>> 
>> Benchmark                         Mode  Cnt  Score   Error  Units
>> # Intel Skylake
>> MethodHashCode.benchmarkHashCode  avgt    5  1.121 ? 1.189  ns/op
>> # Arm Neoverse N1
>> MethodHashCode.benchmarkHashCode  avgt    5  1.001 ? 0.001  ns/op
>
> Sean Gwizdak 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:
> 
>  - Remove trailing whitespace.
>  - Move hashCode benchmark into the newly created MethodBenchmark file
>  - Merge branch 'master' into method-hashcode-JDK-8332249
>  - Remove changes to JavaDoc per guidance.
>  - Fix whitespace issues pointed by the bot
>  - Micro-optimize Method.hashCode

As usual in these cases, we need to make a footprint argument as well. `Method` is a special class with lots of injected fields, so the only "true" source of layout information is `-XX:+PrintFieldLayout`. It tells me there is a 4-byte tail due to object alignment in compressed oops mode. This can accommodate a new `int` field. There seems to be no space when compressed oops are disabled.


# Out of the box, compressed oops enabled
Layout of class java/lang/reflect/Method
Instance fields:
 @0 12/- RESERVED
 @12 "override" Z 1/1 INHERITED
 @13 "callerSensitive" B 1/1 REGULAR
 @14 2/1 EMPTY
 @16 "accessCheckCache" Ljava/lang/Object; 4/4 INHERITED
 @20 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 4/4 INHERITED
 @24 "declaredAnnotations" Ljava/util/Map; 4/4 INHERITED
 @28 "slot" I 4/4 REGULAR
 @32 "modifiers" I 4/4 REGULAR
 @36 "clazz" Ljava/lang/Class; 4/4 REGULAR
 @40 "name" Ljava/lang/String; 4/4 REGULAR
 @44 "returnType" Ljava/lang/Class; 4/4 REGULAR
 @48 "parameterTypes" [Ljava/lang/Class; 4/4 REGULAR
 @52 "exceptionTypes" [Ljava/lang/Class; 4/4 REGULAR
 @56 "signature" Ljava/lang/String; 4/4 REGULAR
 @60 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 4/4 REGULAR
 @64 "annotations" [B 4/4 REGULAR
 @68 "parameterAnnotations" [B 4/4 REGULAR
 @72 "annotationDefault" [B 4/4 REGULAR
 @76 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 4/4 REGULAR
 @80 "root" Ljava/lang/reflect/Method; 4/4 REGULAR
Instance size = 88 bytes

# -XX:-UseCompressedOops
Layout of class java/lang/reflect/Method
Instance fields:
 @0 12/- RESERVED
 @12 "override" Z 1/1 INHERITED
 @13 "callerSensitive" B 1/1 REGULAR
 @14 2/1 EMPTY
 @16 "accessCheckCache" Ljava/lang/Object; 8/8 INHERITED
 @24 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 8/8 INHERITED
 @32 "declaredAnnotations" Ljava/util/Map; 8/8 INHERITED
 @40 "slot" I 4/4 REGULAR
 @44 "modifiers" I 4/4 REGULAR
 @48 "clazz" Ljava/lang/Class; 8/8 REGULAR
 @56 "name" Ljava/lang/String; 8/8 REGULAR
 @64 "returnType" Ljava/lang/Class; 8/8 REGULAR
 @72 "parameterTypes" [Ljava/lang/Class; 8/8 REGULAR
 @80 "exceptionTypes" [Ljava/lang/Class; 8/8 REGULAR
 @88 "signature" Ljava/lang/String; 8/8 REGULAR
 @96 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 8/8 REGULAR
 @104 "annotations" [B 8/8 REGULAR
 @112 "parameterAnnotations" [B 8/8 REGULAR
 @120 "annotationDefault" [B 8/8 REGULAR
 @128 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 8/8 REGULAR
 @136 "root" Ljava/lang/reflect/Method; 8/8 REGULAR
Instance size = 144 bytes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2160170846

From prappo at openjdk.org  Tue Jun 11 09:01:49 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Jun 2024 09:01:49 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v2]
In-Reply-To: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
Message-ID: <MtieFYqWEbxpceQyHbTHdRaBvK4v4GTBtiNgkqO4UGU=.e6dc977d-8538-4e66-98f2-7a0485b35a4e@github.com>

> Please review this fix for an intermittent test failure.
> 
> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
> 
> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
> 
> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Change url as suggested in review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19627/files
  - new: https://git.openjdk.org/jdk/pull/19627/files/da0c0b7b..21f63a98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19627&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19627&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19627/head:pull/19627

PR: https://git.openjdk.org/jdk/pull/19627

From duke at openjdk.org  Tue Jun 11 09:19:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 11 Jun 2024 09:19:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <lNywbhbLV4eOITvagu4FwP6PWuFE7_F7XYJf0eK275E=.3d554081-7fdf-48d1-94b0-393590290492@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>
 <9_OMKYvdx-xW6KC3sKovIYawgaRZfkKyvU97jcuskzM=.484f62c9-521c-47b5-a68a-6abc89c0e768@github.com>
 <IM4whi_rK2qmJJfMCziFoep3XRyO1vuHugTkm8IUqtc=.a23c747f-e2c3-40fd-90d3-f7bfb01bb96b@github.com>
 <lNywbhbLV4eOITvagu4FwP6PWuFE7_F7XYJf0eK275E=.3d554081-7fdf-48d1-94b0-393590290492@github.com>
Message-ID: <3Glk5fqUv6mOnaBeQZIMctUDhZzASCQEf4VNpTaEfvE=.ee098533-80c0-4bc1-8ae1-c8551b2c9ac6@github.com>

On Tue, 11 Jun 2024 06:27:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 It seems that when the following code uses StringUTF16.putChar, C2's optimization is not as good as the manual merging and storage effect.
>> 
>> class AbstractStringBuilder {
>>     private AbstractStringBuilder appendNull() {
>>     	// ...
>> 		StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
>> 		// ...
>> 	}
>> 
>> 	public AbstractStringBuilder append(boolean b) {
>> 	    // ...
>> 		StringUTF16.putCharsAt(val, count, 't', 'r', 'u', 'e');
>> 		// ...
>> 		StringUTF16.putCharsAt(val, count, 'f', 'a', 'l', 's', 'e');
>> 		// ...
>> 	}
>> }
>> 
>> class StringUTF16 {
>>    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>>         putChar(value, i    , c1);
>>         putChar(value, i + 1, c2);
>>         putChar(value, i + 2, c3);
>>         putChar(value, i + 3, c4);
>>     }
>> 
>>     @IntrinsicCandidate
>>     // intrinsic performs no bounds checks
>>     static void putChar(byte[] val, int index, int c) {
>>         assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
>>         index <<= 1;
>>         val[index++] = (byte)(c >> HI_BYTE_SHIFT);
>>         val[index]   = (byte)(c >> LO_BYTE_SHIFT);
>>     }
>> }
>> 
>> 
>> The code for manually merging storage is as follows, without using Unsafe:
>> 
>> class AbstractStringBuilder {
>>     static final long NULL_UTF16;
>>     static final long TRUE_UTF16;
>>     static final long FALS_UTF16;
>> 
>>     static {
>>         byte[] bytes = new byte[8];
>> 
>>         StringUTF16.putCharsAt(bytes, 0, 'n', 'u', 'l', 'l');
>>         NULL_UTF16 = getLong(bytes, 0);
>> 
>>         StringUTF16.putCharsAt(bytes, 0, 't', 'r', 'u', 'e');
>>         TRUE_UTF16 = getLong(bytes, 0);
>> 
>>         StringUTF16.putCharsAt(bytes, 0, 'f', 'a', 'l', 's');
>>         FALS_UTF16 = getLong(bytes, 0);
>>     }
>> 
>>     private static long getLong(byte[] bytes, int offset) {
>>         return (((long)bytes[offset    ] & 0xff)      ) |
>>                (((long)bytes[offset + 1] & 0xff) <<  8) |
>>                (((long)bytes[offset + 2] & 0xff) << 16) |
>>                (((long)bytes[offset + 3] & 0xff) << 24) |
>>                (((long)bytes[offset + 4] & 0xff) << 32) |
>>                (((long)bytes[offset + 5] & 0xff) << 40) |
>>                (((long)bytes[offset + 6] & 0xff) << 48) |
>>                (((long)bytes[offset + 7] & 0xff) << 56);
>>     }
>> 
>>     private static void setLong(byte[] array, int offset, long value) {
>>         array[offset]     = (byte)  value;
>>         array[offse...
>
> @wenshao 
>> @eme64 It seems that when the following code uses StringUTF16.putChar, C2's optimization is not as good as the manual merging and storage effect.
> 
> As I asked above, you will need to provide some evidence / generated assembly / perf data, and logs from `TraceMergeStores`. I currently do not have time to produce these myself, and I think they would be crucial to determine where the missing performance has gone. See my earlier comment:
> https://github.com/openjdk/jdk/pull/19626#issuecomment-2158533469
> 
> And please also try @cl4es advide here:
> https://github.com/openjdk/jdk/pull/19626#issuecomment-2159509806
> 
> And sure, maybe you need some public API for setting multiple bytes at once, which the `MergeStores` optimization can optimize. I'm a C2 engineer, so I leave that up to the library folks ;)

@eme64 The assembly information is below, can you take a look and see if it can help you diagnose the problem?

* JavaCode

class AbstractStringBuilder {
     private AbstractStringBuilder appendNull() {
        int count = this.count;
        ensureCapacityInternal(count + 4);
        byte[] val = this.value;
        if (isLatin1()) {
            val[count    ] = 'n';
            val[count + 1] = 'u';
            val[count + 2] = 'l';
            val[count + 3] = 'l';
        } else {
            StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
        }
        this.count = count + 4;
        return this;
    }
}

class StringUTF16 {
    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
    }
}


* Apple M1 StringBuilder.appendNull PrintAssembly

/Users/wenshao/Work/git/jdk/build/macosx-aarch64-server-release/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=compileonly,*StringBuilder.appendNull -XX:-TieredCompilation -XX:TieredStopAtLevel=4 -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=61041:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 ....

Compiled method (n/a) 96    1     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLLLL)L (native)
 total in heap  [0x0000000102efba08,0x0000000102efbb20] = 280
 relocation     [0x0000000102efbae0,0x0000000102efbae8] = 8
 main code      [0x0000000102efbb00,0x0000000102efbb20] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c3e1c80} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  # parm5:    c_rarg6:c_rarg6 
                        = 'java/lang/Object'
  # parm6:    c_rarg7:c_rarg7 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102efbb00:   nop
  0x0000000102efbb04:   ldr	w12, [x7, #36]
  0x0000000102efbb08:   lsl	x12, x12, #3
  0x0000000102efbb0c:   ldr	x12, [x12, #16]
  0x0000000102efbb10:   cbz	x12, 0x0000000102efbb1c
  0x0000000102efbb14:   ldr	x8, [x12, #64]
  0x0000000102efbb18:   br	x8
  0x0000000102efbb1c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 102    2     n       java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native)
 total in heap  [0x0000000102f01108,0x0000000102f01220] = 280
 relocation     [0x0000000102f011e0,0x0000000102f011e8] = 8
 main code      [0x0000000102f01200,0x0000000102f01220] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c432368} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f01200:   nop
  0x0000000102f01204:   ldr	w12, [x3, #36]
  0x0000000102f01208:   lsl	x12, x12, #3
  0x0000000102f0120c:   ldr	x12, [x12, #16]
  0x0000000102f01210:   cbz	x12, 0x0000000102f0121c
  0x0000000102f01214:   ldr	x8, [x12, #64]
  0x0000000102f01218:   br	x8
  0x0000000102f0121c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 103    3     n       java.lang.invoke.MethodHandle::invokeBasic(LLLLLL)L (native)
 total in heap  [0x0000000102f01408,0x0000000102f01530] = 296
 relocation     [0x0000000102f014e0,0x0000000102f014e8] = 8
 main code      [0x0000000102f01500,0x0000000102f01530] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c43ace8} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm3:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  # parm4:    c_rarg6:c_rarg6 
                        = 'java/lang/Object'
  # parm5:    c_rarg7:c_rarg7 
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f01500:   nop
  0x0000000102f01504:   ldr	w12, [x1, #20]
  0x0000000102f01508:   lsl	x12, x12, #3
  0x0000000102f0150c:   ldr	w12, [x12, #40]
  0x0000000102f01510:   lsl	x12, x12, #3
  0x0000000102f01514:   ldr	w12, [x12, #36]
  0x0000000102f01518:   lsl	x12, x12, #3
  0x0000000102f0151c:   ldr	x12, [x12, #16]
  0x0000000102f01520:   cbz	x12, 0x0000000102f0152c
  0x0000000102f01524:   ldr	x8, [x12, #64]
  0x0000000102f01528:   br	x8
  0x0000000102f0152c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 104    4     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLLLLLL)L (native)
 total in heap  [0x0000000102f01708,0x0000000102f01828] = 288
 relocation     [0x0000000102f017e0,0x0000000102f017e8] = 8
 main code      [0x0000000102f01800,0x0000000102f01824] = 36
 stub code      [0x0000000102f01824,0x0000000102f01828] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c43ae60} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  # parm5:    c_rarg6:c_rarg6 
                        = 'java/lang/Object'
  # parm6:    c_rarg7:c_rarg7 
                        = 'java/lang/Object'
  # parm7:    c_rarg0:c_rarg0 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f01800:   nop
  0x0000000102f01804:   ldr	xzr, [x1]
  0x0000000102f01808:   ldr	w12, [x0, #36]
  0x0000000102f0180c:   lsl	x12, x12, #3
  0x0000000102f01810:   ldr	x12, [x12, #16]
  0x0000000102f01814:   cbz	x12, 0x0000000102f01820
  0x0000000102f01818:   ldr	x8, [x12, #64]
  0x0000000102f0181c:   br	x8
  0x0000000102f01820:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f01824:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 107    5     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLL)V (native)
 total in heap  [0x0000000102f01d88,0x0000000102f01ea8] = 288
 relocation     [0x0000000102f01e60,0x0000000102f01e68] = 8
 main code      [0x0000000102f01e80,0x0000000102f01ea4] = 36
 stub code      [0x0000000102f01ea4,0x0000000102f01ea8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c44f7a0} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f01e80:   nop
  0x0000000102f01e84:   ldr	xzr, [x1]
  0x0000000102f01e88:   ldr	w12, [x4, #36]
  0x0000000102f01e8c:   lsl	x12, x12, #3
  0x0000000102f01e90:   ldr	x12, [x12, #16]
  0x0000000102f01e94:   cbz	x12, 0x0000000102f01ea0
  0x0000000102f01e98:   ldr	x8, [x12, #64]
  0x0000000102f01e9c:   br	x8
  0x0000000102f01ea0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f01ea4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 108    6     n       java.lang.invoke.MethodHandle::invokeBasic(LL)L (native)
 total in heap  [0x0000000102f02408,0x0000000102f02530] = 296
 relocation     [0x0000000102f024e0,0x0000000102f024e8] = 8
 main code      [0x0000000102f02500,0x0000000102f02530] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c450b68} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f02500:   nop
  0x0000000102f02504:   ldr	w12, [x1, #20]
  0x0000000102f02508:   lsl	x12, x12, #3
  0x0000000102f0250c:   ldr	w12, [x12, #40]
  0x0000000102f02510:   lsl	x12, x12, #3
  0x0000000102f02514:   ldr	w12, [x12, #36]
  0x0000000102f02518:   lsl	x12, x12, #3
  0x0000000102f0251c:   ldr	x12, [x12, #16]
  0x0000000102f02520:   cbz	x12, 0x0000000102f0252c
  0x0000000102f02524:   ldr	x8, [x12, #64]
  0x0000000102f02528:   br	x8
  0x0000000102f0252c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 109    7     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLL)L (native)
 total in heap  [0x0000000102f02708,0x0000000102f02828] = 288
 relocation     [0x0000000102f027e0,0x0000000102f027e8] = 8
 main code      [0x0000000102f02800,0x0000000102f02824] = 36
 stub code      [0x0000000102f02824,0x0000000102f02828] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c450c80} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f02800:   nop
  0x0000000102f02804:   ldr	xzr, [x1]
  0x0000000102f02808:   ldr	w12, [x4, #36]
  0x0000000102f0280c:   lsl	x12, x12, #3
  0x0000000102f02810:   ldr	x12, [x12, #16]
  0x0000000102f02814:   cbz	x12, 0x0000000102f02820
  0x0000000102f02818:   ldr	x8, [x12, #64]
  0x0000000102f0281c:   br	x8
  0x0000000102f02820:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f02824:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 117    8     n       java.lang.invoke.MethodHandle::linkToSpecial(LLL)L (native)
 total in heap  [0x0000000102f05088,0x0000000102f051a8] = 288
 relocation     [0x0000000102f05160,0x0000000102f05168] = 8
 main code      [0x0000000102f05180,0x0000000102f051a4] = 36
 stub code      [0x0000000102f051a4,0x0000000102f051a8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c4911f8} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f05180:   nop
  0x0000000102f05184:   ldr	xzr, [x1]
  0x0000000102f05188:   ldr	w12, [x3, #36]
  0x0000000102f0518c:   lsl	x12, x12, #3
  0x0000000102f05190:   ldr	x12, [x12, #16]
  0x0000000102f05194:   cbz	x12, 0x0000000102f051a0
  0x0000000102f05198:   ldr	x8, [x12, #64]
  0x0000000102f0519c:   br	x8
  0x0000000102f051a0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f051a4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 123    9     n       java.lang.invoke.MethodHandle::linkToStatic(LLIL)I (native)
 total in heap  [0x0000000102f08b88,0x0000000102f08ca0] = 280
 relocation     [0x0000000102f08c60,0x0000000102f08c68] = 8
 main code      [0x0000000102f08c80,0x0000000102f08ca0] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c4c2f78} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3   = int
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f08c80:   nop
  0x0000000102f08c84:   ldr	w12, [x4, #36]
  0x0000000102f08c88:   lsl	x12, x12, #3
  0x0000000102f08c8c:   ldr	x12, [x12, #16]
  0x0000000102f08c90:   cbz	x12, 0x0000000102f08c9c
  0x0000000102f08c94:   ldr	x8, [x12, #64]
  0x0000000102f08c98:   br	x8
  0x0000000102f08c9c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 128   10     n       java.lang.invoke.MethodHandle::linkToSpecial(LLL)V (native)
 total in heap  [0x0000000102f09208,0x0000000102f09328] = 288
 relocation     [0x0000000102f092e0,0x0000000102f092e8] = 8
 main code      [0x0000000102f09300,0x0000000102f09324] = 36
 stub code      [0x0000000102f09324,0x0000000102f09328] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c4dbc20} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f09300:   nop
  0x0000000102f09304:   ldr	xzr, [x1]
  0x0000000102f09308:   ldr	w12, [x3, #36]
  0x0000000102f0930c:   lsl	x12, x12, #3
  0x0000000102f09310:   ldr	x12, [x12, #16]
  0x0000000102f09314:   cbz	x12, 0x0000000102f09320
  0x0000000102f09318:   ldr	x8, [x12, #64]
  0x0000000102f0931c:   br	x8
  0x0000000102f09320:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f09324:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 129   11     n       java.lang.invoke.MethodHandle::invokeBasic(L)L (native)
 total in heap  [0x0000000102f09508,0x0000000102f09630] = 296
 relocation     [0x0000000102f095e0,0x0000000102f095e8] = 8
 main code      [0x0000000102f09600,0x0000000102f09630] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c4dc348} 'invokeBasic' '(Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f09600:   nop
  0x0000000102f09604:   ldr	w12, [x1, #20]
  0x0000000102f09608:   lsl	x12, x12, #3
  0x0000000102f0960c:   ldr	w12, [x12, #40]
  0x0000000102f09610:   lsl	x12, x12, #3
  0x0000000102f09614:   ldr	w12, [x12, #36]
  0x0000000102f09618:   lsl	x12, x12, #3
  0x0000000102f0961c:   ldr	x12, [x12, #16]
  0x0000000102f09620:   cbz	x12, 0x0000000102f0962c
  0x0000000102f09624:   ldr	x8, [x12, #64]
  0x0000000102f09628:   br	x8
  0x0000000102f0962c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 131   12     n       java.lang.invoke.MethodHandle::linkToStatic(LL)L (native)
 total in heap  [0x0000000102f09808,0x0000000102f09920] = 280
 relocation     [0x0000000102f098e0,0x0000000102f098e8] = 8
 main code      [0x0000000102f09900,0x0000000102f09920] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c4e4358} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f09900:   nop
  0x0000000102f09904:   ldr	w12, [x2, #36]
  0x0000000102f09908:   lsl	x12, x12, #3
  0x0000000102f0990c:   ldr	x12, [x12, #16]
  0x0000000102f09910:   cbz	x12, 0x0000000102f0991c
  0x0000000102f09914:   ldr	x8, [x12, #64]
  0x0000000102f09918:   br	x8
  0x0000000102f0991c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 206   13     n       java.lang.invoke.MethodHandle::linkToInterface(LL)L (native)
 total in heap  [0x0000000102f0b708,0x0000000102f0b868] = 352
 relocation     [0x0000000102f0b7e0,0x0000000102f0b7e8] = 8
 main code      [0x0000000102f0b800,0x0000000102f0b864] = 100
 stub code      [0x0000000102f0b864,0x0000000102f0b868] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c5a1548} 'linkToInterface' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0b800:   nop
  0x0000000102f0b804:   ldr	w10, [x1, #8]
  0x0000000102f0b808:   eor	x10, x10, #0x700000000000
  0x0000000102f0b80c:   ldr	w14, [x2, #24]
  0x0000000102f0b810:   lsl	x14, x14, #3
  0x0000000102f0b814:   ldr	x14, [x14, #16]
  0x0000000102f0b818:   ldr	x12, [x2, #16]
  0x0000000102f0b81c:   ldr	w11, [x10, #172]
  0x0000000102f0b820:   add	x11, x10, x11, uxtx #3
  0x0000000102f0b824:   add	x11, x11, #0x1d8
  0x0000000102f0b828:   add	x10, x10, x12, uxtx #3
  0x0000000102f0b82c:   ldr	x12, [x11]
  0x0000000102f0b830:   cmp	x14, x12
  0x0000000102f0b834:   b.eq	0x0000000102f0b848  // b.none
  0x0000000102f0b838:   cbz	x12, 0x0000000102f0b860
  0x0000000102f0b83c:   ldr	x12, [x11, #16]!
  0x0000000102f0b840:   cmp	x14, x12
  0x0000000102f0b844:   b.ne	0x0000000102f0b838  // b.any
  0x0000000102f0b848:   ldr	w11, [x11, #8]
  0x0000000102f0b84c:   ldr	x12, [x10, w11, uxtw]
  0x0000000102f0b850:   cbz	x12, 0x0000000102f0b85c
  0x0000000102f0b854:   ldr	x8, [x12, #64]
  0x0000000102f0b858:   br	x8
  0x0000000102f0b85c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
  0x0000000102f0b860:   b	0x0000000102e9dd80          ;   {runtime_call IncompatibleClassChangeError throw_exception}
[Stub Code]
  0x0000000102f0b864:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 210   14     n       java.lang.invoke.MethodHandle::linkToStatic(L)L (native)
 total in heap  [0x0000000102f0bd88,0x0000000102f0bea0] = 280
 relocation     [0x0000000102f0be60,0x0000000102f0be68] = 8
 main code      [0x0000000102f0be80,0x0000000102f0bea0] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c5c9ad0} 'linkToStatic' '(Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0be80:   nop
  0x0000000102f0be84:   ldr	w12, [x1, #36]
  0x0000000102f0be88:   lsl	x12, x12, #3
  0x0000000102f0be8c:   ldr	x12, [x12, #16]
  0x0000000102f0be90:   cbz	x12, 0x0000000102f0be9c
  0x0000000102f0be94:   ldr	x8, [x12, #64]
  0x0000000102f0be98:   br	x8
  0x0000000102f0be9c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 213   15     n       java.lang.invoke.MethodHandle::linkToStatic(LLLL)L (native)
 total in heap  [0x0000000102f0c788,0x0000000102f0c8a0] = 280
 relocation     [0x0000000102f0c860,0x0000000102f0c868] = 8
 main code      [0x0000000102f0c880,0x0000000102f0c8a0] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c5dd5e8} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0c880:   nop
  0x0000000102f0c884:   ldr	w12, [x4, #36]
  0x0000000102f0c888:   lsl	x12, x12, #3
  0x0000000102f0c88c:   ldr	x12, [x12, #16]
  0x0000000102f0c890:   cbz	x12, 0x0000000102f0c89c
  0x0000000102f0c894:   ldr	x8, [x12, #64]
  0x0000000102f0c898:   br	x8
  0x0000000102f0c89c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 214   16     n       java.lang.invoke.MethodHandle::invokeBasic()L (native)
 total in heap  [0x0000000102f0d188,0x0000000102f0d2b0] = 296
 relocation     [0x0000000102f0d260,0x0000000102f0d268] = 8
 main code      [0x0000000102f0d280,0x0000000102f0d2b0] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c5e1620} 'invokeBasic' '()Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0d280:   nop
  0x0000000102f0d284:   ldr	w12, [x1, #20]
  0x0000000102f0d288:   lsl	x12, x12, #3
  0x0000000102f0d28c:   ldr	w12, [x12, #40]
  0x0000000102f0d290:   lsl	x12, x12, #3
  0x0000000102f0d294:   ldr	w12, [x12, #36]
  0x0000000102f0d298:   lsl	x12, x12, #3
  0x0000000102f0d29c:   ldr	x12, [x12, #16]
  0x0000000102f0d2a0:   cbz	x12, 0x0000000102f0d2ac
  0x0000000102f0d2a4:   ldr	x8, [x12, #64]
  0x0000000102f0d2a8:   br	x8
  0x0000000102f0d2ac:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 214   17     n       java.lang.invoke.MethodHandle::linkToSpecial(LL)L (native)
 total in heap  [0x0000000102f0d488,0x0000000102f0d5a8] = 288
 relocation     [0x0000000102f0d560,0x0000000102f0d568] = 8
 main code      [0x0000000102f0d580,0x0000000102f0d5a4] = 36
 stub code      [0x0000000102f0d5a4,0x0000000102f0d5a8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c5e1738} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0d580:   nop
  0x0000000102f0d584:   ldr	xzr, [x1]
  0x0000000102f0d588:   ldr	w12, [x2, #36]
  0x0000000102f0d58c:   lsl	x12, x12, #3
  0x0000000102f0d590:   ldr	x12, [x12, #16]
  0x0000000102f0d594:   cbz	x12, 0x0000000102f0d5a0
  0x0000000102f0d598:   ldr	x8, [x12, #64]
  0x0000000102f0d59c:   br	x8
  0x0000000102f0d5a0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f0d5a4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 218   18     n       java.lang.invoke.MethodHandle::linkToSpecial(LL)V (native)
 total in heap  [0x0000000102f0d788,0x0000000102f0d8a8] = 288
 relocation     [0x0000000102f0d860,0x0000000102f0d868] = 8
 main code      [0x0000000102f0d880,0x0000000102f0d8a4] = 36
 stub code      [0x0000000102f0d8a4,0x0000000102f0d8a8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c5462f8} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0d880:   nop
  0x0000000102f0d884:   ldr	xzr, [x1]
  0x0000000102f0d888:   ldr	w12, [x2, #36]
  0x0000000102f0d88c:   lsl	x12, x12, #3
  0x0000000102f0d890:   ldr	x12, [x12, #16]
  0x0000000102f0d894:   cbz	x12, 0x0000000102f0d8a0
  0x0000000102f0d898:   ldr	x8, [x12, #64]
  0x0000000102f0d89c:   br	x8
  0x0000000102f0d8a0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f0d8a4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 220   19     n       java.lang.invoke.MethodHandle::linkToInterface(LLL)I (native)
 total in heap  [0x0000000102f0da88,0x0000000102f0dbe8] = 352
 relocation     [0x0000000102f0db60,0x0000000102f0db68] = 8
 main code      [0x0000000102f0db80,0x0000000102f0dbe4] = 100
 stub code      [0x0000000102f0dbe4,0x0000000102f0dbe8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c5488b0} 'linkToInterface' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0db80:   nop
  0x0000000102f0db84:   ldr	w10, [x1, #8]
  0x0000000102f0db88:   eor	x10, x10, #0x700000000000
  0x0000000102f0db8c:   ldr	w14, [x3, #24]
  0x0000000102f0db90:   lsl	x14, x14, #3
  0x0000000102f0db94:   ldr	x14, [x14, #16]
  0x0000000102f0db98:   ldr	x12, [x3, #16]
  0x0000000102f0db9c:   ldr	w11, [x10, #172]
  0x0000000102f0dba0:   add	x11, x10, x11, uxtx #3
  0x0000000102f0dba4:   add	x11, x11, #0x1d8
  0x0000000102f0dba8:   add	x10, x10, x12, uxtx #3
  0x0000000102f0dbac:   ldr	x12, [x11]
  0x0000000102f0dbb0:   cmp	x14, x12
  0x0000000102f0dbb4:   b.eq	0x0000000102f0dbc8  // b.none
  0x0000000102f0dbb8:   cbz	x12, 0x0000000102f0dbe0
  0x0000000102f0dbbc:   ldr	x12, [x11, #16]!
  0x0000000102f0dbc0:   cmp	x14, x12
  0x0000000102f0dbc4:   b.ne	0x0000000102f0dbb8  // b.any
  0x0000000102f0dbc8:   ldr	w11, [x11, #8]
  0x0000000102f0dbcc:   ldr	x12, [x10, w11, uxtw]
  0x0000000102f0dbd0:   cbz	x12, 0x0000000102f0dbdc
  0x0000000102f0dbd4:   ldr	x8, [x12, #64]
  0x0000000102f0dbd8:   br	x8
  0x0000000102f0dbdc:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
  0x0000000102f0dbe0:   b	0x0000000102e9dd80          ;   {runtime_call IncompatibleClassChangeError throw_exception}
[Stub Code]
  0x0000000102f0dbe4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 224   20     n       java.lang.invoke.MethodHandle::linkToStatic(LL)I (native)
 total in heap  [0x0000000102f0e108,0x0000000102f0e220] = 280
 relocation     [0x0000000102f0e1e0,0x0000000102f0e1e8] = 8
 main code      [0x0000000102f0e200,0x0000000102f0e220] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c5531f8} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0e200:   nop
  0x0000000102f0e204:   ldr	w12, [x2, #36]
  0x0000000102f0e208:   lsl	x12, x12, #3
  0x0000000102f0e20c:   ldr	x12, [x12, #16]
  0x0000000102f0e210:   cbz	x12, 0x0000000102f0e21c
  0x0000000102f0e214:   ldr	x8, [x12, #64]
  0x0000000102f0e218:   br	x8
  0x0000000102f0e21c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 226   21     n       java.lang.invoke.MethodHandle::linkToStatic(LLL)I (native)
 total in heap  [0x0000000102f0e408,0x0000000102f0e520] = 280
 relocation     [0x0000000102f0e4e0,0x0000000102f0e4e8] = 8
 main code      [0x0000000102f0e500,0x0000000102f0e520] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c555080} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0e500:   nop
  0x0000000102f0e504:   ldr	w12, [x3, #36]
  0x0000000102f0e508:   lsl	x12, x12, #3
  0x0000000102f0e50c:   ldr	x12, [x12, #16]
  0x0000000102f0e510:   cbz	x12, 0x0000000102f0e51c
  0x0000000102f0e514:   ldr	x8, [x12, #64]
  0x0000000102f0e518:   br	x8
  0x0000000102f0e51c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 227   22     n       java.lang.invoke.MethodHandle::linkToVirtual(LL)L (native)
 total in heap  [0x0000000102f0e708,0x0000000102f0e828] = 288
 relocation     [0x0000000102f0e7e0,0x0000000102f0e7e8] = 8
 main code      [0x0000000102f0e800,0x0000000102f0e828] = 40

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c555590} 'linkToVirtual' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0e800:   nop
  0x0000000102f0e804:   ldr	w10, [x1, #8]
  0x0000000102f0e808:   eor	x10, x10, #0x700000000000
  0x0000000102f0e80c:   ldr	x11, [x2, #16]
  0x0000000102f0e810:   add	x12, x10, x11, uxtx #3
  0x0000000102f0e814:   ldr	x12, [x12, #472]
  0x0000000102f0e818:   cbz	x12, 0x0000000102f0e824
  0x0000000102f0e81c:   ldr	x8, [x12, #64]
  0x0000000102f0e820:   br	x8
  0x0000000102f0e824:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 229   23     n       java.lang.invoke.MethodHandle::linkToSpecial(LL)I (native)
 total in heap  [0x0000000102f0ea08,0x0000000102f0eb28] = 288
 relocation     [0x0000000102f0eae0,0x0000000102f0eae8] = 8
 main code      [0x0000000102f0eb00,0x0000000102f0eb24] = 36
 stub code      [0x0000000102f0eb24,0x0000000102f0eb28] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c55ec78} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f0eb00:   nop
  0x0000000102f0eb04:   ldr	xzr, [x1]
  0x0000000102f0eb08:   ldr	w12, [x2, #36]
  0x0000000102f0eb0c:   lsl	x12, x12, #3
  0x0000000102f0eb10:   ldr	x12, [x12, #16]
  0x0000000102f0eb14:   cbz	x12, 0x0000000102f0eb20
  0x0000000102f0eb18:   ldr	x8, [x12, #64]
  0x0000000102f0eb1c:   br	x8
  0x0000000102f0eb20:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f0eb24:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 248   24     n       jdk.internal.vm.Continuation::enterSpecial (native)
 total in heap  [0x0000000102f0f088,0x0000000102f0f380] = 760
 relocation     [0x0000000102f0f160,0x0000000102f0f188] = 40
 main code      [0x0000000102f0f1c0,0x0000000102f0f330] = 368
 stub code      [0x0000000102f0f330,0x0000000102f0f370] = 64
 metadata       [0x0000000102f0f370,0x0000000102f0f380] = 16

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Entry Point]
  # {method} {0x000000011c08c298} 'enterSpecial' '(Ljdk/internal/vm/Continuation;ZZ)V' in 'jdk/internal/vm/Continuation'
  # parm0:    c_rarg1:c_rarg1 
                        = 'jdk/internal/vm/Continuation'
  # parm1:    c_rarg2   = boolean
  # parm2:    c_rarg3   = boolean
  #           [sp+0x50]  (sp of caller)
  0x0000000102f0f1c0:   ldp	x2, x1, [x20, #8]
  0x0000000102f0f1c4:   ldr	x3, [x20]
  0x0000000102f0f1c8:   ldr	x8, [x28, #1344]
  0x0000000102f0f1cc:   cmp	sp, x8
  0x0000000102f0f1d0:   b.ls	0x0000000102f0f1dc  // b.plast
  0x0000000102f0f1d4:   mov	x8, sp
  0x0000000102f0f1d8:   str	x8, [x28, #1344]
  0x0000000102f0f1dc:   stp	x29, x30, [sp, #-16]!
  0x0000000102f0f1e0:   mov	x29, sp
  0x0000000102f0f1e4:   sub	sp, sp, #0x40
  0x0000000102f0f1e8:   ldr	x8, [x28, #1336]
  0x0000000102f0f1ec:   str	x8, [sp, #8]
  0x0000000102f0f1f0:   mov	x8, sp
  0x0000000102f0f1f4:   str	x8, [x28, #1336]
  0x0000000102f0f1f8:   str	x1, [sp, #16]
  0x0000000102f0f1fc:   str	w3, [sp, #32]
  0x0000000102f0f200:   str	xzr, [sp, #24]
  0x0000000102f0f204:   str	wzr, [sp, #36]
  0x0000000102f0f208:   str	wzr, [sp, #56]
  0x0000000102f0f20c:   ldr	x8, [x28, #1344]
  0x0000000102f0f210:   str	x8, [sp, #40]
  0x0000000102f0f214:   ldr	x8, [x28, #1360]
  0x0000000102f0f218:   str	x8, [sp, #48]
  0x0000000102f0f21c:   str	xzr, [x28, #1344]
  0x0000000102f0f220:   str	xzr, [x28, #1360]
  0x0000000102f0f224:   cbnz	x2, 0x0000000102f0f2a0
  0x0000000102f0f228:   bl	0x0000000102ea8580          ; ImmutableOopMap {}
                                                            ;   {static_call}
  0x0000000102f0f22c:   nop                                 ;   {other}
  0x0000000102f0f230:   movk	xzr, #0x1a4
  0x0000000102f0f234:   movk	xzr, #0x0
  0x0000000102f0f238:   b	0x0000000102f0f2b0
  0x0000000102f0f23c:   nop
[Verified Entry Point]
  0x0000000102f0f240:   stp	x29, x30, [sp, #-16]!
  0x0000000102f0f244:   mov	x29, sp
  0x0000000102f0f248:   sub	sp, sp, #0x40
  0x0000000102f0f24c:   ldr	x8, [x28, #1336]
  0x0000000102f0f250:   str	x8, [sp, #8]
  0x0000000102f0f254:   mov	x8, sp
  0x0000000102f0f258:   str	x8, [x28, #1336]
  0x0000000102f0f25c:   str	x1, [sp, #16]
  0x0000000102f0f260:   str	w3, [sp, #32]
  0x0000000102f0f264:   str	xzr, [sp, #24]
  0x0000000102f0f268:   str	wzr, [sp, #36]
  0x0000000102f0f26c:   str	wzr, [sp, #56]
  0x0000000102f0f270:   ldr	x8, [x28, #1344]
  0x0000000102f0f274:   str	x8, [sp, #40]
  0x0000000102f0f278:   ldr	x8, [x28, #1360]
  0x0000000102f0f27c:   str	x8, [sp, #48]
  0x0000000102f0f280:   str	xzr, [x28, #1344]
  0x0000000102f0f284:   str	xzr, [x28, #1360]
  0x0000000102f0f288:   cbnz	x2, 0x0000000102f0f2a0
  0x0000000102f0f28c:   bl	0x0000000102ea8580          ; ImmutableOopMap {}
                                                            ;   {static_call}
  0x0000000102f0f290:   nop                                 ;   {other}
  0x0000000102f0f294:   movk	xzr, #0x208
  0x0000000102f0f298:   movk	xzr, #0x100
  0x0000000102f0f29c:   b	0x0000000102f0f2b0
  0x0000000102f0f2a0:   bl	Stub::Cont thaw             ; ImmutableOopMap {}
                                                            ;   {runtime_call StubRoutines (continuation stubs)}
  0x0000000102f0f2a4:   nop                                 ;   {other}
  0x0000000102f0f2a8:   movk	xzr, #0x21c
  0x0000000102f0f2ac:   movk	xzr, #0x200
  0x0000000102f0f2b0:   ldr	x8, [sp, #40]
  0x0000000102f0f2b4:   str	x8, [x28, #1344]
  0x0000000102f0f2b8:   ldr	x8, [sp, #48]
  0x0000000102f0f2bc:   str	x8, [x28, #1360]
  0x0000000102f0f2c0:   ldr	x9, [sp, #8]
  0x0000000102f0f2c4:   str	x9, [x28, #1336]
  0x0000000102f0f2c8:   add	x29, sp, #0x40
  0x0000000102f0f2cc:   mov	sp, x29
  0x0000000102f0f2d0:   ldp	x29, x30, [sp], #16
  0x0000000102f0f2d4:   ret
[Exception Handler]
  0x0000000102f0f2d8:   mov	x19, x0
  0x0000000102f0f2dc:   ldr	x8, [sp, #40]
  0x0000000102f0f2e0:   str	x8, [x28, #1344]
  0x0000000102f0f2e4:   ldr	x8, [sp, #48]
  0x0000000102f0f2e8:   str	x8, [x28, #1360]
  0x0000000102f0f2ec:   ldr	x9, [sp, #8]
  0x0000000102f0f2f0:   str	x9, [x28, #1336]
  0x0000000102f0f2f4:   add	x29, sp, #0x40
  0x0000000102f0f2f8:   ldr	x1, [x29, #8]
  0x0000000102f0f2fc:   mov	x0, x28
  0x0000000102f0f300:   stp	x8, x12, [sp, #-16]!
  0x0000000102f0f304:   mov	x8, #0x7460                	// #29792
  0x0000000102f0f308:   movk	x8, #0x254, lsl #16
  0x0000000102f0f30c:   movk	x8, #0x1, lsl #32
  0x0000000102f0f310:   blr	x8
  0x0000000102f0f314:   ldp	x8, x12, [sp], #16
  0x0000000102f0f318:   mov	x1, x0
  0x0000000102f0f31c:   mov	x0, x19
  0x0000000102f0f320:   mov	sp, x29
  0x0000000102f0f324:   ldp	x29, x30, [sp], #16
  0x0000000102f0f328:   mov	x3, x30
  0x0000000102f0f32c:   br	x1
[Stub Code]
  0x0000000102f0f330:   isb                                 ;   {no_reloc}
  0x0000000102f0f334:   mov	x12, #0x0                   	// #0
                                                            ;   {metadata(nullptr)}
  0x0000000102f0f338:   movk	x12, #0x0, lsl #16
  0x0000000102f0f33c:   movk	x12, #0x0, lsl #32
  0x0000000102f0f340:   mov	x8, #0x0                   	// #0
  0x0000000102f0f344:   movk	x8, #0x0, lsl #16
  0x0000000102f0f348:   movk	x8, #0x0, lsl #32
  0x0000000102f0f34c:   br	x8
  0x0000000102f0f350:   isb                                 ;   {static_stub}
  0x0000000102f0f354:   mov	x12, #0x0                   	// #0
                                                            ;   {metadata(nullptr)}
  0x0000000102f0f358:   movk	x12, #0x0, lsl #16
  0x0000000102f0f35c:   movk	x12, #0x0, lsl #32
  0x0000000102f0f360:   mov	x8, #0x0                   	// #0
  0x0000000102f0f364:   movk	x8, #0x0, lsl #16
  0x0000000102f0f368:   movk	x8, #0x0, lsl #32
  0x0000000102f0f36c:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 250   25     n       jdk.internal.vm.Continuation::doYield (native)
 total in heap  [0x0000000102f0f388,0x0000000102f0f528] = 416
 relocation     [0x0000000102f0f460,0x0000000102f0f468] = 8
 main code      [0x0000000102f0f480,0x0000000102f0f528] = 168

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c08c1e0} 'doYield' '()I' in 'jdk/internal/vm/Continuation'
  #           [sp+0x10]  (sp of caller)
  0x0000000102f0f480:   stp	x29, x30, [sp, #-16]!
  0x0000000102f0f484:   mov	x29, sp
  0x0000000102f0f488:   mov	x1, sp
  0x0000000102f0f48c:   nop                                 ;   {other}
  0x0000000102f0f490:   movk	xzr, #0x104
  0x0000000102f0f494:   movk	xzr, #0x0
  0x0000000102f0f498:   mov	x0, x28
  0x0000000102f0f49c:   adr	x8, 0x0000000102f0f48c
  0x0000000102f0f4a0:   str	x8, [x28, #936]
  0x0000000102f0f4a4:   mov	x8, sp
  0x0000000102f0f4a8:   str	x8, [x28, #928]
  0x0000000102f0f4ac:   str	x29, [x28, #944]
  0x0000000102f0f4b0:   stp	x8, x12, [sp, #-16]!
  0x0000000102f0f4b4:   mov	x8, #0xdb70                	// #56176
  0x0000000102f0f4b8:   movk	x8, #0x1f3, lsl #16
  0x0000000102f0f4bc:   movk	x8, #0x1, lsl #32
  0x0000000102f0f4c0:   blr	x8
  0x0000000102f0f4c4:   ldp	x8, x12, [sp], #16
  0x0000000102f0f4c8:   str	xzr, [x28, #928]
  0x0000000102f0f4cc:   str	xzr, [x28, #944]
  0x0000000102f0f4d0:   str	xzr, [x28, #936]
  0x0000000102f0f4d4:   cbnz	x0, 0x0000000102f0f4fc
  0x0000000102f0f4d8:   ldr	x8, [x28, #1336]
  0x0000000102f0f4dc:   mov	sp, x8
  0x0000000102f0f4e0:   ldr	x8, [sp, #40]
  0x0000000102f0f4e4:   str	x8, [x28, #1344]
  0x0000000102f0f4e8:   ldr	x8, [sp, #48]
  0x0000000102f0f4ec:   str	x8, [x28, #1360]
  0x0000000102f0f4f0:   ldr	x9, [sp, #8]
  0x0000000102f0f4f4:   str	x9, [x28, #1336]
  0x0000000102f0f4f8:   add	x29, sp, #0x40
  0x0000000102f0f4fc:   ldr	x8, [x28, #8]
  0x0000000102f0f500:   cbz	x8, 0x0000000102f0f51c
  0x0000000102f0f504:   mov	sp, x29
  0x0000000102f0f508:   ldp	x29, x30, [sp], #16
  0x0000000102f0f50c:   mov	x8, #0xc040                	// #49216
                                                            ;   {runtime_call StubRoutines (initial stubs)}
  0x0000000102f0f510:   movk	x8, #0x2e6, lsl #16
  0x0000000102f0f514:   movk	x8, #0x1, lsl #32
  0x0000000102f0f518:   br	x8
  0x0000000102f0f51c:   mov	sp, x29
  0x0000000102f0f520:   ldp	x29, x30, [sp], #16
  0x0000000102f0f524:   ret
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 336   26     n       java.lang.invoke.MethodHandle::linkToStatic(LLL)V (native)
 total in heap  [0x0000000102f12788,0x0000000102f128a0] = 280
 relocation     [0x0000000102f12860,0x0000000102f12868] = 8
 main code      [0x0000000102f12880,0x0000000102f128a0] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c679960} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f12880:   nop
  0x0000000102f12884:   ldr	w12, [x3, #36]
  0x0000000102f12888:   lsl	x12, x12, #3
  0x0000000102f1288c:   ldr	x12, [x12, #16]
  0x0000000102f12890:   cbz	x12, 0x0000000102f1289c
  0x0000000102f12894:   ldr	x8, [x12, #64]
  0x0000000102f12898:   br	x8
  0x0000000102f1289c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 337   27     n       java.lang.invoke.MethodHandle::invokeBasic(LL)V (native)
 total in heap  [0x0000000102f12a88,0x0000000102f12bb0] = 296
 relocation     [0x0000000102f12b60,0x0000000102f12b68] = 8
 main code      [0x0000000102f12b80,0x0000000102f12bb0] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c679a78} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;)V' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f12b80:   nop
  0x0000000102f12b84:   ldr	w12, [x1, #20]
  0x0000000102f12b88:   lsl	x12, x12, #3
  0x0000000102f12b8c:   ldr	w12, [x12, #40]
  0x0000000102f12b90:   lsl	x12, x12, #3
  0x0000000102f12b94:   ldr	w12, [x12, #36]
  0x0000000102f12b98:   lsl	x12, x12, #3
  0x0000000102f12b9c:   ldr	x12, [x12, #16]
  0x0000000102f12ba0:   cbz	x12, 0x0000000102f12bac
  0x0000000102f12ba4:   ldr	x8, [x12, #64]
  0x0000000102f12ba8:   br	x8
  0x0000000102f12bac:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 340   28     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLL)L (native)
 total in heap  [0x0000000102f12d88,0x0000000102f12ea0] = 280
 relocation     [0x0000000102f12e60,0x0000000102f12e68] = 8
 main code      [0x0000000102f12e80,0x0000000102f12ea0] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c67d468} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f12e80:   nop
  0x0000000102f12e84:   ldr	w12, [x5, #36]
  0x0000000102f12e88:   lsl	x12, x12, #3
  0x0000000102f12e8c:   ldr	x12, [x12, #16]
  0x0000000102f12e90:   cbz	x12, 0x0000000102f12e9c
  0x0000000102f12e94:   ldr	x8, [x12, #64]
  0x0000000102f12e98:   br	x8
  0x0000000102f12e9c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 341   29     n       java.lang.invoke.MethodHandle::invokeBasic(LLLL)L (native)
 total in heap  [0x0000000102f13088,0x0000000102f131b0] = 296
 relocation     [0x0000000102f13160,0x0000000102f13168] = 8
 main code      [0x0000000102f13180,0x0000000102f131b0] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c67d8f8} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm3:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f13180:   nop
  0x0000000102f13184:   ldr	w12, [x1, #20]
  0x0000000102f13188:   lsl	x12, x12, #3
  0x0000000102f1318c:   ldr	w12, [x12, #40]
  0x0000000102f13190:   lsl	x12, x12, #3
  0x0000000102f13194:   ldr	w12, [x12, #36]
  0x0000000102f13198:   lsl	x12, x12, #3
  0x0000000102f1319c:   ldr	x12, [x12, #16]
  0x0000000102f131a0:   cbz	x12, 0x0000000102f131ac
  0x0000000102f131a4:   ldr	x8, [x12, #64]
  0x0000000102f131a8:   br	x8
  0x0000000102f131ac:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 344   30     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLLL)L (native)
 total in heap  [0x0000000102f13388,0x0000000102f134a0] = 280
 relocation     [0x0000000102f13460,0x0000000102f13468] = 8
 main code      [0x0000000102f13480,0x0000000102f134a0] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c67f2e0} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  # parm5:    c_rarg6:c_rarg6 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f13480:   nop
  0x0000000102f13484:   ldr	w12, [x6, #36]
  0x0000000102f13488:   lsl	x12, x12, #3
  0x0000000102f1348c:   ldr	x12, [x12, #16]
  0x0000000102f13490:   cbz	x12, 0x0000000102f1349c
  0x0000000102f13494:   ldr	x8, [x12, #64]
  0x0000000102f13498:   br	x8
  0x0000000102f1349c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 345   31     n       java.lang.invoke.MethodHandle::invokeBasic(LLLLL)L (native)
 total in heap  [0x0000000102f13688,0x0000000102f137b0] = 296
 relocation     [0x0000000102f13760,0x0000000102f13768] = 8
 main code      [0x0000000102f13780,0x0000000102f137b0] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c67f5a8} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm3:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  # parm4:    c_rarg6:c_rarg6 
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f13780:   nop
  0x0000000102f13784:   ldr	w12, [x1, #20]
  0x0000000102f13788:   lsl	x12, x12, #3
  0x0000000102f1378c:   ldr	w12, [x12, #40]
  0x0000000102f13790:   lsl	x12, x12, #3
  0x0000000102f13794:   ldr	w12, [x12, #36]
  0x0000000102f13798:   lsl	x12, x12, #3
  0x0000000102f1379c:   ldr	x12, [x12, #16]
  0x0000000102f137a0:   cbz	x12, 0x0000000102f137ac
  0x0000000102f137a4:   ldr	x8, [x12, #64]
  0x0000000102f137a8:   br	x8
  0x0000000102f137ac:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 346   32     n       java.lang.invoke.MethodHandle::invokeBasic(LLL)L (native)
 total in heap  [0x0000000102f13988,0x0000000102f13ab0] = 296
 relocation     [0x0000000102f13a60,0x0000000102f13a68] = 8
 main code      [0x0000000102f13a80,0x0000000102f13ab0] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c67f870} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f13a80:   nop
  0x0000000102f13a84:   ldr	w12, [x1, #20]
  0x0000000102f13a88:   lsl	x12, x12, #3
  0x0000000102f13a8c:   ldr	w12, [x12, #40]
  0x0000000102f13a90:   lsl	x12, x12, #3
  0x0000000102f13a94:   ldr	w12, [x12, #36]
  0x0000000102f13a98:   lsl	x12, x12, #3
  0x0000000102f13a9c:   ldr	x12, [x12, #16]
  0x0000000102f13aa0:   cbz	x12, 0x0000000102f13aac
  0x0000000102f13aa4:   ldr	x8, [x12, #64]
  0x0000000102f13aa8:   br	x8
  0x0000000102f13aac:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 346   33     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLLL)L (native)
 total in heap  [0x0000000102f13c88,0x0000000102f13da8] = 288
 relocation     [0x0000000102f13d60,0x0000000102f13d68] = 8
 main code      [0x0000000102f13d80,0x0000000102f13da4] = 36
 stub code      [0x0000000102f13da4,0x0000000102f13da8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c67f988} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f13d80:   nop
  0x0000000102f13d84:   ldr	xzr, [x1]
  0x0000000102f13d88:   ldr	w12, [x5, #36]
  0x0000000102f13d8c:   lsl	x12, x12, #3
  0x0000000102f13d90:   ldr	x12, [x12, #16]
  0x0000000102f13d94:   cbz	x12, 0x0000000102f13da0
  0x0000000102f13d98:   ldr	x8, [x12, #64]
  0x0000000102f13d9c:   br	x8
  0x0000000102f13da0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f13da4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 370   34     n       java.lang.invoke.MethodHandle::linkToStatic(LL)V (native)
 total in heap  [0x0000000102f15f08,0x0000000102f16020] = 280
 relocation     [0x0000000102f15fe0,0x0000000102f15fe8] = 8
 main code      [0x0000000102f16000,0x0000000102f16020] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c6efad0} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f16000:   nop
  0x0000000102f16004:   ldr	w12, [x2, #36]
  0x0000000102f16008:   lsl	x12, x12, #3
  0x0000000102f1600c:   ldr	x12, [x12, #16]
  0x0000000102f16010:   cbz	x12, 0x0000000102f1601c
  0x0000000102f16014:   ldr	x8, [x12, #64]
  0x0000000102f16018:   br	x8
  0x0000000102f1601c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 385   35     n       java.lang.invoke.MethodHandle::linkToStatic(IL)I (native)
 total in heap  [0x0000000102f16208,0x0000000102f16320] = 280
 relocation     [0x0000000102f162e0,0x0000000102f162e8] = 8
 main code      [0x0000000102f16300,0x0000000102f16320] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c795268} 'linkToStatic' '(ILjava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1   = int
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f16300:   nop
  0x0000000102f16304:   ldr	w12, [x2, #36]
  0x0000000102f16308:   lsl	x12, x12, #3
  0x0000000102f1630c:   ldr	x12, [x12, #16]
  0x0000000102f16310:   cbz	x12, 0x0000000102f1631c
  0x0000000102f16314:   ldr	x8, [x12, #64]
  0x0000000102f16318:   br	x8
  0x0000000102f1631c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 393   36     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLL)I (native)
 total in heap  [0x0000000102f18808,0x0000000102f18920] = 280
 relocation     [0x0000000102f188e0,0x0000000102f188e8] = 8
 main code      [0x0000000102f18900,0x0000000102f18920] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7c5e80} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f18900:   nop
  0x0000000102f18904:   ldr	w12, [x5, #36]
  0x0000000102f18908:   lsl	x12, x12, #3
  0x0000000102f1890c:   ldr	x12, [x12, #16]
  0x0000000102f18910:   cbz	x12, 0x0000000102f1891c
  0x0000000102f18914:   ldr	x8, [x12, #64]
  0x0000000102f18918:   br	x8
  0x0000000102f1891c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

============================= C2-compiled nmethod ==============================
----------------------------------- Assembly -----------------------------------

Compiled method (c2) 397   37             java.lang.AbstractStringBuilder::appendNull (75 bytes)
 total in heap  [0x0000000102f1cf88,0x0000000102f1d558] = 1488
 relocation     [0x0000000102f1d060,0x0000000102f1d0b8] = 88
 main code      [0x0000000102f1d0c0,0x0000000102f1d4f0] = 1072
 stub code      [0x0000000102f1d4f0,0x0000000102f1d520] = 48
 metadata       [0x0000000102f1d520,0x0000000102f1d558] = 56
 immutable data [0x0000000144856800,0x0000000144856c78] = 1144
 dependencies   [0x0000000144856800,0x0000000144856810] = 16
 nul chk table  [0x0000000144856810,0x0000000144856820] = 16
 handler table  [0x0000000144856820,0x0000000144856850] = 48
 scopes pcs     [0x0000000144856850,0x0000000144856b20] = 720
 scopes data    [0x0000000144856b20,0x0000000144856c78] = 344

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Instructions begin]
  0x0000000102f1d0c0:   nop
  0x0000000102f1d0c4:   nop
  0x0000000102f1d0c8:   nop
[Entry Point]
  # {method} {0x000000011c0cefd0} 'appendNull' '()Ljava/lang/AbstractStringBuilder;' in 'java/lang/AbstractStringBuilder'
  #           [sp+0x50]  (sp of caller)
  0x0000000102f1d0cc:   ldr	w8, [x1, #8]
  0x0000000102f1d0d0:   ldr	w10, [x9, #8]
  0x0000000102f1d0d4:   cmp	w8, w10
  0x0000000102f1d0d8:   b.eq	0x0000000102f1d0e0  // b.none
  0x0000000102f1d0dc:   b	0x0000000102ea7c80          ;   {runtime_call ic_miss_stub}
[Verified Entry Point]
  0x0000000102f1d0e0:   nop
  0x0000000102f1d0e4:   sub	x9, sp, #0x14, lsl #12
  0x0000000102f1d0e8:   str	xzr, [x9]
  0x0000000102f1d0ec:   sub	sp, sp, #0x50
  0x0000000102f1d0f0:   stp	x29, x30, [sp, #64]
  0x0000000102f1d0f4:   ldr	w8, 0x0000000102f1d4ec
  0x0000000102f1d0f8:   ldr	w9, [x28, #32]
  0x0000000102f1d0fc:   cmp	x8, x9
  0x0000000102f1d100:   b.ne	0x0000000102f1d4d8  // b.any;*synchronization entry
                                                            ; - java.lang.AbstractStringBuilder::appendNull at -1 (line 711)
  0x0000000102f1d104:   ldr	w10, [x1, #20]
  0x0000000102f1d108:   mov	x19, x1
  0x0000000102f1d10c:   lsl	x14, x10, #3                ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 1 (line 316)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d110:   ldr	w15, [x14, #12]             ; implicit exception: dispatches to 0x0000000102f1d4a0
                                                            ;*arraylength {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 4 (line 316)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d114:   ldrsb	w12, [x1, #16]              ;*getfield coder {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 6 (line 316)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d118:   ldr	w17, [x1, #12]              ;*getfield count {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 1 (line 711)
  0x0000000102f1d11c:   asr	w11, w15, w12
  0x0000000102f1d120:   sub	w13, w17, w11
  0x0000000102f1d124:   add	w11, w13, #0x4
  0x0000000102f1d128:   add	w13, w17, #0x4              ;*iadd {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 8 (line 712)
  0x0000000102f1d12c:   cmp	w11, #0x0
  0x0000000102f1d130:   b.gt	0x0000000102f1d17c
  0x0000000102f1d134:   lsl	x10, x10, #3                ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 13 (line 713)
  0x0000000102f1d138:   cbz	w12, 0x0000000102f1d3d8     ;*ifeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 21 (line 714)
  0x0000000102f1d13c:   mov	w11, #0x6e                  	// #110
  0x0000000102f1d140:   add	x10, x10, w17, sxtw #1
  0x0000000102f1d144:   strh	w11, [x10, #16]             ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 3 (line 1552)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 722)
  0x0000000102f1d148:   mov	w11, #0x75                  	// #117
  0x0000000102f1d14c:   mov	w12, #0x6c                  	// #108
  0x0000000102f1d150:   strh	w11, [x10, #18]             ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 11 (line 1553)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 722)
  0x0000000102f1d154:   strh	w12, [x10, #20]             ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 20 (line 1554)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 722)
  0x0000000102f1d158:   strh	w12, [x10, #22]             ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 29 (line 1555)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 722)
  0x0000000102f1d15c:   str	w13, [x19, #12]             ;*synchronization entry
                                                            ; - java.lang.AbstractStringBuilder::appendNull at -1 (line 711)
  0x0000000102f1d160:   mov	x0, x19
  0x0000000102f1d164:   ldp	x29, x30, [sp, #64]
  0x0000000102f1d168:   add	sp, sp, #0x50
  0x0000000102f1d16c:   ldr	x8, [x28, #1096]            ;   {poll_return}
  0x0000000102f1d170:   cmp	sp, x8
  0x0000000102f1d174:   b.hi	0x0000000102f1d4cc  // b.pmore
  0x0000000102f1d178:   ret
  0x0000000102f1d17c:   stp	w15, w13, [sp]
  0x0000000102f1d180:   str	x14, [sp, #8]
  0x0000000102f1d184:   str	w17, [sp, #20]
  0x0000000102f1d188:   mov	x29, x1
  0x0000000102f1d18c:   mov	w2, w13
  0x0000000102f1d190:   bl	0x0000000102ea7f80          ; ImmutableOopMap {rfp=Oop [8]=Oop }
                                                            ;*invokevirtual newCapacity {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 319)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
                                                            ;   {optimized virtual_call}
  0x0000000102f1d194:   nop                                 ;   {other}
  0x0000000102f1d198:   movk	xzr, #0x20c
  0x0000000102f1d19c:   movk	xzr, #0x0                   ;*invokevirtual newCapacity {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 319)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d1a0:   mov	x19, x29
  0x0000000102f1d1a4:   ldrsb	w10, [x19, #16]
  0x0000000102f1d1a8:   lsl	w14, w0, w10                ;*ishl {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 31 (line 319)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d1ac:   ldr	w11, [sp]
  0x0000000102f1d1b0:   cmp	w11, w14
  0x0000000102f1d1b4:   csel	w29, w11, w14, lt  // lt = tstop;*invokestatic min {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 25 (line 3542)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d1b8:   cmp	w14, w11
  0x0000000102f1d1bc:   b.eq	0x0000000102f1d480  // b.none;*if_icmpne {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 3 (line 3537)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d1c0:   mov	w12, w14
  0x0000000102f1d1c4:   mov	x10, #0x17                  	// #23
  0x0000000102f1d1c8:   add	x12, x10, w12, sxtw         ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d1cc:   cmp	w11, w29
  0x0000000102f1d1d0:   b.cc	0x0000000102f1d434  // b.lo, b.ul, b.last
  0x0000000102f1d1d4:   cmp	w14, w29
  0x0000000102f1d1d8:   b.cc	0x0000000102f1d434  // b.lo, b.ul, b.last
                                                            ;*invokestatic arraycopy {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 28 (line 3541)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d1dc:   and	x13, x12, #0xfffffffffffffff8;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d1e0:   cmp	w14, #0x100, lsl #12
  0x0000000102f1d1e4:   b.hi	0x0000000102f1d398  // b.pmore
  0x0000000102f1d1e8:   ldr	x20, [x28, #440]
  0x0000000102f1d1ec:   ldr	x11, [x28, #456]
  0x0000000102f1d1f0:   add	x10, x20, x13
  0x0000000102f1d1f4:   cmp	x10, x11
  0x0000000102f1d1f8:   b.cs	0x0000000102f1d398  // b.hs, b.nlast
                                                            ;*putfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d1fc:   orr	x11, xzr, #0x1
  0x0000000102f1d200:   str	x10, [x28, #440]
  0x0000000102f1d204:   str	x11, [x20]
  0x0000000102f1d208:   mov	x11, #0x40000               	// #262144
                                                            ;   {metadata({type array byte})}
  0x0000000102f1d20c:   movk	x11, #0xa00
  0x0000000102f1d210:   prfm	pstl1keep, [x10, #384]
  0x0000000102f1d214:   str	w11, [x20, #8]
  0x0000000102f1d218:   prfm	pstl1keep, [x10, #512]
  0x0000000102f1d21c:   str	w14, [x20, #12]
  0x0000000102f1d220:   prfm	pstl1keep, [x10, #640]      ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d224:   lsr	x11, x12, #3
  0x0000000102f1d228:   add	x1, x20, #0x10
  0x0000000102f1d22c:   lsr	x21, x20, #3
  0x0000000102f1d230:   cbz	w29, 0x0000000102f1d400
  0x0000000102f1d234:   ldr	x10, [sp, #8]
  0x0000000102f1d238:   add	x0, x10, #0x10
  0x0000000102f1d23c:   cmp	w29, w14
  0x0000000102f1d240:   b.lt	0x0000000102f1d2b4  // b.tstop
  0x0000000102f1d244:   sub	x10, x13, #0x10
  0x0000000102f1d248:   lsr	x2, x10, #3
  0x0000000102f1d24c:   bl	Stub::arrayof_jlong_disjoint_arraycopy
                                                            ;   {runtime_call StubRoutines (final stubs)}
  0x0000000102f1d250:   nop                                 ;   {other}
  0x0000000102f1d254:   movk	xzr, #0x0
  0x0000000102f1d258:   movk	xzr, #0x0
  0x0000000102f1d25c:   dmb	ishst
  0x0000000102f1d260:   ldrsb	w10, [x28, #56]
  0x0000000102f1d264:   cbnz	w10, 0x0000000102f1d304
  0x0000000102f1d268:   mov	x10, x19
  0x0000000102f1d26c:   mov	x11, x20
  0x0000000102f1d270:   eor	x11, x11, x10
  0x0000000102f1d274:   lsr	x11, x11, #23
  0x0000000102f1d278:   str	w21, [x19, #20]
  0x0000000102f1d27c:   cbz	x11, 0x0000000102f1d2a0
  0x0000000102f1d280:   lsr	x10, x10, #9
  0x0000000102f1d284:   mov	x11, #0xc000                	// #49152
  0x0000000102f1d288:   movk	x11, #0x5e6, lsl #16
  0x0000000102f1d28c:   movk	x11, #0x1, lsl #32
  0x0000000102f1d290:   add	x0, x11, x10
  0x0000000102f1d294:   ldrsb	w10, [x0]
  0x0000000102f1d298:   cmp	w10, #0x2
  0x0000000102f1d29c:   b.ne	0x0000000102f1d330  // b.any;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 13 (line 713)
  0x0000000102f1d2a0:   ldrsb	w12, [x19, #16]             ;*getfield coder {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::isLatin1 at 7 (line 1791)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 18 (line 714)
  0x0000000102f1d2a4:   lsr	x10, x20, #3
  0x0000000102f1d2a8:   ldr	w13, [sp, #4]
  0x0000000102f1d2ac:   ldr	w17, [sp, #20]
  0x0000000102f1d2b0:   b	0x0000000102f1d134
  0x0000000102f1d2b4:   sxtw	x2, w29
  0x0000000102f1d2b8:   add	x12, x2, #0x10
  0x0000000102f1d2bc:   and	x10, x12, #0xfffffffffffffff8
  0x0000000102f1d2c0:   add	x10, x20, x10
  0x0000000102f1d2c4:   sub	x11, x11, x12, lsr #3
  0x0000000102f1d2c8:   subs	x8, x11, #0x8
  0x0000000102f1d2cc:   b.cc	0x0000000102f1d2d4  // b.lo, b.ul, b.last
  0x0000000102f1d2d0:   bl	Stub::zero_blocks           ;   {runtime_call StubRoutines (final stubs)}
  0x0000000102f1d2d4:   tbz	w11, #2, 0x0000000102f1d2e0
  0x0000000102f1d2d8:   stp	xzr, xzr, [x10], #16
  0x0000000102f1d2dc:   stp	xzr, xzr, [x10], #16
  0x0000000102f1d2e0:   tbz	w11, #1, 0x0000000102f1d2e8
  0x0000000102f1d2e4:   stp	xzr, xzr, [x10], #16
  0x0000000102f1d2e8:   tbz	w11, #0, 0x0000000102f1d2f0
  0x0000000102f1d2ec:   str	xzr, [x10]
  0x0000000102f1d2f0:   bl	Stub::arrayof_jbyte_disjoint_arraycopy
                                                            ;   {runtime_call StubRoutines (final stubs)}
  0x0000000102f1d2f4:   nop                                 ;   {other}
  0x0000000102f1d2f8:   movk	xzr, #0x0
  0x0000000102f1d2fc:   movk	xzr, #0x0
  0x0000000102f1d300:   b	0x0000000102f1d25c
  0x0000000102f1d304:   ldr	w11, [x19, #20]
  0x0000000102f1d308:   lsl	x0, x11, #3
  0x0000000102f1d30c:   cbz	x0, 0x0000000102f1d268
  0x0000000102f1d310:   ldr	x10, [x28, #40]
  0x0000000102f1d314:   cbz	x10, 0x0000000102f1d450
  0x0000000102f1d318:   ldr	x11, [x28, #48]
  0x0000000102f1d31c:   sub	x12, x10, #0x8
  0x0000000102f1d320:   add	x10, x11, x10
  0x0000000102f1d324:   stur	x0, [x10, #-8]
  0x0000000102f1d328:   str	x12, [x28, #40]
  0x0000000102f1d32c:   b	0x0000000102f1d268
  0x0000000102f1d330:   ldp	x11, x10, [x28, #64]
  0x0000000102f1d334:   dmb	ish
  0x0000000102f1d338:   ldrsb	w12, [x0]
  0x0000000102f1d33c:   cbz	w12, 0x0000000102f1d388
  0x0000000102f1d340:   strb	wzr, [x0]
  0x0000000102f1d344:   cbz	x11, 0x0000000102f1d35c
  0x0000000102f1d348:   sub	x12, x11, #0x8
  0x0000000102f1d34c:   add	x10, x10, x11
  0x0000000102f1d350:   stur	x0, [x10, #-8]
  0x0000000102f1d354:   str	x12, [x28, #64]
  0x0000000102f1d358:   b	0x0000000102f1d388
  0x0000000102f1d35c:   mov	x1, x28
  0x0000000102f1d360:   adr	x9, 0x0000000102f1d378
  0x0000000102f1d364:   mov	x8, #0x6ae4                	// #27364
                                                            ;   {runtime_call G1BarrierSetRuntime::write_ref_field_post_entry(unsigned char volatile*, JavaThread*)}
  0x0000000102f1d368:   movk	x8, #0x200, lsl #16
  0x0000000102f1d36c:   movk	x8, #0x1, lsl #32
  0x0000000102f1d370:   stp	xzr, x9, [sp, #-16]!
  0x0000000102f1d374:   blr	x8
  0x0000000102f1d378:   nop                                 ;   {other}
  0x0000000102f1d37c:   movk	xzr, #0x0
  0x0000000102f1d380:   movk	xzr, #0x0
  0x0000000102f1d384:   add	sp, sp, #0x10               ;*putfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d388:   ldr	w11, [x19, #20]
  0x0000000102f1d38c:   lsl	x10, x11, #3                ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 13 (line 713)
  0x0000000102f1d390:   mov	x20, x10
  0x0000000102f1d394:   b	0x0000000102f1d2a0
  0x0000000102f1d398:   str	w14, [sp]
  0x0000000102f1d39c:   stp	x19, x12, [sp, #24]
  0x0000000102f1d3a0:   str	x13, [sp, #40]
  0x0000000102f1d3a4:   mov	x1, #0xa00                 	// #2560
                                                            ;   {metadata({type array byte})}
  0x0000000102f1d3a8:   movk	x1, #0x4, lsl #16
  0x0000000102f1d3ac:   movk	x1, #0x7000, lsl #32
  0x0000000102f1d3b0:   mov	w2, w14
  0x0000000102f1d3b4:   bl	0x0000000102eecf00          ; ImmutableOopMap {[8]=Oop [24]=Oop }
                                                            ;*newarray {reexecute=0 rethrow=0 return_oop=1}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
                                                            ;   {runtime_call _new_array_nozero_Java}
  0x0000000102f1d3b8:   nop                                 ;   {other}
  0x0000000102f1d3bc:   movk	xzr, #0x430
  0x0000000102f1d3c0:   movk	xzr, #0x100                 ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d3c4:   ldr	w14, [sp]
  0x0000000102f1d3c8:   ldr	x19, [sp, #24]
  0x0000000102f1d3cc:   mov	x20, x0
  0x0000000102f1d3d0:   ldp	x12, x13, [sp, #32]
  0x0000000102f1d3d4:   b	0x0000000102f1d224
  0x0000000102f1d3d8:   cmp	w12, #0x0                   ;*invokevirtual isLatin1 {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 18 (line 714)
  0x0000000102f1d3dc:   cset	w29, eq  // eq = none       ;*ireturn {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::isLatin1 at 18 (line 1791)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 18 (line 714)
  0x0000000102f1d3e0:   mov	w1, #0xffffff45            	// #-187
  0x0000000102f1d3e4:   str	x19, [sp]
  0x0000000102f1d3e8:   str	w17, [sp, #8]
  0x0000000102f1d3ec:   str	x10, [sp, #16]
  0x0000000102f1d3f0:   bl	0x0000000102eaed00          ; ImmutableOopMap {[0]=Oop [16]=Oop }
                                                            ;*ifeq {reexecute=1 rethrow=0 return_oop=0}
                                                            ; - (reexecute) java.lang.AbstractStringBuilder::appendNull at 21 (line 714)
                                                            ;   {runtime_call UncommonTrapBlob}
  0x0000000102f1d3f4:   nop                                 ;   {other}
  0x0000000102f1d3f8:   movk	xzr, #0x46c
  0x0000000102f1d3fc:   movk	xzr, #0x200                 ;*ifeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 21 (line 714)
  0x0000000102f1d400:   mov	x10, x1
  0x0000000102f1d404:   sub	x11, x11, #0x2
  0x0000000102f1d408:   subs	x8, x11, #0x8
  0x0000000102f1d40c:   b.cc	0x0000000102f1d414  // b.lo, b.ul, b.last
  0x0000000102f1d410:   bl	Stub::zero_blocks           ;   {runtime_call StubRoutines (final stubs)}
  0x0000000102f1d414:   tbz	w11, #2, 0x0000000102f1d420
  0x0000000102f1d418:   stp	xzr, xzr, [x10], #16
  0x0000000102f1d41c:   stp	xzr, xzr, [x10], #16
  0x0000000102f1d420:   tbz	w11, #1, 0x0000000102f1d428
  0x0000000102f1d424:   stp	xzr, xzr, [x10], #16
  0x0000000102f1d428:   tbz	w11, #0, 0x0000000102f1d430
  0x0000000102f1d42c:   str	xzr, [x10]
  0x0000000102f1d430:   b	0x0000000102f1d25c          ;*invokestatic arraycopy {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 28 (line 3541)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d434:   mov	w1, #0xffffffcc            	// #-52
  0x0000000102f1d438:   str	x19, [sp]
  0x0000000102f1d43c:   str	w14, [sp, #16]
  0x0000000102f1d440:   bl	0x0000000102eaed00          ; ImmutableOopMap {[0]=Oop [8]=Oop }
                                                            ;*newarray {reexecute=1 rethrow=0 return_oop=0}
                                                            ; - (reexecute) java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
                                                            ;   {runtime_call UncommonTrapBlob}
  0x0000000102f1d444:   nop                                 ;   {other}
  0x0000000102f1d448:   movk	xzr, #0x4bc
  0x0000000102f1d44c:   movk	xzr, #0x300
  0x0000000102f1d450:   mov	x1, x28
  0x0000000102f1d454:   adr	x9, 0x0000000102f1d46c
  0x0000000102f1d458:   mov	x8, #0x6abc                	// #27324
                                                            ;   {runtime_call G1BarrierSetRuntime::write_ref_field_pre_entry(oopDesc*, JavaThread*)}
  0x0000000102f1d45c:   movk	x8, #0x200, lsl #16
  0x0000000102f1d460:   movk	x8, #0x1, lsl #32
  0x0000000102f1d464:   stp	xzr, x9, [sp, #-16]!
  0x0000000102f1d468:   blr	x8
  0x0000000102f1d46c:   nop                                 ;   {other}
  0x0000000102f1d470:   movk	xzr, #0x0
  0x0000000102f1d474:   movk	xzr, #0x0
  0x0000000102f1d478:   add	sp, sp, #0x10               ;*putfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d47c:   b	0x0000000102f1d268
  0x0000000102f1d480:   mov	w1, #0xffffff45            	// #-187
  0x0000000102f1d484:   str	x19, [sp]
  0x0000000102f1d488:   str	w11, [sp, #16]
  0x0000000102f1d48c:   str	w14, [sp, #24]
  0x0000000102f1d490:   bl	0x0000000102eaed00          ; ImmutableOopMap {[0]=Oop [8]=Oop }
                                                            ;*if_icmpne {reexecute=1 rethrow=0 return_oop=0}
                                                            ; - (reexecute) java.util.Arrays::copyOf at 3 (line 3537)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
                                                            ;   {runtime_call UncommonTrapBlob}
  0x0000000102f1d494:   nop                                 ;   {other}
  0x0000000102f1d498:   movk	xzr, #0x50c
  0x0000000102f1d49c:   movk	xzr, #0x400                 ;*if_icmpne {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 3 (line 3537)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d4a0:   mov	w1, #0xfffffff6            	// #-10
  0x0000000102f1d4a4:   bl	0x0000000102eaed00          ; ImmutableOopMap {}
                                                            ;*arraylength {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 4 (line 316)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
                                                            ;   {runtime_call UncommonTrapBlob}
  0x0000000102f1d4a8:   nop                                 ;   {other}
  0x0000000102f1d4ac:   movk	xzr, #0x520
  0x0000000102f1d4b0:   movk	xzr, #0x500                 ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 318)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d4b4:   mov	x1, x0
  0x0000000102f1d4b8:   b	0x0000000102f1d4c0          ;*invokevirtual newCapacity {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 319)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d4bc:   mov	x1, x0                      ;*synchronization entry
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at -1 (line 316)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 712)
  0x0000000102f1d4c0:   ldp	x29, x30, [sp, #64]
  0x0000000102f1d4c4:   add	sp, sp, #0x50
  0x0000000102f1d4c8:   b	0x0000000102eeed00          ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 13 (line 713)
                                                            ;   {runtime_call _rethrow_Java}
  0x0000000102f1d4cc:   adr	x8, 0x0000000102f1d16c      ;   {internal_word}
  0x0000000102f1d4d0:   str	x8, [x28, #1120]
  0x0000000102f1d4d4:   b	0x0000000102eae680          ;   {runtime_call SafepointBlob}
  0x0000000102f1d4d8:   mov	x8, #0x16c0                	// #5824
                                                            ;   {runtime_call StubRoutines (final stubs)}
  0x0000000102f1d4dc:   movk	x8, #0x2eb, lsl #16
  0x0000000102f1d4e0:   movk	x8, #0x1, lsl #32
  0x0000000102f1d4e4:   blr	x8
  0x0000000102f1d4e8:   b	0x0000000102f1d104
  0x0000000102f1d4ec:   udf	#1                          ;   {other}
[Stub Code]
  0x0000000102f1d4f0:   isb                                 ;   {no_reloc}
  0x0000000102f1d4f4:   mov	x12, #0x0                   	// #0
                                                            ;   {metadata(nullptr)}
  0x0000000102f1d4f8:   movk	x12, #0x0, lsl #16
  0x0000000102f1d4fc:   movk	x12, #0x0, lsl #32
  0x0000000102f1d500:   mov	x8, #0x0                   	// #0
  0x0000000102f1d504:   movk	x8, #0x0, lsl #16
  0x0000000102f1d508:   movk	x8, #0x0, lsl #32
  0x0000000102f1d50c:   br	x8
[Exception Handler]
  0x0000000102f1d510:   b	0x0000000102eed880          ;   {runtime_call ExceptionBlob}
[Deopt Handler Code]
  0x0000000102f1d514:   adr	x30, 0x0000000102f1d514
  0x0000000102f1d518:   b	0x0000000102eae980          ;   {runtime_call DeoptimizationBlob}
  0x0000000102f1d51c:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38661   38     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLLLLL)L (native)
 total in heap  [0x0000000102f1cc88,0x0000000102f1cda8] = 288
 relocation     [0x0000000102f1cd60,0x0000000102f1cd68] = 8
 main code      [0x0000000102f1cd80,0x0000000102f1cda4] = 36
 stub code      [0x0000000102f1cda4,0x0000000102f1cda8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d03b0} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  # parm5:    c_rarg6:c_rarg6 
                        = 'java/lang/Object'
  # parm6:    c_rarg7:c_rarg7 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1cd80:   nop
  0x0000000102f1cd84:   ldr	xzr, [x1]
  0x0000000102f1cd88:   ldr	w12, [x7, #36]
  0x0000000102f1cd8c:   lsl	x12, x12, #3
  0x0000000102f1cd90:   ldr	x12, [x12, #16]
  0x0000000102f1cd94:   cbz	x12, 0x0000000102f1cda0
  0x0000000102f1cd98:   ldr	x8, [x12, #64]
  0x0000000102f1cd9c:   br	x8
  0x0000000102f1cda0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f1cda4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38663   39     n       java.lang.invoke.MethodHandle::linkToStatic(LJL)L (native)
 total in heap  [0x0000000102f1c988,0x0000000102f1caa0] = 280
 relocation     [0x0000000102f1ca60,0x0000000102f1ca68] = 8
 main code      [0x0000000102f1ca80,0x0000000102f1caa0] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d0768} 'linkToStatic' '(Ljava/lang/Object;JLjava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = long
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1ca80:   nop
  0x0000000102f1ca84:   ldr	w12, [x3, #36]
  0x0000000102f1ca88:   lsl	x12, x12, #3
  0x0000000102f1ca8c:   ldr	x12, [x12, #16]
  0x0000000102f1ca90:   cbz	x12, 0x0000000102f1ca9c
  0x0000000102f1ca94:   ldr	x8, [x12, #64]
  0x0000000102f1ca98:   br	x8
  0x0000000102f1ca9c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38664   40     n       java.lang.invoke.MethodHandle::invokeBasic(LJ)L (native)
 total in heap  [0x0000000102f1c688,0x0000000102f1c7b0] = 296
 relocation     [0x0000000102f1c760,0x0000000102f1c768] = 8
 main code      [0x0000000102f1c780,0x0000000102f1c7b0] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d0880} 'invokeBasic' '(Ljava/lang/Object;J)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3 
                        = long
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1c780:   nop
  0x0000000102f1c784:   ldr	w12, [x1, #20]
  0x0000000102f1c788:   lsl	x12, x12, #3
  0x0000000102f1c78c:   ldr	w12, [x12, #40]
  0x0000000102f1c790:   lsl	x12, x12, #3
  0x0000000102f1c794:   ldr	w12, [x12, #36]
  0x0000000102f1c798:   lsl	x12, x12, #3
  0x0000000102f1c79c:   ldr	x12, [x12, #16]
  0x0000000102f1c7a0:   cbz	x12, 0x0000000102f1c7ac
  0x0000000102f1c7a4:   ldr	x8, [x12, #64]
  0x0000000102f1c7a8:   br	x8
  0x0000000102f1c7ac:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38664   41     n       java.lang.invoke.MethodHandle::linkToSpecial(LLJL)L (native)
 total in heap  [0x0000000102f1c388,0x0000000102f1c4a8] = 288
 relocation     [0x0000000102f1c460,0x0000000102f1c468] = 8
 main code      [0x0000000102f1c480,0x0000000102f1c4a4] = 36
 stub code      [0x0000000102f1c4a4,0x0000000102f1c4a8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d0b08} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;JLjava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = long
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1c480:   nop
  0x0000000102f1c484:   ldr	xzr, [x1]
  0x0000000102f1c488:   ldr	w12, [x4, #36]
  0x0000000102f1c48c:   lsl	x12, x12, #3
  0x0000000102f1c490:   ldr	x12, [x12, #16]
  0x0000000102f1c494:   cbz	x12, 0x0000000102f1c4a0
  0x0000000102f1c498:   ldr	x8, [x12, #64]
  0x0000000102f1c49c:   br	x8
  0x0000000102f1c4a0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f1c4a4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38665   42     n       java.lang.invoke.MethodHandle::linkToStatic(JLJLL)J (native)
 total in heap  [0x0000000102f1bd08,0x0000000102f1be20] = 280
 relocation     [0x0000000102f1bde0,0x0000000102f1bde8] = 8
 main code      [0x0000000102f1be00,0x0000000102f1be20] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d0da0} 'linkToStatic' '(JLjava/lang/Object;JLjava/lang/Object;Ljava/lang/invoke/MemberName;)J' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = long
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = long
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1be00:   nop
  0x0000000102f1be04:   ldr	w12, [x5, #36]
  0x0000000102f1be08:   lsl	x12, x12, #3
  0x0000000102f1be0c:   ldr	x12, [x12, #16]
  0x0000000102f1be10:   cbz	x12, 0x0000000102f1be1c
  0x0000000102f1be14:   ldr	x8, [x12, #64]
  0x0000000102f1be18:   br	x8
  0x0000000102f1be1c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38666   43     n       java.lang.invoke.MethodHandle::invokeBasic(JLJL)J (native)
 total in heap  [0x0000000102f1ba08,0x0000000102f1bb30] = 296
 relocation     [0x0000000102f1bae0,0x0000000102f1bae8] = 8
 main code      [0x0000000102f1bb00,0x0000000102f1bb30] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d0eb8} 'invokeBasic' '(JLjava/lang/Object;JLjava/lang/Object;)J' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = long
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4 
                        = long
  # parm3:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1bb00:   nop
  0x0000000102f1bb04:   ldr	w12, [x1, #20]
  0x0000000102f1bb08:   lsl	x12, x12, #3
  0x0000000102f1bb0c:   ldr	w12, [x12, #40]
  0x0000000102f1bb10:   lsl	x12, x12, #3
  0x0000000102f1bb14:   ldr	w12, [x12, #36]
  0x0000000102f1bb18:   lsl	x12, x12, #3
  0x0000000102f1bb1c:   ldr	x12, [x12, #16]
  0x0000000102f1bb20:   cbz	x12, 0x0000000102f1bb2c
  0x0000000102f1bb24:   ldr	x8, [x12, #64]
  0x0000000102f1bb28:   br	x8
  0x0000000102f1bb2c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38666   44     n       java.lang.invoke.MethodHandle::linkToSpecial(LJLJLL)J (native)
 total in heap  [0x0000000102f1b388,0x0000000102f1b4a8] = 288
 relocation     [0x0000000102f1b460,0x0000000102f1b468] = 8
 main code      [0x0000000102f1b480,0x0000000102f1b4a4] = 36
 stub code      [0x0000000102f1b4a4,0x0000000102f1b4a8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d11a0} 'linkToSpecial' '(Ljava/lang/Object;JLjava/lang/Object;JLjava/lang/Object;Ljava/lang/invoke/MemberName;)J' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = long
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = long
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/Object'
  # parm5:    c_rarg6:c_rarg6 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1b480:   nop
  0x0000000102f1b484:   ldr	xzr, [x1]
  0x0000000102f1b488:   ldr	w12, [x6, #36]
  0x0000000102f1b48c:   lsl	x12, x12, #3
  0x0000000102f1b490:   ldr	x12, [x12, #16]
  0x0000000102f1b494:   cbz	x12, 0x0000000102f1b4a0
  0x0000000102f1b498:   ldr	x8, [x12, #64]
  0x0000000102f1b49c:   br	x8
  0x0000000102f1b4a0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f1b4a4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38668   45     n       java.lang.invoke.MethodHandle::invokeBasic(JLJ)J (native)
 total in heap  [0x0000000102f1a988,0x0000000102f1aab0] = 296
 relocation     [0x0000000102f1aa60,0x0000000102f1aa68] = 8
 main code      [0x0000000102f1aa80,0x0000000102f1aab0] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d14c8} 'invokeBasic' '(JLjava/lang/Object;J)J' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = long
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4 
                        = long
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1aa80:   nop
  0x0000000102f1aa84:   ldr	w12, [x1, #20]
  0x0000000102f1aa88:   lsl	x12, x12, #3
  0x0000000102f1aa8c:   ldr	w12, [x12, #40]
  0x0000000102f1aa90:   lsl	x12, x12, #3
  0x0000000102f1aa94:   ldr	w12, [x12, #36]
  0x0000000102f1aa98:   lsl	x12, x12, #3
  0x0000000102f1aa9c:   ldr	x12, [x12, #16]
  0x0000000102f1aaa0:   cbz	x12, 0x0000000102f1aaac
  0x0000000102f1aaa4:   ldr	x8, [x12, #64]
  0x0000000102f1aaa8:   br	x8
  0x0000000102f1aaac:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38668   46     n       java.lang.invoke.MethodHandle::linkToSpecial(LJLJL)J (native)
 total in heap  [0x0000000102f1a688,0x0000000102f1a7a8] = 288
 relocation     [0x0000000102f1a760,0x0000000102f1a768] = 8
 main code      [0x0000000102f1a780,0x0000000102f1a7a4] = 36
 stub code      [0x0000000102f1a7a4,0x0000000102f1a7a8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d15e0} 'linkToSpecial' '(Ljava/lang/Object;JLjava/lang/Object;JLjava/lang/invoke/MemberName;)J' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = long
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = long
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1a780:   nop
  0x0000000102f1a784:   ldr	xzr, [x1]
  0x0000000102f1a788:   ldr	w12, [x5, #36]
  0x0000000102f1a78c:   lsl	x12, x12, #3
  0x0000000102f1a790:   ldr	x12, [x12, #16]
  0x0000000102f1a794:   cbz	x12, 0x0000000102f1a7a0
  0x0000000102f1a798:   ldr	x8, [x12, #64]
  0x0000000102f1a79c:   br	x8
  0x0000000102f1a7a0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f1a7a4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38669   47     n       java.lang.invoke.MethodHandle::linkToStatic(JL)L (native)
 total in heap  [0x0000000102f1a008,0x0000000102f1a120] = 280
 relocation     [0x0000000102f1a0e0,0x0000000102f1a0e8] = 8
 main code      [0x0000000102f1a100,0x0000000102f1a120] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d1910} 'linkToStatic' '(JLjava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = long
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1a100:   nop
  0x0000000102f1a104:   ldr	w12, [x2, #36]
  0x0000000102f1a108:   lsl	x12, x12, #3
  0x0000000102f1a10c:   ldr	x12, [x12, #16]
  0x0000000102f1a110:   cbz	x12, 0x0000000102f1a11c
  0x0000000102f1a114:   ldr	x8, [x12, #64]
  0x0000000102f1a118:   br	x8
  0x0000000102f1a11c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38670   48     n       java.lang.invoke.MethodHandle::invokeBasic(J)L (native)
 total in heap  [0x0000000102f19d08,0x0000000102f19e30] = 296
 relocation     [0x0000000102f19de0,0x0000000102f19de8] = 8
 main code      [0x0000000102f19e00,0x0000000102f19e30] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d1b18} 'invokeBasic' '(J)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = long
  #           [sp+0x0]  (sp of caller)
  0x0000000102f19e00:   nop
  0x0000000102f19e04:   ldr	w12, [x1, #20]
  0x0000000102f19e08:   lsl	x12, x12, #3
  0x0000000102f19e0c:   ldr	w12, [x12, #40]
  0x0000000102f19e10:   lsl	x12, x12, #3
  0x0000000102f19e14:   ldr	w12, [x12, #36]
  0x0000000102f19e18:   lsl	x12, x12, #3
  0x0000000102f19e1c:   ldr	x12, [x12, #16]
  0x0000000102f19e20:   cbz	x12, 0x0000000102f19e2c
  0x0000000102f19e24:   ldr	x8, [x12, #64]
  0x0000000102f19e28:   br	x8
  0x0000000102f19e2c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38670   49     n       java.lang.invoke.MethodHandle::linkToSpecial(LJL)L (native)
 total in heap  [0x0000000102f19a08,0x0000000102f19b28] = 288
 relocation     [0x0000000102f19ae0,0x0000000102f19ae8] = 8
 main code      [0x0000000102f19b00,0x0000000102f19b24] = 36
 stub code      [0x0000000102f19b24,0x0000000102f19b28] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d1c30} 'linkToSpecial' '(Ljava/lang/Object;JLjava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = long
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f19b00:   nop
  0x0000000102f19b04:   ldr	xzr, [x1]
  0x0000000102f19b08:   ldr	w12, [x3, #36]
  0x0000000102f19b0c:   lsl	x12, x12, #3
  0x0000000102f19b10:   ldr	x12, [x12, #16]
  0x0000000102f19b14:   cbz	x12, 0x0000000102f19b20
  0x0000000102f19b18:   ldr	x8, [x12, #64]
  0x0000000102f19b1c:   br	x8
  0x0000000102f19b20:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f19b24:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38671   50     n       java.lang.invoke.MethodHandle::linkToStatic(JJL)J (native)
 total in heap  [0x0000000102f19588,0x0000000102f196a0] = 280
 relocation     [0x0000000102f19660,0x0000000102f19668] = 8
 main code      [0x0000000102f19680,0x0000000102f196a0] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d1dd8} 'linkToStatic' '(JJLjava/lang/invoke/MemberName;)J' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = long
  # parm1:    c_rarg2:c_rarg2 
                        = long
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f19680:   nop
  0x0000000102f19684:   ldr	w12, [x3, #36]
  0x0000000102f19688:   lsl	x12, x12, #3
  0x0000000102f1968c:   ldr	x12, [x12, #16]
  0x0000000102f19690:   cbz	x12, 0x0000000102f1969c
  0x0000000102f19694:   ldr	x8, [x12, #64]
  0x0000000102f19698:   br	x8
  0x0000000102f1969c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38671   51     n       java.lang.invoke.MethodHandle::invokeBasic(JJ)J (native)
 total in heap  [0x0000000102f1d588,0x0000000102f1d6b0] = 296
 relocation     [0x0000000102f1d660,0x0000000102f1d668] = 8
 main code      [0x0000000102f1d680,0x0000000102f1d6b0] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d1ef0} 'invokeBasic' '(JJ)J' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = long
  # parm1:    c_rarg3:c_rarg3 
                        = long
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1d680:   nop
  0x0000000102f1d684:   ldr	w12, [x1, #20]
  0x0000000102f1d688:   lsl	x12, x12, #3
  0x0000000102f1d68c:   ldr	w12, [x12, #40]
  0x0000000102f1d690:   lsl	x12, x12, #3
  0x0000000102f1d694:   ldr	w12, [x12, #36]
  0x0000000102f1d698:   lsl	x12, x12, #3
  0x0000000102f1d69c:   ldr	x12, [x12, #16]
  0x0000000102f1d6a0:   cbz	x12, 0x0000000102f1d6ac
  0x0000000102f1d6a4:   ldr	x8, [x12, #64]
  0x0000000102f1d6a8:   br	x8
  0x0000000102f1d6ac:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38672   52     n       java.lang.invoke.MethodHandle::linkToSpecial(LJJL)J (native)
 total in heap  [0x0000000102f1d888,0x0000000102f1d9a8] = 288
 relocation     [0x0000000102f1d960,0x0000000102f1d968] = 8
 main code      [0x0000000102f1d980,0x0000000102f1d9a4] = 36
 stub code      [0x0000000102f1d9a4,0x0000000102f1d9a8] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d2008} 'linkToSpecial' '(Ljava/lang/Object;JJLjava/lang/invoke/MemberName;)J' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = long
  # parm2:    c_rarg3:c_rarg3 
                        = long
  # parm3:    c_rarg4:c_rarg4 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1d980:   nop
  0x0000000102f1d984:   ldr	xzr, [x1]
  0x0000000102f1d988:   ldr	w12, [x4, #36]
  0x0000000102f1d98c:   lsl	x12, x12, #3
  0x0000000102f1d990:   ldr	x12, [x12, #16]
  0x0000000102f1d994:   cbz	x12, 0x0000000102f1d9a0
  0x0000000102f1d998:   ldr	x8, [x12, #64]
  0x0000000102f1d99c:   br	x8
  0x0000000102f1d9a0:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f1d9a4:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38698   53     n       java.lang.invoke.MethodHandle::linkToStatic(LLLJL)L (native)
 total in heap  [0x0000000102f1df08,0x0000000102f1e020] = 280
 relocation     [0x0000000102f1dfe0,0x0000000102f1dfe8] = 8
 main code      [0x0000000102f1e000,0x0000000102f1e020] = 32

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d3a80} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;JLjava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4 
                        = long
  # parm4:    c_rarg5:c_rarg5 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1e000:   nop
  0x0000000102f1e004:   ldr	w12, [x5, #36]
  0x0000000102f1e008:   lsl	x12, x12, #3
  0x0000000102f1e00c:   ldr	x12, [x12, #16]
  0x0000000102f1e010:   cbz	x12, 0x0000000102f1e01c
  0x0000000102f1e014:   ldr	x8, [x12, #64]
  0x0000000102f1e018:   br	x8
  0x0000000102f1e01c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38699   54     n       java.lang.invoke.MethodHandle::invokeBasic(LLLJ)L (native)
 total in heap  [0x0000000102f1e208,0x0000000102f1e330] = 296
 relocation     [0x0000000102f1e2e0,0x0000000102f1e2e8] = 8
 main code      [0x0000000102f1e300,0x0000000102f1e330] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d3bc8} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;J)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3 
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4 
                        = 'java/lang/Object'
  # parm3:    c_rarg5:c_rarg5 
                        = long
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1e300:   nop
  0x0000000102f1e304:   ldr	w12, [x1, #20]
  0x0000000102f1e308:   lsl	x12, x12, #3
  0x0000000102f1e30c:   ldr	w12, [x12, #40]
  0x0000000102f1e310:   lsl	x12, x12, #3
  0x0000000102f1e314:   ldr	w12, [x12, #36]
  0x0000000102f1e318:   lsl	x12, x12, #3
  0x0000000102f1e31c:   ldr	x12, [x12, #16]
  0x0000000102f1e320:   cbz	x12, 0x0000000102f1e32c
  0x0000000102f1e324:   ldr	x8, [x12, #64]
  0x0000000102f1e328:   br	x8
  0x0000000102f1e32c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38702   55     n       java.lang.invoke.MethodHandle::invokeBasic(J)J (native)
 total in heap  [0x0000000102f1e508,0x0000000102f1e630] = 296
 relocation     [0x0000000102f1e5e0,0x0000000102f1e5e8] = 8
 main code      [0x0000000102f1e600,0x0000000102f1e630] = 48

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d4b48} 'invokeBasic' '(J)J' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1 
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2 
                        = long
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1e600:   nop
  0x0000000102f1e604:   ldr	w12, [x1, #20]
  0x0000000102f1e608:   lsl	x12, x12, #3
  0x0000000102f1e60c:   ldr	w12, [x12, #40]
  0x0000000102f1e610:   lsl	x12, x12, #3
  0x0000000102f1e614:   ldr	w12, [x12, #36]
  0x0000000102f1e618:   lsl	x12, x12, #3
  0x0000000102f1e61c:   ldr	x12, [x12, #16]
  0x0000000102f1e620:   cbz	x12, 0x0000000102f1e62c
  0x0000000102f1e624:   ldr	x8, [x12, #64]
  0x0000000102f1e628:   br	x8
  0x0000000102f1e62c:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 38702   56     n       java.lang.invoke.MethodHandle::linkToSpecial(LJL)J (native)
 total in heap  [0x0000000102f1e808,0x0000000102f1e928] = 288
 relocation     [0x0000000102f1e8e0,0x0000000102f1e8e8] = 8
 main code      [0x0000000102f1e900,0x0000000102f1e924] = 36
 stub code      [0x0000000102f1e924,0x0000000102f1e928] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011c7d5010} 'linkToSpecial' '(Ljava/lang/Object;JLjava/lang/invoke/MemberName;)J' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1 
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2 
                        = long
  # parm2:    c_rarg3:c_rarg3 
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x0000000102f1e900:   nop
  0x0000000102f1e904:   ldr	xzr, [x1]
  0x0000000102f1e908:   ldr	w12, [x3, #36]
  0x0000000102f1e90c:   lsl	x12, x12, #3
  0x0000000102f1e910:   ldr	x12, [x12, #16]
  0x0000000102f1e914:   cbz	x12, 0x0000000102f1e920
  0x0000000102f1e918:   ldr	x8, [x12, #64]
  0x0000000102f1e91c:   br	x8
  0x0000000102f1e920:   b	0x0000000102e9e080          ;   {runtime_call AbstractMethodError throw_exception}
[Stub Code]
  0x0000000102f1e924:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]
Process finished with exit code 0

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2160211224

From pminborg at openjdk.org  Tue Jun 11 09:21:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 11 Jun 2024 09:21:13 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory.
In-Reply-To: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
Message-ID: <0jfjAQxqikBm-E8yJO_M6vVzKrnQWwdrYu29P8ihJg8=.2cfd2e88-19b3-4360-97a8-4eef33bd0cb9@github.com>

On Mon, 10 Jun 2024 15:45:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to explicitly state that returned segments form the `asSlice` and `reinterpret` method share memory regions with `this` memory segment.
> 
> Note: The term "subset"  means a true subset or the same set.

> In my opinion, any 'sub' terminology is misleading since, as you pointed out, one can (and often will) `reinterpret` to a _larger_ size. Wouldn't something like, "The returned memory segment is backed by the same region of memory that backs this memory segment", be sufficiently accurate? Could even append, "No memory will be allocated or deallocated", to really hammer the point home.
> 
> Using 'subset' for `asSlice` makes sense. Though possibly unnecessary.

If a segment is reinterpreted to be *larger* than `this` segment, then the extra memory is not a part of `this` segment's backing part. So, in this case the total memory is a subset (but not a _proper subset_ but rather the same) of `this` backing memory _plus_ some additional memory.

If a segment is reinterpreted to be *smaller* than `this` segment, then the reduced memory is a proper subset.

So, strictly the proposed text is correct. The proposition "The returned memory segment is backed by the same region of memory that backs this memory segment" appears to be incorrect if a _smaller_ chunk is carved out?

Maybe something more neutral like "The returned memory segment shares a region of backing memory with this segment"?

Adding text similar to "No memory will be allocated or deallocated" sounds like a good idea.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19633#issuecomment-2160213978

From epeter at openjdk.org  Tue Jun 11 09:37:12 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 11 Jun 2024 09:37:12 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <3Glk5fqUv6mOnaBeQZIMctUDhZzASCQEf4VNpTaEfvE=.ee098533-80c0-4bc1-8ae1-c8551b2c9ac6@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>
 <9_OMKYvdx-xW6KC3sKovIYawgaRZfkKyvU97jcuskzM=.484f62c9-521c-47b5-a68a-6abc89c0e768@github.com>
 <IM4whi_rK2qmJJfMCziFoep3XRyO1vuHugTkm8IUqtc=.a23c747f-e2c3-40fd-90d3-f7bfb01bb96b@github.com>
 <lNywbhbLV4eOITvagu4FwP6PWuFE7_F7XYJf0eK275E=.3d554081-7fdf-48d1-94b0-393590290492@github.com>
 <3Glk5fqUv6mOnaBeQZIMctUDhZzASCQEf4VNpTaEfvE=.ee098533-80c0-4bc1-8ae1-c8551b2c9ac6@github.com>
Message-ID: <XMGmFmOQwkC32zOEMFPiFxtBWB40vA9dlOo3a8HIYs0=.f8f9c6a0-876f-49c8-9c72-094d5f4dc15d@github.com>

On Tue, 11 Jun 2024 09:17:00 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> @wenshao 
>>> @eme64 It seems that when the following code uses StringUTF16.putChar, C2's optimization is not as good as the manual merging and storage effect.
>> 
>> As I asked above, you will need to provide some evidence / generated assembly / perf data, and logs from `TraceMergeStores`. I currently do not have time to produce these myself, and I think they would be crucial to determine where the missing performance has gone. See my earlier comment:
>> https://github.com/openjdk/jdk/pull/19626#issuecomment-2158533469
>> 
>> And please also try @cl4es advide here:
>> https://github.com/openjdk/jdk/pull/19626#issuecomment-2159509806
>> 
>> And sure, maybe you need some public API for setting multiple bytes at once, which the `MergeStores` optimization can optimize. I'm a C2 engineer, so I leave that up to the library folks ;)
>
> @eme64 The assembly information is below, can you take a look and see if it can help you diagnose the problem?
> 
> * JavaCode
> 
> class AbstractStringBuilder {
>      private AbstractStringBuilder appendNull() {
>         int count = this.count;
>         ensureCapacityInternal(count + 4);
>         byte[] val = this.value;
>         if (isLatin1()) {
>             val[count    ] = 'n';
>             val[count + 1] = 'u';
>             val[count + 2] = 'l';
>             val[count + 3] = 'l';
>         } else {
>             StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
>         }
>         this.count = count + 4;
>         return this;
>     }
> }
> 
> class StringUTF16 {
>     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>         putChar(value, i    , c1);
>         putChar(value, i + 1, c2);
>         putChar(value, i + 2, c3);
>         putChar(value, i + 3, c4);
>     }
> }
> 
> 
> * Apple M1 StringBuilder.appendNull PrintAssembly
> 
> /Users/wenshao/Work/git/jdk/build/macosx-aarch64-server-release/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=compileonly,*StringBuilder.appendNull -XX:-TieredCompilation -XX:TieredStopAtLevel=4 -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=61041:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 ....
> 
> Compiled method (n/a) 96    1     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLLLL)L (native)
>  total in heap  [0x0000000102efba08,0x0000000102efbb20] = 280
>  relocation     [0x0000000102efbae0,0x0000000102efbae8] = 8
>  main code      [0x0000000102efbb00,0x0000000102efbb20] = 32
> 
> [Disassembly]
> --------------------------------------------------------------------------------
> [Constant Pool (empty)]
> 
> --------------------------------------------------------------------------------
> 
> [Verified Entry Point]
>   # {method} {0x000000011c3e1c80} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
>   # parm0:    c_rarg1:c_rarg1 
>                         = 'java/lang/Object'
>   # parm1:    c_rarg2:c_rarg2 
>                         = 'java/lang/Object'
>   # parm2:    c_rarg3:c_rarg3 
>                         = 'java/lang/Object'
>   # parm3:    c_rarg4:c_rarg4 
>                         = 'java/lang/Object'
>   # parm4:    c_rarg5:c_rarg5 
>                         = 'j...

@wenshao This is just an assembly dump. You need to have some profiling data that tells you where the time is spent. I'm not going to do the analysis work for you, I'm sorry. I gave you some pointers as how to do that. If you have more questions about how to do that, feel free to ask. You also have not provided the `TraceMergeStores` log yet, as I asked you.

Can you investigate WHY there is a performance difference? Which `loads` and `branches` etc are generated?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2160251736

From duke at openjdk.org  Tue Jun 11 09:42:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 11 Jun 2024 09:42:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <XMGmFmOQwkC32zOEMFPiFxtBWB40vA9dlOo3a8HIYs0=.f8f9c6a0-876f-49c8-9c72-094d5f4dc15d@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>
 <9_OMKYvdx-xW6KC3sKovIYawgaRZfkKyvU97jcuskzM=.484f62c9-521c-47b5-a68a-6abc89c0e768@github.com>
 <IM4whi_rK2qmJJfMCziFoep3XRyO1vuHugTkm8IUqtc=.a23c747f-e2c3-40fd-90d3-f7bfb01bb96b@github.com>
 <lNywbhbLV4eOITvagu4FwP6PWuFE7_F7XYJf0eK275E=.3d554081-7fdf-48d1-94b0-393590290492@github.com>
 <3Glk5fqUv6mOnaBeQZIMctUDhZzASCQEf4VNpTaEfvE=.ee098533-80c0-4bc1-8ae1-c8551b2c9ac6@github.com>
 <XMGmFmOQwkC32zOEMFPiFxtBWB40vA9dlOo3a8HIYs0=.f8f9c6a0-876f-49c8-9c72-094d5f4dc15d@github.com>
Message-ID: <muLEOgXh9sfJWdMO2FBis0GJyfiDjp-1t-OWAeZLvTE=.e7ec5275-a611-4605-8eb9-44cafb17ce65@github.com>

On Tue, 11 Jun 2024 09:32:14 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 The assembly information is below, can you take a look and see if it can help you diagnose the problem?
>> 
>> * JavaCode
>> 
>> class AbstractStringBuilder {
>>      private AbstractStringBuilder appendNull() {
>>         int count = this.count;
>>         ensureCapacityInternal(count + 4);
>>         byte[] val = this.value;
>>         if (isLatin1()) {
>>             val[count    ] = 'n';
>>             val[count + 1] = 'u';
>>             val[count + 2] = 'l';
>>             val[count + 3] = 'l';
>>         } else {
>>             StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
>>         }
>>         this.count = count + 4;
>>         return this;
>>     }
>> }
>> 
>> class StringUTF16 {
>>     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>>         putChar(value, i    , c1);
>>         putChar(value, i + 1, c2);
>>         putChar(value, i + 2, c3);
>>         putChar(value, i + 3, c4);
>>     }
>> }
>> 
>> 
>> * Apple M1 StringBuilder.appendNull PrintAssembly
>> 
>> /Users/wenshao/Work/git/jdk/build/macosx-aarch64-server-release/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=compileonly,*StringBuilder.appendNull -XX:-TieredCompilation -XX:TieredStopAtLevel=4 -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=61041:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 ....
>> 
>> Compiled method (n/a) 96    1     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLLLL)L (native)
>>  total in heap  [0x0000000102efba08,0x0000000102efbb20] = 280
>>  relocation     [0x0000000102efbae0,0x0000000102efbae8] = 8
>>  main code      [0x0000000102efbb00,0x0000000102efbb20] = 32
>> 
>> [Disassembly]
>> --------------------------------------------------------------------------------
>> [Constant Pool (empty)]
>> 
>> --------------------------------------------------------------------------------
>> 
>> [Verified Entry Point]
>>   # {method} {0x000000011c3e1c80} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
>>   # parm0:    c_rarg1:c_rarg1 
>>                         = 'java/lang/Object'
>>   # parm1:    c_rarg2:c_rarg2 
>>                         = 'java/lang/Object'
>>   # parm2:    c_rarg3:c_rarg3 
>>                         = 'java/lang/Object'
>>   # parm3:    c_rarg4:c...
>
> @wenshao This is just an assembly dump. You need to have some profiling data that tells you where the time is spent. I'm not going to do the analysis work for you, I'm sorry. I gave you some pointers as how to do that. If you have more questions about how to do that, feel free to ask. You also have not provided the `TraceMergeStores` log yet, as I asked you.
> 
> Can you investigate WHY there is a performance difference? Which `loads` and `branches` etc are generated?

@eme64 How to TraceMergeStores?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2160275514

From epeter at openjdk.org  Tue Jun 11 09:46:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 11 Jun 2024 09:46:24 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
In-Reply-To: <muLEOgXh9sfJWdMO2FBis0GJyfiDjp-1t-OWAeZLvTE=.e7ec5275-a611-4605-8eb9-44cafb17ce65@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <uAFe_nxV1lchLlZgtgiE2uT9zO6DtDuwWtKEpjPQW7o=.05fc790c-8ab5-4edc-8040-d65ebe67f6f0@github.com>
 <9_OMKYvdx-xW6KC3sKovIYawgaRZfkKyvU97jcuskzM=.484f62c9-521c-47b5-a68a-6abc89c0e768@github.com>
 <IM4whi_rK2qmJJfMCziFoep3XRyO1vuHugTkm8IUqtc=.a23c747f-e2c3-40fd-90d3-f7bfb01bb96b@github.com>
 <lNywbhbLV4eOITvagu4FwP6PWuFE7_F7XYJf0eK275E=.3d554081-7fdf-48d1-94b0-393590290492@github.com>
 <3Glk5fqUv6mOnaBeQZIMctUDhZzASCQEf4VNpTaEfvE=.ee098533-80c0-4bc1-8ae1-c8551b2c9ac6@github.com>
 <XMGmFmOQwkC32zOEMFPiFxtBWB40vA9dlOo3a8HIYs0=.f8f9c6a0-876f-49c8-9c72-094d5f4dc15d@github.com>
 <muLEOgXh9sfJWdMO2FBis0GJyfiDjp-1t-OWAeZLvTE=.e7ec5275-a611-4605-8eb9-44cafb17ce65@github.com>
Message-ID: <AGmCXE7NCZ0repArAlEMmWprOwtYsmeM6IxoO7aIsq8=.a5e74630-3842-4177-84ab-c1beb0b74715@github.com>

On Tue, 11 Jun 2024 09:39:29 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> @wenshao This is just an assembly dump. You need to have some profiling data that tells you where the time is spent. I'm not going to do the analysis work for you, I'm sorry. I gave you some pointers as how to do that. If you have more questions about how to do that, feel free to ask. You also have not provided the `TraceMergeStores` log yet, as I asked you.
>> 
>> Can you investigate WHY there is a performance difference? Which `loads` and `branches` etc are generated?
>
> @eme64 How to TraceMergeStores?

@wenshao Have you grepped it in the code base?
`grep TraceMergeStores src/hotspot/share/ -r`
Hence, use enable flag with `-XX:+TraceMergeStores`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2160285500

From epeter at openjdk.org  Tue Jun 11 09:53:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 11 Jun 2024 09:53:17 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v3]
In-Reply-To: <O8qE6Q52X9n2dUuj-sbcg22kFkpO6oFlkP84z0F3vMI=.4f06d485-f3f7-4a8b-a537-a816405ce18c@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <O8qE6Q52X9n2dUuj-sbcg22kFkpO6oFlkP84z0F3vMI=.4f06d485-f3f7-4a8b-a537-a816405ce18c@github.com>
Message-ID: <hgybFh7PjN_jYdpzoHxQ-9q2hThgHlPSmvyQ6EJrnIM=.e82f609d-3032-4684-a3dc-69aef80f2b94@github.com>

On Tue, 11 Jun 2024 05:42:27 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix

Also: the assembly that you pasted: does it have the original stores, or do you see that the stores were actually merged?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2160305076

From jvernee at openjdk.org  Tue Jun 11 10:14:12 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Jun 2024 10:14:12 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory.
In-Reply-To: <0jfjAQxqikBm-E8yJO_M6vVzKrnQWwdrYu29P8ihJg8=.2cfd2e88-19b3-4360-97a8-4eef33bd0cb9@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
 <0jfjAQxqikBm-E8yJO_M6vVzKrnQWwdrYu29P8ihJg8=.2cfd2e88-19b3-4360-97a8-4eef33bd0cb9@github.com>
Message-ID: <uepPQOTzncu74Gdnb8xjzbeNxaII8NyzSGsJBN4Jeig=.05f32a71-7d2b-4409-8286-05df589a6e50@github.com>

On Tue, 11 Jun 2024 09:18:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> If a segment is reinterpreted to be larger than this segment, then the extra memory is not a part of this segment's backing part.

Another way to think about this is: a segment's backing region can be larger or smaller than the bounds specified by the segment itself. Though, in most cases they are the same. For example, If we allocate 10 bytes of memory in native code, and return it to the Java side, I'd argue that the backing region of the memory segment we get back is still 10 bytes in size, even though the `byteSize()` of the memory segment is `0`. `reinterpret` can be used to adjust the size of the _segment_, but it doesn't change the size of the underlying memory region, which remains 10 bytes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19633#issuecomment-2160359044

From prappo at openjdk.org  Tue Jun 11 11:06:17 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Jun 2024 11:06:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
Message-ID: <zuNDuUKk1vjisadTmYy9ejFqSmDKWLvKoFY-umQC7IU=.20b7ac6e-a91a-4c13-8c2d-17d2d23002be@github.com>

On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double quotes

I was asked to have a look at this PR elsewhere. I cannot verify correctness of translation, but I can review this PR generally for `jdk.javadoc`.

>From what I can see, the changes are only to the property files, which is expected from the PR title. The keys from English files 1-1 match the keys from non-English files: there are no missing or extra keys.

>From that point of view, the changes to `jdk.javadoc` look good.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2110098592

From duke at openjdk.org  Tue Jun 11 11:35:28 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 11 Jun 2024 11:35:28 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  revert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/f96cde4e..27a3050a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=02-03

  Stats: 18 lines in 1 file changed: 0 ins; 9 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From duke at openjdk.org  Tue Jun 11 12:14:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 11 Jun 2024 12:14:14 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <sLLwY_A95pj3a62IYg3HTO7Lw6tI1SwF4qb4CT0mz10=.81db16a6-4e17-4d8b-b694-2b19605e5965@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

([f96cde4e](https://git.openjdk.org/jdk/pull/19626/files/f96cde4e79e12e2ea46e6061f918a69f11d59985)) ([0cbaa5ac](https://git.openjdk.org/jdk/pull/19626/files/0cbaa5ac04873373131f1a7216353a5af5b3e48e)) The previous overriding of StringUTF16.putChar method did not improve performance, so I reverted to the original version.

I have collected information on TraceMergeStores, but I don't have enough knowledge to analyze it yet

https://github.com/wenshao/jdk/wiki/pr19626_appendNull_0

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2160603791

From pminborg at openjdk.org  Tue Jun 11 12:22:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 11 Jun 2024 12:22:24 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory. [v2]
In-Reply-To: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
Message-ID: <U7LP04StNxz9s8Lvk9Zbi67dV-xBaT5_4XpcY66ab6k=.08dab1f4-a697-4298-ac7b-cde0eccf0552@github.com>

> This PR proposes to explicitly state that returned segments form the `asSlice` and `reinterpret` method share memory regions with `this` memory segment.
> 
> Note: The term "subset"  means a true subset or the same set.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Change wording in doc updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19633/files
  - new: https://git.openjdk.org/jdk/pull/19633/files/6cde00c8..13f33e65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19633&range=00-01

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/19633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19633/head:pull/19633

PR: https://git.openjdk.org/jdk/pull/19633

From jvernee at openjdk.org  Tue Jun 11 12:26:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Jun 2024 12:26:11 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory. [v2]
In-Reply-To: <U7LP04StNxz9s8Lvk9Zbi67dV-xBaT5_4XpcY66ab6k=.08dab1f4-a697-4298-ac7b-cde0eccf0552@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
 <U7LP04StNxz9s8Lvk9Zbi67dV-xBaT5_4XpcY66ab6k=.08dab1f4-a697-4298-ac7b-cde0eccf0552@github.com>
Message-ID: <CglBCD3dwGUUoJSJ0k4Igl_9qe8sJG0vkGcl__X5Rgo=.69715f3b-526d-4041-b7dc-8c778ad8f1f5@github.com>

On Tue, 11 Jun 2024 12:22:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to explicitly state that returned segments form the `asSlice` and `reinterpret` method share memory regions with `this` memory segment.
>> 
>> Note: The term "subset"  means a true subset or the same set.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change wording in doc updates

Latest version looks good to me.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19633#pullrequestreview-2110281525

From jpai at openjdk.org  Tue Jun 11 13:13:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Jun 2024 13:13:33 GMT
Subject: RFR: 8222884: ConcurrentClassDescLookup.java times out intermittently
Message-ID: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>

Can I please get a review of this test-only change which proposes to address intermittent failures in `test/jdk/java/io/Serializable/concurrentClassDescLookup/ConcurrentClassDescLookup.java`?

This addresses https://bugs.openjdk.org/browse/JDK-8222884. As noted in that issue, the test in its current form has a potential race. The test main thread launches 50 "successful lookup" tasks and 50 "failed lookup" tasks. Each task is a `Thread`. The test passes an `Object` instance shared by 50 of these tasks and each task when it starts execution in its `run()` method does a `wait()` on that `Object` instance. The test main thread then after launching 50 tasks, sleeps for a second (to let the 50 `Thread`s start execution and arrive at the `Object.wait()`) and then after waking up the main thread does a `notifyAll()` on that `Object` instance. In theory and likely in practice too, it's possible that (especially) for the last batch of 50 tasks (the "failing lookup" tasks), the `notifyAll()` might end up getting invoked before one or more task Thread(s) have actually done a `wait()`. That can then mean that one or more task `Thread`(s) will keep `wait()`ing indefinitely with no one 
 `notify()`ing the `Object` instance to proceed with the task execution.

The commit in this PR removes the use of `Object.wait()/notifyAll()` and instead uses a `CountdownLatch` to allow for a more deterministic barrier. The test continues to pass with this change. Additionally, this change was run against a CI setup, by Matthias, where it was previously failing intermittently. Matthias reports that it hasn't failed after this change.

-------------

Commit messages:
 - 8222884: ConcurrentClassDescLookup.java times out intermittently

Changes: https://git.openjdk.org/jdk/pull/19659/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19659&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8222884
  Stats: 36 lines in 1 file changed: 7 ins; 7 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19659.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19659/head:pull/19659

PR: https://git.openjdk.org/jdk/pull/19659

From kevinw at openjdk.org  Tue Jun 11 13:28:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 13:28:33 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal
Message-ID: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>

jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.

RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.

The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

-------------

Commit messages:
 - Remove tmp file
 - Annotations
 - Annotations
 - Merge remote-tracking branch 'upstream/master' into 8327793_jstatd_deprecate
 - Basic deprecation of module, jstatd prints warning.

Changes: https://git.openjdk.org/jdk/pull/19658/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327793
  Stats: 35 lines in 12 files changed: 23 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/19658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19658/head:pull/19658

PR: https://git.openjdk.org/jdk/pull/19658

From alanb at openjdk.org  Tue Jun 11 13:38:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jun 2024 13:38:12 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal
In-Reply-To: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
Message-ID: <TENQc1MzLc7pK_lsZ3sjsZAC7pckcqOGaorSt15ttzU=.8b00fe1f-8b7b-4333-934a-eeb6452699ad@github.com>

On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
> 
> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

The sun.jvmstat.monitor.remote package is not exported so I don't think adding `@Deprecated` makes sense. 

Look at JDK-8245068 when rmid was deprecated and see the warning that it printed. I think it's the warning piece that you'll need here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2160786798

From rriggs at openjdk.org  Tue Jun 11 13:48:11 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Jun 2024 13:48:11 GMT
Subject: RFR: 8222884: ConcurrentClassDescLookup.java times out
 intermittently
In-Reply-To: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>
References: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>
Message-ID: <CyJRxAD7SazG7H0xRCptltR1i7vMhZG5zTIINnQFTIU=.c1c04a74-18eb-4728-97cf-6eb0e3023dad@github.com>

On Tue, 11 Jun 2024 13:09:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address intermittent failures in `test/jdk/java/io/Serializable/concurrentClassDescLookup/ConcurrentClassDescLookup.java`?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8222884. As noted in that issue, the test in its current form has a potential race. The test main thread launches 50 "successful lookup" tasks and 50 "failed lookup" tasks. Each task is a `Thread`. The test passes an `Object` instance shared by 50 of these tasks and each task when it starts execution in its `run()` method does a `wait()` on that `Object` instance. The test main thread then after launching 50 tasks, sleeps for a second (to let the 50 `Thread`s start execution and arrive at the `Object.wait()`) and then after waking up the main thread does a `notifyAll()` on that `Object` instance. In theory and likely in practice too, it's possible that (especially) for the last batch of 50 tasks (the "failing lookup" tasks), the `notifyAll()` might end up getting invoked before one or more task Thread(s) have actually done a `wait()`. That can then mean that one or more task `Thread`(s) will keep `wait()`ing indefinitely with no on
 e `notify()`ing the `Object` instance to proceed with the task execution.
> 
> The commit in this PR removes the use of `Object.wait()/notifyAll()` and instead uses a `CountdownLatch` to allow for a more deterministic barrier. The test continues to pass with this change. Additionally, this change was run against a CI setup, by Matthias, where it was previously failing intermittently. Matthias reports that it hasn't failed after this change.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19659#pullrequestreview-2110524082

From mcimadamore at openjdk.org  Tue Jun 11 14:00:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 11 Jun 2024 14:00:13 GMT
Subject: RFR: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory. [v2]
In-Reply-To: <U7LP04StNxz9s8Lvk9Zbi67dV-xBaT5_4XpcY66ab6k=.08dab1f4-a697-4298-ac7b-cde0eccf0552@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
 <U7LP04StNxz9s8Lvk9Zbi67dV-xBaT5_4XpcY66ab6k=.08dab1f4-a697-4298-ac7b-cde0eccf0552@github.com>
Message-ID: <5vQLwoNm3gJL2TY8l1ntFiDJqmiyJ4BHPRGIcxgkkA4=.af72459c-e839-4b31-af87-787e6dba212f@github.com>

On Tue, 11 Jun 2024 12:22:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to explicitly state that returned segments form the `asSlice` and `reinterpret` method share memory regions with `this` memory segment.
>> 
>> Note: The term "subset"  means a true subset or the same set.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change wording in doc updates

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19633#pullrequestreview-2110560144

From mullan at openjdk.org  Tue Jun 11 14:08:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Jun 2024 14:08:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v2]
In-Reply-To: <KSfvEpU3M549RiJQk2XxvhO9YygBORGTxOz4S-uyG18=.413cd464-0762-4490-8597-7d78baaede7d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <KSfvEpU3M549RiJQk2XxvhO9YygBORGTxOz4S-uyG18=.413cd464-0762-4490-8597-7d78baaede7d@github.com>
Message-ID: <XkkTDAn9-sZDr-0Z1t7G7_Gg5YJdsy6CD_Uqu8HztXs=.ae4dbf01-fd6b-47a1-b8ba-6e154f5e1288@github.com>

On Mon, 10 Jun 2024 16:52:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent style of calls and comments.

A couple of comments so far; still reviewing.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 36:

> 34:  * @run main NotificationEmissionTest 1
> 35: 
> 36:  * @run main/othervm NotificationEmissionTest 1

Lines 34 & 36: is it necessary to run NotificationEmissionTest twice with and w/o `othervm`?

test/jdk/javax/management/remote/mandatory/passwordAuthenticator/SimpleStandard.java line 155:

> 153:      */
> 154:     private void checkSubject() {
> 155:          Subject subject = Boolean.getBoolean("SimpleStandard.useGetSubjectACC") ?

Nit, remove extra leading space.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2110572609
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1634951807
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1634955377

From Alan.Bateman at oracle.com  Tue Jun 11 15:16:55 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Jun 2024 16:16:55 +0100
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
Message-ID: <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>

On 06/06/2024 18:37, David Lloyd wrote:
> Just bumping this one more time. I intend to start by opening a JIRA 
> to add the two proposed methods to `ReflectionFactory`, and go from 
> there. I guess that we might need a JEP for the proposed serialization 
> restrictions, which is going to be considerably more involved, so I'm 
> putting that off as a second step for now, pending further discussion.
>

I don't think the JDK should be adding another backdoor for 
serialization libs to do deep reflection.

I'm curious, does your serialization library uses the ReflectionFactory 
to get method handles to the readObject/writeObject methods (if they are 
defined)?

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240611/29f63425/attachment-0001.htm>

From mbaesken at openjdk.org  Tue Jun 11 15:28:16 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Jun 2024 15:28:16 GMT
Subject: RFR: 8222884: ConcurrentClassDescLookup.java times out
 intermittently
In-Reply-To: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>
References: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>
Message-ID: <oBesvtmgV13qxMDVzUjUFia0QDDIhPzrNOYV8rLV6cY=.c7c37c89-49ed-4909-96d2-f05fec436b91@github.com>

On Tue, 11 Jun 2024 13:09:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address intermittent failures in `test/jdk/java/io/Serializable/concurrentClassDescLookup/ConcurrentClassDescLookup.java`?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8222884. As noted in that issue, the test in its current form has a potential race. The test main thread launches 50 "successful lookup" tasks and 50 "failed lookup" tasks. Each task is a `Thread`. The test passes an `Object` instance shared by 50 of these tasks and each task when it starts execution in its `run()` method does a `wait()` on that `Object` instance. The test main thread then after launching 50 tasks, sleeps for a second (to let the 50 `Thread`s start execution and arrive at the `Object.wait()`) and then after waking up the main thread does a `notifyAll()` on that `Object` instance. In theory and likely in practice too, it's possible that (especially) for the last batch of 50 tasks (the "failing lookup" tasks), the `notifyAll()` might end up getting invoked before one or more task Thread(s) have actually done a `wait()`. That can then mean that one or more task `Thread`(s) will keep `wait()`ing indefinitely with no on
 e `notify()`ing the `Object` instance to proceed with the task execution.
> 
> The commit in this PR removes the use of `Object.wait()/notifyAll()` and instead uses a `CountdownLatch` to allow for a more deterministic barrier. The test continues to pass with this change. Additionally, this change was run against a CI setup, by Matthias, where it was previously failing intermittently. Matthias reports that it hasn't failed after this change.

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19659#pullrequestreview-2110799797

From epeter at openjdk.org  Tue Jun 11 15:38:14 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 11 Jun 2024 15:38:14 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <sLLwY_A95pj3a62IYg3HTO7Lw6tI1SwF4qb4CT0mz10=.81db16a6-4e17-4d8b-b694-2b19605e5965@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <sLLwY_A95pj3a62IYg3HTO7Lw6tI1SwF4qb4CT0mz10=.81db16a6-4e17-4d8b-b694-2b19605e5965@github.com>
Message-ID: <yK7XjXIvol4vo8f2pLXgooWXQF_xP1mr26lfo0kNOKg=.69ee8193-42fb-4870-a030-e470af5789ed@github.com>

On Tue, 11 Jun 2024 12:11:21 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert
>
> ([f96cde4e](https://git.openjdk.org/jdk/pull/19626/files/f96cde4e79e12e2ea46e6061f918a69f11d59985)) ([0cbaa5ac](https://git.openjdk.org/jdk/pull/19626/files/0cbaa5ac04873373131f1a7216353a5af5b3e48e)) The previous overriding of StringUTF16.putChar method did not improve performance, so I reverted to the original version.
> 
> I have collected information on TraceMergeStores, but I don't have enough knowledge to analyze it yet
> 
> https://github.com/wenshao/jdk/wiki/pr19626_appendNull_0

@wenshao have you published info about `TraceMergeStores` somewhere? It is very well possible that the optimization does not apply in your code. Then you would need to dig into the VM code and see why.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2161066866

From duke at openjdk.org  Tue Jun 11 15:58:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 11 Jun 2024 15:58:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <yK7XjXIvol4vo8f2pLXgooWXQF_xP1mr26lfo0kNOKg=.69ee8193-42fb-4870-a030-e470af5789ed@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <sLLwY_A95pj3a62IYg3HTO7Lw6tI1SwF4qb4CT0mz10=.81db16a6-4e17-4d8b-b694-2b19605e5965@github.com>
 <yK7XjXIvol4vo8f2pLXgooWXQF_xP1mr26lfo0kNOKg=.69ee8193-42fb-4870-a030-e470af5789ed@github.com>
Message-ID: <K9hwrh9iTTyV3Xr8NZNjquCQshofREdRROWsyWehpYA=.51ccfe5d-94a8-47ae-a935-bc5798556ba0@github.com>

On Tue, 11 Jun 2024 15:35:47 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> ([f96cde4e](https://git.openjdk.org/jdk/pull/19626/files/f96cde4e79e12e2ea46e6061f918a69f11d59985)) ([0cbaa5ac](https://git.openjdk.org/jdk/pull/19626/files/0cbaa5ac04873373131f1a7216353a5af5b3e48e)) The previous overriding of StringUTF16.putChar method did not improve performance, so I reverted to the original version.
>> 
>> I have collected information on TraceMergeStores, but I don't have enough knowledge to analyze it yet
>> 
>> https://github.com/wenshao/jdk/wiki/pr19626_appendNull_0
>
> @wenshao have you published info about `TraceMergeStores` somewhere? It is very well possible that the optimization does not apply in your code. Then you would need to dig into the VM code and see why.

@eme64 TraceMergeStores are here,  but I can't understand these assembly codes

# JavaCode

class AbstractStringBuilder {
     private AbstractStringBuilder appendNull() {
        int count = this.count;
        ensureCapacityInternal(count + 4);
        byte[] val = this.value;
        if (isLatin1()) {
            val[count    ] = 'n';
            val[count + 1] = 'u';
            val[count + 2] = 'l';
            val[count + 3] = 'l';
        } else {
            StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
        }
        this.count = count + 4;
        return this;
    }
}

class StringUTF16 {
    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
    }
}


# TraceMergeStores

CompileCommand: compileonly *StringBuilder.appendNull bool compileonly = true

Compiled method (n/a) 100    1     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLLLL)L (native)
 total in heap  [0x00000001043b8088,0x00000001043b8230] = 424
 relocation     [0x00000001043b8170,0x00000001043b8188] = 24
 main code      [0x00000001043b81c0,0x00000001043b8230] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011842b8b8} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5
                        = 'java/lang/Object'
  # parm5:    c_rarg6:c_rarg6
                        = 'java/lang/Object'
  # parm6:    c_rarg7:c_rarg7
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043b81c0:   nop
 ;; verify_klass {
  0x00000001043b81c4:   cbz	x7, 0x00000001043b81fc
  0x00000001043b81c8:   stp	x8, x9, [sp, #-16]!
  0x00000001043b81cc:   ldr	w9, [x7, #8]
  0x00000001043b81d0:   eor	x9, x9, #0x400000000000
  0x00000001043b81d4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043b81d8:   ldr	x8, [x8, #1528]
  0x00000001043b81dc:   cmp	x9, x8
  0x00000001043b81e0:   b.eq	0x00000001043b8208  // b.none
  0x00000001043b81e4:   ldr	x9, [x9, #64]
  0x00000001043b81e8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043b81ec:   ldr	x8, [x8, #1528]
  0x00000001043b81f0:   cmp	x9, x8
  0x00000001043b81f4:   b.eq	0x00000001043b8208  // b.none
  0x00000001043b81f8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043b81fc:   dcps1	#0xdeae
  0x00000001043b8200:   .inst	0x03aa865f ; undefined
  0x00000001043b8204:   udf	#1
 ;; L_ok:
  0x00000001043b8208:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043b820c:   ldr	w12, [x7, #36]
  0x00000001043b8210:   lsl	x12, x12, #3
  0x00000001043b8214:   ldr	x12, [x12, #16]
  0x00000001043b8218:   cbz	x12, 0x00000001043b8224
  0x00000001043b821c:   ldr	x8, [x12, #88]
  0x00000001043b8220:   br	x8
  0x00000001043b8224:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043b8228:   add	x8, x8, #0x900
  0x00000001043b822c:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 109    2     n       java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native)
 total in heap  [0x00000001043bd808,0x00000001043bd9b0] = 424
 relocation     [0x00000001043bd8f0,0x00000001043bd908] = 24
 main code      [0x00000001043bd940,0x00000001043bd9b0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001184823e8} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043bd940:   nop
 ;; verify_klass {
  0x00000001043bd944:   cbz	x3, 0x00000001043bd97c
  0x00000001043bd948:   stp	x8, x9, [sp, #-16]!
  0x00000001043bd94c:   ldr	w9, [x3, #8]
  0x00000001043bd950:   eor	x9, x9, #0x400000000000
  0x00000001043bd954:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bd958:   ldr	x8, [x8, #1528]
  0x00000001043bd95c:   cmp	x9, x8
  0x00000001043bd960:   b.eq	0x00000001043bd988  // b.none
  0x00000001043bd964:   ldr	x9, [x9, #64]
  0x00000001043bd968:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bd96c:   ldr	x8, [x8, #1528]
  0x00000001043bd970:   cmp	x9, x8
  0x00000001043bd974:   b.eq	0x00000001043bd988  // b.none
  0x00000001043bd978:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043bd97c:   dcps1	#0xdeae
  0x00000001043bd980:   .inst	0x03aa865f ; undefined
  0x00000001043bd984:   udf	#1
 ;; L_ok:
  0x00000001043bd988:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043bd98c:   ldr	w12, [x3, #36]
  0x00000001043bd990:   lsl	x12, x12, #3
  0x00000001043bd994:   ldr	x12, [x12, #16]
  0x00000001043bd998:   cbz	x12, 0x00000001043bd9a4
  0x00000001043bd99c:   ldr	x8, [x12, #88]
  0x00000001043bd9a0:   br	x8
  0x00000001043bd9a4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043bd9a8:   add	x8, x8, #0x900
  0x00000001043bd9ac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 112    3     n       java.lang.invoke.MethodHandle::invokeBasic(LLLLLL)L (native)
 total in heap  [0x00000001043bdb08,0x00000001043bdc38] = 304
 relocation     [0x00000001043bdbf0,0x00000001043bdbf8] = 8
 main code      [0x00000001043bdc00,0x00000001043bdc38] = 56

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011848bac8} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm3:    c_rarg5:c_rarg5
                        = 'java/lang/Object'
  # parm4:    c_rarg6:c_rarg6
                        = 'java/lang/Object'
  # parm5:    c_rarg7:c_rarg7
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x00000001043bdc00:   nop
 ;; jump_to_lambda_form {
  0x00000001043bdc04:   ldr	w12, [x1, #20]
  0x00000001043bdc08:   lsl	x12, x12, #3
  0x00000001043bdc0c:   ldr	w12, [x12, #40]
  0x00000001043bdc10:   lsl	x12, x12, #3
  0x00000001043bdc14:   ldr	w12, [x12, #36]
  0x00000001043bdc18:   lsl	x12, x12, #3
  0x00000001043bdc1c:   ldr	x12, [x12, #16]
  0x00000001043bdc20:   cbz	x12, 0x00000001043bdc2c
  0x00000001043bdc24:   ldr	x8, [x12, #88]
  0x00000001043bdc28:   br	x8
  0x00000001043bdc2c:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043bdc30:   add	x8, x8, #0x900
  0x00000001043bdc34:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 113    4     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLLLLLL)L (native)
 total in heap  [0x00000001043bde08,0x00000001043be098] = 656
 relocation     [0x00000001043bdef0,0x00000001043bdf28] = 56
 main code      [0x00000001043bdf40,0x00000001043be094] = 340
 stub code      [0x00000001043be094,0x00000001043be098] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011848bc70} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5
                        = 'java/lang/Object'
  # parm5:    c_rarg6:c_rarg6
                        = 'java/lang/Object'
  # parm6:    c_rarg7:c_rarg7
                        = 'java/lang/Object'
  # parm7:    c_rarg0:c_rarg0
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043bdf40:   nop
 ;; verify_klass {
  0x00000001043bdf44:   cbz	x0, 0x00000001043bdf7c
  0x00000001043bdf48:   stp	x8, x9, [sp, #-16]!
  0x00000001043bdf4c:   ldr	w9, [x0, #8]
  0x00000001043bdf50:   eor	x9, x9, #0x400000000000
  0x00000001043bdf54:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bdf58:   ldr	x8, [x8, #1528]
  0x00000001043bdf5c:   cmp	x9, x8
  0x00000001043bdf60:   b.eq	0x00000001043bdf88  // b.none
  0x00000001043bdf64:   ldr	x9, [x9, #64]
  0x00000001043bdf68:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bdf6c:   ldr	x8, [x8, #1528]
  0x00000001043bdf70:   cmp	x9, x8
  0x00000001043bdf74:   b.eq	0x00000001043bdf88  // b.none
  0x00000001043bdf78:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043bdf7c:   dcps1	#0xdeae
  0x00000001043bdf80:   .inst	0x03aa865f ; undefined
  0x00000001043bdf84:   udf	#1
 ;; L_ok:
  0x00000001043bdf88:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043bdf8c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043bdf90:   ldr	w10, [x1, #8]
  0x00000001043bdf94:   eor	x10, x10, #0x400000000000
  0x00000001043bdf98:   ldr	w11, [x0, #24]
  0x00000001043bdf9c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043bdfa0:   cbz	x11, 0x00000001043bdfd8
  0x00000001043bdfa4:   stp	x8, x9, [sp, #-16]!
  0x00000001043bdfa8:   ldr	w9, [x11, #8]
  0x00000001043bdfac:   eor	x9, x9, #0x400000000000
  0x00000001043bdfb0:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bdfb4:   ldr	x8, [x8, #1064]
  0x00000001043bdfb8:   cmp	x9, x8
  0x00000001043bdfbc:   b.eq	0x00000001043bdfe4  // b.none
  0x00000001043bdfc0:   ldr	x9, [x9, #64]
  0x00000001043bdfc4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bdfc8:   ldr	x8, [x8, #1064]
  0x00000001043bdfcc:   cmp	x9, x8
  0x00000001043bdfd0:   b.eq	0x00000001043bdfe4  // b.none
  0x00000001043bdfd4:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043bdfd8:   dcps1	#0xdeae
  0x00000001043bdfdc:   .inst	0x03aa81bf ; undefined
  0x00000001043bdfe0:   udf	#1
 ;; L_ok:
  0x00000001043bdfe4:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043bdfe8:   ldr	x11, [x11, #16]
  0x00000001043bdfec:   cmp	x10, x11
  0x00000001043bdff0:   b.eq	0x00000001043be070  // b.none
  0x00000001043bdff4:   ldr	w14, [x11, #24]
  0x00000001043bdff8:   ldr	x8, [x10, x14]
  0x00000001043bdffc:   cmp	x11, x8
  0x00000001043be000:   b.eq	0x00000001043be070  // b.none
  0x00000001043be004:   cmp	x14, #0x28
  0x00000001043be008:   b.ne	0x00000001043be06c  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043be00c:   stp	x0, x2, [sp, #-32]!
  0x00000001043be010:   stp	x5, xzr, [sp, #16]
  0x00000001043be014:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043be018:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043be01c:   movk	x9, #0x3d0, lsl #16
  0x00000001043be020:   movk	x9, #0x1, lsl #32
  0x00000001043be024:   ldr	w8, [x9]
  0x00000001043be028:   add	w8, w8, #0x1
  0x00000001043be02c:   str	w8, [x9]
  0x00000001043be030:   ldr	x5, [x10, #48]
  0x00000001043be034:   ldr	w2, [x5]
  0x00000001043be038:   add	x5, x5, #0x8
  0x00000001043be03c:   cmp	sp, xzr
  0x00000001043be040:   cbz	x2, 0x00000001043be058
  0x00000001043be044:   ldr	x8, [x5], #8
  0x00000001043be048:   cmp	x0, x8
  0x00000001043be04c:   b.eq	0x00000001043be058  // b.none
  0x00000001043be050:   sub	x2, x2, #0x1
  0x00000001043be054:   cbnz	x2, 0x00000001043be044
  0x00000001043be058:   ldp	x5, xzr, [sp, #16]
  0x00000001043be05c:   ldp	x0, x2, [sp], #32
  0x00000001043be060:   b.ne	0x00000001043be06c  // b.any
  0x00000001043be064:   str	x11, [x10, #40]
  0x00000001043be068:   b	0x00000001043be070
  0x00000001043be06c:   hlt	#0x0
 ;; } check_receiver
  0x00000001043be070:   ldr	w12, [x0, #36]
  0x00000001043be074:   lsl	x12, x12, #3
  0x00000001043be078:   ldr	x12, [x12, #16]
  0x00000001043be07c:   cbz	x12, 0x00000001043be088
  0x00000001043be080:   ldr	x8, [x12, #88]
  0x00000001043be084:   br	x8
  0x00000001043be088:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043be08c:   add	x8, x8, #0x900
  0x00000001043be090:   br	x8
[Stub Code]
  0x00000001043be094:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 120    5     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLL)V (native)
 total in heap  [0x00000001043be888,0x00000001043beb18] = 656
 relocation     [0x00000001043be970,0x00000001043be9a8] = 56
 main code      [0x00000001043be9c0,0x00000001043beb14] = 340
 stub code      [0x00000001043beb14,0x00000001043beb18] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001184a2628} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043be9c0:   nop
 ;; verify_klass {
  0x00000001043be9c4:   cbz	x4, 0x00000001043be9fc
  0x00000001043be9c8:   stp	x8, x9, [sp, #-16]!
  0x00000001043be9cc:   ldr	w9, [x4, #8]
  0x00000001043be9d0:   eor	x9, x9, #0x400000000000
  0x00000001043be9d4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043be9d8:   ldr	x8, [x8, #1528]
  0x00000001043be9dc:   cmp	x9, x8
  0x00000001043be9e0:   b.eq	0x00000001043bea08  // b.none
  0x00000001043be9e4:   ldr	x9, [x9, #64]
  0x00000001043be9e8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043be9ec:   ldr	x8, [x8, #1528]
  0x00000001043be9f0:   cmp	x9, x8
  0x00000001043be9f4:   b.eq	0x00000001043bea08  // b.none
  0x00000001043be9f8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043be9fc:   dcps1	#0xdeae
  0x00000001043bea00:   .inst	0x03aa865f ; undefined
  0x00000001043bea04:   udf	#1
 ;; L_ok:
  0x00000001043bea08:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043bea0c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043bea10:   ldr	w10, [x1, #8]
  0x00000001043bea14:   eor	x10, x10, #0x400000000000
  0x00000001043bea18:   ldr	w11, [x4, #24]
  0x00000001043bea1c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043bea20:   cbz	x11, 0x00000001043bea58
  0x00000001043bea24:   stp	x8, x9, [sp, #-16]!
  0x00000001043bea28:   ldr	w9, [x11, #8]
  0x00000001043bea2c:   eor	x9, x9, #0x400000000000
  0x00000001043bea30:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bea34:   ldr	x8, [x8, #1064]
  0x00000001043bea38:   cmp	x9, x8
  0x00000001043bea3c:   b.eq	0x00000001043bea64  // b.none
  0x00000001043bea40:   ldr	x9, [x9, #64]
  0x00000001043bea44:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bea48:   ldr	x8, [x8, #1064]
  0x00000001043bea4c:   cmp	x9, x8
  0x00000001043bea50:   b.eq	0x00000001043bea64  // b.none
  0x00000001043bea54:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043bea58:   dcps1	#0xdeae
  0x00000001043bea5c:   .inst	0x03aa81bf ; undefined
  0x00000001043bea60:   udf	#1
 ;; L_ok:
  0x00000001043bea64:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043bea68:   ldr	x11, [x11, #16]
  0x00000001043bea6c:   cmp	x10, x11
  0x00000001043bea70:   b.eq	0x00000001043beaf0  // b.none
  0x00000001043bea74:   ldr	w14, [x11, #24]
  0x00000001043bea78:   ldr	x8, [x10, x14]
  0x00000001043bea7c:   cmp	x11, x8
  0x00000001043bea80:   b.eq	0x00000001043beaf0  // b.none
  0x00000001043bea84:   cmp	x14, #0x28
  0x00000001043bea88:   b.ne	0x00000001043beaec  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043bea8c:   stp	x0, x2, [sp, #-32]!
  0x00000001043bea90:   stp	x5, xzr, [sp, #16]
  0x00000001043bea94:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043bea98:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043bea9c:   movk	x9, #0x3d0, lsl #16
  0x00000001043beaa0:   movk	x9, #0x1, lsl #32
  0x00000001043beaa4:   ldr	w8, [x9]
  0x00000001043beaa8:   add	w8, w8, #0x1
  0x00000001043beaac:   str	w8, [x9]
  0x00000001043beab0:   ldr	x5, [x10, #48]
  0x00000001043beab4:   ldr	w2, [x5]
  0x00000001043beab8:   add	x5, x5, #0x8
  0x00000001043beabc:   cmp	sp, xzr
  0x00000001043beac0:   cbz	x2, 0x00000001043bead8
  0x00000001043beac4:   ldr	x8, [x5], #8
  0x00000001043beac8:   cmp	x0, x8
  0x00000001043beacc:   b.eq	0x00000001043bead8  // b.none
  0x00000001043bead0:   sub	x2, x2, #0x1
  0x00000001043bead4:   cbnz	x2, 0x00000001043beac4
  0x00000001043bead8:   ldp	x5, xzr, [sp, #16]
  0x00000001043beadc:   ldp	x0, x2, [sp], #32
  0x00000001043beae0:   b.ne	0x00000001043beaec  // b.any
  0x00000001043beae4:   str	x11, [x10, #40]
  0x00000001043beae8:   b	0x00000001043beaf0
  0x00000001043beaec:   hlt	#0x0
 ;; } check_receiver
  0x00000001043beaf0:   ldr	w12, [x4, #36]
  0x00000001043beaf4:   lsl	x12, x12, #3
  0x00000001043beaf8:   ldr	x12, [x12, #16]
  0x00000001043beafc:   cbz	x12, 0x00000001043beb08
  0x00000001043beb00:   ldr	x8, [x12, #88]
  0x00000001043beb04:   br	x8
  0x00000001043beb08:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043beb0c:   add	x8, x8, #0x900
  0x00000001043beb10:   br	x8
[Stub Code]
  0x00000001043beb14:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 122    6     n       java.lang.invoke.MethodHandle::invokeBasic(LL)L (native)
 total in heap  [0x00000001043bef08,0x00000001043bf038] = 304
 relocation     [0x00000001043beff0,0x00000001043beff8] = 8
 main code      [0x00000001043bf000,0x00000001043bf038] = 56

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001184a3c38} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x00000001043bf000:   nop
 ;; jump_to_lambda_form {
  0x00000001043bf004:   ldr	w12, [x1, #20]
  0x00000001043bf008:   lsl	x12, x12, #3
  0x00000001043bf00c:   ldr	w12, [x12, #40]
  0x00000001043bf010:   lsl	x12, x12, #3
  0x00000001043bf014:   ldr	w12, [x12, #36]
  0x00000001043bf018:   lsl	x12, x12, #3
  0x00000001043bf01c:   ldr	x12, [x12, #16]
  0x00000001043bf020:   cbz	x12, 0x00000001043bf02c
  0x00000001043bf024:   ldr	x8, [x12, #88]
  0x00000001043bf028:   br	x8
  0x00000001043bf02c:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043bf030:   add	x8, x8, #0x900
  0x00000001043bf034:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 123    7     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLL)L (native)
 total in heap  [0x00000001043bf208,0x00000001043bf498] = 656
 relocation     [0x00000001043bf2f0,0x00000001043bf328] = 56
 main code      [0x00000001043bf340,0x00000001043bf494] = 340
 stub code      [0x00000001043bf494,0x00000001043bf498] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001184a3d70} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043bf340:   nop
 ;; verify_klass {
  0x00000001043bf344:   cbz	x4, 0x00000001043bf37c
  0x00000001043bf348:   stp	x8, x9, [sp, #-16]!
  0x00000001043bf34c:   ldr	w9, [x4, #8]
  0x00000001043bf350:   eor	x9, x9, #0x400000000000
  0x00000001043bf354:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bf358:   ldr	x8, [x8, #1528]
  0x00000001043bf35c:   cmp	x9, x8
  0x00000001043bf360:   b.eq	0x00000001043bf388  // b.none
  0x00000001043bf364:   ldr	x9, [x9, #64]
  0x00000001043bf368:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bf36c:   ldr	x8, [x8, #1528]
  0x00000001043bf370:   cmp	x9, x8
  0x00000001043bf374:   b.eq	0x00000001043bf388  // b.none
  0x00000001043bf378:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043bf37c:   dcps1	#0xdeae
  0x00000001043bf380:   .inst	0x03aa865f ; undefined
  0x00000001043bf384:   udf	#1
 ;; L_ok:
  0x00000001043bf388:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043bf38c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043bf390:   ldr	w10, [x1, #8]
  0x00000001043bf394:   eor	x10, x10, #0x400000000000
  0x00000001043bf398:   ldr	w11, [x4, #24]
  0x00000001043bf39c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043bf3a0:   cbz	x11, 0x00000001043bf3d8
  0x00000001043bf3a4:   stp	x8, x9, [sp, #-16]!
  0x00000001043bf3a8:   ldr	w9, [x11, #8]
  0x00000001043bf3ac:   eor	x9, x9, #0x400000000000
  0x00000001043bf3b0:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bf3b4:   ldr	x8, [x8, #1064]
  0x00000001043bf3b8:   cmp	x9, x8
  0x00000001043bf3bc:   b.eq	0x00000001043bf3e4  // b.none
  0x00000001043bf3c0:   ldr	x9, [x9, #64]
  0x00000001043bf3c4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043bf3c8:   ldr	x8, [x8, #1064]
  0x00000001043bf3cc:   cmp	x9, x8
  0x00000001043bf3d0:   b.eq	0x00000001043bf3e4  // b.none
  0x00000001043bf3d4:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043bf3d8:   dcps1	#0xdeae
  0x00000001043bf3dc:   .inst	0x03aa81bf ; undefined
  0x00000001043bf3e0:   udf	#1
 ;; L_ok:
  0x00000001043bf3e4:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043bf3e8:   ldr	x11, [x11, #16]
  0x00000001043bf3ec:   cmp	x10, x11
  0x00000001043bf3f0:   b.eq	0x00000001043bf470  // b.none
  0x00000001043bf3f4:   ldr	w14, [x11, #24]
  0x00000001043bf3f8:   ldr	x8, [x10, x14]
  0x00000001043bf3fc:   cmp	x11, x8
  0x00000001043bf400:   b.eq	0x00000001043bf470  // b.none
  0x00000001043bf404:   cmp	x14, #0x28
  0x00000001043bf408:   b.ne	0x00000001043bf46c  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043bf40c:   stp	x0, x2, [sp, #-32]!
  0x00000001043bf410:   stp	x5, xzr, [sp, #16]
  0x00000001043bf414:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043bf418:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043bf41c:   movk	x9, #0x3d0, lsl #16
  0x00000001043bf420:   movk	x9, #0x1, lsl #32
  0x00000001043bf424:   ldr	w8, [x9]
  0x00000001043bf428:   add	w8, w8, #0x1
  0x00000001043bf42c:   str	w8, [x9]
  0x00000001043bf430:   ldr	x5, [x10, #48]
  0x00000001043bf434:   ldr	w2, [x5]
  0x00000001043bf438:   add	x5, x5, #0x8
  0x00000001043bf43c:   cmp	sp, xzr
  0x00000001043bf440:   cbz	x2, 0x00000001043bf458
  0x00000001043bf444:   ldr	x8, [x5], #8
  0x00000001043bf448:   cmp	x0, x8
  0x00000001043bf44c:   b.eq	0x00000001043bf458  // b.none
  0x00000001043bf450:   sub	x2, x2, #0x1
  0x00000001043bf454:   cbnz	x2, 0x00000001043bf444
  0x00000001043bf458:   ldp	x5, xzr, [sp, #16]
  0x00000001043bf45c:   ldp	x0, x2, [sp], #32
  0x00000001043bf460:   b.ne	0x00000001043bf46c  // b.any
  0x00000001043bf464:   str	x11, [x10, #40]
  0x00000001043bf468:   b	0x00000001043bf470
  0x00000001043bf46c:   hlt	#0x0
 ;; } check_receiver
  0x00000001043bf470:   ldr	w12, [x4, #36]
  0x00000001043bf474:   lsl	x12, x12, #3
  0x00000001043bf478:   ldr	x12, [x12, #16]
  0x00000001043bf47c:   cbz	x12, 0x00000001043bf488
  0x00000001043bf480:   ldr	x8, [x12, #88]
  0x00000001043bf484:   br	x8
  0x00000001043bf488:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043bf48c:   add	x8, x8, #0x900
  0x00000001043bf490:   br	x8
[Stub Code]
  0x00000001043bf494:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 133    8     n       java.lang.invoke.MethodHandle::linkToSpecial(LLL)L (native)
 total in heap  [0x00000001043c2288,0x00000001043c2518] = 656
 relocation     [0x00000001043c2370,0x00000001043c23a8] = 56
 main code      [0x00000001043c23c0,0x00000001043c2514] = 340
 stub code      [0x00000001043c2514,0x00000001043c2518] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001184e9370} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043c23c0:   nop
 ;; verify_klass {
  0x00000001043c23c4:   cbz	x3, 0x00000001043c23fc
  0x00000001043c23c8:   stp	x8, x9, [sp, #-16]!
  0x00000001043c23cc:   ldr	w9, [x3, #8]
  0x00000001043c23d0:   eor	x9, x9, #0x400000000000
  0x00000001043c23d4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c23d8:   ldr	x8, [x8, #1528]
  0x00000001043c23dc:   cmp	x9, x8
  0x00000001043c23e0:   b.eq	0x00000001043c2408  // b.none
  0x00000001043c23e4:   ldr	x9, [x9, #64]
  0x00000001043c23e8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c23ec:   ldr	x8, [x8, #1528]
  0x00000001043c23f0:   cmp	x9, x8
  0x00000001043c23f4:   b.eq	0x00000001043c2408  // b.none
  0x00000001043c23f8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043c23fc:   dcps1	#0xdeae
  0x00000001043c2400:   .inst	0x03aa865f ; undefined
  0x00000001043c2404:   udf	#1
 ;; L_ok:
  0x00000001043c2408:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043c240c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043c2410:   ldr	w10, [x1, #8]
  0x00000001043c2414:   eor	x10, x10, #0x400000000000
  0x00000001043c2418:   ldr	w11, [x3, #24]
  0x00000001043c241c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043c2420:   cbz	x11, 0x00000001043c2458
  0x00000001043c2424:   stp	x8, x9, [sp, #-16]!
  0x00000001043c2428:   ldr	w9, [x11, #8]
  0x00000001043c242c:   eor	x9, x9, #0x400000000000
  0x00000001043c2430:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c2434:   ldr	x8, [x8, #1064]
  0x00000001043c2438:   cmp	x9, x8
  0x00000001043c243c:   b.eq	0x00000001043c2464  // b.none
  0x00000001043c2440:   ldr	x9, [x9, #64]
  0x00000001043c2444:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c2448:   ldr	x8, [x8, #1064]
  0x00000001043c244c:   cmp	x9, x8
  0x00000001043c2450:   b.eq	0x00000001043c2464  // b.none
  0x00000001043c2454:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043c2458:   dcps1	#0xdeae
  0x00000001043c245c:   .inst	0x03aa81bf ; undefined
  0x00000001043c2460:   udf	#1
 ;; L_ok:
  0x00000001043c2464:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043c2468:   ldr	x11, [x11, #16]
  0x00000001043c246c:   cmp	x10, x11
  0x00000001043c2470:   b.eq	0x00000001043c24f0  // b.none
  0x00000001043c2474:   ldr	w14, [x11, #24]
  0x00000001043c2478:   ldr	x8, [x10, x14]
  0x00000001043c247c:   cmp	x11, x8
  0x00000001043c2480:   b.eq	0x00000001043c24f0  // b.none
  0x00000001043c2484:   cmp	x14, #0x28
  0x00000001043c2488:   b.ne	0x00000001043c24ec  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043c248c:   stp	x0, x2, [sp, #-32]!
  0x00000001043c2490:   stp	x5, xzr, [sp, #16]
  0x00000001043c2494:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043c2498:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043c249c:   movk	x9, #0x3d0, lsl #16
  0x00000001043c24a0:   movk	x9, #0x1, lsl #32
  0x00000001043c24a4:   ldr	w8, [x9]
  0x00000001043c24a8:   add	w8, w8, #0x1
  0x00000001043c24ac:   str	w8, [x9]
  0x00000001043c24b0:   ldr	x5, [x10, #48]
  0x00000001043c24b4:   ldr	w2, [x5]
  0x00000001043c24b8:   add	x5, x5, #0x8
  0x00000001043c24bc:   cmp	sp, xzr
  0x00000001043c24c0:   cbz	x2, 0x00000001043c24d8
  0x00000001043c24c4:   ldr	x8, [x5], #8
  0x00000001043c24c8:   cmp	x0, x8
  0x00000001043c24cc:   b.eq	0x00000001043c24d8  // b.none
  0x00000001043c24d0:   sub	x2, x2, #0x1
  0x00000001043c24d4:   cbnz	x2, 0x00000001043c24c4
  0x00000001043c24d8:   ldp	x5, xzr, [sp, #16]
  0x00000001043c24dc:   ldp	x0, x2, [sp], #32
  0x00000001043c24e0:   b.ne	0x00000001043c24ec  // b.any
  0x00000001043c24e4:   str	x11, [x10, #40]
  0x00000001043c24e8:   b	0x00000001043c24f0
  0x00000001043c24ec:   hlt	#0x0
 ;; } check_receiver
  0x00000001043c24f0:   ldr	w12, [x3, #36]
  0x00000001043c24f4:   lsl	x12, x12, #3
  0x00000001043c24f8:   ldr	x12, [x12, #16]
  0x00000001043c24fc:   cbz	x12, 0x00000001043c2508
  0x00000001043c2500:   ldr	x8, [x12, #88]
  0x00000001043c2504:   br	x8
  0x00000001043c2508:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043c250c:   add	x8, x8, #0x900
  0x00000001043c2510:   br	x8
[Stub Code]
  0x00000001043c2514:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 141    9     n       java.lang.invoke.MethodHandle::linkToStatic(LLIL)I (native)
 total in heap  [0x00000001043c5e88,0x00000001043c6030] = 424
 relocation     [0x00000001043c5f70,0x00000001043c5f88] = 24
 main code      [0x00000001043c5fc0,0x00000001043c6030] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011859f420} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3   = int
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043c5fc0:   nop
 ;; verify_klass {
  0x00000001043c5fc4:   cbz	x4, 0x00000001043c5ffc
  0x00000001043c5fc8:   stp	x8, x9, [sp, #-16]!
  0x00000001043c5fcc:   ldr	w9, [x4, #8]
  0x00000001043c5fd0:   eor	x9, x9, #0x400000000000
  0x00000001043c5fd4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c5fd8:   ldr	x8, [x8, #1528]
  0x00000001043c5fdc:   cmp	x9, x8
  0x00000001043c5fe0:   b.eq	0x00000001043c6008  // b.none
  0x00000001043c5fe4:   ldr	x9, [x9, #64]
  0x00000001043c5fe8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c5fec:   ldr	x8, [x8, #1528]
  0x00000001043c5ff0:   cmp	x9, x8
  0x00000001043c5ff4:   b.eq	0x00000001043c6008  // b.none
  0x00000001043c5ff8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043c5ffc:   dcps1	#0xdeae
  0x00000001043c6000:   .inst	0x03aa865f ; undefined
  0x00000001043c6004:   udf	#1
 ;; L_ok:
  0x00000001043c6008:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043c600c:   ldr	w12, [x4, #36]
  0x00000001043c6010:   lsl	x12, x12, #3
  0x00000001043c6014:   ldr	x12, [x12, #16]
  0x00000001043c6018:   cbz	x12, 0x00000001043c6024
  0x00000001043c601c:   ldr	x8, [x12, #88]
  0x00000001043c6020:   br	x8
  0x00000001043c6024:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043c6028:   add	x8, x8, #0x900
  0x00000001043c602c:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 148   10     n       java.lang.invoke.MethodHandle::linkToSpecial(LLL)V (native)
 total in heap  [0x00000001043c7708,0x00000001043c7998] = 656
 relocation     [0x00000001043c77f0,0x00000001043c7828] = 56
 main code      [0x00000001043c7840,0x00000001043c7994] = 340
 stub code      [0x00000001043c7994,0x00000001043c7998] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001185c44d8} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043c7840:   nop
 ;; verify_klass {
  0x00000001043c7844:   cbz	x3, 0x00000001043c787c
  0x00000001043c7848:   stp	x8, x9, [sp, #-16]!
  0x00000001043c784c:   ldr	w9, [x3, #8]
  0x00000001043c7850:   eor	x9, x9, #0x400000000000
  0x00000001043c7854:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c7858:   ldr	x8, [x8, #1528]
  0x00000001043c785c:   cmp	x9, x8
  0x00000001043c7860:   b.eq	0x00000001043c7888  // b.none
  0x00000001043c7864:   ldr	x9, [x9, #64]
  0x00000001043c7868:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c786c:   ldr	x8, [x8, #1528]
  0x00000001043c7870:   cmp	x9, x8
  0x00000001043c7874:   b.eq	0x00000001043c7888  // b.none
  0x00000001043c7878:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043c787c:   dcps1	#0xdeae
  0x00000001043c7880:   .inst	0x03aa865f ; undefined
  0x00000001043c7884:   udf	#1
 ;; L_ok:
  0x00000001043c7888:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043c788c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043c7890:   ldr	w10, [x1, #8]
  0x00000001043c7894:   eor	x10, x10, #0x400000000000
  0x00000001043c7898:   ldr	w11, [x3, #24]
  0x00000001043c789c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043c78a0:   cbz	x11, 0x00000001043c78d8
  0x00000001043c78a4:   stp	x8, x9, [sp, #-16]!
  0x00000001043c78a8:   ldr	w9, [x11, #8]
  0x00000001043c78ac:   eor	x9, x9, #0x400000000000
  0x00000001043c78b0:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c78b4:   ldr	x8, [x8, #1064]
  0x00000001043c78b8:   cmp	x9, x8
  0x00000001043c78bc:   b.eq	0x00000001043c78e4  // b.none
  0x00000001043c78c0:   ldr	x9, [x9, #64]
  0x00000001043c78c4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c78c8:   ldr	x8, [x8, #1064]
  0x00000001043c78cc:   cmp	x9, x8
  0x00000001043c78d0:   b.eq	0x00000001043c78e4  // b.none
  0x00000001043c78d4:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043c78d8:   dcps1	#0xdeae
  0x00000001043c78dc:   .inst	0x03aa81bf ; undefined
  0x00000001043c78e0:   udf	#1
 ;; L_ok:
  0x00000001043c78e4:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043c78e8:   ldr	x11, [x11, #16]
  0x00000001043c78ec:   cmp	x10, x11
  0x00000001043c78f0:   b.eq	0x00000001043c7970  // b.none
  0x00000001043c78f4:   ldr	w14, [x11, #24]
  0x00000001043c78f8:   ldr	x8, [x10, x14]
  0x00000001043c78fc:   cmp	x11, x8
  0x00000001043c7900:   b.eq	0x00000001043c7970  // b.none
  0x00000001043c7904:   cmp	x14, #0x28
  0x00000001043c7908:   b.ne	0x00000001043c796c  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043c790c:   stp	x0, x2, [sp, #-32]!
  0x00000001043c7910:   stp	x5, xzr, [sp, #16]
  0x00000001043c7914:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043c7918:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043c791c:   movk	x9, #0x3d0, lsl #16
  0x00000001043c7920:   movk	x9, #0x1, lsl #32
  0x00000001043c7924:   ldr	w8, [x9]
  0x00000001043c7928:   add	w8, w8, #0x1
  0x00000001043c792c:   str	w8, [x9]
  0x00000001043c7930:   ldr	x5, [x10, #48]
  0x00000001043c7934:   ldr	w2, [x5]
  0x00000001043c7938:   add	x5, x5, #0x8
  0x00000001043c793c:   cmp	sp, xzr
  0x00000001043c7940:   cbz	x2, 0x00000001043c7958
  0x00000001043c7944:   ldr	x8, [x5], #8
  0x00000001043c7948:   cmp	x0, x8
  0x00000001043c794c:   b.eq	0x00000001043c7958  // b.none
  0x00000001043c7950:   sub	x2, x2, #0x1
  0x00000001043c7954:   cbnz	x2, 0x00000001043c7944
  0x00000001043c7958:   ldp	x5, xzr, [sp, #16]
  0x00000001043c795c:   ldp	x0, x2, [sp], #32
  0x00000001043c7960:   b.ne	0x00000001043c796c  // b.any
  0x00000001043c7964:   str	x11, [x10, #40]
  0x00000001043c7968:   b	0x00000001043c7970
  0x00000001043c796c:   hlt	#0x0
 ;; } check_receiver
  0x00000001043c7970:   ldr	w12, [x3, #36]
  0x00000001043c7974:   lsl	x12, x12, #3
  0x00000001043c7978:   ldr	x12, [x12, #16]
  0x00000001043c797c:   cbz	x12, 0x00000001043c7988
  0x00000001043c7980:   ldr	x8, [x12, #88]
  0x00000001043c7984:   br	x8
  0x00000001043c7988:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043c798c:   add	x8, x8, #0x900
  0x00000001043c7990:   br	x8
[Stub Code]
  0x00000001043c7994:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 151   11     n       java.lang.invoke.MethodHandle::invokeBasic(L)L (native)
 total in heap  [0x00000001043c7a08,0x00000001043c7b38] = 304
 relocation     [0x00000001043c7af0,0x00000001043c7af8] = 8
 main code      [0x00000001043c7b00,0x00000001043c7b38] = 56

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001185c4cb8} 'invokeBasic' '(Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x00000001043c7b00:   nop
 ;; jump_to_lambda_form {
  0x00000001043c7b04:   ldr	w12, [x1, #20]
  0x00000001043c7b08:   lsl	x12, x12, #3
  0x00000001043c7b0c:   ldr	w12, [x12, #40]
  0x00000001043c7b10:   lsl	x12, x12, #3
  0x00000001043c7b14:   ldr	w12, [x12, #36]
  0x00000001043c7b18:   lsl	x12, x12, #3
  0x00000001043c7b1c:   ldr	x12, [x12, #16]
  0x00000001043c7b20:   cbz	x12, 0x00000001043c7b2c
  0x00000001043c7b24:   ldr	x8, [x12, #88]
  0x00000001043c7b28:   br	x8
  0x00000001043c7b2c:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043c7b30:   add	x8, x8, #0x900
  0x00000001043c7b34:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 153   12     n       java.lang.invoke.MethodHandle::linkToStatic(LL)L (native)
 total in heap  [0x00000001043c7d08,0x00000001043c7eb0] = 424
 relocation     [0x00000001043c7df0,0x00000001043c7e08] = 24
 main code      [0x00000001043c7e40,0x00000001043c7eb0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001185cd878} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043c7e40:   nop
 ;; verify_klass {
  0x00000001043c7e44:   cbz	x2, 0x00000001043c7e7c
  0x00000001043c7e48:   stp	x8, x9, [sp, #-16]!
  0x00000001043c7e4c:   ldr	w9, [x2, #8]
  0x00000001043c7e50:   eor	x9, x9, #0x400000000000
  0x00000001043c7e54:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c7e58:   ldr	x8, [x8, #1528]
  0x00000001043c7e5c:   cmp	x9, x8
  0x00000001043c7e60:   b.eq	0x00000001043c7e88  // b.none
  0x00000001043c7e64:   ldr	x9, [x9, #64]
  0x00000001043c7e68:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043c7e6c:   ldr	x8, [x8, #1528]
  0x00000001043c7e70:   cmp	x9, x8
  0x00000001043c7e74:   b.eq	0x00000001043c7e88  // b.none
  0x00000001043c7e78:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043c7e7c:   dcps1	#0xdeae
  0x00000001043c7e80:   .inst	0x03aa865f ; undefined
  0x00000001043c7e84:   udf	#1
 ;; L_ok:
  0x00000001043c7e88:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043c7e8c:   ldr	w12, [x2, #36]
  0x00000001043c7e90:   lsl	x12, x12, #3
  0x00000001043c7e94:   ldr	x12, [x12, #16]
  0x00000001043c7e98:   cbz	x12, 0x00000001043c7ea4
  0x00000001043c7e9c:   ldr	x8, [x12, #88]
  0x00000001043c7ea0:   br	x8
  0x00000001043c7ea4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043c7ea8:   add	x8, x8, #0x900
  0x00000001043c7eac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 248   13     n       java.lang.invoke.MethodHandle::linkToInterface(LL)L (native)
 total in heap  [0x00000001043ca008,0x00000001043ca250] = 584
 relocation     [0x00000001043ca0f0,0x00000001043ca120] = 48
 main code      [0x00000001043ca140,0x00000001043ca250] = 272

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118550410} 'linkToInterface' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043ca140:   nop
 ;; verify_klass {
  0x00000001043ca144:   cbz	x2, 0x00000001043ca17c
  0x00000001043ca148:   stp	x8, x9, [sp, #-16]!
  0x00000001043ca14c:   ldr	w9, [x2, #8]
  0x00000001043ca150:   eor	x9, x9, #0x400000000000
  0x00000001043ca154:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043ca158:   ldr	x8, [x8, #1528]
  0x00000001043ca15c:   cmp	x9, x8
  0x00000001043ca160:   b.eq	0x00000001043ca188  // b.none
  0x00000001043ca164:   ldr	x9, [x9, #64]
  0x00000001043ca168:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043ca16c:   ldr	x8, [x8, #1528]
  0x00000001043ca170:   cmp	x9, x8
  0x00000001043ca174:   b.eq	0x00000001043ca188  // b.none
  0x00000001043ca178:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043ca17c:   dcps1	#0xdeae
  0x00000001043ca180:   .inst	0x03aa865f ; undefined
  0x00000001043ca184:   udf	#1
 ;; L_ok:
  0x00000001043ca188:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043ca18c:   ldr	w10, [x1, #8]
  0x00000001043ca190:   eor	x10, x10, #0x400000000000
 ;; check_receiver {
 ;; } check_receiver
  0x00000001043ca194:   ldr	w14, [x2, #24]
  0x00000001043ca198:   lsl	x14, x14, #3
 ;; verify_klass {
  0x00000001043ca19c:   cbz	x14, 0x00000001043ca1d4
  0x00000001043ca1a0:   stp	x8, x9, [sp, #-16]!
  0x00000001043ca1a4:   ldr	w9, [x14, #8]
  0x00000001043ca1a8:   eor	x9, x9, #0x400000000000
  0x00000001043ca1ac:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043ca1b0:   ldr	x8, [x8, #1064]
  0x00000001043ca1b4:   cmp	x9, x8
  0x00000001043ca1b8:   b.eq	0x00000001043ca1e0  // b.none
  0x00000001043ca1bc:   ldr	x9, [x9, #64]
  0x00000001043ca1c0:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043ca1c4:   ldr	x8, [x8, #1064]
  0x00000001043ca1c8:   cmp	x9, x8
  0x00000001043ca1cc:   b.eq	0x00000001043ca1e0  // b.none
  0x00000001043ca1d0:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043ca1d4:   dcps1	#0xdeae
  0x00000001043ca1d8:   .inst	0x03aa81bf ; undefined
  0x00000001043ca1dc:   udf	#1
 ;; L_ok:
  0x00000001043ca1e0:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043ca1e4:   ldr	x14, [x14, #16]
  0x00000001043ca1e8:   ldr	x12, [x2, #16]
  0x00000001043ca1ec:   cmp	w12, #0x0
  0x00000001043ca1f0:   b.ge	0x00000001043ca1f8  // b.tcont
  0x00000001043ca1f4:   hlt	#0x0
  0x00000001043ca1f8:   ldr	w11, [x10, #180]
  0x00000001043ca1fc:   add	x11, x10, x11, uxtx #3
  0x00000001043ca200:   add	x11, x11, #0x1e8
  0x00000001043ca204:   add	x10, x10, x12, uxtx #3
  0x00000001043ca208:   ldr	x12, [x11]
  0x00000001043ca20c:   cmp	x14, x12
  0x00000001043ca210:   b.eq	0x00000001043ca224  // b.none
  0x00000001043ca214:   cbz	x12, 0x00000001043ca244
  0x00000001043ca218:   ldr	x12, [x11, #16]!
  0x00000001043ca21c:   cmp	x14, x12
  0x00000001043ca220:   b.ne	0x00000001043ca214  // b.any
  0x00000001043ca224:   ldr	w11, [x11, #8]
  0x00000001043ca228:   ldr	x12, [x10, w11, uxtw]
  0x00000001043ca22c:   cbz	x12, 0x00000001043ca238
  0x00000001043ca230:   ldr	x8, [x12, #88]
  0x00000001043ca234:   br	x8
  0x00000001043ca238:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043ca23c:   add	x8, x8, #0x900
  0x00000001043ca240:   br	x8
  0x00000001043ca244:   adrp	x8, 0x0000000104315000      ;   {runtime_call IncompatibleClassChangeError throw_exception}
  0x00000001043ca248:   add	x8, x8, #0x880
  0x00000001043ca24c:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 255   14     n       java.lang.invoke.MethodHandle::linkToStatic(L)L (native)
 total in heap  [0x00000001043ca688,0x00000001043ca830] = 424
 relocation     [0x00000001043ca770,0x00000001043ca788] = 24
 main code      [0x00000001043ca7c0,0x00000001043ca830] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011857c0f8} 'linkToStatic' '(Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043ca7c0:   nop
 ;; verify_klass {
  0x00000001043ca7c4:   cbz	x1, 0x00000001043ca7fc
  0x00000001043ca7c8:   stp	x8, x9, [sp, #-16]!
  0x00000001043ca7cc:   ldr	w9, [x1, #8]
  0x00000001043ca7d0:   eor	x9, x9, #0x400000000000
  0x00000001043ca7d4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043ca7d8:   ldr	x8, [x8, #1528]
  0x00000001043ca7dc:   cmp	x9, x8
  0x00000001043ca7e0:   b.eq	0x00000001043ca808  // b.none
  0x00000001043ca7e4:   ldr	x9, [x9, #64]
  0x00000001043ca7e8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043ca7ec:   ldr	x8, [x8, #1528]
  0x00000001043ca7f0:   cmp	x9, x8
  0x00000001043ca7f4:   b.eq	0x00000001043ca808  // b.none
  0x00000001043ca7f8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043ca7fc:   dcps1	#0xdeae
  0x00000001043ca800:   .inst	0x03aa865f ; undefined
  0x00000001043ca804:   udf	#1
 ;; L_ok:
  0x00000001043ca808:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043ca80c:   ldr	w12, [x1, #36]
  0x00000001043ca810:   lsl	x12, x12, #3
  0x00000001043ca814:   ldr	x12, [x12, #16]
  0x00000001043ca818:   cbz	x12, 0x00000001043ca824
  0x00000001043ca81c:   ldr	x8, [x12, #88]
  0x00000001043ca820:   br	x8
  0x00000001043ca824:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043ca828:   add	x8, x8, #0x900
  0x00000001043ca82c:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 259   15     n       java.lang.invoke.MethodHandle::linkToStatic(LLLL)L (native)
 total in heap  [0x00000001043cb088,0x00000001043cb230] = 424
 relocation     [0x00000001043cb170,0x00000001043cb188] = 24
 main code      [0x00000001043cb1c0,0x00000001043cb230] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118531740} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043cb1c0:   nop
 ;; verify_klass {
  0x00000001043cb1c4:   cbz	x4, 0x00000001043cb1fc
  0x00000001043cb1c8:   stp	x8, x9, [sp, #-16]!
  0x00000001043cb1cc:   ldr	w9, [x4, #8]
  0x00000001043cb1d0:   eor	x9, x9, #0x400000000000
  0x00000001043cb1d4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cb1d8:   ldr	x8, [x8, #1528]
  0x00000001043cb1dc:   cmp	x9, x8
  0x00000001043cb1e0:   b.eq	0x00000001043cb208  // b.none
  0x00000001043cb1e4:   ldr	x9, [x9, #64]
  0x00000001043cb1e8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cb1ec:   ldr	x8, [x8, #1528]
  0x00000001043cb1f0:   cmp	x9, x8
  0x00000001043cb1f4:   b.eq	0x00000001043cb208  // b.none
  0x00000001043cb1f8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043cb1fc:   dcps1	#0xdeae
  0x00000001043cb200:   .inst	0x03aa865f ; undefined
  0x00000001043cb204:   udf	#1
 ;; L_ok:
  0x00000001043cb208:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cb20c:   ldr	w12, [x4, #36]
  0x00000001043cb210:   lsl	x12, x12, #3
  0x00000001043cb214:   ldr	x12, [x12, #16]
  0x00000001043cb218:   cbz	x12, 0x00000001043cb224
  0x00000001043cb21c:   ldr	x8, [x12, #88]
  0x00000001043cb220:   br	x8
  0x00000001043cb224:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043cb228:   add	x8, x8, #0x900
  0x00000001043cb22c:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 262   16     n       java.lang.invoke.MethodHandle::invokeBasic()L (native)
 total in heap  [0x00000001043cba88,0x00000001043cbbb8] = 304
 relocation     [0x00000001043cbb70,0x00000001043cbb78] = 8
 main code      [0x00000001043cbb80,0x00000001043cbbb8] = 56

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118535d38} 'invokeBasic' '()Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  #           [sp+0x0]  (sp of caller)
  0x00000001043cbb80:   nop
 ;; jump_to_lambda_form {
  0x00000001043cbb84:   ldr	w12, [x1, #20]
  0x00000001043cbb88:   lsl	x12, x12, #3
  0x00000001043cbb8c:   ldr	w12, [x12, #40]
  0x00000001043cbb90:   lsl	x12, x12, #3
  0x00000001043cbb94:   ldr	w12, [x12, #36]
  0x00000001043cbb98:   lsl	x12, x12, #3
  0x00000001043cbb9c:   ldr	x12, [x12, #16]
  0x00000001043cbba0:   cbz	x12, 0x00000001043cbbac
  0x00000001043cbba4:   ldr	x8, [x12, #88]
  0x00000001043cbba8:   br	x8
  0x00000001043cbbac:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043cbbb0:   add	x8, x8, #0x900
  0x00000001043cbbb4:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 262   17     n       java.lang.invoke.MethodHandle::linkToSpecial(LL)L (native)
 total in heap  [0x00000001043cbd88,0x00000001043cc018] = 656
 relocation     [0x00000001043cbe70,0x00000001043cbea8] = 56
 main code      [0x00000001043cbec0,0x00000001043cc014] = 340
 stub code      [0x00000001043cc014,0x00000001043cc018] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118535e70} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043cbec0:   nop
 ;; verify_klass {
  0x00000001043cbec4:   cbz	x2, 0x00000001043cbefc
  0x00000001043cbec8:   stp	x8, x9, [sp, #-16]!
  0x00000001043cbecc:   ldr	w9, [x2, #8]
  0x00000001043cbed0:   eor	x9, x9, #0x400000000000
  0x00000001043cbed4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cbed8:   ldr	x8, [x8, #1528]
  0x00000001043cbedc:   cmp	x9, x8
  0x00000001043cbee0:   b.eq	0x00000001043cbf08  // b.none
  0x00000001043cbee4:   ldr	x9, [x9, #64]
  0x00000001043cbee8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cbeec:   ldr	x8, [x8, #1528]
  0x00000001043cbef0:   cmp	x9, x8
  0x00000001043cbef4:   b.eq	0x00000001043cbf08  // b.none
  0x00000001043cbef8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043cbefc:   dcps1	#0xdeae
  0x00000001043cbf00:   .inst	0x03aa865f ; undefined
  0x00000001043cbf04:   udf	#1
 ;; L_ok:
  0x00000001043cbf08:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cbf0c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043cbf10:   ldr	w10, [x1, #8]
  0x00000001043cbf14:   eor	x10, x10, #0x400000000000
  0x00000001043cbf18:   ldr	w11, [x2, #24]
  0x00000001043cbf1c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043cbf20:   cbz	x11, 0x00000001043cbf58
  0x00000001043cbf24:   stp	x8, x9, [sp, #-16]!
  0x00000001043cbf28:   ldr	w9, [x11, #8]
  0x00000001043cbf2c:   eor	x9, x9, #0x400000000000
  0x00000001043cbf30:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cbf34:   ldr	x8, [x8, #1064]
  0x00000001043cbf38:   cmp	x9, x8
  0x00000001043cbf3c:   b.eq	0x00000001043cbf64  // b.none
  0x00000001043cbf40:   ldr	x9, [x9, #64]
  0x00000001043cbf44:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cbf48:   ldr	x8, [x8, #1064]
  0x00000001043cbf4c:   cmp	x9, x8
  0x00000001043cbf50:   b.eq	0x00000001043cbf64  // b.none
  0x00000001043cbf54:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043cbf58:   dcps1	#0xdeae
  0x00000001043cbf5c:   .inst	0x03aa81bf ; undefined
  0x00000001043cbf60:   udf	#1
 ;; L_ok:
  0x00000001043cbf64:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cbf68:   ldr	x11, [x11, #16]
  0x00000001043cbf6c:   cmp	x10, x11
  0x00000001043cbf70:   b.eq	0x00000001043cbff0  // b.none
  0x00000001043cbf74:   ldr	w14, [x11, #24]
  0x00000001043cbf78:   ldr	x8, [x10, x14]
  0x00000001043cbf7c:   cmp	x11, x8
  0x00000001043cbf80:   b.eq	0x00000001043cbff0  // b.none
  0x00000001043cbf84:   cmp	x14, #0x28
  0x00000001043cbf88:   b.ne	0x00000001043cbfec  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043cbf8c:   stp	x0, x2, [sp, #-32]!
  0x00000001043cbf90:   stp	x5, xzr, [sp, #16]
  0x00000001043cbf94:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043cbf98:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043cbf9c:   movk	x9, #0x3d0, lsl #16
  0x00000001043cbfa0:   movk	x9, #0x1, lsl #32
  0x00000001043cbfa4:   ldr	w8, [x9]
  0x00000001043cbfa8:   add	w8, w8, #0x1
  0x00000001043cbfac:   str	w8, [x9]
  0x00000001043cbfb0:   ldr	x5, [x10, #48]
  0x00000001043cbfb4:   ldr	w2, [x5]
  0x00000001043cbfb8:   add	x5, x5, #0x8
  0x00000001043cbfbc:   cmp	sp, xzr
  0x00000001043cbfc0:   cbz	x2, 0x00000001043cbfd8
  0x00000001043cbfc4:   ldr	x8, [x5], #8
  0x00000001043cbfc8:   cmp	x0, x8
  0x00000001043cbfcc:   b.eq	0x00000001043cbfd8  // b.none
  0x00000001043cbfd0:   sub	x2, x2, #0x1
  0x00000001043cbfd4:   cbnz	x2, 0x00000001043cbfc4
  0x00000001043cbfd8:   ldp	x5, xzr, [sp, #16]
  0x00000001043cbfdc:   ldp	x0, x2, [sp], #32
  0x00000001043cbfe0:   b.ne	0x00000001043cbfec  // b.any
  0x00000001043cbfe4:   str	x11, [x10, #40]
  0x00000001043cbfe8:   b	0x00000001043cbff0
  0x00000001043cbfec:   hlt	#0x0
 ;; } check_receiver
  0x00000001043cbff0:   ldr	w12, [x2, #36]
  0x00000001043cbff4:   lsl	x12, x12, #3
  0x00000001043cbff8:   ldr	x12, [x12, #16]
  0x00000001043cbffc:   cbz	x12, 0x00000001043cc008
  0x00000001043cc000:   ldr	x8, [x12, #88]
  0x00000001043cc004:   br	x8
  0x00000001043cc008:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043cc00c:   add	x8, x8, #0x900
  0x00000001043cc010:   br	x8
[Stub Code]
  0x00000001043cc014:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 269   18     n       java.lang.invoke.MethodHandle::linkToSpecial(LL)V (native)
 total in heap  [0x00000001043cc088,0x00000001043cc318] = 656
 relocation     [0x00000001043cc170,0x00000001043cc1a8] = 56
 main code      [0x00000001043cc1c0,0x00000001043cc314] = 340
 stub code      [0x00000001043cc314,0x00000001043cc318] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118607ba8} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043cc1c0:   nop
 ;; verify_klass {
  0x00000001043cc1c4:   cbz	x2, 0x00000001043cc1fc
  0x00000001043cc1c8:   stp	x8, x9, [sp, #-16]!
  0x00000001043cc1cc:   ldr	w9, [x2, #8]
  0x00000001043cc1d0:   eor	x9, x9, #0x400000000000
  0x00000001043cc1d4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cc1d8:   ldr	x8, [x8, #1528]
  0x00000001043cc1dc:   cmp	x9, x8
  0x00000001043cc1e0:   b.eq	0x00000001043cc208  // b.none
  0x00000001043cc1e4:   ldr	x9, [x9, #64]
  0x00000001043cc1e8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cc1ec:   ldr	x8, [x8, #1528]
  0x00000001043cc1f0:   cmp	x9, x8
  0x00000001043cc1f4:   b.eq	0x00000001043cc208  // b.none
  0x00000001043cc1f8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043cc1fc:   dcps1	#0xdeae
  0x00000001043cc200:   .inst	0x03aa865f ; undefined
  0x00000001043cc204:   udf	#1
 ;; L_ok:
  0x00000001043cc208:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cc20c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043cc210:   ldr	w10, [x1, #8]
  0x00000001043cc214:   eor	x10, x10, #0x400000000000
  0x00000001043cc218:   ldr	w11, [x2, #24]
  0x00000001043cc21c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043cc220:   cbz	x11, 0x00000001043cc258
  0x00000001043cc224:   stp	x8, x9, [sp, #-16]!
  0x00000001043cc228:   ldr	w9, [x11, #8]
  0x00000001043cc22c:   eor	x9, x9, #0x400000000000
  0x00000001043cc230:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cc234:   ldr	x8, [x8, #1064]
  0x00000001043cc238:   cmp	x9, x8
  0x00000001043cc23c:   b.eq	0x00000001043cc264  // b.none
  0x00000001043cc240:   ldr	x9, [x9, #64]
  0x00000001043cc244:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cc248:   ldr	x8, [x8, #1064]
  0x00000001043cc24c:   cmp	x9, x8
  0x00000001043cc250:   b.eq	0x00000001043cc264  // b.none
  0x00000001043cc254:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043cc258:   dcps1	#0xdeae
  0x00000001043cc25c:   .inst	0x03aa81bf ; undefined
  0x00000001043cc260:   udf	#1
 ;; L_ok:
  0x00000001043cc264:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cc268:   ldr	x11, [x11, #16]
  0x00000001043cc26c:   cmp	x10, x11
  0x00000001043cc270:   b.eq	0x00000001043cc2f0  // b.none
  0x00000001043cc274:   ldr	w14, [x11, #24]
  0x00000001043cc278:   ldr	x8, [x10, x14]
  0x00000001043cc27c:   cmp	x11, x8
  0x00000001043cc280:   b.eq	0x00000001043cc2f0  // b.none
  0x00000001043cc284:   cmp	x14, #0x28
  0x00000001043cc288:   b.ne	0x00000001043cc2ec  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043cc28c:   stp	x0, x2, [sp, #-32]!
  0x00000001043cc290:   stp	x5, xzr, [sp, #16]
  0x00000001043cc294:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043cc298:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043cc29c:   movk	x9, #0x3d0, lsl #16
  0x00000001043cc2a0:   movk	x9, #0x1, lsl #32
  0x00000001043cc2a4:   ldr	w8, [x9]
  0x00000001043cc2a8:   add	w8, w8, #0x1
  0x00000001043cc2ac:   str	w8, [x9]
  0x00000001043cc2b0:   ldr	x5, [x10, #48]
  0x00000001043cc2b4:   ldr	w2, [x5]
  0x00000001043cc2b8:   add	x5, x5, #0x8
  0x00000001043cc2bc:   cmp	sp, xzr
  0x00000001043cc2c0:   cbz	x2, 0x00000001043cc2d8
  0x00000001043cc2c4:   ldr	x8, [x5], #8
  0x00000001043cc2c8:   cmp	x0, x8
  0x00000001043cc2cc:   b.eq	0x00000001043cc2d8  // b.none
  0x00000001043cc2d0:   sub	x2, x2, #0x1
  0x00000001043cc2d4:   cbnz	x2, 0x00000001043cc2c4
  0x00000001043cc2d8:   ldp	x5, xzr, [sp, #16]
  0x00000001043cc2dc:   ldp	x0, x2, [sp], #32
  0x00000001043cc2e0:   b.ne	0x00000001043cc2ec  // b.any
  0x00000001043cc2e4:   str	x11, [x10, #40]
  0x00000001043cc2e8:   b	0x00000001043cc2f0
  0x00000001043cc2ec:   hlt	#0x0
 ;; } check_receiver
  0x00000001043cc2f0:   ldr	w12, [x2, #36]
  0x00000001043cc2f4:   lsl	x12, x12, #3
  0x00000001043cc2f8:   ldr	x12, [x12, #16]
  0x00000001043cc2fc:   cbz	x12, 0x00000001043cc308
  0x00000001043cc300:   ldr	x8, [x12, #88]
  0x00000001043cc304:   br	x8
  0x00000001043cc308:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043cc30c:   add	x8, x8, #0x900
  0x00000001043cc310:   br	x8
[Stub Code]
  0x00000001043cc314:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 274   19     n       java.lang.invoke.MethodHandle::linkToInterface(LLL)I (native)
 total in heap  [0x00000001043cc388,0x00000001043cc5d0] = 584
 relocation     [0x00000001043cc470,0x00000001043cc4a0] = 48
 main code      [0x00000001043cc4c0,0x00000001043cc5d0] = 272

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011860a560} 'linkToInterface' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043cc4c0:   nop
 ;; verify_klass {
  0x00000001043cc4c4:   cbz	x3, 0x00000001043cc4fc
  0x00000001043cc4c8:   stp	x8, x9, [sp, #-16]!
  0x00000001043cc4cc:   ldr	w9, [x3, #8]
  0x00000001043cc4d0:   eor	x9, x9, #0x400000000000
  0x00000001043cc4d4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cc4d8:   ldr	x8, [x8, #1528]
  0x00000001043cc4dc:   cmp	x9, x8
  0x00000001043cc4e0:   b.eq	0x00000001043cc508  // b.none
  0x00000001043cc4e4:   ldr	x9, [x9, #64]
  0x00000001043cc4e8:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cc4ec:   ldr	x8, [x8, #1528]
  0x00000001043cc4f0:   cmp	x9, x8
  0x00000001043cc4f4:   b.eq	0x00000001043cc508  // b.none
  0x00000001043cc4f8:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043cc4fc:   dcps1	#0xdeae
  0x00000001043cc500:   .inst	0x03aa865f ; undefined
  0x00000001043cc504:   udf	#1
 ;; L_ok:
  0x00000001043cc508:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cc50c:   ldr	w10, [x1, #8]
  0x00000001043cc510:   eor	x10, x10, #0x400000000000
 ;; check_receiver {
 ;; } check_receiver
  0x00000001043cc514:   ldr	w14, [x3, #24]
  0x00000001043cc518:   lsl	x14, x14, #3
 ;; verify_klass {
  0x00000001043cc51c:   cbz	x14, 0x00000001043cc554
  0x00000001043cc520:   stp	x8, x9, [sp, #-16]!
  0x00000001043cc524:   ldr	w9, [x14, #8]
  0x00000001043cc528:   eor	x9, x9, #0x400000000000
  0x00000001043cc52c:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cc530:   ldr	x8, [x8, #1064]
  0x00000001043cc534:   cmp	x9, x8
  0x00000001043cc538:   b.eq	0x00000001043cc560  // b.none
  0x00000001043cc53c:   ldr	x9, [x9, #64]
  0x00000001043cc540:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cc544:   ldr	x8, [x8, #1064]
  0x00000001043cc548:   cmp	x9, x8
  0x00000001043cc54c:   b.eq	0x00000001043cc560  // b.none
  0x00000001043cc550:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043cc554:   dcps1	#0xdeae
  0x00000001043cc558:   .inst	0x03aa81bf ; undefined
  0x00000001043cc55c:   udf	#1
 ;; L_ok:
  0x00000001043cc560:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cc564:   ldr	x14, [x14, #16]
  0x00000001043cc568:   ldr	x12, [x3, #16]
  0x00000001043cc56c:   cmp	w12, #0x0
  0x00000001043cc570:   b.ge	0x00000001043cc578  // b.tcont
  0x00000001043cc574:   hlt	#0x0
  0x00000001043cc578:   ldr	w11, [x10, #180]
  0x00000001043cc57c:   add	x11, x10, x11, uxtx #3
  0x00000001043cc580:   add	x11, x11, #0x1e8
  0x00000001043cc584:   add	x10, x10, x12, uxtx #3
  0x00000001043cc588:   ldr	x12, [x11]
  0x00000001043cc58c:   cmp	x14, x12
  0x00000001043cc590:   b.eq	0x00000001043cc5a4  // b.none
  0x00000001043cc594:   cbz	x12, 0x00000001043cc5c4
  0x00000001043cc598:   ldr	x12, [x11, #16]!
  0x00000001043cc59c:   cmp	x14, x12
  0x00000001043cc5a0:   b.ne	0x00000001043cc594  // b.any
  0x00000001043cc5a4:   ldr	w11, [x11, #8]
  0x00000001043cc5a8:   ldr	x12, [x10, w11, uxtw]
  0x00000001043cc5ac:   cbz	x12, 0x00000001043cc5b8
  0x00000001043cc5b0:   ldr	x8, [x12, #88]
  0x00000001043cc5b4:   br	x8
  0x00000001043cc5b8:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043cc5bc:   add	x8, x8, #0x900
  0x00000001043cc5c0:   br	x8
  0x00000001043cc5c4:   adrp	x8, 0x0000000104315000      ;   {runtime_call IncompatibleClassChangeError throw_exception}
  0x00000001043cc5c8:   add	x8, x8, #0x880
  0x00000001043cc5cc:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 282   20     n       java.lang.invoke.MethodHandle::linkToStatic(LL)I (native)
 total in heap  [0x00000001043cca08,0x00000001043ccbb0] = 424
 relocation     [0x00000001043ccaf0,0x00000001043ccb08] = 24
 main code      [0x00000001043ccb40,0x00000001043ccbb0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118615be8} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043ccb40:   nop
 ;; verify_klass {
  0x00000001043ccb44:   cbz	x2, 0x00000001043ccb7c
  0x00000001043ccb48:   stp	x8, x9, [sp, #-16]!
  0x00000001043ccb4c:   ldr	w9, [x2, #8]
  0x00000001043ccb50:   eor	x9, x9, #0x400000000000
  0x00000001043ccb54:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043ccb58:   ldr	x8, [x8, #1528]
  0x00000001043ccb5c:   cmp	x9, x8
  0x00000001043ccb60:   b.eq	0x00000001043ccb88  // b.none
  0x00000001043ccb64:   ldr	x9, [x9, #64]
  0x00000001043ccb68:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043ccb6c:   ldr	x8, [x8, #1528]
  0x00000001043ccb70:   cmp	x9, x8
  0x00000001043ccb74:   b.eq	0x00000001043ccb88  // b.none
  0x00000001043ccb78:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043ccb7c:   dcps1	#0xdeae
  0x00000001043ccb80:   .inst	0x03aa865f ; undefined
  0x00000001043ccb84:   udf	#1
 ;; L_ok:
  0x00000001043ccb88:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043ccb8c:   ldr	w12, [x2, #36]
  0x00000001043ccb90:   lsl	x12, x12, #3
  0x00000001043ccb94:   ldr	x12, [x12, #16]
  0x00000001043ccb98:   cbz	x12, 0x00000001043ccba4
  0x00000001043ccb9c:   ldr	x8, [x12, #88]
  0x00000001043ccba0:   br	x8
  0x00000001043ccba4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043ccba8:   add	x8, x8, #0x900
  0x00000001043ccbac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 285   21     n       java.lang.invoke.MethodHandle::linkToStatic(LLL)I (native)
 total in heap  [0x00000001043ccd08,0x00000001043cceb0] = 424
 relocation     [0x00000001043ccdf0,0x00000001043cce08] = 24
 main code      [0x00000001043cce40,0x00000001043cceb0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118617d10} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043cce40:   nop
 ;; verify_klass {
  0x00000001043cce44:   cbz	x3, 0x00000001043cce7c
  0x00000001043cce48:   stp	x8, x9, [sp, #-16]!
  0x00000001043cce4c:   ldr	w9, [x3, #8]
  0x00000001043cce50:   eor	x9, x9, #0x400000000000
  0x00000001043cce54:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cce58:   ldr	x8, [x8, #1528]
  0x00000001043cce5c:   cmp	x9, x8
  0x00000001043cce60:   b.eq	0x00000001043cce88  // b.none
  0x00000001043cce64:   ldr	x9, [x9, #64]
  0x00000001043cce68:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cce6c:   ldr	x8, [x8, #1528]
  0x00000001043cce70:   cmp	x9, x8
  0x00000001043cce74:   b.eq	0x00000001043cce88  // b.none
  0x00000001043cce78:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043cce7c:   dcps1	#0xdeae
  0x00000001043cce80:   .inst	0x03aa865f ; undefined
  0x00000001043cce84:   udf	#1
 ;; L_ok:
  0x00000001043cce88:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cce8c:   ldr	w12, [x3, #36]
  0x00000001043cce90:   lsl	x12, x12, #3
  0x00000001043cce94:   ldr	x12, [x12, #16]
  0x00000001043cce98:   cbz	x12, 0x00000001043ccea4
  0x00000001043cce9c:   ldr	x8, [x12, #88]
  0x00000001043ccea0:   br	x8
  0x00000001043ccea4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043ccea8:   add	x8, x8, #0x900
  0x00000001043cceac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 287   22     n       java.lang.invoke.MethodHandle::linkToVirtual(LL)L (native)
 total in heap  [0x00000001043cd008,0x00000001043cd2a0] = 664
 relocation     [0x00000001043cd0f0,0x00000001043cd128] = 56
 main code      [0x00000001043cd140,0x00000001043cd29c] = 348
 stub code      [0x00000001043cd29c,0x00000001043cd2a0] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118618290} 'linkToVirtual' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043cd140:   nop
 ;; verify_klass {
  0x00000001043cd144:   cbz	x2, 0x00000001043cd17c
  0x00000001043cd148:   stp	x8, x9, [sp, #-16]!
  0x00000001043cd14c:   ldr	w9, [x2, #8]
  0x00000001043cd150:   eor	x9, x9, #0x400000000000
  0x00000001043cd154:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cd158:   ldr	x8, [x8, #1528]
  0x00000001043cd15c:   cmp	x9, x8
  0x00000001043cd160:   b.eq	0x00000001043cd188  // b.none
  0x00000001043cd164:   ldr	x9, [x9, #64]
  0x00000001043cd168:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cd16c:   ldr	x8, [x8, #1528]
  0x00000001043cd170:   cmp	x9, x8
  0x00000001043cd174:   b.eq	0x00000001043cd188  // b.none
  0x00000001043cd178:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043cd17c:   dcps1	#0xdeae
  0x00000001043cd180:   .inst	0x03aa865f ; undefined
  0x00000001043cd184:   udf	#1
 ;; L_ok:
  0x00000001043cd188:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cd18c:   ldr	w10, [x1, #8]
  0x00000001043cd190:   eor	x10, x10, #0x400000000000
 ;; check_receiver {
  0x00000001043cd194:   ldr	w11, [x2, #24]
  0x00000001043cd198:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043cd19c:   cbz	x11, 0x00000001043cd1d4
  0x00000001043cd1a0:   stp	x8, x9, [sp, #-16]!
  0x00000001043cd1a4:   ldr	w9, [x11, #8]
  0x00000001043cd1a8:   eor	x9, x9, #0x400000000000
  0x00000001043cd1ac:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cd1b0:   ldr	x8, [x8, #1064]
  0x00000001043cd1b4:   cmp	x9, x8
  0x00000001043cd1b8:   b.eq	0x00000001043cd1e0  // b.none
  0x00000001043cd1bc:   ldr	x9, [x9, #64]
  0x00000001043cd1c0:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cd1c4:   ldr	x8, [x8, #1064]
  0x00000001043cd1c8:   cmp	x9, x8
  0x00000001043cd1cc:   b.eq	0x00000001043cd1e0  // b.none
  0x00000001043cd1d0:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043cd1d4:   dcps1	#0xdeae
  0x00000001043cd1d8:   .inst	0x03aa81bf ; undefined
  0x00000001043cd1dc:   udf	#1
 ;; L_ok:
  0x00000001043cd1e0:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cd1e4:   ldr	x11, [x11, #16]
  0x00000001043cd1e8:   cmp	x10, x11
  0x00000001043cd1ec:   b.eq	0x00000001043cd26c  // b.none
  0x00000001043cd1f0:   ldr	w14, [x11, #24]
  0x00000001043cd1f4:   ldr	x8, [x10, x14]
  0x00000001043cd1f8:   cmp	x11, x8
  0x00000001043cd1fc:   b.eq	0x00000001043cd26c  // b.none
  0x00000001043cd200:   cmp	x14, #0x28
  0x00000001043cd204:   b.ne	0x00000001043cd268  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043cd208:   stp	x0, x2, [sp, #-32]!
  0x00000001043cd20c:   stp	x5, xzr, [sp, #16]
  0x00000001043cd210:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043cd214:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043cd218:   movk	x9, #0x3d0, lsl #16
  0x00000001043cd21c:   movk	x9, #0x1, lsl #32
  0x00000001043cd220:   ldr	w8, [x9]
  0x00000001043cd224:   add	w8, w8, #0x1
  0x00000001043cd228:   str	w8, [x9]
  0x00000001043cd22c:   ldr	x5, [x10, #48]
  0x00000001043cd230:   ldr	w2, [x5]
  0x00000001043cd234:   add	x5, x5, #0x8
  0x00000001043cd238:   cmp	sp, xzr
  0x00000001043cd23c:   cbz	x2, 0x00000001043cd254
  0x00000001043cd240:   ldr	x8, [x5], #8
  0x00000001043cd244:   cmp	x0, x8
  0x00000001043cd248:   b.eq	0x00000001043cd254  // b.none
  0x00000001043cd24c:   sub	x2, x2, #0x1
  0x00000001043cd250:   cbnz	x2, 0x00000001043cd240
  0x00000001043cd254:   ldp	x5, xzr, [sp, #16]
  0x00000001043cd258:   ldp	x0, x2, [sp], #32
  0x00000001043cd25c:   b.ne	0x00000001043cd268  // b.any
  0x00000001043cd260:   str	x11, [x10, #40]
  0x00000001043cd264:   b	0x00000001043cd26c
  0x00000001043cd268:   hlt	#0x0
 ;; } check_receiver
  0x00000001043cd26c:   ldr	x11, [x2, #16]
  0x00000001043cd270:   cmp	w11, #0x0
  0x00000001043cd274:   b.ge	0x00000001043cd27c  // b.tcont
  0x00000001043cd278:   hlt	#0x0
 ;; L_index_ok:
  0x00000001043cd27c:   add	x12, x10, x11, uxtx #3
  0x00000001043cd280:   ldr	x12, [x12, #488]
  0x00000001043cd284:   cbz	x12, 0x00000001043cd290
  0x00000001043cd288:   ldr	x8, [x12, #88]
  0x00000001043cd28c:   br	x8
  0x00000001043cd290:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043cd294:   add	x8, x8, #0x900
  0x00000001043cd298:   br	x8
[Stub Code]
  0x00000001043cd29c:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 292   23     n       java.lang.invoke.MethodHandle::linkToSpecial(LL)I (native)
 total in heap  [0x00000001043cd308,0x00000001043cd598] = 656
 relocation     [0x00000001043cd3f0,0x00000001043cd428] = 56
 main code      [0x00000001043cd440,0x00000001043cd594] = 340
 stub code      [0x00000001043cd594,0x00000001043cd598] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118622568} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043cd440:   nop
 ;; verify_klass {
  0x00000001043cd444:   cbz	x2, 0x00000001043cd47c
  0x00000001043cd448:   stp	x8, x9, [sp, #-16]!
  0x00000001043cd44c:   ldr	w9, [x2, #8]
  0x00000001043cd450:   eor	x9, x9, #0x400000000000
  0x00000001043cd454:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cd458:   ldr	x8, [x8, #1528]
  0x00000001043cd45c:   cmp	x9, x8
  0x00000001043cd460:   b.eq	0x00000001043cd488  // b.none
  0x00000001043cd464:   ldr	x9, [x9, #64]
  0x00000001043cd468:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cd46c:   ldr	x8, [x8, #1528]
  0x00000001043cd470:   cmp	x9, x8
  0x00000001043cd474:   b.eq	0x00000001043cd488  // b.none
  0x00000001043cd478:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043cd47c:   dcps1	#0xdeae
  0x00000001043cd480:   .inst	0x03aa865f ; undefined
  0x00000001043cd484:   udf	#1
 ;; L_ok:
  0x00000001043cd488:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cd48c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043cd490:   ldr	w10, [x1, #8]
  0x00000001043cd494:   eor	x10, x10, #0x400000000000
  0x00000001043cd498:   ldr	w11, [x2, #24]
  0x00000001043cd49c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043cd4a0:   cbz	x11, 0x00000001043cd4d8
  0x00000001043cd4a4:   stp	x8, x9, [sp, #-16]!
  0x00000001043cd4a8:   ldr	w9, [x11, #8]
  0x00000001043cd4ac:   eor	x9, x9, #0x400000000000
  0x00000001043cd4b0:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cd4b4:   ldr	x8, [x8, #1064]
  0x00000001043cd4b8:   cmp	x9, x8
  0x00000001043cd4bc:   b.eq	0x00000001043cd4e4  // b.none
  0x00000001043cd4c0:   ldr	x9, [x9, #64]
  0x00000001043cd4c4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043cd4c8:   ldr	x8, [x8, #1064]
  0x00000001043cd4cc:   cmp	x9, x8
  0x00000001043cd4d0:   b.eq	0x00000001043cd4e4  // b.none
  0x00000001043cd4d4:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043cd4d8:   dcps1	#0xdeae
  0x00000001043cd4dc:   .inst	0x03aa81bf ; undefined
  0x00000001043cd4e0:   udf	#1
 ;; L_ok:
  0x00000001043cd4e4:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043cd4e8:   ldr	x11, [x11, #16]
  0x00000001043cd4ec:   cmp	x10, x11
  0x00000001043cd4f0:   b.eq	0x00000001043cd570  // b.none
  0x00000001043cd4f4:   ldr	w14, [x11, #24]
  0x00000001043cd4f8:   ldr	x8, [x10, x14]
  0x00000001043cd4fc:   cmp	x11, x8
  0x00000001043cd500:   b.eq	0x00000001043cd570  // b.none
  0x00000001043cd504:   cmp	x14, #0x28
  0x00000001043cd508:   b.ne	0x00000001043cd56c  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043cd50c:   stp	x0, x2, [sp, #-32]!
  0x00000001043cd510:   stp	x5, xzr, [sp, #16]
  0x00000001043cd514:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043cd518:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043cd51c:   movk	x9, #0x3d0, lsl #16
  0x00000001043cd520:   movk	x9, #0x1, lsl #32
  0x00000001043cd524:   ldr	w8, [x9]
  0x00000001043cd528:   add	w8, w8, #0x1
  0x00000001043cd52c:   str	w8, [x9]
  0x00000001043cd530:   ldr	x5, [x10, #48]
  0x00000001043cd534:   ldr	w2, [x5]
  0x00000001043cd538:   add	x5, x5, #0x8
  0x00000001043cd53c:   cmp	sp, xzr
  0x00000001043cd540:   cbz	x2, 0x00000001043cd558
  0x00000001043cd544:   ldr	x8, [x5], #8
  0x00000001043cd548:   cmp	x0, x8
  0x00000001043cd54c:   b.eq	0x00000001043cd558  // b.none
  0x00000001043cd550:   sub	x2, x2, #0x1
  0x00000001043cd554:   cbnz	x2, 0x00000001043cd544
  0x00000001043cd558:   ldp	x5, xzr, [sp, #16]
  0x00000001043cd55c:   ldp	x0, x2, [sp], #32
  0x00000001043cd560:   b.ne	0x00000001043cd56c  // b.any
  0x00000001043cd564:   str	x11, [x10, #40]
  0x00000001043cd568:   b	0x00000001043cd570
  0x00000001043cd56c:   hlt	#0x0
 ;; } check_receiver
  0x00000001043cd570:   ldr	w12, [x2, #36]
  0x00000001043cd574:   lsl	x12, x12, #3
  0x00000001043cd578:   ldr	x12, [x12, #16]
  0x00000001043cd57c:   cbz	x12, 0x00000001043cd588
  0x00000001043cd580:   ldr	x8, [x12, #88]
  0x00000001043cd584:   br	x8
  0x00000001043cd588:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043cd58c:   add	x8, x8, #0x900
  0x00000001043cd590:   br	x8
[Stub Code]
  0x00000001043cd594:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 316   24     n       jdk.internal.vm.Continuation::enterSpecial (native)
 total in heap  [0x00000001043cd988,0x00000001043cdd38] = 944
 relocation     [0x00000001043cda70,0x00000001043cdaa0] = 48
 main code      [0x00000001043cdac0,0x00000001043cdcc8] = 520
 stub code      [0x00000001043cdcc8,0x00000001043cdd28] = 96
 metadata       [0x00000001043cdd28,0x00000001043cdd38] = 16

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Entry Point]
  # {method} {0x0000000118095258} 'enterSpecial' '(Ljdk/internal/vm/Continuation;ZZ)V' in 'jdk/internal/vm/Continuation'
  # parm0:    c_rarg1:c_rarg1
                        = 'jdk/internal/vm/Continuation'
  # parm1:    c_rarg2   = boolean
  # parm2:    c_rarg3   = boolean
  #           [sp+0x50]  (sp of caller)
  0x00000001043cdac0:   ldr	w8, [x28, #1592]
  0x00000001043cdac4:   cbnz	w8, 0x00000001043cdad4
 ;; enterSpecial interpreter entry called when not in interp_only_mode
  0x00000001043cdac8:   dcps1	#0xdeae
  0x00000001043cdacc:   .inst	0x03adb77e ; undefined
  0x00000001043cdad0:   udf	#1
 ;; merged ldr pair
  0x00000001043cdad4:   ldp	x2, x1, [x20, #8]
  0x00000001043cdad8:   ldr	x3, [x20]
  0x00000001043cdadc:   ldr	x8, [x28, #1432]
  0x00000001043cdae0:   cmp	sp, x8
  0x00000001043cdae4:   b.ls	0x00000001043cdaf0  // b.plast
  0x00000001043cdae8:   mov	x8, sp
  0x00000001043cdaec:   str	x8, [x28, #1432]
  0x00000001043cdaf0:   stp	x29, x30, [sp, #-16]!
  0x00000001043cdaf4:   mov	x29, sp
  0x00000001043cdaf8:   sub	sp, sp, #0x40
  0x00000001043cdafc:   ldr	x8, [x28, #1424]
  0x00000001043cdb00:   str	x8, [sp, #8]
  0x00000001043cdb04:   mov	x8, sp
  0x00000001043cdb08:   str	x8, [x28, #1424]
 ;; 0x1234
  0x00000001043cdb0c:   mov	w8, #0x1234                	// #4660
  0x00000001043cdb10:   str	w8, [sp, #4]
  0x00000001043cdb14:   str	x1, [sp, #16]
  0x00000001043cdb18:   str	w3, [sp, #32]
  0x00000001043cdb1c:   str	xzr, [sp, #24]
  0x00000001043cdb20:   str	wzr, [sp, #36]
  0x00000001043cdb24:   str	wzr, [sp, #56]
  0x00000001043cdb28:   ldr	x8, [x28, #1432]
  0x00000001043cdb2c:   str	x8, [sp, #40]
  0x00000001043cdb30:   ldr	x8, [x28, #1448]
  0x00000001043cdb34:   str	x8, [sp, #48]
  0x00000001043cdb38:   str	xzr, [x28, #1432]
  0x00000001043cdb3c:   str	xzr, [x28, #1448]
  0x00000001043cdb40:   cbnz	x2, 0x00000001043cdbe8
  0x00000001043cdb44:   bl	0x000000010438a780          ; ImmutableOopMap {}
                                                            ;   {static_call}
  0x00000001043cdb48:   nop                                 ;   {other}
  0x00000001043cdb4c:   movk	xzr, #0x1c0
  0x00000001043cdb50:   movk	xzr, #0x0
  0x00000001043cdb54:   b	0x00000001043cdc00
  0x00000001043cdb58:   nop
  0x00000001043cdb5c:   nop
  0x00000001043cdb60:   nop
  0x00000001043cdb64:   nop
  0x00000001043cdb68:   nop
  0x00000001043cdb6c:   nop
  0x00000001043cdb70:   nop
  0x00000001043cdb74:   nop
  0x00000001043cdb78:   nop
  0x00000001043cdb7c:   nop
[Verified Entry Point]
  0x00000001043cdb80:   stp	x29, x30, [sp, #-16]!
  0x00000001043cdb84:   mov	x29, sp
  0x00000001043cdb88:   sub	sp, sp, #0x40
  0x00000001043cdb8c:   ldr	x8, [x28, #1424]
  0x00000001043cdb90:   str	x8, [sp, #8]
  0x00000001043cdb94:   mov	x8, sp
  0x00000001043cdb98:   str	x8, [x28, #1424]
 ;; 0x1234
  0x00000001043cdb9c:   mov	w8, #0x1234                	// #4660
  0x00000001043cdba0:   str	w8, [sp, #4]
  0x00000001043cdba4:   str	x1, [sp, #16]
  0x00000001043cdba8:   str	w3, [sp, #32]
  0x00000001043cdbac:   str	xzr, [sp, #24]
  0x00000001043cdbb0:   str	wzr, [sp, #36]
  0x00000001043cdbb4:   str	wzr, [sp, #56]
  0x00000001043cdbb8:   ldr	x8, [x28, #1432]
  0x00000001043cdbbc:   str	x8, [sp, #40]
  0x00000001043cdbc0:   ldr	x8, [x28, #1448]
  0x00000001043cdbc4:   str	x8, [sp, #48]
  0x00000001043cdbc8:   str	xzr, [x28, #1432]
  0x00000001043cdbcc:   str	xzr, [x28, #1448]
  0x00000001043cdbd0:   cbnz	x2, 0x00000001043cdbe8
  0x00000001043cdbd4:   bl	0x000000010438a780          ; ImmutableOopMap {}
                                                            ;   {static_call}
  0x00000001043cdbd8:   nop                                 ;   {other}
  0x00000001043cdbdc:   movk	xzr, #0x250
  0x00000001043cdbe0:   movk	xzr, #0x100
  0x00000001043cdbe4:   b	0x00000001043cdc00
  0x00000001043cdbe8:   adrp	x8, 0x00000001042bb000      ;   {runtime_call StubRoutines (continuation stubs)}
  0x00000001043cdbec:   add	x8, x8, #0x500
  0x00000001043cdbf0:   blr	x8
  0x00000001043cdbf4:   nop                                 ;   {other}
  0x00000001043cdbf8:   movk	xzr, #0x26c
  0x00000001043cdbfc:   movk	xzr, #0x200
  0x00000001043cdc00:   ldr	x8, [x28, #1424]
  0x00000001043cdc04:   cmp	sp, x8
  0x00000001043cdc08:   b.eq	0x00000001043cdc18  // b.none
 ;; incorrect sp1
  0x00000001043cdc0c:   dcps1	#0xdeae
  0x00000001043cdc10:   .inst	0x03adb8f1 ; undefined
  0x00000001043cdc14:   udf	#1
  0x00000001043cdc18:   ldr	x8, [sp, #40]
  0x00000001043cdc1c:   str	x8, [x28, #1432]
  0x00000001043cdc20:   ldr	w8, [sp, #32]
  0x00000001043cdc24:   cbz	w8, 0x00000001043cdc2c
  0x00000001043cdc28:   str	xzr, [x28, #1456]
  0x00000001043cdc2c:   ldr	x8, [sp, #48]
  0x00000001043cdc30:   str	x8, [x28, #1448]
  0x00000001043cdc34:   ldr	x9, [sp, #8]
  0x00000001043cdc38:   str	x9, [x28, #1424]
  0x00000001043cdc3c:   add	x29, sp, #0x40
  0x00000001043cdc40:   mov	sp, x29
  0x00000001043cdc44:   ldp	x29, x30, [sp], #16
  0x00000001043cdc48:   ret
[Exception Handler]
  0x00000001043cdc4c:   mov	x19, x0
  0x00000001043cdc50:   ldr	x8, [x28, #1424]
  0x00000001043cdc54:   cmp	sp, x8
  0x00000001043cdc58:   b.eq	0x00000001043cdc68  // b.none
 ;; incorrect sp1
  0x00000001043cdc5c:   dcps1	#0xdeae
  0x00000001043cdc60:   .inst	0x03adb8f1 ; undefined
  0x00000001043cdc64:   udf	#1
  0x00000001043cdc68:   ldr	x8, [sp, #40]
  0x00000001043cdc6c:   str	x8, [x28, #1432]
  0x00000001043cdc70:   ldr	w8, [sp, #32]
  0x00000001043cdc74:   cbz	w8, 0x00000001043cdc7c
  0x00000001043cdc78:   str	xzr, [x28, #1456]
  0x00000001043cdc7c:   ldr	x8, [sp, #48]
  0x00000001043cdc80:   str	x8, [x28, #1448]
  0x00000001043cdc84:   ldr	x9, [sp, #8]
  0x00000001043cdc88:   str	x9, [x28, #1424]
  0x00000001043cdc8c:   add	x29, sp, #0x40
  0x00000001043cdc90:   ldr	x1, [x29, #8]
  0x00000001043cdc94:   mov	x0, x28
  0x00000001043cdc98:   stp	x8, x12, [sp, #-16]!
 ;; 0x103521148
  0x00000001043cdc9c:   mov	x8, #0x1148                	// #4424
  0x00000001043cdca0:   movk	x8, #0x352, lsl #16
  0x00000001043cdca4:   movk	x8, #0x1, lsl #32
  0x00000001043cdca8:   blr	x8
  0x00000001043cdcac:   ldp	x8, x12, [sp], #16
  0x00000001043cdcb0:   mov	x1, x0
  0x00000001043cdcb4:   mov	x0, x19
  0x00000001043cdcb8:   mov	sp, x29
  0x00000001043cdcbc:   ldp	x29, x30, [sp], #16
  0x00000001043cdcc0:   mov	x3, x30
  0x00000001043cdcc4:   br	x1
[Stub Code]
  0x00000001043cdcc8:   ldr	x8, 0x00000001043cdcd0      ;   {no_reloc}
  0x00000001043cdccc:   br	x8
  0x00000001043cdcd0:   adr	z0.d, [z28.d, z24.d, sxtw #1]
  0x00000001043cdcd4:   udf	#1
  0x00000001043cdcd8:   isb                                 ;   {static_stub}
  0x00000001043cdcdc:   mov	x12, #0x0                   	// #0
                                                            ;   {metadata(nullptr)}
  0x00000001043cdce0:   movk	x12, #0x0, lsl #16
  0x00000001043cdce4:   movk	x12, #0x0, lsl #32
  0x00000001043cdce8:   mov	x8, #0x0                   	// #0
  0x00000001043cdcec:   movk	x8, #0x0, lsl #16
  0x00000001043cdcf0:   movk	x8, #0x0, lsl #32
  0x00000001043cdcf4:   br	x8
  0x00000001043cdcf8:   ldr	x8, 0x00000001043cdd00      ;   {trampoline_stub}
  0x00000001043cdcfc:   br	x8
  0x00000001043cdd00:   adr	z0.d, [z28.d, z24.d, sxtw #1]
  0x00000001043cdd04:   udf	#1
  0x00000001043cdd08:   isb                                 ;   {static_stub}
  0x00000001043cdd0c:   mov	x12, #0x0                   	// #0
                                                            ;   {metadata(nullptr)}
  0x00000001043cdd10:   movk	x12, #0x0, lsl #16
  0x00000001043cdd14:   movk	x12, #0x0, lsl #32
  0x00000001043cdd18:   mov	x8, #0x0                   	// #0
  0x00000001043cdd1c:   movk	x8, #0x0, lsl #16
  0x00000001043cdd20:   movk	x8, #0x0, lsl #32
  0x00000001043cdd24:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 319   25     n       jdk.internal.vm.Continuation::doYield (native)
 total in heap  [0x00000001043cdd88,0x00000001043cdf50] = 456
 relocation     [0x00000001043cde70,0x00000001043cde78] = 8
 main code      [0x00000001043cde80,0x00000001043cdf4c] = 204
 stub code      [0x00000001043cdf4c,0x00000001043cdf50] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118095188} 'doYield' '()I' in 'jdk/internal/vm/Continuation'
  #           [sp+0x10]  (sp of caller)
  0x00000001043cde80:   stp	x29, x30, [sp, #-16]!
  0x00000001043cde84:   mov	x29, sp
  0x00000001043cde88:   mov	x1, sp
  0x00000001043cde8c:   nop                                 ;   {other}
  0x00000001043cde90:   movk	xzr, #0x104
  0x00000001043cde94:   movk	xzr, #0x0
  0x00000001043cde98:   mov	x0, x28
  0x00000001043cde9c:   adr	x8, 0x00000001043cde8c
  0x00000001043cdea0:   str	x8, [x28, #1008]
  0x00000001043cdea4:   mov	x8, sp
  0x00000001043cdea8:   str	x8, [x28, #1000]
  0x00000001043cdeac:   str	x29, [x28, #1016]
  0x00000001043cdeb0:   stp	x8, x12, [sp, #-16]!
 ;; 0x102AE84D8
  0x00000001043cdeb4:   mov	x8, #0x84d8                	// #34008
  0x00000001043cdeb8:   movk	x8, #0x2ae, lsl #16
  0x00000001043cdebc:   movk	x8, #0x1, lsl #32
  0x00000001043cdec0:   blr	x8
  0x00000001043cdec4:   ldp	x8, x12, [sp], #16
  0x00000001043cdec8:   str	xzr, [x28, #1000]
  0x00000001043cdecc:   str	xzr, [x28, #1016]
  0x00000001043cded0:   str	xzr, [x28, #1008]
  0x00000001043cded4:   cbnz	x0, 0x00000001043cdf20
  0x00000001043cded8:   ldr	x8, [x28, #1424]
  0x00000001043cdedc:   mov	sp, x8
  0x00000001043cdee0:   ldr	x8, [x28, #1424]
  0x00000001043cdee4:   cmp	sp, x8
  0x00000001043cdee8:   b.eq	0x00000001043cdef8  // b.none
 ;; incorrect sp1
  0x00000001043cdeec:   dcps1	#0xdeae
  0x00000001043cdef0:   .inst	0x03adb8f1 ; undefined
  0x00000001043cdef4:   udf	#1
  0x00000001043cdef8:   ldr	x8, [sp, #40]
  0x00000001043cdefc:   str	x8, [x28, #1432]
  0x00000001043cdf00:   ldr	w8, [sp, #32]
  0x00000001043cdf04:   cbz	w8, 0x00000001043cdf0c
  0x00000001043cdf08:   str	xzr, [x28, #1456]
  0x00000001043cdf0c:   ldr	x8, [sp, #48]
  0x00000001043cdf10:   str	x8, [x28, #1448]
  0x00000001043cdf14:   ldr	x9, [sp, #8]
  0x00000001043cdf18:   str	x9, [x28, #1424]
  0x00000001043cdf1c:   add	x29, sp, #0x40
  0x00000001043cdf20:   ldr	x8, [x28, #8]
  0x00000001043cdf24:   cbz	x8, 0x00000001043cdf40
  0x00000001043cdf28:   mov	sp, x29
  0x00000001043cdf2c:   ldp	x29, x30, [sp], #16
 ;; 0x1042B8080
  0x00000001043cdf30:   mov	x8, #0x8080                	// #32896
                                                            ;   {runtime_call StubRoutines (initial stubs)}
  0x00000001043cdf34:   movk	x8, #0x42b, lsl #16
  0x00000001043cdf38:   movk	x8, #0x1, lsl #32
  0x00000001043cdf3c:   br	x8
  0x00000001043cdf40:   mov	sp, x29
  0x00000001043cdf44:   ldp	x29, x30, [sp], #16
  0x00000001043cdf48:   ret
[Stub Code]
  0x00000001043cdf4c:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 407   26     n       java.lang.invoke.MethodHandle::linkToStatic(LLL)V (native)
 total in heap  [0x00000001043d1408,0x00000001043d15b0] = 424
 relocation     [0x00000001043d14f0,0x00000001043d1508] = 24
 main code      [0x00000001043d1540,0x00000001043d15b0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001186ff788} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d1540:   nop
 ;; verify_klass {
  0x00000001043d1544:   cbz	x3, 0x00000001043d157c
  0x00000001043d1548:   stp	x8, x9, [sp, #-16]!
  0x00000001043d154c:   ldr	w9, [x3, #8]
  0x00000001043d1550:   eor	x9, x9, #0x400000000000
  0x00000001043d1554:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d1558:   ldr	x8, [x8, #1528]
  0x00000001043d155c:   cmp	x9, x8
  0x00000001043d1560:   b.eq	0x00000001043d1588  // b.none
  0x00000001043d1564:   ldr	x9, [x9, #64]
  0x00000001043d1568:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d156c:   ldr	x8, [x8, #1528]
  0x00000001043d1570:   cmp	x9, x8
  0x00000001043d1574:   b.eq	0x00000001043d1588  // b.none
  0x00000001043d1578:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043d157c:   dcps1	#0xdeae
  0x00000001043d1580:   .inst	0x03aa865f ; undefined
  0x00000001043d1584:   udf	#1
 ;; L_ok:
  0x00000001043d1588:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043d158c:   ldr	w12, [x3, #36]
  0x00000001043d1590:   lsl	x12, x12, #3
  0x00000001043d1594:   ldr	x12, [x12, #16]
  0x00000001043d1598:   cbz	x12, 0x00000001043d15a4
  0x00000001043d159c:   ldr	x8, [x12, #88]
  0x00000001043d15a0:   br	x8
  0x00000001043d15a4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d15a8:   add	x8, x8, #0x900
  0x00000001043d15ac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 409   27     n       java.lang.invoke.MethodHandle::invokeBasic(LL)V (native)
 total in heap  [0x00000001043d1708,0x00000001043d1838] = 304
 relocation     [0x00000001043d17f0,0x00000001043d17f8] = 8
 main code      [0x00000001043d1800,0x00000001043d1838] = 56

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001186ff8c0} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;)V' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d1800:   nop
 ;; jump_to_lambda_form {
  0x00000001043d1804:   ldr	w12, [x1, #20]
  0x00000001043d1808:   lsl	x12, x12, #3
  0x00000001043d180c:   ldr	w12, [x12, #40]
  0x00000001043d1810:   lsl	x12, x12, #3
  0x00000001043d1814:   ldr	w12, [x12, #36]
  0x00000001043d1818:   lsl	x12, x12, #3
  0x00000001043d181c:   ldr	x12, [x12, #16]
  0x00000001043d1820:   cbz	x12, 0x00000001043d182c
  0x00000001043d1824:   ldr	x8, [x12, #88]
  0x00000001043d1828:   br	x8
  0x00000001043d182c:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d1830:   add	x8, x8, #0x900
  0x00000001043d1834:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 413   28     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLL)L (native)
 total in heap  [0x00000001043d1a08,0x00000001043d1bb0] = 424
 relocation     [0x00000001043d1af0,0x00000001043d1b08] = 24
 main code      [0x00000001043d1b40,0x00000001043d1bb0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001187839c8} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d1b40:   nop
 ;; verify_klass {
  0x00000001043d1b44:   cbz	x5, 0x00000001043d1b7c
  0x00000001043d1b48:   stp	x8, x9, [sp, #-16]!
  0x00000001043d1b4c:   ldr	w9, [x5, #8]
  0x00000001043d1b50:   eor	x9, x9, #0x400000000000
  0x00000001043d1b54:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d1b58:   ldr	x8, [x8, #1528]
  0x00000001043d1b5c:   cmp	x9, x8
  0x00000001043d1b60:   b.eq	0x00000001043d1b88  // b.none
  0x00000001043d1b64:   ldr	x9, [x9, #64]
  0x00000001043d1b68:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d1b6c:   ldr	x8, [x8, #1528]
  0x00000001043d1b70:   cmp	x9, x8
  0x00000001043d1b74:   b.eq	0x00000001043d1b88  // b.none
  0x00000001043d1b78:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043d1b7c:   dcps1	#0xdeae
  0x00000001043d1b80:   .inst	0x03aa865f ; undefined
  0x00000001043d1b84:   udf	#1
 ;; L_ok:
  0x00000001043d1b88:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043d1b8c:   ldr	w12, [x5, #36]
  0x00000001043d1b90:   lsl	x12, x12, #3
  0x00000001043d1b94:   ldr	x12, [x12, #16]
  0x00000001043d1b98:   cbz	x12, 0x00000001043d1ba4
  0x00000001043d1b9c:   ldr	x8, [x12, #88]
  0x00000001043d1ba0:   br	x8
  0x00000001043d1ba4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d1ba8:   add	x8, x8, #0x900
  0x00000001043d1bac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 415   29     n       java.lang.invoke.MethodHandle::invokeBasic(LLLL)L (native)
 total in heap  [0x00000001043d1d08,0x00000001043d1e38] = 304
 relocation     [0x00000001043d1df0,0x00000001043d1df8] = 8
 main code      [0x00000001043d1e00,0x00000001043d1e38] = 56

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118783eb8} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm3:    c_rarg5:c_rarg5
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d1e00:   nop
 ;; jump_to_lambda_form {
  0x00000001043d1e04:   ldr	w12, [x1, #20]
  0x00000001043d1e08:   lsl	x12, x12, #3
  0x00000001043d1e0c:   ldr	w12, [x12, #40]
  0x00000001043d1e10:   lsl	x12, x12, #3
  0x00000001043d1e14:   ldr	w12, [x12, #36]
  0x00000001043d1e18:   lsl	x12, x12, #3
  0x00000001043d1e1c:   ldr	x12, [x12, #16]
  0x00000001043d1e20:   cbz	x12, 0x00000001043d1e2c
  0x00000001043d1e24:   ldr	x8, [x12, #88]
  0x00000001043d1e28:   br	x8
  0x00000001043d1e2c:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d1e30:   add	x8, x8, #0x900
  0x00000001043d1e34:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 418   30     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLLL)L (native)
 total in heap  [0x00000001043d2008,0x00000001043d21b0] = 424
 relocation     [0x00000001043d20f0,0x00000001043d2108] = 24
 main code      [0x00000001043d2140,0x00000001043d21b0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118785b40} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5
                        = 'java/lang/Object'
  # parm5:    c_rarg6:c_rarg6
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d2140:   nop
 ;; verify_klass {
  0x00000001043d2144:   cbz	x6, 0x00000001043d217c
  0x00000001043d2148:   stp	x8, x9, [sp, #-16]!
  0x00000001043d214c:   ldr	w9, [x6, #8]
  0x00000001043d2150:   eor	x9, x9, #0x400000000000
  0x00000001043d2154:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d2158:   ldr	x8, [x8, #1528]
  0x00000001043d215c:   cmp	x9, x8
  0x00000001043d2160:   b.eq	0x00000001043d2188  // b.none
  0x00000001043d2164:   ldr	x9, [x9, #64]
  0x00000001043d2168:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d216c:   ldr	x8, [x8, #1528]
  0x00000001043d2170:   cmp	x9, x8
  0x00000001043d2174:   b.eq	0x00000001043d2188  // b.none
  0x00000001043d2178:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043d217c:   dcps1	#0xdeae
  0x00000001043d2180:   .inst	0x03aa865f ; undefined
  0x00000001043d2184:   udf	#1
 ;; L_ok:
  0x00000001043d2188:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043d218c:   ldr	w12, [x6, #36]
  0x00000001043d2190:   lsl	x12, x12, #3
  0x00000001043d2194:   ldr	x12, [x12, #16]
  0x00000001043d2198:   cbz	x12, 0x00000001043d21a4
  0x00000001043d219c:   ldr	x8, [x12, #88]
  0x00000001043d21a0:   br	x8
  0x00000001043d21a4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d21a8:   add	x8, x8, #0x900
  0x00000001043d21ac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 420   31     n       java.lang.invoke.MethodHandle::invokeBasic(LLLLL)L (native)
 total in heap  [0x00000001043d2308,0x00000001043d2438] = 304
 relocation     [0x00000001043d23f0,0x00000001043d23f8] = 8
 main code      [0x00000001043d2400,0x00000001043d2438] = 56

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118785e70} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm3:    c_rarg5:c_rarg5
                        = 'java/lang/Object'
  # parm4:    c_rarg6:c_rarg6
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d2400:   nop
 ;; jump_to_lambda_form {
  0x00000001043d2404:   ldr	w12, [x1, #20]
  0x00000001043d2408:   lsl	x12, x12, #3
  0x00000001043d240c:   ldr	w12, [x12, #40]
  0x00000001043d2410:   lsl	x12, x12, #3
  0x00000001043d2414:   ldr	w12, [x12, #36]
  0x00000001043d2418:   lsl	x12, x12, #3
  0x00000001043d241c:   ldr	x12, [x12, #16]
  0x00000001043d2420:   cbz	x12, 0x00000001043d242c
  0x00000001043d2424:   ldr	x8, [x12, #88]
  0x00000001043d2428:   br	x8
  0x00000001043d242c:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d2430:   add	x8, x8, #0x900
  0x00000001043d2434:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 421   32     n       java.lang.invoke.MethodHandle::invokeBasic(LLL)L (native)
 total in heap  [0x00000001043d2608,0x00000001043d2738] = 304
 relocation     [0x00000001043d26f0,0x00000001043d26f8] = 8
 main code      [0x00000001043d2700,0x00000001043d2738] = 56

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001187861a0} 'invokeBasic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # this:     c_rarg1:c_rarg1
                        = 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm1:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm2:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d2700:   nop
 ;; jump_to_lambda_form {
  0x00000001043d2704:   ldr	w12, [x1, #20]
  0x00000001043d2708:   lsl	x12, x12, #3
  0x00000001043d270c:   ldr	w12, [x12, #40]
  0x00000001043d2710:   lsl	x12, x12, #3
  0x00000001043d2714:   ldr	w12, [x12, #36]
  0x00000001043d2718:   lsl	x12, x12, #3
  0x00000001043d271c:   ldr	x12, [x12, #16]
  0x00000001043d2720:   cbz	x12, 0x00000001043d272c
  0x00000001043d2724:   ldr	x8, [x12, #88]
  0x00000001043d2728:   br	x8
  0x00000001043d272c:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d2730:   add	x8, x8, #0x900
  0x00000001043d2734:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 422   33     n       java.lang.invoke.MethodHandle::linkToSpecial(LLLLL)L (native)
 total in heap  [0x00000001043d2908,0x00000001043d2b98] = 656
 relocation     [0x00000001043d29f0,0x00000001043d2a28] = 56
 main code      [0x00000001043d2a40,0x00000001043d2b94] = 340
 stub code      [0x00000001043d2b94,0x00000001043d2b98] = 4

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001187862d8} 'linkToSpecial' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d2a40:   nop
 ;; verify_klass {
  0x00000001043d2a44:   cbz	x5, 0x00000001043d2a7c
  0x00000001043d2a48:   stp	x8, x9, [sp, #-16]!
  0x00000001043d2a4c:   ldr	w9, [x5, #8]
  0x00000001043d2a50:   eor	x9, x9, #0x400000000000
  0x00000001043d2a54:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d2a58:   ldr	x8, [x8, #1528]
  0x00000001043d2a5c:   cmp	x9, x8
  0x00000001043d2a60:   b.eq	0x00000001043d2a88  // b.none
  0x00000001043d2a64:   ldr	x9, [x9, #64]
  0x00000001043d2a68:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d2a6c:   ldr	x8, [x8, #1528]
  0x00000001043d2a70:   cmp	x9, x8
  0x00000001043d2a74:   b.eq	0x00000001043d2a88  // b.none
  0x00000001043d2a78:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043d2a7c:   dcps1	#0xdeae
  0x00000001043d2a80:   .inst	0x03aa865f ; undefined
  0x00000001043d2a84:   udf	#1
 ;; L_ok:
  0x00000001043d2a88:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043d2a8c:   ldr	xzr, [x1]
 ;; check_receiver {
  0x00000001043d2a90:   ldr	w10, [x1, #8]
  0x00000001043d2a94:   eor	x10, x10, #0x400000000000
  0x00000001043d2a98:   ldr	w11, [x5, #24]
  0x00000001043d2a9c:   lsl	x11, x11, #3
 ;; verify_klass {
  0x00000001043d2aa0:   cbz	x11, 0x00000001043d2ad8
  0x00000001043d2aa4:   stp	x8, x9, [sp, #-16]!
  0x00000001043d2aa8:   ldr	w9, [x11, #8]
  0x00000001043d2aac:   eor	x9, x9, #0x400000000000
  0x00000001043d2ab0:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d2ab4:   ldr	x8, [x8, #1064]
  0x00000001043d2ab8:   cmp	x9, x8
  0x00000001043d2abc:   b.eq	0x00000001043d2ae4  // b.none
  0x00000001043d2ac0:   ldr	x9, [x9, #64]
  0x00000001043d2ac4:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d2ac8:   ldr	x8, [x8, #1064]
  0x00000001043d2acc:   cmp	x9, x8
  0x00000001043d2ad0:   b.eq	0x00000001043d2ae4  // b.none
  0x00000001043d2ad4:   ldp	x8, x9, [sp], #16
 ;; MH argument is a Class
  0x00000001043d2ad8:   dcps1	#0xdeae
  0x00000001043d2adc:   .inst	0x03aa81bf ; undefined
  0x00000001043d2ae0:   udf	#1
 ;; L_ok:
  0x00000001043d2ae4:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043d2ae8:   ldr	x11, [x11, #16]
  0x00000001043d2aec:   cmp	x10, x11
  0x00000001043d2af0:   b.eq	0x00000001043d2b70  // b.none
  0x00000001043d2af4:   ldr	w14, [x11, #24]
  0x00000001043d2af8:   ldr	x8, [x10, x14]
  0x00000001043d2afc:   cmp	x11, x8
  0x00000001043d2b00:   b.eq	0x00000001043d2b70  // b.none
  0x00000001043d2b04:   cmp	x14, #0x28
  0x00000001043d2b08:   b.ne	0x00000001043d2b6c  // b.any
 ;; check_klass_subtype_slow_path
  0x00000001043d2b0c:   stp	x0, x2, [sp, #-32]!
  0x00000001043d2b10:   stp	x5, xzr, [sp, #16]
  0x00000001043d2b14:   mov	x0, x11
 ;; 0x103D01C40
  0x00000001043d2b18:   mov	x9, #0x1c40                	// #7232
                                                            ;   {external_word}
  0x00000001043d2b1c:   movk	x9, #0x3d0, lsl #16
  0x00000001043d2b20:   movk	x9, #0x1, lsl #32
  0x00000001043d2b24:   ldr	w8, [x9]
  0x00000001043d2b28:   add	w8, w8, #0x1
  0x00000001043d2b2c:   str	w8, [x9]
  0x00000001043d2b30:   ldr	x5, [x10, #48]
  0x00000001043d2b34:   ldr	w2, [x5]
  0x00000001043d2b38:   add	x5, x5, #0x8
  0x00000001043d2b3c:   cmp	sp, xzr
  0x00000001043d2b40:   cbz	x2, 0x00000001043d2b58
  0x00000001043d2b44:   ldr	x8, [x5], #8
  0x00000001043d2b48:   cmp	x0, x8
  0x00000001043d2b4c:   b.eq	0x00000001043d2b58  // b.none
  0x00000001043d2b50:   sub	x2, x2, #0x1
  0x00000001043d2b54:   cbnz	x2, 0x00000001043d2b44
  0x00000001043d2b58:   ldp	x5, xzr, [sp, #16]
  0x00000001043d2b5c:   ldp	x0, x2, [sp], #32
  0x00000001043d2b60:   b.ne	0x00000001043d2b6c  // b.any
  0x00000001043d2b64:   str	x11, [x10, #40]
  0x00000001043d2b68:   b	0x00000001043d2b70
  0x00000001043d2b6c:   hlt	#0x0
 ;; } check_receiver
  0x00000001043d2b70:   ldr	w12, [x5, #36]
  0x00000001043d2b74:   lsl	x12, x12, #3
  0x00000001043d2b78:   ldr	x12, [x12, #16]
  0x00000001043d2b7c:   cbz	x12, 0x00000001043d2b88
  0x00000001043d2b80:   ldr	x8, [x12, #88]
  0x00000001043d2b84:   br	x8
  0x00000001043d2b88:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d2b8c:   add	x8, x8, #0x900
  0x00000001043d2b90:   br	x8
[Stub Code]
  0x00000001043d2b94:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 456   34     n       java.lang.invoke.MethodHandle::linkToStatic(LL)V (native)
 total in heap  [0x00000001043d4c08,0x00000001043d4db0] = 424
 relocation     [0x00000001043d4cf0,0x00000001043d4d08] = 24
 main code      [0x00000001043d4d40,0x00000001043d4db0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x00000001187ffe98} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/invoke/MemberName;)V' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d4d40:   nop
 ;; verify_klass {
  0x00000001043d4d44:   cbz	x2, 0x00000001043d4d7c
  0x00000001043d4d48:   stp	x8, x9, [sp, #-16]!
  0x00000001043d4d4c:   ldr	w9, [x2, #8]
  0x00000001043d4d50:   eor	x9, x9, #0x400000000000
  0x00000001043d4d54:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d4d58:   ldr	x8, [x8, #1528]
  0x00000001043d4d5c:   cmp	x9, x8
  0x00000001043d4d60:   b.eq	0x00000001043d4d88  // b.none
  0x00000001043d4d64:   ldr	x9, [x9, #64]
  0x00000001043d4d68:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d4d6c:   ldr	x8, [x8, #1528]
  0x00000001043d4d70:   cmp	x9, x8
  0x00000001043d4d74:   b.eq	0x00000001043d4d88  // b.none
  0x00000001043d4d78:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043d4d7c:   dcps1	#0xdeae
  0x00000001043d4d80:   .inst	0x03aa865f ; undefined
  0x00000001043d4d84:   udf	#1
 ;; L_ok:
  0x00000001043d4d88:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043d4d8c:   ldr	w12, [x2, #36]
  0x00000001043d4d90:   lsl	x12, x12, #3
  0x00000001043d4d94:   ldr	x12, [x12, #16]
  0x00000001043d4d98:   cbz	x12, 0x00000001043d4da4
  0x00000001043d4d9c:   ldr	x8, [x12, #88]
  0x00000001043d4da0:   br	x8
  0x00000001043d4da4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d4da8:   add	x8, x8, #0x900
  0x00000001043d4dac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 468   35     n       java.lang.invoke.MethodHandle::linkToStatic(IL)I (native)
 total in heap  [0x00000001043d4f08,0x00000001043d50b0] = 424
 relocation     [0x00000001043d4ff0,0x00000001043d5008] = 24
 main code      [0x00000001043d5040,0x00000001043d50b0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x0000000118768228} 'linkToStatic' '(ILjava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1   = int
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d5040:   nop
 ;; verify_klass {
  0x00000001043d5044:   cbz	x2, 0x00000001043d507c
  0x00000001043d5048:   stp	x8, x9, [sp, #-16]!
  0x00000001043d504c:   ldr	w9, [x2, #8]
  0x00000001043d5050:   eor	x9, x9, #0x400000000000
  0x00000001043d5054:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d5058:   ldr	x8, [x8, #1528]
  0x00000001043d505c:   cmp	x9, x8
  0x00000001043d5060:   b.eq	0x00000001043d5088  // b.none
  0x00000001043d5064:   ldr	x9, [x9, #64]
  0x00000001043d5068:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d506c:   ldr	x8, [x8, #1528]
  0x00000001043d5070:   cmp	x9, x8
  0x00000001043d5074:   b.eq	0x00000001043d5088  // b.none
  0x00000001043d5078:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043d507c:   dcps1	#0xdeae
  0x00000001043d5080:   .inst	0x03aa865f ; undefined
  0x00000001043d5084:   udf	#1
 ;; L_ok:
  0x00000001043d5088:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043d508c:   ldr	w12, [x2, #36]
  0x00000001043d5090:   lsl	x12, x12, #3
  0x00000001043d5094:   ldr	x12, [x12, #16]
  0x00000001043d5098:   cbz	x12, 0x00000001043d50a4
  0x00000001043d509c:   ldr	x8, [x12, #88]
  0x00000001043d50a0:   br	x8
  0x00000001043d50a4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d50a8:   add	x8, x8, #0x900
  0x00000001043d50ac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

Compiled method (n/a) 482   36     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLL)I (native)
 total in heap  [0x00000001043d7908,0x00000001043d7ab0] = 424
 relocation     [0x00000001043d79f0,0x00000001043d7a08] = 24
 main code      [0x00000001043d7a40,0x00000001043d7ab0] = 112

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Verified Entry Point]
  # {method} {0x000000011872db68} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)I' in 'java/lang/invoke/MethodHandle'
  # parm0:    c_rarg1:c_rarg1
                        = 'java/lang/Object'
  # parm1:    c_rarg2:c_rarg2
                        = 'java/lang/Object'
  # parm2:    c_rarg3:c_rarg3
                        = 'java/lang/Object'
  # parm3:    c_rarg4:c_rarg4
                        = 'java/lang/Object'
  # parm4:    c_rarg5:c_rarg5
                        = 'java/lang/invoke/MemberName'
  #           [sp+0x0]  (sp of caller)
  0x00000001043d7a40:   nop
 ;; verify_klass {
  0x00000001043d7a44:   cbz	x5, 0x00000001043d7a7c
  0x00000001043d7a48:   stp	x8, x9, [sp, #-16]!
  0x00000001043d7a4c:   ldr	w9, [x5, #8]
  0x00000001043d7a50:   eor	x9, x9, #0x400000000000
  0x00000001043d7a54:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d7a58:   ldr	x8, [x8, #1528]
  0x00000001043d7a5c:   cmp	x9, x8
  0x00000001043d7a60:   b.eq	0x00000001043d7a88  // b.none
  0x00000001043d7a64:   ldr	x9, [x9, #64]
  0x00000001043d7a68:   adrp	x8, 0x0000000103d1b000      ;   {external_word}
  0x00000001043d7a6c:   ldr	x8, [x8, #1528]
  0x00000001043d7a70:   cmp	x9, x8
  0x00000001043d7a74:   b.eq	0x00000001043d7a88  // b.none
  0x00000001043d7a78:   ldp	x8, x9, [sp], #16
 ;; MemberName required for invokeVirtual etc.
  0x00000001043d7a7c:   dcps1	#0xdeae
  0x00000001043d7a80:   .inst	0x03aa865f ; undefined
  0x00000001043d7a84:   udf	#1
 ;; L_ok:
  0x00000001043d7a88:   ldp	x8, x9, [sp], #16
 ;; } verify_klass
  0x00000001043d7a8c:   ldr	w12, [x5, #36]
  0x00000001043d7a90:   lsl	x12, x12, #3
  0x00000001043d7a94:   ldr	x12, [x12, #16]
  0x00000001043d7a98:   cbz	x12, 0x00000001043d7aa4
  0x00000001043d7a9c:   ldr	x8, [x12, #88]
  0x00000001043d7aa0:   br	x8
  0x00000001043d7aa4:   adrp	x8, 0x000000010438f000      ;   {runtime_call AbstractMethodError throw_exception}
  0x00000001043d7aa8:   add	x8, x8, #0x900
  0x00000001043d7aac:   br	x8
--------------------------------------------------------------------------------
[/Disassembly]

============================= C2-compiled nmethod ==============================
#r020 c_rarg1:c_rarg1   : parm 0: java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable):NotNull *
# -- Old r31_sp -- Framesize: 80 --
#r223 r31_sp+76: in_preserve
#r222 r31_sp+72: return address
#r221 r31_sp+68: in_preserve
#r220 r31_sp+64: saved fp register
#r219 r31_sp+60: pad2, stack alignment
#r218 r31_sp+56: pad2, stack alignment
#r217 r31_sp+52: Fixed slot 1
#r216 r31_sp+48: Fixed slot 0
#r235 r31_sp+44: spill
#r234 r31_sp+40: spill
#r233 r31_sp+36: spill
#r232 r31_sp+32: spill
#r231 r31_sp+28: spill
#r230 r31_sp+24: spill
#r229 r31_sp+20: spill
#r228 r31_sp+16: spill
#r227 r31_sp+12: spill
#r226 r31_sp+ 8: spill
#r225 r31_sp+ 4: spill
#r224 r31_sp+ 0: spill
#
----------------------- MetaData before Compile_id = 37 ------------------------
{method}
 - this oop:          0x00000001180dc2e8
 - method holder:     'java/lang/AbstractStringBuilder'
 - constants:         0x00000001180d8ec0 constant pool [613]/operands[14] {0x00000001180d8ec0} for 'java/lang/AbstractStringBuilder' cache=0x000000011830d4f0
 - access:            0x2  private
 - flags:             0x4080  queued_for_compilation has_loops_flag_init
 - name:              'appendNull'
 - signature:         '()Ljava/lang/AbstractStringBuilder;'
 - max stack:         7
 - max locals:        3
 - size of params:    1
 - method size:       14
 - vtable index:      -2
 - i2i entry:         0x00000001042c0980
 - adapters:          AHE at 0x0000600003025d20: 0xb i2c: 0x000000010438eb00 c2i: 0x000000010438eb60 c2iUV: 0x000000010438eb2c c2iNCI: 0x000000010438eb9c
 - compiled entry     0x000000010438eb60
 - code size:         75
 - code start:        0x00000001180dc268
 - code end (excl):   0x00000001180dc2b3
 - method data:       0x0000000118806518
 - checked ex length: 0
 - linenumber start:  0x00000001180dc2b3
 - localvar length:   3
 - localvar start:    0x00000001180dc2c2

------------------------ OptoAssembly for Compile_id = 37 -----------------------
#
#  java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable) * ( java/lang/AbstractStringBuilder (java/lang/CharSequence,java/lang/Appendable):NotNull * )
#
000     N451: #	out( B1 ) <- BLOCK HEAD IS JUNK  Freq: 1
000     # MachUEPNode
	ldrw rscratch1, [j_rarg0 + oopDesc::klass_offset_in_bytes()]	# compressed klass
	ldrw r10, [rscratch2 + CompiledICData::speculated_klass_offset()]	# compressed klass
	cmpw rscratch1, r10
	bne, SharedRuntime::_ic_miss_stub


020     B1: #	out( B37 B2 ) <- BLOCK HEAD IS JUNK  Freq: 1
020     # stack bang size=80
	sub  sp, sp, #80
	stp  rfp, lr, [sp, #64]
	ldr  rscratch1, [guard]
	dmb ishld
	ldr  rscratch2, [rthread, #thread_disarmed_guard_value_offset]
	cmp  rscratch1, rscratch2
	b.eq skip
	blr #nmethod_entry_barrier_stub
	b skip
	guard: int

	skip:

060     ldrw  R10, [R1, #20]	# compressed ptr ! Field: java/lang/AbstractStringBuilder.value
064 +   spill R1 -> R19	# spill size = 64
068 +   decode_heap_oop R14, R10
06c     ldrw  R15, [R14, #12]	# range
070     NullCheck R14

070     B2: #	out( B6 B3 ) <- in( B1 )  Freq: 0.999999
070 +   ldrsbw  R12, [R1, #16]	# byte ! Field: java/lang/AbstractStringBuilder.coder
074 +   ldrw  R17, [R1, #12]	# int ! Field: java/lang/AbstractStringBuilder.count
078 +   asrvw  R11, R15, R12
07c     subw  R13, R17, R11
080 +   addw R11, R13, #4
084     addw R13, R17, #4
088 +   cmpw  R11, #0
08c     bgt  B6  P=0.152733 C=19701.000000

090     B3: #	out( B32 B4 ) <- in( B19 B2 )  Freq: 0.999996
090 +   decode_heap_oop R10, R10
094     cbweq   R12, B32  P=0.000000 C=6861.000000

098     B4: #	out( B31 B5 ) <- in( B3 )  Freq: 0.999995
098 +   mov R11, #110	# int
09c     cbeq   R10, B31  P=0.000001 C=-1.000000

0a0     B5: #	out( N451 ) <- in( B4 )  Freq: 0.999994
0a0 +   add R10, R10, R17, I2L #1	# ptr
0a4 +   strh  R11, [R10, #16]	# short
0a8     mov R11, #117	# int
0ac +   mov R12, #108	# int
0b0     strh  R11, [R10, #18]	# short
0b4 +   strh  R12, [R10, #20]	# short
0b8 +   strh  R12, [R10, #22]	# short
0bc +   strw  R13, [R19, #12]	# int ! Field: java/lang/AbstractStringBuilder.count
0c0     spill R19 -> R0	# spill size = 64
0c4 +   # pop frame 80
	ldp  lr, rfp, [sp,#64]
	add  sp, sp, #80
	# test polling word
	ldr  rscratch1, [rthread],#1168
	cmp  sp, rscratch1
	bhi #slow_path
0d8 +   ret	// return register

0dc     B6: #	out( B39 B7 ) <- in( B2 )  Freq: 0.152733
0dc +   spill R15 -> [sp, #0]	# spill size = 32
0e0 +   spill R13 -> [sp, #4]	# spill size = 32
0e0 +   spill R14 -> [sp, #8]	# spill size = 64
0e4 +   spill R17 -> [sp, #20]	# spill size = 32
0e8 +   spill R1 -> R29	# spill size = 64
0ec +   spill R13 -> R2	# spill size = 32
0f0     call,static 0x000000010438a180 	// ==>  java.lang.AbstractStringBuilder::newCapacity
        # java.lang.AbstractStringBuilder::ensureCapacityInternal @ bci:24 (line 246) L[0]=R29 L[1]=_ L[2]=_ STK[0]=R29 STK[1]=r31_sp + #8
        # java.lang.AbstractStringBuilder::appendNull @ bci:9 (line 639) L[0]=R29 L[1]=r31_sp + #20 L[2]=_
        # OopMap {rfp=Oop [8]=Oop off=244/0xf4}

100     B7: #	out( B36 B8 ) <- in( B6 )  Freq: 0.15273
        # Block is sole successor of call
100 +   spill R29 -> R19	# spill size = 64
104 +   ldrsbw  R10, [R19, #16]	# byte ! Field: java/lang/AbstractStringBuilder.coder
108 +   lslvw  R14, R0, R10
10c     spill [sp, #0] -> R11	# spill size = 32
110 +   cmpw  R11, R14
114 +   cselw R29, R11, R14 lt
118 +   cmpw  R14, R11
11c     beq  B36  P=0.000000 C=3020.000000

120     B8: #	out( B34 B9 ) <- in( B7 )  Freq: 0.15273
120 +   spill R14 -> R12	# spill size = 32
124 +   mov R10, #23	# long
128     # castII of R12
128     add  R12, R10, R12, sxtw
12c +   cmpw  R11, R29	# unsigned
130     blo  B34	# unsigned  P=0.000001 C=-1.000000

134     B9: #	out( B34 B10 ) <- in( B8 )  Freq: 0.15273
134 +   cmpw  R14, R29	# unsigned
138     blo  B34	# unsigned  P=0.000001 C=-1.000000

13c     B10: #	out( B29 B11 ) <- in( B9 )  Freq: 0.15273
13c +   and  R13, R12, #-8	# int
140 +   cmpw  R14, #1048576	# unsigned
144     bhi  B29	# unsigned  P=0.000001 C=-1.000000

148     B11: #	out( B29 B12 ) <- in( B10 )  Freq: 0.15273
148 +    -- 	// R28=Thread::current(), empty
148     ldr  R20, [R28, #456]	# ptr
14c +    -- 	// R28=Thread::current(), empty
14c     ldr  R11, [R28, #472]	# ptr
150 +   add R10, R20, R13	# ptr
154 +   cmp  R10, R11	 // ptr
158     bhs  B29	# unsigned  P=0.000100 C=-1.000000

15c     B12: #	out( B13 ) <- in( B11 )  Freq: 0.152714
15c +    -- 	// R28=Thread::current(), empty
15c     mov R11, #1	# long
160     str  R10, [R28, #456]	# ptr
164 +   str  R11, [R20]	# int
168 +   mov  R11, narrowklass: precise [byte (java/lang/Cloneable,java/io/Serializable): :Constant:exact *	# compressed klass ptr
170     prfm [R10, #384], PSTL1KEEP	# Prefetch into level 1 cache write keep
174 +   strw  R11, [R20, #8]	# compressed klass ptr
178 +   prfm [R10, #512], PSTL1KEEP	# Prefetch into level 1 cache write keep
17c +   strw  R14, [R20, #12]	# int
180 +   prfm [R10, #640], PSTL1KEEP	# Prefetch into level 1 cache write keep

184     B13: #	out( B33 B14 ) <- in( B30 B12 )  Freq: 0.15273
184
184 +   # checkcastPP of R20
184     lsr R11, R12, (#3 & 0x3f)
188     add R1, R20, #16	# ptr
18c +   encode_heap_oop_not_null R21, R20
1a0     cbweq   R29, B33  P=0.000001 C=-1.000000

1a4     B14: #	out( B20 B15 ) <- in( B13 )  Freq: 0.15273
1a4 +   spill [sp, #8] -> R10	# spill size = 64
1a8 +   add R0, R10, #16	# ptr
1ac +   cmpw  R29, R14
1b0     blt  B20  P=0.001000 C=-1.000000

1b4     B15: #	out( B16 ) <- in( B14 )  Freq: 0.152577
1b4 +   add R10, R13, #-16
1b8 +   lsr R2, R10, (#3 & 0x3f)
1bc     CALL, runtime leaf nofp 0x0000000104317480 jlong_disjoint_arraycopy
        No JVM State Info
        #

1cc     B16: #	out( B21 B17 ) <- in( B20 B15 B33 )  Freq: 0.15273
1cc     MEMBAR-store-store
1d0 +    -- 	// R28=Thread::current(), empty
1d0     ldrsbw  R10, [R28, #56]	# byte
1d4     cbwne   R10, B21  P=0.001000 C=-1.000000

1d8     B17: #	out( B19 B18 ) <- in( B35 B23 B21 B16 )  Freq: 0.15273
1d8 +   mov R10, R19	# ptr -> long
1dc     mov R11, R20	# ptr -> long
1e0 +   eor  R11, R11, R10	# int
1e4 +   lsr R11, R11, (#23 & 0x3f)
1e8 +   strw  R21, [R19, #20]	# compressed ptr ! Field: java/lang/AbstractStringBuilder.value
1ec     cbeq   R11, B19  P=0.001000 C=-1.000000

1f0     B18: #	out( B24 B19 ) <- in( B17 )  Freq: 0.152577
1f0 +   lsr R10, R10, (#9 & 0x3f)
1f4 +   adr  R11, 0x00000001072b8000	# Byte Map Base
200     add R0, R11, R10	# ptr
204 +   ldrsbw  R10, [R0]	# byte
208 +   cmpw  R10, #2
20c     bne  B24  P=0.001000 C=-1.000000

210     B19: #	out( B3 ) <- in( B28 B18 B17 )  Freq: 0.15273
210 +   ldrsbw  R12, [R19, #16]	# byte ! Field: java/lang/AbstractStringBuilder.coder
214     encode_heap_oop R10, R20
218     spill [sp, #4] -> R13	# spill size = 32
21c +   spill [sp, #20] -> R17	# spill size = 32
220 +   b  B3

224     B20: #	out( B16 ) <- in( B14 )  Freq: 0.00015273
224 +   sxtw  R2, R29	# i2l
228 +   add R12, R2, #16
22c +   and  R10, R12, #-8	# int
230 +   add R10, R20, R10	# ptr
234     sub  R11, R11, R12, LSR #3
238     ClearArray R11, R10
260 +   CALL, runtime leaf nofp 0x00000001043167c0 arrayof_jbyte_disjoint_arraycopy
        No JVM State Info
        #
270 +   b  B16

274     B21: #	out( B17 B22 ) <- in( B16 )  Freq: 0.000152728
274 +   ldrw  R11, [R19, #20]	# compressed ptr ! Field: java/lang/AbstractStringBuilder.value
278 +   decode_heap_oop R0, R11
27c     cbeq   R0, B17  P=0.500000 C=-1.000000

280     B22: #	out( B35 B23 ) <- in( B21 )  Freq: 7.63639e-05
280 +    -- 	// R28=Thread::current(), empty
280     ldr  R10, [R28, #40]	# int
284     cbeq   R10, B35  P=0.001000 C=-1.000000

288     B23: #	out( B17 ) <- in( B22 )  Freq: 7.62875e-05
288 +    -- 	// R28=Thread::current(), empty
288     ldr  R11, [R28, #48]	# ptr
28c +   add R12, R10, #-8
290 +   add R10, R11, R10	# ptr
294     str  R0, [R10, #-8]	# ptr
298 +    -- 	// R28=Thread::current(), empty
298     str  R12, [R28, #40]	# int
29c     b  B17

2a0     B24: #	out( B28 B25 ) <- in( B18 )  Freq: 0.000152577
2a0 +    -- 	// R28=Thread::current(), empty
2a0     ldr  R10, [R28, #72]	# ptr
2a4 +    -- 	// R28=Thread::current(), empty
2a4     ldr  R11, [R28, #64]	# int
2a4 +   membar_volatile
	dmb ish
2a8 +   ldrsbw  R12, [R0]	# byte
2ac     cbweq   R12, B28  P=0.500000 C=-1.000000

2b0     B25: #	out( B27 B26 ) <- in( B24 )  Freq: 7.62885e-05
2b0 +   storestore (elided)
	strb zr, [R0]	# byte
2b4     cbeq   R11, B27  P=0.500000 C=-1.000000

2b8     B26: #	out( B28 ) <- in( B25 )  Freq: 3.81443e-05
2b8 +   add R12, R11, #-8
2bc +   add R10, R10, R11	# ptr
2c0     str  R0, [R10, #-8]	# ptr
2c4 +    -- 	// R28=Thread::current(), empty
2c4     str  R12, [R28, #64]	# int
2c8     b  B28

2cc     B27: #	out( B28 ) <- in( B25 )  Freq: 3.81443e-05
2cc +    -- 	// R28=Thread::current(), empty
2cc     spill R28 -> R1	# spill size = 64
2d0 +   CALL, runtime leaf 0x0000000102c36b34 write_ref_field_post_entry
        No JVM State Info
        #

2f8     B28: #	out( B19 ) <- in( B27 B26 B24 )  Freq: 0.000152577
2f8     ldrw  R11, [R19, #20]	# compressed ptr ! Field: java/lang/AbstractStringBuilder.value
2fc +   decode_heap_oop R10, R11
300     spill R10 -> R20	# spill size = 64
304 +   b  B19

308     B29: #	out( B38 B30 ) <- in( B10 B11 )  Freq: 1.54303e-05
308 +   spill R14 -> [sp, #0]	# spill size = 32
30c +   spill R19 -> [sp, #24]	# spill size = 64
310 +   spill R12 -> [sp, #32]	# spill size = 64
310 +   spill R13 -> [sp, #40]	# spill size = 64
314 +   mov  R1, precise [byte (java/lang/Cloneable,java/io/Serializable): :Constant:exact *	# ptr

320     spill R14 -> R2	# spill size = 32
324     call,static 0x00000001043aa000 	// ==>  wrapper for: _new_array_nozero_Java
        # java.util.Arrays::copyOf @ bci:15 (line 3540) L[0]=r31_sp + #8 L[1]=r31_sp + #0 L[2]=_
        # java.lang.AbstractStringBuilder::ensureCapacityInternal @ bci:32 (line 245) L[0]=_ L[1]=_ L[2]=_ STK[0]=r31_sp + #24
        # java.lang.AbstractStringBuilder::appendNull @ bci:9 (line 639) L[0]=r31_sp + #24 L[1]=r31_sp + #20 L[2]=_
        # OopMap {[8]=Oop [24]=Oop off=808/0x328}

334     B30: #	out( B13 ) <- in( B29 )  Freq: 1.54299e-05
        # Block is sole successor of call
334 +   spill [sp, #0] -> R14	# spill size = 32
338 +   spill [sp, #24] -> R19	# spill size = 64
33c +   spill R0 -> R20	# spill size = 64
340 +   spill [sp, #32] -> R12	# spill size = 64
344 +   spill [sp, #40] -> R13	# spill size = 64
344 +   b  B13

348     B31: #	out( N451 ) <- in( B4 )  Freq: 1.01327e-06
348     ShouldNotReachHere

354     B32: #	out( N451 ) <- in( B3 )  Freq: 4.76835e-07
354 +   cmpw  R12, #0
358 +   csincw R29, zr, zr ne	# signed, int
35c     mov R1, #-187	# int
360     spill R19 -> [sp, #0]	# spill size = 64
364 +   spill R17 -> [sp, #8]	# spill size = 32
368 +   spill R10 -> [sp, #16]	# spill size = 64
36c     call,static 0x0000000104390f80 	// ==>  wrapper for: uncommon_trap(reason='unstable_if' action='reinterpret' debug_id='0')
        # java.lang.AbstractStringBuilder::appendNull @ bci:21 (line 641) L[0]=r31_sp + #0 L[1]=r31_sp + #8 L[2]=r31_sp + #16 STK[0]=R29
        # OopMap {[0]=Oop [16]=Oop off=880/0x370}
37c     ShouldNotReachHere

388     B33: #	out( B16 ) <- in( B13 )  Freq: 1.54758e-07
388 +   spill R1 -> R10	# spill size = 64
38c +   add R11, R11, #-2
390     ClearArray R11, R10
3b8
3b8 +   b  B16

3bc     B34: #	out( N451 ) <- in( B8 B9 )  Freq: 3.0546e-07
3bc +   mov R1, #-52	# int
3c0     spill R19 -> [sp, #0]	# spill size = 64
3c4 +   spill R14 -> [sp, #16]	# spill size = 32
3c8     call,static 0x0000000104390f80 	// ==>  wrapper for: uncommon_trap(reason='intrinsic_or_type_checked_inlining' action='make_not_entrant' debug_id='0')
        # java.util.Arrays::copyOf @ bci:15 (line 3540) L[0]=r31_sp + #8 L[1]=r31_sp + #16 L[2]=_ STK[0]=r31_sp + #16
        # java.lang.AbstractStringBuilder::ensureCapacityInternal @ bci:32 (line 245) L[0]=_ L[1]=_ L[2]=_ STK[0]=r31_sp + #0
        # java.lang.AbstractStringBuilder::appendNull @ bci:9 (line 639) L[0]=r31_sp + #0 L[1]=r31_sp + #20 L[2]=_
        # OopMap {[0]=Oop [8]=Oop off=972/0x3cc}
3d8     ShouldNotReachHere

3e4     B35: #	out( B17 ) <- in( B22 )  Freq: 7.63629e-08
3e4 +    -- 	// R28=Thread::current(), empty
3e4     spill R28 -> R1	# spill size = 64
3e8 +   CALL, runtime leaf 0x0000000102c368a8 write_ref_field_pre_entry
        No JVM State Info
        #
410 +   b  B17

414     B36: #	out( N451 ) <- in( B7 )  Freq: 7.28274e-08
414 +   mov R1, #-187	# int
418     spill R19 -> [sp, #0]	# spill size = 64
41c +   spill R11 -> [sp, #16]	# spill size = 32
420 +   spill R14 -> [sp, #24]	# spill size = 32
424     call,static 0x0000000104390f80 	// ==>  wrapper for: uncommon_trap(reason='unstable_if' action='reinterpret' debug_id='0')
        # java.util.Arrays::copyOf @ bci:3 (line 3537) L[0]=r31_sp + #8 L[1]=_ L[2]=_ STK[0]=r31_sp + #24 STK[1]=r31_sp + #16
        # java.lang.AbstractStringBuilder::ensureCapacityInternal @ bci:32 (line 245) L[0]=_ L[1]=_ L[2]=_ STK[0]=r31_sp + #0
        # java.lang.AbstractStringBuilder::appendNull @ bci:9 (line 639) L[0]=r31_sp + #0 L[1]=r31_sp + #20 L[2]=_
        # OopMap {[0]=Oop [8]=Oop off=1064/0x428}
434     ShouldNotReachHere

440     B37: #	out( N451 ) <- in( B1 )  Freq: 1.01328e-06
440 +   mov R1, #-10	# int
444     call,static 0x0000000104390f80 	// ==>  wrapper for: uncommon_trap(reason='null_check' action='maybe_recompile' debug_id='0')
        # java.lang.AbstractStringBuilder::ensureCapacityInternal @ bci:4 (line 243) L[0]=_ L[1]=_ L[2]=_ STK[0]=#null
        # java.lang.AbstractStringBuilder::appendNull @ bci:9 (line 639) L[0]=_ L[1]=_ L[2]=_
        # OopMap {off=1096/0x448}
454     ShouldNotReachHere

460     B38: #	out( B40 ) <- in( B29 )  Freq: 1.54303e-10
460      -- 	// exception oop; no code emitted
460 +   spill R0 -> R1	# spill size = 64
464 +   b  B40

468     B39: #	out( B40 ) <- in( B6 )  Freq: 1.52733e-06
468      -- 	// exception oop; no code emitted
468 +   spill R0 -> R1	# spill size = 64

46c     B40: #	out( N451 ) <- in( B39 B38 )  Freq: 1.52749e-06
46c     # pop frame 80
	ldp  lr, rfp, [sp,#64]
	add  sp, sp, #80

474 +   b rethrow_stub

--------------------------------------------------------------------------------
----------------------------------- Assembly -----------------------------------

Compiled method (c2) 495   37             java.lang.AbstractStringBuilder::appendNull (75 bytes)
 total in heap  [0x00000001043dd808,0x00000001043ddf48] = 1856
 relocation     [0x00000001043dd8f0,0x00000001043dd990] = 160
 main code      [0x00000001043dd9c0,0x00000001043dde70] = 1200
 stub code      [0x00000001043dde70,0x00000001043ddf10] = 160
 metadata       [0x00000001043ddf10,0x00000001043ddf48] = 56
 immutable data [0x000000013f00a010,0x000000013f00a498] = 1160
 dependencies   [0x000000013f00a010,0x000000013f00a020] = 16
 nul chk table  [0x000000013f00a020,0x000000013f00a030] = 16
 handler table  [0x000000013f00a030,0x000000013f00a060] = 48
 scopes pcs     [0x000000013f00a060,0x000000013f00a340] = 736
 scopes data    [0x000000013f00a340,0x000000013f00a498] = 344

[Disassembly]
--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[Instructions begin]
 ;; N451: #	out( B1 ) <- BLOCK HEAD IS JUNK  Freq: 1
  0x00000001043dd9c0:   nop
[Entry Point]
  # {method} {0x00000001180dc2e8} 'appendNull' '()Ljava/lang/AbstractStringBuilder;' in 'java/lang/AbstractStringBuilder'
  #           [sp+0x50]  (sp of caller)
  0x00000001043dd9c4:   ldr	w8, [x1, #8]
  0x00000001043dd9c8:   ldr	w10, [x9, #8]
  0x00000001043dd9cc:   cmp	w8, w10
  0x00000001043dd9d0:   b.eq	0x00000001043dd9e0  // b.none
  0x00000001043dd9d4:   adrp	x8, 0x0000000104389000      ;   {runtime_call ic_miss_stub}
  0x00000001043dd9d8:   add	x8, x8, #0xe80
  0x00000001043dd9dc:   br	x8
[Verified Entry Point]
 ;; B1: #	out( B37 B2 ) <- BLOCK HEAD IS JUNK  Freq: 1
  0x00000001043dd9e0:   nop
  0x00000001043dd9e4:   sub	x9, sp, #0x1c, lsl #12
  0x00000001043dd9e8:   str	xzr, [x9]
  0x00000001043dd9ec:   sub	sp, sp, #0x50
  0x00000001043dd9f0:   stp	x29, x30, [sp, #64]
  0x00000001043dd9f4:   ldrb	w8, [x28, #1200]
  0x00000001043dd9f8:   cbz	x8, 0x00000001043dda10
 ;; 0x102E6B164
  0x00000001043dd9fc:   mov	x8, #0xb164                	// #45412
                                                            ;   {external_word}
  0x00000001043dda00:   movk	x8, #0x2e6, lsl #16
  0x00000001043dda04:   movk	x8, #0x1, lsl #32
  0x00000001043dda08:   mov	x0, x28
  0x00000001043dda0c:   blr	x8
  0x00000001043dda10:   ldr	w8, 0x00000001043dde68
  0x00000001043dda14:   ldr	w9, [x28, #32]
  0x00000001043dda18:   cmp	x8, x9
  0x00000001043dda1c:   b.ne	0x00000001043dde54  // b.any;*synchronization entry
                                                            ; - java.lang.AbstractStringBuilder::appendNull at -1 (line 638)
  0x00000001043dda20:   ldr	w10, [x1, #20]
  0x00000001043dda24:   mov	x19, x1
  0x00000001043dda28:   lsl	x14, x10, #3                ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 1 (line 243)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
  0x00000001043dda2c:   ldr	w15, [x14, #12]             ; implicit exception: dispatches to 0x00000001043dde00
                                                            ;*arraylength {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 4 (line 243)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B2: #	out( B6 B3 ) <- in( B1 )  Freq: 0.999999
  0x00000001043dda30:   ldrsb	w12, [x1, #16]              ;*getfield coder {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 6 (line 243)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
  0x00000001043dda34:   ldr	w17, [x1, #12]              ;*getfield count {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 1 (line 638)
  0x00000001043dda38:   asr	w11, w15, w12
  0x00000001043dda3c:   sub	w13, w17, w11
  0x00000001043dda40:   add	w11, w13, #0x4
  0x00000001043dda44:   add	w13, w17, #0x4              ;*iadd {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 8 (line 639)
  0x00000001043dda48:   cmp	w11, #0x0
  0x00000001043dda4c:   b.gt	0x00000001043dda9c
 ;; B3: #	out( B32 B4 ) <- in( B19 B2 )  Freq: 0.999996
  0x00000001043dda50:   lsl	x10, x10, #3                ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
  0x00000001043dda54:   cbz	w12, 0x00000001043ddd14     ;*ifeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 21 (line 641)
 ;; B4: #	out( B31 B5 ) <- in( B3 )  Freq: 0.999995
 ;; 0x6E
  0x00000001043dda58:   mov	w11, #0x6e                  	// #110
  0x00000001043dda5c:   cbz	x10, 0x00000001043ddd08
 ;; B5: #	out( N451 ) <- in( B4 )  Freq: 0.999994
  0x00000001043dda60:   add	x10, x10, w17, sxtw #1
  0x00000001043dda64:   strh	w11, [x10, #16]             ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 3 (line 1552)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
 ;; 0x75
  0x00000001043dda68:   mov	w11, #0x75                  	// #117
 ;; 0x6C
  0x00000001043dda6c:   mov	w12, #0x6c                  	// #108
  0x00000001043dda70:   strh	w11, [x10, #18]             ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 11 (line 1553)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
  0x00000001043dda74:   strh	w12, [x10, #20]             ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 20 (line 1554)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
  0x00000001043dda78:   strh	w12, [x10, #22]             ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 29 (line 1555)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
  0x00000001043dda7c:   str	w13, [x19, #12]             ;*synchronization entry
                                                            ; - java.lang.AbstractStringBuilder::appendNull at -1 (line 638)
  0x00000001043dda80:   mov	x0, x19
  0x00000001043dda84:   ldp	x29, x30, [sp, #64]
  0x00000001043dda88:   add	sp, sp, #0x50
  0x00000001043dda8c:   ldr	x8, [x28, #1168]            ;   {poll_return}
  0x00000001043dda90:   cmp	sp, x8
  0x00000001043dda94:   b.hi	0x00000001043dde40  // b.pmore
  0x00000001043dda98:   ret
 ;; B6: #	out( B39 B7 ) <- in( B2 )  Freq: 0.152733
 ;; merged str pair
  0x00000001043dda9c:   stp	w15, w13, [sp]
  0x00000001043ddaa0:   str	x14, [sp, #8]
  0x00000001043ddaa4:   str	w17, [sp, #20]
  0x00000001043ddaa8:   mov	x29, x1
  0x00000001043ddaac:   mov	w2, w13
  0x00000001043ddab0:   bl	0x000000010438a180          ; ImmutableOopMap {rfp=Oop [8]=Oop }
                                                            ;*invokevirtual newCapacity {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
                                                            ;   {optimized virtual_call}
  0x00000001043ddab4:   nop                                 ;   {other}
  0x00000001043ddab8:   movk	xzr, #0x2ac
  0x00000001043ddabc:   movk	xzr, #0x0                   ;*invokevirtual newCapacity {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B7: #	out( B36 B8 ) <- in( B6 )  Freq: 0.15273
  0x00000001043ddac0:   mov	x19, x29
  0x00000001043ddac4:   ldrsb	w10, [x19, #16]
  0x00000001043ddac8:   lsl	w14, w0, w10                ;*ishl {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 31 (line 246)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
  0x00000001043ddacc:   ldr	w11, [sp]
  0x00000001043ddad0:   cmp	w11, w14
  0x00000001043ddad4:   csel	w29, w11, w14, lt  // lt = tstop;*invokestatic min {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 25 (line 3542)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
  0x00000001043ddad8:   cmp	w14, w11
  0x00000001043ddadc:   b.eq	0x00000001043dddd4  // b.none;*if_icmpne {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 3 (line 3537)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B8: #	out( B34 B9 ) <- in( B7 )  Freq: 0.15273
  0x00000001043ddae0:   mov	w12, w14
 ;; 0x17
  0x00000001043ddae4:   mov	x10, #0x17                  	// #23
  0x00000001043ddae8:   add	x12, x10, w12, sxtw         ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
  0x00000001043ddaec:   cmp	w11, w29
  0x00000001043ddaf0:   b.cc	0x00000001043ddd7c  // b.lo, b.ul, b.last
 ;; B9: #	out( B34 B10 ) <- in( B8 )  Freq: 0.15273
  0x00000001043ddaf4:   cmp	w14, w29
  0x00000001043ddaf8:   b.cc	0x00000001043ddd7c  // b.lo, b.ul, b.last
                                                            ;*invokestatic arraycopy {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 28 (line 3541)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B10: #	out( B29 B11 ) <- in( B9 )  Freq: 0.15273
  0x00000001043ddafc:   and	x13, x12, #0xfffffffffffffff8;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
  0x00000001043ddb00:   cmp	w14, #0x100, lsl #12
  0x00000001043ddb04:   b.hi	0x00000001043ddcc8  // b.pmore
 ;; B11: #	out( B29 B12 ) <- in( B10 )  Freq: 0.15273
  0x00000001043ddb08:   ldr	x20, [x28, #456]
  0x00000001043ddb0c:   ldr	x11, [x28, #472]
  0x00000001043ddb10:   add	x10, x20, x13
  0x00000001043ddb14:   cmp	x10, x11
  0x00000001043ddb18:   b.cs	0x00000001043ddcc8  // b.hs, b.nlast
                                                            ;*putfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B12: #	out( B13 ) <- in( B11 )  Freq: 0.152714
 ;; 0x1
  0x00000001043ddb1c:   orr	x11, xzr, #0x1
  0x00000001043ddb20:   str	x10, [x28, #456]
  0x00000001043ddb24:   str	x11, [x20]
  0x00000001043ddb28:   mov	x11, #0x40000               	// #262144
                                                            ;   {metadata({type array byte})}
  0x00000001043ddb2c:   movk	x11, #0xa50
  0x00000001043ddb30:   prfm	pstl1keep, [x10, #384]
  0x00000001043ddb34:   str	w11, [x20, #8]
  0x00000001043ddb38:   prfm	pstl1keep, [x10, #512]
  0x00000001043ddb3c:   str	w14, [x20, #12]
  0x00000001043ddb40:   prfm	pstl1keep, [x10, #640]      ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B13: #	out( B33 B14 ) <- in( B30 B12 )  Freq: 0.15273
  0x00000001043ddb44:   lsr	x11, x12, #3
  0x00000001043ddb48:   add	x1, x20, #0x10
  0x00000001043ddb4c:   cbnz	x20, 0x00000001043ddb5c
 ;; null oop passed to encode_heap_oop_not_null2
  0x00000001043ddb50:   dcps1	#0xdeae
  0x00000001043ddb54:   .inst	0x03a96f55 ; undefined
  0x00000001043ddb58:   udf	#1
  0x00000001043ddb5c:   lsr	x21, x20, #3
  0x00000001043ddb60:   cbz	w29, 0x00000001043ddd48
 ;; B14: #	out( B20 B15 ) <- in( B13 )  Freq: 0.15273
  0x00000001043ddb64:   ldr	x10, [sp, #8]
  0x00000001043ddb68:   add	x0, x10, #0x10
  0x00000001043ddb6c:   cmp	w29, w14
  0x00000001043ddb70:   b.lt	0x00000001043ddbe4  // b.tstop
 ;; B15: #	out( B16 ) <- in( B14 )  Freq: 0.152577
  0x00000001043ddb74:   sub	x10, x13, #0x10
  0x00000001043ddb78:   lsr	x2, x10, #3
  0x00000001043ddb7c:   bl	Stub::arrayof_jlong_disjoint_arraycopy
                                                            ;   {runtime_call StubRoutines (final stubs)}
  0x00000001043ddb80:   nop                                 ;   {other}
  0x00000001043ddb84:   movk	xzr, #0x0
  0x00000001043ddb88:   movk	xzr, #0x0
 ;; B16: #	out( B21 B17 ) <- in( B20 B15 B33 )  Freq: 0.15273
  0x00000001043ddb8c:   dmb	ishst
  0x00000001043ddb90:   ldrsb	w10, [x28, #56]
  0x00000001043ddb94:   cbnz	w10, 0x00000001043ddc34
 ;; B17: #	out( B19 B18 ) <- in( B35 B23 B21 B16 )  Freq: 0.15273
  0x00000001043ddb98:   mov	x10, x19
  0x00000001043ddb9c:   mov	x11, x20
  0x00000001043ddba0:   eor	x11, x11, x10
  0x00000001043ddba4:   lsr	x11, x11, #23
  0x00000001043ddba8:   str	w21, [x19, #20]
  0x00000001043ddbac:   cbz	x11, 0x00000001043ddbd0
 ;; B18: #	out( B24 B19 ) <- in( B17 )  Freq: 0.152577
  0x00000001043ddbb0:   lsr	x10, x10, #9
 ;; 0x1072B8000
  0x00000001043ddbb4:   mov	x11, #0x8000                	// #32768
  0x00000001043ddbb8:   movk	x11, #0x72b, lsl #16
  0x00000001043ddbbc:   movk	x11, #0x1, lsl #32
  0x00000001043ddbc0:   add	x0, x11, x10
  0x00000001043ddbc4:   ldrsb	w10, [x0]
  0x00000001043ddbc8:   cmp	w10, #0x2
  0x00000001043ddbcc:   b.ne	0x00000001043ddc60  // b.any;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
 ;; B19: #	out( B3 ) <- in( B28 B18 B17 )  Freq: 0.15273
  0x00000001043ddbd0:   ldrsb	w12, [x19, #16]             ;*getfield coder {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::isLatin1 at 7 (line 1708)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
  0x00000001043ddbd4:   lsr	x10, x20, #3
  0x00000001043ddbd8:   ldr	w13, [sp, #4]
  0x00000001043ddbdc:   ldr	w17, [sp, #20]
  0x00000001043ddbe0:   b	0x00000001043dda50
 ;; B20: #	out( B16 ) <- in( B14 )  Freq: 0.00015273
  0x00000001043ddbe4:   sxtw	x2, w29
  0x00000001043ddbe8:   add	x12, x2, #0x10
  0x00000001043ddbec:   and	x10, x12, #0xfffffffffffffff8
  0x00000001043ddbf0:   add	x10, x20, x10
  0x00000001043ddbf4:   sub	x11, x11, x12, lsr #3
 ;; zero_words {
  0x00000001043ddbf8:   subs	x8, x11, #0x8
  0x00000001043ddbfc:   b.cc	0x00000001043ddc04  // b.lo, b.ul, b.last
  0x00000001043ddc00:   bl	Stub::zero_blocks           ;   {runtime_call StubRoutines (final stubs)}
  0x00000001043ddc04:   tbz	w11, #2, 0x00000001043ddc10
  0x00000001043ddc08:   stp	xzr, xzr, [x10], #16
  0x00000001043ddc0c:   stp	xzr, xzr, [x10], #16
  0x00000001043ddc10:   tbz	w11, #1, 0x00000001043ddc18
  0x00000001043ddc14:   stp	xzr, xzr, [x10], #16
  0x00000001043ddc18:   tbz	w11, #0, 0x00000001043ddc20
  0x00000001043ddc1c:   str	xzr, [x10]
 ;; } zero_words
  0x00000001043ddc20:   bl	Stub::arrayof_jbyte_disjoint_arraycopy
                                                            ;   {runtime_call StubRoutines (final stubs)}
  0x00000001043ddc24:   nop                                 ;   {other}
  0x00000001043ddc28:   movk	xzr, #0x0
  0x00000001043ddc2c:   movk	xzr, #0x0
  0x00000001043ddc30:   b	0x00000001043ddb8c
 ;; B21: #	out( B17 B22 ) <- in( B16 )  Freq: 0.000152728
  0x00000001043ddc34:   ldr	w11, [x19, #20]
  0x00000001043ddc38:   lsl	x0, x11, #3
  0x00000001043ddc3c:   cbz	x0, 0x00000001043ddb98
 ;; B22: #	out( B35 B23 ) <- in( B21 )  Freq: 7.63639e-05
  0x00000001043ddc40:   ldr	x10, [x28, #40]
  0x00000001043ddc44:   cbz	x10, 0x00000001043ddda4
 ;; B23: #	out( B17 ) <- in( B22 )  Freq: 7.62875e-05
  0x00000001043ddc48:   ldr	x11, [x28, #48]
  0x00000001043ddc4c:   sub	x12, x10, #0x8
  0x00000001043ddc50:   add	x10, x11, x10
  0x00000001043ddc54:   stur	x0, [x10, #-8]
  0x00000001043ddc58:   str	x12, [x28, #40]
  0x00000001043ddc5c:   b	0x00000001043ddb98
 ;; B24: #	out( B28 B25 ) <- in( B18 )  Freq: 0.000152577
 ;; merged ldr pair
  0x00000001043ddc60:   ldp	x11, x10, [x28, #64]
 ;; membar_volatile
  0x00000001043ddc64:   dmb	ish
  0x00000001043ddc68:   ldrsb	w12, [x0]
  0x00000001043ddc6c:   cbz	w12, 0x00000001043ddcb8
 ;; B25: #	out( B27 B26 ) <- in( B24 )  Freq: 7.62885e-05
  0x00000001043ddc70:   strb	wzr, [x0]
  0x00000001043ddc74:   cbz	x11, 0x00000001043ddc8c
 ;; B26: #	out( B28 ) <- in( B25 )  Freq: 3.81443e-05
  0x00000001043ddc78:   sub	x12, x11, #0x8
  0x00000001043ddc7c:   add	x10, x10, x11
  0x00000001043ddc80:   stur	x0, [x10, #-8]
  0x00000001043ddc84:   str	x12, [x28, #64]
  0x00000001043ddc88:   b	0x00000001043ddcb8
 ;; B27: #	out( B28 ) <- in( B25 )  Freq: 3.81443e-05
  0x00000001043ddc8c:   mov	x1, x28
  0x00000001043ddc90:   adr	x9, 0x00000001043ddca8
 ;; 0x102C36B34
  0x00000001043ddc94:   mov	x8, #0x6b34                	// #27444
                                                            ;   {runtime_call G1BarrierSetRuntime::write_ref_field_post_entry(unsigned char volatile*, JavaThread*)}
  0x00000001043ddc98:   movk	x8, #0x2c3, lsl #16
  0x00000001043ddc9c:   movk	x8, #0x1, lsl #32
  0x00000001043ddca0:   stp	xzr, x9, [sp, #-16]!
  0x00000001043ddca4:   blr	x8
  0x00000001043ddca8:   nop                                 ;   {other}
  0x00000001043ddcac:   movk	xzr, #0x0
  0x00000001043ddcb0:   movk	xzr, #0x0
  0x00000001043ddcb4:   add	sp, sp, #0x10               ;*putfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B28: #	out( B19 ) <- in( B27 B26 B24 )  Freq: 0.000152577
  0x00000001043ddcb8:   ldr	w11, [x19, #20]
  0x00000001043ddcbc:   lsl	x10, x11, #3                ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
  0x00000001043ddcc0:   mov	x20, x10
  0x00000001043ddcc4:   b	0x00000001043ddbd0
 ;; B29: #	out( B38 B30 ) <- in( B10 B11 )  Freq: 1.54303e-05
  0x00000001043ddcc8:   str	w14, [sp]
 ;; merged str pair
  0x00000001043ddccc:   stp	x19, x12, [sp, #24]
  0x00000001043ddcd0:   str	x13, [sp, #40]
 ;; 0x400000040A50
  0x00000001043ddcd4:   mov	x1, #0xa50                 	// #2640
                                                            ;   {metadata({type array byte})}
  0x00000001043ddcd8:   movk	x1, #0x4, lsl #16
  0x00000001043ddcdc:   movk	x1, #0x4000, lsl #32
  0x00000001043ddce0:   mov	w2, w14
  0x00000001043ddce4:   bl	0x00000001043aa000          ; ImmutableOopMap {[8]=Oop [24]=Oop }
                                                            ;*newarray {reexecute=0 rethrow=0 return_oop=1}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
                                                            ;   {runtime_call _new_array_nozero_Java}
  0x00000001043ddce8:   nop                                 ;   {other}
  0x00000001043ddcec:   movk	xzr, #0x4e0
  0x00000001043ddcf0:   movk	xzr, #0x100                 ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B30: #	out( B13 ) <- in( B29 )  Freq: 1.54299e-05
  0x00000001043ddcf4:   ldr	w14, [sp]
  0x00000001043ddcf8:   ldr	x19, [sp, #24]
  0x00000001043ddcfc:   mov	x20, x0
 ;; merged ldr pair
  0x00000001043ddd00:   ldp	x12, x13, [sp, #32]
  0x00000001043ddd04:   b	0x00000001043ddb44
 ;; B31: #	out( N451 ) <- in( B4 )  Freq: 1.01327e-06
 ;; unexpected null in intrinsic
  0x00000001043ddd08:   dcps1	#0xdeae
  0x00000001043ddd0c:   .inst	0x03a1fca6 ; undefined
  0x00000001043ddd10:   udf	#1                          ;*invokestatic putChar {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.StringUTF16::putCharsAt at 3 (line 1552)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
 ;; B32: #	out( N451 ) <- in( B3 )  Freq: 4.76835e-07
  0x00000001043ddd14:   cmp	w12, #0x0                   ;*invokevirtual isLatin1 {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
  0x00000001043ddd18:   cset	w29, eq  // eq = none       ;*ireturn {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::isLatin1 at 18 (line 1708)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
 ;; 0xFFFFFF45
  0x00000001043ddd1c:   mov	w1, #0xffffff45            	// #-187
  0x00000001043ddd20:   str	x19, [sp]
  0x00000001043ddd24:   str	w17, [sp, #8]
  0x00000001043ddd28:   str	x10, [sp, #16]
  0x00000001043ddd2c:   bl	0x0000000104390f80          ; ImmutableOopMap {[0]=Oop [16]=Oop }
                                                            ;*ifeq {reexecute=1 rethrow=0 return_oop=0}
                                                            ; - (reexecute) java.lang.AbstractStringBuilder::appendNull at 21 (line 641)
                                                            ;   {runtime_call UncommonTrapBlob}
  0x00000001043ddd30:   nop                                 ;   {other}
  0x00000001043ddd34:   movk	xzr, #0x528
  0x00000001043ddd38:   movk	xzr, #0x200
 ;; uncommon trap returned which should never happen
  0x00000001043ddd3c:   dcps1	#0xdeae
  0x00000001043ddd40:   .inst	0x03a1ffc2 ; undefined
  0x00000001043ddd44:   udf	#1                          ;*ifeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 21 (line 641)
 ;; B33: #	out( B16 ) <- in( B13 )  Freq: 1.54758e-07
  0x00000001043ddd48:   mov	x10, x1
  0x00000001043ddd4c:   sub	x11, x11, #0x2
 ;; zero_words {
  0x00000001043ddd50:   subs	x8, x11, #0x8
  0x00000001043ddd54:   b.cc	0x00000001043ddd5c  // b.lo, b.ul, b.last
  0x00000001043ddd58:   bl	Stub::zero_blocks           ;   {runtime_call StubRoutines (final stubs)}
  0x00000001043ddd5c:   tbz	w11, #2, 0x00000001043ddd68
  0x00000001043ddd60:   stp	xzr, xzr, [x10], #16
  0x00000001043ddd64:   stp	xzr, xzr, [x10], #16
  0x00000001043ddd68:   tbz	w11, #1, 0x00000001043ddd70
  0x00000001043ddd6c:   stp	xzr, xzr, [x10], #16
  0x00000001043ddd70:   tbz	w11, #0, 0x00000001043ddd78
  0x00000001043ddd74:   str	xzr, [x10]
 ;; } zero_words
  0x00000001043ddd78:   b	0x00000001043ddb8c          ;*invokestatic arraycopy {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 28 (line 3541)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B34: #	out( N451 ) <- in( B8 B9 )  Freq: 3.0546e-07
 ;; 0xFFFFFFCC
  0x00000001043ddd7c:   mov	w1, #0xffffffcc            	// #-52
  0x00000001043ddd80:   str	x19, [sp]
  0x00000001043ddd84:   str	w14, [sp, #16]
  0x00000001043ddd88:   bl	0x0000000104390f80          ; ImmutableOopMap {[0]=Oop [8]=Oop }
                                                            ;*newarray {reexecute=1 rethrow=0 return_oop=0}
                                                            ; - (reexecute) java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
                                                            ;   {runtime_call UncommonTrapBlob}
  0x00000001043ddd8c:   nop                                 ;   {other}
  0x00000001043ddd90:   movk	xzr, #0x584
  0x00000001043ddd94:   movk	xzr, #0x300
 ;; uncommon trap returned which should never happen
  0x00000001043ddd98:   dcps1	#0xdeae
  0x00000001043ddd9c:   .inst	0x03a1ffc2 ; undefined
  0x00000001043ddda0:   udf	#1
 ;; B35: #	out( B17 ) <- in( B22 )  Freq: 7.63629e-08
  0x00000001043ddda4:   mov	x1, x28
  0x00000001043ddda8:   adr	x9, 0x00000001043dddc0
 ;; 0x102C368A8
  0x00000001043dddac:   mov	x8, #0x68a8                	// #26792
                                                            ;   {runtime_call G1BarrierSetRuntime::write_ref_field_pre_entry(oopDesc*, JavaThread*)}
  0x00000001043dddb0:   movk	x8, #0x2c3, lsl #16
  0x00000001043dddb4:   movk	x8, #0x1, lsl #32
  0x00000001043dddb8:   stp	xzr, x9, [sp, #-16]!
  0x00000001043dddbc:   blr	x8
  0x00000001043dddc0:   nop                                 ;   {other}
  0x00000001043dddc4:   movk	xzr, #0x0
  0x00000001043dddc8:   movk	xzr, #0x0
  0x00000001043dddcc:   add	sp, sp, #0x10               ;*putfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
  0x00000001043dddd0:   b	0x00000001043ddb98
 ;; B36: #	out( N451 ) <- in( B7 )  Freq: 7.28274e-08
 ;; 0xFFFFFF45
  0x00000001043dddd4:   mov	w1, #0xffffff45            	// #-187
  0x00000001043dddd8:   str	x19, [sp]
  0x00000001043ddddc:   str	w11, [sp, #16]
  0x00000001043ddde0:   str	w14, [sp, #24]
  0x00000001043ddde4:   bl	0x0000000104390f80          ; ImmutableOopMap {[0]=Oop [8]=Oop }
                                                            ;*if_icmpne {reexecute=1 rethrow=0 return_oop=0}
                                                            ; - (reexecute) java.util.Arrays::copyOf at 3 (line 3537)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
                                                            ;   {runtime_call UncommonTrapBlob}
  0x00000001043ddde8:   nop                                 ;   {other}
  0x00000001043dddec:   movk	xzr, #0x5e0
  0x00000001043dddf0:   movk	xzr, #0x400
 ;; uncommon trap returned which should never happen
  0x00000001043dddf4:   dcps1	#0xdeae
  0x00000001043dddf8:   .inst	0x03a1ffc2 ; undefined
  0x00000001043dddfc:   udf	#1                          ;*if_icmpne {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 3 (line 3537)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B37: #	out( N451 ) <- in( B1 )  Freq: 1.01328e-06
 ;; 0xFFFFFFF6
  0x00000001043dde00:   mov	w1, #0xfffffff6            	// #-10
  0x00000001043dde04:   bl	0x0000000104390f80          ; ImmutableOopMap {}
                                                            ;*arraylength {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 4 (line 243)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
                                                            ;   {runtime_call UncommonTrapBlob}
  0x00000001043dde08:   nop                                 ;   {other}
  0x00000001043dde0c:   movk	xzr, #0x600
  0x00000001043dde10:   movk	xzr, #0x500
 ;; uncommon trap returned which should never happen
  0x00000001043dde14:   dcps1	#0xdeae
  0x00000001043dde18:   .inst	0x03a1ffc2 ; undefined
  0x00000001043dde1c:   udf	#1                          ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.util.Arrays::copyOf at 15 (line 3540)
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B38: #	out( B40 ) <- in( B29 )  Freq: 1.54303e-10
  0x00000001043dde20:   mov	x1, x0
  0x00000001043dde24:   b	0x00000001043dde2c          ;*invokevirtual newCapacity {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B39: #	out( B40 ) <- in( B6 )  Freq: 1.52733e-06
  0x00000001043dde28:   mov	x1, x0                      ;*synchronization entry
                                                            ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at -1 (line 243)
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
 ;; B40: #	out( N451 ) <- in( B39 B38 )  Freq: 1.52749e-06
  0x00000001043dde2c:   ldp	x29, x30, [sp, #64]
  0x00000001043dde30:   add	sp, sp, #0x50
  0x00000001043dde34:   adrp	x8, 0x00000001043ac000      ;   {runtime_call _rethrow_Java}
  0x00000001043dde38:   add	x8, x8, #0x600
  0x00000001043dde3c:   br	x8                          ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
  0x00000001043dde40:   adr	x8, 0x00000001043dda8c      ;   {internal_word}
  0x00000001043dde44:   str	x8, [x28, #1192]
  0x00000001043dde48:   adrp	x8, 0x0000000104390000      ;   {runtime_call SafepointBlob}
  0x00000001043dde4c:   add	x8, x8, #0x900
  0x00000001043dde50:   br	x8
 ;; 0x104318940
  0x00000001043dde54:   mov	x8, #0x8940                	// #35136
                                                            ;   {runtime_call StubRoutines (final stubs)}
  0x00000001043dde58:   movk	x8, #0x431, lsl #16
  0x00000001043dde5c:   movk	x8, #0x1, lsl #32
  0x00000001043dde60:   blr	x8
  0x00000001043dde64:   b	0x00000001043dda20
  0x00000001043dde68:   udf	#1                          ;   {other}
  0x00000001043dde6c:   udf	#0
[Stub Code]
  0x00000001043dde70:   ldr	x8, 0x00000001043dde78      ;   {no_reloc}
  0x00000001043dde74:   br	x8
  0x00000001043dde78:   adr	z0.d, [z12.d, z24.d, sxtw]
  0x00000001043dde7c:   udf	#1
  0x00000001043dde80:   isb                                 ;   {static_stub}
  0x00000001043dde84:   mov	x12, #0x0                   	// #0
                                                            ;   {metadata(nullptr)}
  0x00000001043dde88:   movk	x12, #0x0, lsl #16
  0x00000001043dde8c:   movk	x12, #0x0, lsl #32
  0x00000001043dde90:   mov	x8, #0x0                   	// #0
  0x00000001043dde94:   movk	x8, #0x0, lsl #16
  0x00000001043dde98:   movk	x8, #0x0, lsl #32
  0x00000001043dde9c:   br	x8
  0x00000001043ddea0:   ldr	x8, 0x00000001043ddea8      ;   {trampoline_stub}
  0x00000001043ddea4:   br	x8
  0x00000001043ddea8:   sqrdmulh	z0.b, z4.b, z17.b
  0x00000001043ddeac:   udf	#1
  0x00000001043ddeb0:   ldr	x8, 0x00000001043ddeb8      ;   {trampoline_stub}
  0x00000001043ddeb4:   br	x8
  0x00000001043ddeb8:   pmul	z0.b, z0.b, z17.b
  0x00000001043ddebc:   udf	#1
  0x00000001043ddec0:   ldr	x8, 0x00000001043ddec8      ;   {trampoline_stub}
  0x00000001043ddec4:   br	x8
  0x00000001043ddec8:   pmul	z0.b, z30.b, z17.b
  0x00000001043ddecc:   udf	#1
  0x00000001043dded0:   ldr	x8, 0x00000001043dded8      ;   {trampoline_stub}
  0x00000001043dded4:   br	x8
  0x00000001043dded8:   adr	z0.d, [z0.d, z26.d, sxtw]
  0x00000001043ddedc:   udf	#1
  0x00000001043ddee0:   ldr	x8, 0x00000001043ddee8      ;   {trampoline_stub}
  0x00000001043ddee4:   br	x8
  0x00000001043ddee8:   .inst	0x04390f80 ; undefined
  0x00000001043ddeec:   udf	#1
[Exception Handler]
  0x00000001043ddef0:   adrp	x8, 0x00000001042d5000      ;   {runtime_call ExceptionBlob}
  0x00000001043ddef4:   add	x8, x8, #0x200
  0x00000001043ddef8:   br	x8
[Deopt Handler Code]
  0x00000001043ddefc:   adr	x30, 0x00000001043ddefc
  0x00000001043ddf00:   adrp	x8, 0x0000000104390000      ;   {runtime_call DeoptimizationBlob}
  0x00000001043ddf04:   add	x8, x8, #0xc00
  0x00000001043ddf08:   br	x8
  0x00000001043ddf0c:   udf	#0
--------------------------------------------------------------------------------
[/Disassembly]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Oops: <list empty>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Metadata:
  0x00000001043ddf10:   0x00000001180dc2e8 {method} {0x00000001180dc2e8} 'appendNull' '()Ljava/lang/AbstractStringBuilder;' in 'java/lang/AbstractStringBuilder'
  0x00000001043ddf18:   0x00000001180db060 {method} {0x00000001180db060} 'ensureCapacityInternal' '(I)V' in 'java/lang/AbstractStringBuilder'
  0x00000001043ddf20:   0x00000001185aa740 {method} {0x00000001185aa740} 'putCharsAt' '([BICCCC)V' in 'java/lang/StringUTF16'
  0x00000001043ddf28:   0x0000000118212388 {method} {0x0000000118212388} 'copyOf' '([BI)[B' in 'java/util/Arrays'
  0x00000001043ddf30:   0x0000400000040a50 {type array byte}
  0x00000001043ddf38:   0x00000001180deea8 {method} {0x00000001180deea8} 'isLatin1' '()Z' in 'java/lang/AbstractStringBuilder'
  0x00000001043ddf40:   0x0000000000000000
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
pc-bytecode offsets:
PcDesc(pc=0x00000001043dd9bf offset=ffffffff bits=0):
PcDesc(pc=0x00000001043dda20 offset=60 bits=0):
   java.lang.AbstractStringBuilder::appendNull at -1 (line 638)
PcDesc(pc=0x00000001043dda2c offset=6c bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 1 (line 243)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043dda30 offset=70 bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 4 (line 243)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043dda34 offset=74 bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 6 (line 243)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043dda38 offset=78 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 1 (line 638)
PcDesc(pc=0x00000001043dda48 offset=88 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 8 (line 639)
PcDesc(pc=0x00000001043dda54 offset=94 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
PcDesc(pc=0x00000001043dda58 offset=98 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 21 (line 641)
PcDesc(pc=0x00000001043dda68 offset=a8 bits=0):
   java.lang.StringUTF16::putCharsAt at 3 (line 1552)
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
PcDesc(pc=0x00000001043dda74 offset=b4 bits=0):
   java.lang.StringUTF16::putCharsAt at 11 (line 1553)
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
PcDesc(pc=0x00000001043dda78 offset=b8 bits=0):
   java.lang.StringUTF16::putCharsAt at 20 (line 1554)
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
PcDesc(pc=0x00000001043dda7c offset=bc bits=0):
   java.lang.StringUTF16::putCharsAt at 29 (line 1555)
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
PcDesc(pc=0x00000001043dda80 offset=c0 bits=0):
   java.lang.AbstractStringBuilder::appendNull at -1 (line 638)
PcDesc(pc=0x00000001043ddab4 offset=f4 bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
   Locals
    - l0: reg rfp [58],oop
    - l1: empty
    - l2: empty
   Expression stack
    - @0: reg rfp [58],oop
    - @1: stack[8],oop
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: reg rfp [58],oop
    - l1: stack[20]
    - l2: empty
PcDesc(pc=0x00000001043ddac0 offset=100 bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddacc offset=10c bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 31 (line 246)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddad8 offset=118 bits=0):
   java.util.Arrays::copyOf at 25 (line 3542)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddae0 offset=120 bits=0):
   java.util.Arrays::copyOf at 3 (line 3537)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddaec offset=12c bits=0):
   java.util.Arrays::copyOf at 15 (line 3540)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddafc offset=13c bits=0):
   java.util.Arrays::copyOf at 28 (line 3541)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddb00 offset=140 bits=0):
   java.util.Arrays::copyOf at 15 (line 3540)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddb1c offset=15c bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddb44 offset=184 bits=0):
   java.util.Arrays::copyOf at 15 (line 3540)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddbd0 offset=210 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
PcDesc(pc=0x00000001043ddbd4 offset=214 bits=0):
   java.lang.AbstractStringBuilder::isLatin1 at 7 (line 1708)
   java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
PcDesc(pc=0x00000001043ddcb8 offset=2f8 bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddcc0 offset=300 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
PcDesc(pc=0x00000001043ddce8 offset=328 bits=4):
   java.util.Arrays::copyOf at 15 (line 3540)
   Locals
    - l0: stack[8],oop
    - l1: stack[0]
    - l2: empty
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
   Expression stack
    - @0: stack[24],oop
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: stack[24],oop
    - l1: stack[20]
    - l2: empty
PcDesc(pc=0x00000001043ddcf4 offset=334 bits=0):
   java.util.Arrays::copyOf at 15 (line 3540)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddd14 offset=354 bits=0):
   java.lang.StringUTF16::putCharsAt at 3 (line 1552)
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
PcDesc(pc=0x00000001043ddd18 offset=358 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
PcDesc(pc=0x00000001043ddd1c offset=35c bits=0):
   java.lang.AbstractStringBuilder::isLatin1 at 18 (line 1708)
   java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
PcDesc(pc=0x00000001043ddd30 offset=370 bits=1):
   java.lang.AbstractStringBuilder::appendNull at 21 (line 641)  reexecute=true
   Locals
    - l0: stack[0],oop
    - l1: stack[8]
    - l2: stack[16],oop
   Expression stack
    - @0: reg rfp [58],int
PcDesc(pc=0x00000001043ddd48 offset=388 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 21 (line 641)
PcDesc(pc=0x00000001043ddd7c offset=3bc bits=0):
   java.util.Arrays::copyOf at 28 (line 3541)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddd8c offset=3cc bits=1):
   java.util.Arrays::copyOf at 15 (line 3540)  reexecute=true
   Locals
    - l0: stack[8],oop
    - l1: stack[16]
    - l2: empty
   Expression stack
    - @0: stack[16]
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
   Expression stack
    - @0: stack[0],oop
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: stack[0],oop
    - l1: stack[20]
    - l2: empty
PcDesc(pc=0x00000001043dddd0 offset=410 bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043ddde8 offset=428 bits=1):
   java.util.Arrays::copyOf at 3 (line 3537)  reexecute=true
   Locals
    - l0: stack[8],oop
    - l1: empty
    - l2: empty
   Expression stack
    - @0: stack[24]
    - @1: stack[16]
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
   Expression stack
    - @0: stack[0],oop
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: stack[0],oop
    - l1: stack[20]
    - l2: empty
PcDesc(pc=0x00000001043dde00 offset=440 bits=0):
   java.util.Arrays::copyOf at 3 (line 3537)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043dde08 offset=448 bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 4 (line 243)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
   Expression stack
    - @0: nullptr
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
PcDesc(pc=0x00000001043dde20 offset=460 bits=0):
   java.util.Arrays::copyOf at 15 (line 3540)
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043dde28 offset=468 bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043dde2c offset=46c bits=0):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at -1 (line 243)
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
PcDesc(pc=0x00000001043dde40 offset=480 bits=0):
   java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
PcDesc(pc=0x00000001043ddf11 offset=551 bits=0):
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
oop maps:ImmutableOopMapSet contains 6 OopMaps

ImmutableOopMap {rfp=Oop [8]=Oop } pc offsets: 244
ImmutableOopMap {[8]=Oop [24]=Oop } pc offsets: 808
ImmutableOopMap {[0]=Oop [16]=Oop } pc offsets: 880
ImmutableOopMap {[0]=Oop [8]=Oop } pc offsets: 972 1064
ImmutableOopMap {} pc offsets: 1096
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
scopes:
ScopeDesc(pc=0x00000001043dda20 offset=60):
   java.lang.AbstractStringBuilder::appendNull at -1 (line 638)
ScopeDesc(pc=0x00000001043dda2c offset=6c):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 1 (line 243)
ScopeDesc(pc=0x00000001043dda2c offset=6c):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043dda30 offset=70):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 4 (line 243)
ScopeDesc(pc=0x00000001043dda30 offset=70):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043dda34 offset=74):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 6 (line 243)
ScopeDesc(pc=0x00000001043dda34 offset=74):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043dda38 offset=78):
   java.lang.AbstractStringBuilder::appendNull at 1 (line 638)
ScopeDesc(pc=0x00000001043dda48 offset=88):
   java.lang.AbstractStringBuilder::appendNull at 8 (line 639)
ScopeDesc(pc=0x00000001043dda54 offset=94):
   java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
ScopeDesc(pc=0x00000001043dda58 offset=98):
   java.lang.AbstractStringBuilder::appendNull at 21 (line 641)
ScopeDesc(pc=0x00000001043dda68 offset=a8):
   java.lang.StringUTF16::putCharsAt at 3 (line 1552)
ScopeDesc(pc=0x00000001043dda68 offset=a8):
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
ScopeDesc(pc=0x00000001043dda74 offset=b4):
   java.lang.StringUTF16::putCharsAt at 11 (line 1553)
ScopeDesc(pc=0x00000001043dda74 offset=b4):
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
ScopeDesc(pc=0x00000001043dda78 offset=b8):
   java.lang.StringUTF16::putCharsAt at 20 (line 1554)
ScopeDesc(pc=0x00000001043dda78 offset=b8):
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
ScopeDesc(pc=0x00000001043dda7c offset=bc):
   java.lang.StringUTF16::putCharsAt at 29 (line 1555)
ScopeDesc(pc=0x00000001043dda7c offset=bc):
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
ScopeDesc(pc=0x00000001043dda80 offset=c0):
   java.lang.AbstractStringBuilder::appendNull at -1 (line 638)
ScopeDesc(pc=0x00000001043ddab4 offset=f4):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
   Locals
    - l0: reg rfp [58],oop
    - l1: empty
    - l2: empty
   Expression stack
    - @0: reg rfp [58],oop
    - @1: stack[8],oop
ScopeDesc(pc=0x00000001043ddab4 offset=f4):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: reg rfp [58],oop
    - l1: stack[20]
    - l2: empty
ScopeDesc(pc=0x00000001043ddac0 offset=100):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
ScopeDesc(pc=0x00000001043ddac0 offset=100):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddacc offset=10c):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 31 (line 246)
ScopeDesc(pc=0x00000001043ddacc offset=10c):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddad8 offset=118):
   java.util.Arrays::copyOf at 25 (line 3542)
ScopeDesc(pc=0x00000001043ddad8 offset=118):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043ddad8 offset=118):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddae0 offset=120):
   java.util.Arrays::copyOf at 3 (line 3537)
ScopeDesc(pc=0x00000001043ddae0 offset=120):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043ddae0 offset=120):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddaec offset=12c):
   java.util.Arrays::copyOf at 15 (line 3540)
ScopeDesc(pc=0x00000001043ddaec offset=12c):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043ddaec offset=12c):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddafc offset=13c):
   java.util.Arrays::copyOf at 28 (line 3541)
ScopeDesc(pc=0x00000001043ddafc offset=13c):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043ddafc offset=13c):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddb00 offset=140):
   java.util.Arrays::copyOf at 15 (line 3540)
ScopeDesc(pc=0x00000001043ddb00 offset=140):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043ddb00 offset=140):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddb1c offset=15c):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
ScopeDesc(pc=0x00000001043ddb1c offset=15c):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddb44 offset=184):
   java.util.Arrays::copyOf at 15 (line 3540)
ScopeDesc(pc=0x00000001043ddb44 offset=184):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043ddb44 offset=184):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddbd0 offset=210):
   java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
ScopeDesc(pc=0x00000001043ddbd4 offset=214):
   java.lang.AbstractStringBuilder::isLatin1 at 7 (line 1708)
ScopeDesc(pc=0x00000001043ddbd4 offset=214):
   java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
ScopeDesc(pc=0x00000001043ddcb8 offset=2f8):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
ScopeDesc(pc=0x00000001043ddcb8 offset=2f8):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddcc0 offset=300):
   java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
ScopeDesc(pc=0x00000001043ddce8 offset=328):
   java.util.Arrays::copyOf at 15 (line 3540)
   Locals
    - l0: stack[8],oop
    - l1: stack[0]
    - l2: empty
ScopeDesc(pc=0x00000001043ddce8 offset=328):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
   Expression stack
    - @0: stack[24],oop
ScopeDesc(pc=0x00000001043ddce8 offset=328):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: stack[24],oop
    - l1: stack[20]
    - l2: empty
ScopeDesc(pc=0x00000001043ddcf4 offset=334):
   java.util.Arrays::copyOf at 15 (line 3540)
ScopeDesc(pc=0x00000001043ddcf4 offset=334):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043ddcf4 offset=334):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddd14 offset=354):
   java.lang.StringUTF16::putCharsAt at 3 (line 1552)
ScopeDesc(pc=0x00000001043ddd14 offset=354):
   java.lang.AbstractStringBuilder::appendNull at 63 (line 647)
ScopeDesc(pc=0x00000001043ddd18 offset=358):
   java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
ScopeDesc(pc=0x00000001043ddd1c offset=35c):
   java.lang.AbstractStringBuilder::isLatin1 at 18 (line 1708)
ScopeDesc(pc=0x00000001043ddd1c offset=35c):
   java.lang.AbstractStringBuilder::appendNull at 18 (line 641)
ScopeDesc(pc=0x00000001043ddd30 offset=370):
   java.lang.AbstractStringBuilder::appendNull at 21 (line 641)  reexecute=true
   Locals
    - l0: stack[0],oop
    - l1: stack[8]
    - l2: stack[16],oop
   Expression stack
    - @0: reg rfp [58],int
ScopeDesc(pc=0x00000001043ddd48 offset=388):
   java.lang.AbstractStringBuilder::appendNull at 21 (line 641)
ScopeDesc(pc=0x00000001043ddd7c offset=3bc):
   java.util.Arrays::copyOf at 28 (line 3541)
ScopeDesc(pc=0x00000001043ddd7c offset=3bc):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043ddd7c offset=3bc):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddd8c offset=3cc):
   java.util.Arrays::copyOf at 15 (line 3540)  reexecute=true
   Locals
    - l0: stack[8],oop
    - l1: stack[16]
    - l2: empty
   Expression stack
    - @0: stack[16]
ScopeDesc(pc=0x00000001043ddd8c offset=3cc):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
   Expression stack
    - @0: stack[0],oop
ScopeDesc(pc=0x00000001043ddd8c offset=3cc):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: stack[0],oop
    - l1: stack[20]
    - l2: empty
ScopeDesc(pc=0x00000001043dddd0 offset=410):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 35 (line 245)
ScopeDesc(pc=0x00000001043dddd0 offset=410):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043ddde8 offset=428):
   java.util.Arrays::copyOf at 3 (line 3537)  reexecute=true
   Locals
    - l0: stack[8],oop
    - l1: empty
    - l2: empty
   Expression stack
    - @0: stack[24]
    - @1: stack[16]
ScopeDesc(pc=0x00000001043ddde8 offset=428):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
   Expression stack
    - @0: stack[0],oop
ScopeDesc(pc=0x00000001043ddde8 offset=428):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: stack[0],oop
    - l1: stack[20]
    - l2: empty
ScopeDesc(pc=0x00000001043dde00 offset=440):
   java.util.Arrays::copyOf at 3 (line 3537)
ScopeDesc(pc=0x00000001043dde00 offset=440):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043dde00 offset=440):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043dde08 offset=448):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 4 (line 243)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
   Expression stack
    - @0: nullptr
ScopeDesc(pc=0x00000001043dde08 offset=448):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
   Locals
    - l0: empty
    - l1: empty
    - l2: empty
ScopeDesc(pc=0x00000001043dde20 offset=460):
   java.util.Arrays::copyOf at 15 (line 3540)
ScopeDesc(pc=0x00000001043dde20 offset=460):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 32 (line 245)
ScopeDesc(pc=0x00000001043dde20 offset=460):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043dde28 offset=468):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at 24 (line 246)
ScopeDesc(pc=0x00000001043dde28 offset=468):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043dde2c offset=46c):
   java.lang.AbstractStringBuilder::ensureCapacityInternal at -1 (line 243)
ScopeDesc(pc=0x00000001043dde2c offset=46c):
   java.lang.AbstractStringBuilder::appendNull at 9 (line 639)
ScopeDesc(pc=0x00000001043dde40 offset=480):
   java.lang.AbstractStringBuilder::appendNull at 13 (line 640)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
relocations:
         @0x00000001043dd8f0: 3005
relocInfo at 0x00000001043dd8f0 [type=6(runtime_call) addr=0x00000001043dd9d4 offset=20] | [destination=0x0000000104389e80]
         @0x00000001043dd8f2: 7c0302e6b1640001380a
relocInfo at 0x00000001043dd8fa [type=7(external_word) addr=0x00000001043dd9fc offset=40 data={02e6b1640001}] | [target=0x0000000102e6b164]
         @0x00000001043dd8fc: 5824
relocInfo at 0x00000001043dd8fc [type=11(poll_return) addr=0x00000001043dda8c offset=144]
         @0x00000001043dd8fe: 1809
relocInfo at 0x00000001043dd8fe [type=3(opt_virtual_call) addr=0x00000001043ddab0 offset=36] | [destination=0x000000010438a180 metadata=0x0000000000000000]
         @0x00000001043dd900: 8001
relocInfo at 0x00000001043dd900 [type=16(post_call_nop) addr=0x00000001043ddab4 offset=4]
         @0x00000001043dd902: 7805601d
relocInfo at 0x00000001043dd904 [type=12(metadata) addr=0x00000001043ddb28 offset=116 data=5] | [metadata_addr=0x00000001043ddf30 *=0x0000400000040a50]metadata_value=0x0000400000040a50: {type array byte}
         @0x00000001043dd906: 3015
relocInfo at 0x00000001043dd906 [type=6(runtime_call) addr=0x00000001043ddb7c offset=84] | [destination=0x0000000104317480]
         @0x00000001043dd908: 8001
relocInfo at 0x00000001043dd908 [type=16(post_call_nop) addr=0x00000001043ddb80 offset=4]
         @0x00000001043dd90a: 3020
relocInfo at 0x00000001043dd90a [type=6(runtime_call) addr=0x00000001043ddc00 offset=128] | [destination=0x0000000104316400]
         @0x00000001043dd90c: 3008
relocInfo at 0x00000001043dd90c [type=6(runtime_call) addr=0x00000001043ddc20 offset=32] | [destination=0x00000001043167c0]
         @0x00000001043dd90e: 8001
relocInfo at 0x00000001043dd90e [type=16(post_call_nop) addr=0x00000001043ddc24 offset=4]
         @0x00000001043dd910: 301c
relocInfo at 0x00000001043dd910 [type=6(runtime_call) addr=0x00000001043ddc94 offset=112] | [destination=0x0000000102c36b34]
         @0x00000001043dd912: 8005
relocInfo at 0x00000001043dd912 [type=16(post_call_nop) addr=0x00000001043ddca8 offset=20]
         @0x00000001043dd914: 7805600b
relocInfo at 0x00000001043dd916 [type=12(metadata) addr=0x00000001043ddcd4 offset=44 data=5] | [metadata_addr=0x00000001043ddf30 *=0x0000400000040a50]metadata_value=0x0000400000040a50: {type array byte}
         @0x00000001043dd918: 3004
relocInfo at 0x00000001043dd918 [type=6(runtime_call) addr=0x00000001043ddce4 offset=16] | [destination=0x00000001043aa000]
         @0x00000001043dd91a: 8001
relocInfo at 0x00000001043dd91a [type=16(post_call_nop) addr=0x00000001043ddce8 offset=4]
         @0x00000001043dd91c: 3011
relocInfo at 0x00000001043dd91c [type=6(runtime_call) addr=0x00000001043ddd2c offset=68] | [destination=0x0000000104390f80]
         @0x00000001043dd91e: 8001
relocInfo at 0x00000001043dd91e [type=16(post_call_nop) addr=0x00000001043ddd30 offset=4]
         @0x00000001043dd920: 300a
relocInfo at 0x00000001043dd920 [type=6(runtime_call) addr=0x00000001043ddd58 offset=40] | [destination=0x0000000104316400]
         @0x00000001043dd922: 300c
relocInfo at 0x00000001043dd922 [type=6(runtime_call) addr=0x00000001043ddd88 offset=48] | [destination=0x0000000104390f80]
         @0x00000001043dd924: 8001
relocInfo at 0x00000001043dd924 [type=16(post_call_nop) addr=0x00000001043ddd8c offset=4]
         @0x00000001043dd926: 3008
relocInfo at 0x00000001043dd926 [type=6(runtime_call) addr=0x00000001043dddac offset=32] | [destination=0x0000000102c368a8]
         @0x00000001043dd928: 8005
relocInfo at 0x00000001043dd928 [type=16(post_call_nop) addr=0x00000001043dddc0 offset=20]
         @0x00000001043dd92a: 3009
relocInfo at 0x00000001043dd92a [type=6(runtime_call) addr=0x00000001043ddde4 offset=36] | [destination=0x0000000104390f80]
         @0x00000001043dd92c: 8001
relocInfo at 0x00000001043dd92c [type=16(post_call_nop) addr=0x00000001043ddde8 offset=4]
         @0x00000001043dd92e: 3007
relocInfo at 0x00000001043dd92e [type=6(runtime_call) addr=0x00000001043dde04 offset=28] | [destination=0x0000000104390f80]
         @0x00000001043dd930: 8001
relocInfo at 0x00000001043dd930 [type=16(post_call_nop) addr=0x00000001043dde08 offset=4]
         @0x00000001043dd932: 300b
relocInfo at 0x00000001043dd932 [type=6(runtime_call) addr=0x00000001043dde34 offset=44] | [destination=0x00000001043ac600]
         @0x00000001043dd934: 78ed4003
relocInfo at 0x00000001043dd936 [type=8(internal_word) addr=0x00000001043dde40 offset=12 data=237] | [target=0x00000001043dda8c]
         @0x00000001043dd938: 3002
relocInfo at 0x00000001043dd938 [type=6(runtime_call) addr=0x00000001043dde48 offset=8] | [destination=0x0000000104390900]
         @0x00000001043dd93a: 3003
relocInfo at 0x00000001043dd93a [type=6(runtime_call) addr=0x00000001043dde54 offset=12] | [destination=0x0000000104318940]
         @0x00000001043dd93c: 8805
relocInfo at 0x00000001043dd93c [type=17(entry_guard) addr=0x00000001043dde68 offset=20]
         @0x00000001043dd93e: 0002
relocInfo at 0x00000001043dd93e [type=0(none) addr=0x00000001043dde70 offset=8]
         @0x00000001043dd940: 7c01ffc46800
relocInfo at 0x00000001043dd944 [type=13(trampoline_stub) addr=0x00000001043dde70 offset=0 data=-60] | [trampoline owner=0x00000001043ddab0]
         @0x00000001043dd946: 7c01ffc42804
relocInfo at 0x00000001043dd94a [type=5(static_stub) addr=0x00000001043dde80 offset=16 data=-60] | [static_call=0x00000001043ddab0]
         @0x00000001043dd94c: 78076001
relocInfo at 0x00000001043dd94e [type=12(metadata) addr=0x00000001043dde84 offset=4 data=7] | [metadata_addr=0x00000001043ddf40 *=0x0000000000000000]
         @0x00000001043dd950: 7c01ff916807
relocInfo at 0x00000001043dd954 [type=13(trampoline_stub) addr=0x00000001043ddea0 offset=28 data=-111] | [trampoline owner=0x00000001043ddb7c]
         @0x00000001043dd956: 7c01ff1a6804
relocInfo at 0x00000001043dd95a [type=13(trampoline_stub) addr=0x00000001043ddeb0 offset=16 data=-230] | [trampoline owner=0x00000001043ddd58]
         @0x00000001043dd95c: 7c01ff706800
relocInfo at 0x00000001043dd960 [type=13(trampoline_stub) addr=0x00000001043ddeb0 offset=0 data=-144] | [trampoline owner=0x00000001043ddc00]
         @0x00000001043dd962: 7c01ff686804
relocInfo at 0x00000001043dd966 [type=13(trampoline_stub) addr=0x00000001043ddec0 offset=16 data=-152] | [trampoline owner=0x00000001043ddc20]
         @0x00000001043dd968: 7c01ff376804
relocInfo at 0x00000001043dd96c [type=13(trampoline_stub) addr=0x00000001043dded0 offset=16 data=-201] | [trampoline owner=0x00000001043ddce4]
         @0x00000001043dd96e: 7c01feef6804
relocInfo at 0x00000001043dd972 [type=13(trampoline_stub) addr=0x00000001043ddee0 offset=16 data=-273] | [trampoline owner=0x00000001043dde04]
         @0x00000001043dd974: 7c01fef76800
relocInfo at 0x00000001043dd978 [type=13(trampoline_stub) addr=0x00000001043ddee0 offset=0 data=-265] | [trampoline owner=0x00000001043ddde4]
         @0x00000001043dd97a: 7c01ff0e6800
relocInfo at 0x00000001043dd97e [type=13(trampoline_stub) addr=0x00000001043ddee0 offset=0 data=-242] | [trampoline owner=0x00000001043ddd88]
         @0x00000001043dd980: 7c01ff256800
relocInfo at 0x00000001043dd984 [type=13(trampoline_stub) addr=0x00000001043ddee0 offset=0 data=-219] | [trampoline owner=0x00000001043ddd2c]
         @0x00000001043dd986: 3004
relocInfo at 0x00000001043dd986 [type=6(runtime_call) addr=0x00000001043ddef0 offset=16] | [destination=0x00000001042d5200]
         @0x00000001043dd988: 3004
relocInfo at 0x00000001043dd988 [type=6(runtime_call) addr=0x00000001043ddf00 offset=16] | [destination=0x0000000104390c00]
         @0x00000001043dd98a: 0000
relocInfo at 0x00000001043dd98a [type=0(none) addr=0x00000001043ddf00 offset=0]
         @0x00000001043dd98c: 0000
relocInfo at 0x00000001043dd98c [type=0(none) addr=0x00000001043ddf00 offset=0]
         @0x00000001043dd98e: 0000
relocInfo at 0x00000001043dd98e [type=0(none) addr=0x00000001043ddf00 offset=0]
         @0x00000001043dd990:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dependencies:
Dependency of type evol_method
  method  = {method} {0x00000001180dc2e8} 'appendNull' '()Ljava/lang/AbstractStringBuilder;' in 'java/lang/AbstractStringBuilder'
Dependency of type evol_method
  method  = {method} {0x00000001180db060} 'ensureCapacityInternal' '(I)V' in 'java/lang/AbstractStringBuilder'
Dependency of type evol_method
  method  = {method} {0x00000001180deea8} 'isLatin1' '()Z' in 'java/lang/AbstractStringBuilder'
Dependency of type evol_method
  method  = *{method} {0x00000001185aa740} 'putCharsAt' '([BICCCC)V' in 'java/lang/StringUTF16'
Dependency of type evol_method
  method  = *{method} {0x0000000118212388} 'copyOf' '([BI)[B' in 'java/util/Arrays'
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ExceptionHandlerTable (size = 48 bytes)
catch_pco = 244 (pc=0x00000001043ddab4, 1 entries)
  bci -1 at scope depth 0 -> pco 1128 (pc=0x00000001043dde28)
catch_pco = 808 (pc=0x00000001043ddce8, 1 entries)
  bci -1 at scope depth 0 -> pco 1120 (pc=0x00000001043dde20)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ImplicitExceptionTable (size = 1 entries, 12 bytes):
{
   < 0x00000001043dda2c, 0x00000001043dde00 >
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Recorded oops:
#0: 0x0000000000000000 nullptr-oop
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Recorded metadata:
#0: 0x0000000000000000 nullptr-oop
#1: 0x00000001180dc2e8 {method} {0x00000001180dc2e8} 'appendNull' '()Ljava/lang/AbstractStringBuilder;' in 'java/lang/AbstractStringBuilder'
#2: 0x00000001180db060 {method} {0x00000001180db060} 'ensureCapacityInternal' '(I)V' in 'java/lang/AbstractStringBuilder'
#3: 0x00000001185aa740 {method} {0x00000001185aa740} 'putCharsAt' '([BICCCC)V' in 'java/lang/StringUTF16'
#4: 0x0000000118212388 {method} {0x0000000118212388} 'copyOf' '([BI)[B' in 'java/util/Arrays'
#5: 0x0000400000040a50 {type array byte}
#6: 0x00000001180deea8 {method} {0x00000001180deea8} 'isLatin1' '()Z' in 'java/lang/AbstractStringBuilder'
#7: 0x0000000000000000 nullptr-oop
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2161107568

From epeter at openjdk.org  Tue Jun 11 16:11:12 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 11 Jun 2024 16:11:12 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <K9hwrh9iTTyV3Xr8NZNjquCQshofREdRROWsyWehpYA=.51ccfe5d-94a8-47ae-a935-bc5798556ba0@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <sLLwY_A95pj3a62IYg3HTO7Lw6tI1SwF4qb4CT0mz10=.81db16a6-4e17-4d8b-b694-2b19605e5965@github.com>
 <yK7XjXIvol4vo8f2pLXgooWXQF_xP1mr26lfo0kNOKg=.69ee8193-42fb-4870-a030-e470af5789ed@github.com>
 <K9hwrh9iTTyV3Xr8NZNjquCQshofREdRROWsyWehpYA=.51ccfe5d-94a8-47ae-a935-bc5798556ba0@github.com>
Message-ID: <ik6LMV8FAB73NLePraQmBRGaRRU5DKiXCWQ8V-9-_eE=.f845b63c-d723-4772-bed9-49a79ab9c167@github.com>

On Tue, 11 Jun 2024 15:55:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> @wenshao have you published info about `TraceMergeStores` somewhere? It is very well possible that the optimization does not apply in your code. Then you would need to dig into the VM code and see why.
>
> @eme64 TraceMergeStores are here,  but I can't understand these assembly codes
> 
> # JavaCode
> 
> class AbstractStringBuilder {
>      private AbstractStringBuilder appendNull() {
>         int count = this.count;
>         ensureCapacityInternal(count + 4);
>         byte[] val = this.value;
>         if (isLatin1()) {
>             val[count    ] = 'n';
>             val[count + 1] = 'u';
>             val[count + 2] = 'l';
>             val[count + 3] = 'l';
>         } else {
>             StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
>         }
>         this.count = count + 4;
>         return this;
>     }
> }
> 
> class StringUTF16 {
>     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>         putChar(value, i    , c1);
>         putChar(value, i + 1, c2);
>         putChar(value, i + 2, c3);
>         putChar(value, i + 3, c4);
>     }
> }
> 
> 
> # TraceMergeStores
> 
> CompileCommand: compileonly *StringBuilder.appendNull bool compileonly = true
> 
> Compiled method (n/a) 100    1     n       java.lang.invoke.MethodHandle::linkToStatic(LLLLLLL)L (native)
>  total in heap  [0x00000001043b8088,0x00000001043b8230] = 424
>  relocation     [0x00000001043b8170,0x00000001043b8188] = 24
>  main code      [0x00000001043b81c0,0x00000001043b8230] = 112
> 
> [Disassembly]
> --------------------------------------------------------------------------------
> [Constant Pool (empty)]
> 
> --------------------------------------------------------------------------------
> 
> [Verified Entry Point]
>   # {method} {0x000000011842b8b8} 'linkToStatic' '(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;' in 'java/lang/invoke/MethodHandle'
>   # parm0:    c_rarg1:c_rarg1
>                         = 'java/lang/Object'
>   # parm1:    c_rarg2:c_rarg2
>                         = 'java/lang/Object'
>   # parm2:    c_rarg3:c_rarg3
>                         = 'java/lang/Object'
>   # parm3:    c_rarg4:c_rarg4
>                         = 'java/lang/Object'
>   # parm4:    c_rarg5:c_rarg5
>                         = 'java/lang/Object'
>   # parm5:    c_rarg6:c_rarg6
>                         = 'java/lang/Object'
>   # parm6:    c_rarg7:c_rarg7
>                         = 'java/lang/invoke/MemberName'
>   #           [sp+0x0]  (sp of caller)
>   0x00000001043b81c0:   nop
>  ;; verify_klass {
>   0x00000001043b81c4:   cbz	x7, 0x00000001043b81fc
>   0x00000001043b81c8:   stp	x8, x9, [sp, #-16]!
>   0x00000001043b81cc:   ldr	w9, [x7, #8]
>   0x00000001043b...

@wenshao The output you have here is not at all the `TraceMergeStores`, but the assembly dump, probably from `PrintOptoAssembly`. In you entire log I never see a single occurance of `TraceMergeStores`, so presumably no such optimisation was done.

I suggest you play around with the examples from my PR https://github.com/openjdk/jdk/pull/16245, and the `TraceMergeStores` flag. That will give you some insight about how it works, and maybe give you a way into understanding why your examples are not optimized.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2161132962

From kevinw at openjdk.org  Tue Jun 11 16:18:23 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 16:18:23 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Sean comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/d43f9a34..56f9111e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=01-02

  Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Tue Jun 11 16:18:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 16:18:24 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v2]
In-Reply-To: <XkkTDAn9-sZDr-0Z1t7G7_Gg5YJdsy6CD_Uqu8HztXs=.ae4dbf01-fd6b-47a1-b8ba-6e154f5e1288@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <KSfvEpU3M549RiJQk2XxvhO9YygBORGTxOz4S-uyG18=.413cd464-0762-4490-8597-7d78baaede7d@github.com>
 <XkkTDAn9-sZDr-0Z1t7G7_Gg5YJdsy6CD_Uqu8HztXs=.ae4dbf01-fd6b-47a1-b8ba-6e154f5e1288@github.com>
Message-ID: <Bbg-eYVNZPzkPnXm9JM4l_Od4FJU9ms__T68Y3x8TYw=.3dd99d69-afc1-454a-86d4-5355fab32464@github.com>

On Tue, 11 Jun 2024 14:02:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More consistent style of calls and comments.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 36:
> 
>> 34:  * @run main NotificationEmissionTest 1
>> 35: 
>> 36:  * @run main/othervm NotificationEmissionTest 1
> 
> Lines 34 & 36: is it necessary to run NotificationEmissionTest twice with and w/o `othervm`?

It's unnecessary, thanks.

> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/SimpleStandard.java line 155:
> 
>> 153:      */
>> 154:     private void checkSubject() {
>> 155:          Subject subject = Boolean.getBoolean("SimpleStandard.useGetSubjectACC") ?
> 
> Nit, remove extra leading space.

got it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635157731
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635157877

From david.lloyd at redhat.com  Tue Jun 11 16:27:56 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 11 Jun 2024 11:27:56 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
Message-ID: <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>

On Tue, Jun 11, 2024 at 10:17?AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 06/06/2024 18:37, David Lloyd wrote:
>
> Just bumping this one more time. I intend to start by opening a JIRA to
> add the two proposed methods to `ReflectionFactory`, and go from there. I
> guess that we might need a JEP for the proposed serialization restrictions,
> which is going to be considerably more involved, so I'm putting that off as
> a second step for now, pending further discussion.
>
>
> I don't think the JDK should be adding another backdoor for serialization
> libs to do deep reflection.
>
> I'm curious, does your serialization library uses the ReflectionFactory to
> get method handles to the readObject/writeObject methods (if they are
> defined)?
>

Yes, all of the method-access methods on ReflectionFactory are used, not
just for readObject/writeObject but also readObjectNoData, readResolve, and
writeReplace, the constructor accessors, and the factory methods for
OptionalDataException. We don't use the static initializer one though
(maybe the ORB does, I'm not sure).

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240611/2f26421f/attachment-0001.htm>

From Alan.Bateman at oracle.com  Tue Jun 11 16:38:03 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Jun 2024 17:38:03 +0100
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
Message-ID: <93c9de05-113f-4f15-8427-8719560c1a04@oracle.com>



On 11/06/2024 17:27, David Lloyd wrote:
> :
>
> Yes, all of the method-access methods on ReflectionFactory are used, 
> not just for readObject/writeObject but also readObjectNoData, 
> readResolve, and writeReplace, the constructor accessors, and the 
> factory methods for OptionalDataException. We don't use the static 
> initializer one though (maybe the ORB does, I'm not sure).
>
Okay, next question is whether you are also using Unsafe to access the 
fields of classes where you've got a MH to invoke the readXXX/writeXXX 
methods? Ignore SVUID for the moment.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240611/d0a460cc/attachment.htm>

From david.lloyd at redhat.com  Tue Jun 11 16:52:29 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 11 Jun 2024 11:52:29 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <93c9de05-113f-4f15-8427-8719560c1a04@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <93c9de05-113f-4f15-8427-8719560c1a04@oracle.com>
Message-ID: <CANghgrTDm0ZVw-bMKNM3ScRYyfxuifqKK4zb8wdZuG_t-gs7TQ@mail.gmail.com>

On Tue, Jun 11, 2024 at 11:38?AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 11/06/2024 17:27, David Lloyd wrote:
>
> :
>
> Yes, all of the method-access methods on ReflectionFactory are used, not
> just for readObject/writeObject but also readObjectNoData, readResolve, and
> writeReplace, the constructor accessors, and the factory methods for
> OptionalDataException. We don't use the static initializer one though
> (maybe the ORB does, I'm not sure).
>
> Okay, next question is whether you are also using Unsafe to access the
> fields of classes where you've got a MH to invoke the readXXX/writeXXX
> methods? Ignore SVUID for the moment.
>

For "normal" objects, no; we invoke readXXX/writeXXX if they're available
with our OIS/OOS proxy object. We are using Unsafe to initialize the
handler of reflection proxy instances though, on the deserialization side,
and similarly for certain fields of some "known" classes for optimization
purposes, though if these classes had readXXX/writeXXX we could probably do
that another way (albeit at a performance penalty, in all likelihood).

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240611/23aecf7a/attachment.htm>

From kevinw at openjdk.org  Tue Jun 11 16:54:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 16:54:36 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v2]
In-Reply-To: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
Message-ID: <QEZBeiY5plgbdgeBL_pRBBS1c7RSSYz3Ss_A6w3gyWQ=.6874b343-4c52-4480-8fe1-2ddac25dd142@github.com>

> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
> 
> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  No annotations for src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19658/files
  - new: https://git.openjdk.org/jdk/pull/19658/files/60bde969..72ac8818

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19658/head:pull/19658

PR: https://git.openjdk.org/jdk/pull/19658

From kevinw at openjdk.org  Tue Jun 11 16:54:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 16:54:36 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal
In-Reply-To: <TENQc1MzLc7pK_lsZ3sjsZAC7pckcqOGaorSt15ttzU=.8b00fe1f-8b7b-4333-934a-eeb6452699ad@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <TENQc1MzLc7pK_lsZ3sjsZAC7pckcqOGaorSt15ttzU=.8b00fe1f-8b7b-4333-934a-eeb6452699ad@github.com>
Message-ID: <5xWnT6Fmt0hBfXPXTfoqFIafe5TwMwKktLN2XPXa64g=.1c874bfc-229b-4286-82e2-fcd39977a040@github.com>

On Tue, 11 Jun 2024 13:35:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The sun.jvmstat.monitor.remote package is not exported so I don't think adding `@Deprecated` makes sense.

Sure, happy to not add annotations in sun.jvmstat.monitor.remote (RemoteHost.java, RemoteVm.java).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2161212800

From ron.pressler at oracle.com  Tue Jun 11 16:57:59 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 11 Jun 2024 16:57:59 +0000
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
Message-ID: <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>



> On 11 Jun 2024, at 17:27, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> 
> 
> On Tue, Jun 11, 2024 at 10:17?AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 06/06/2024 18:37, David Lloyd wrote:
>> Just bumping this one more time. I intend to start by opening a JIRA to add the two proposed methods to `ReflectionFactory`, and go from there. I guess that we might need a JEP for the proposed serialization restrictions, which is going to be considerably more involved, so I'm putting that off as a second step for now, pending further discussion.
>> 
> 
> I don't think the JDK should be adding another backdoor for serialization libs to do deep reflection.
> 
> I'm curious, does your serialization library uses the ReflectionFactory to get method handles to the readObject/writeObject methods (if they are defined)?
> 
> Yes, all of the method-access methods on ReflectionFactory are used, not just for readObject/writeObject but also readObjectNoData, readResolve, and writeReplace, the constructor accessors, and the factory methods for OptionalDataException. We don't use the static initializer one though (maybe the ORB does, I'm not sure).
> 
> -- 
> - DML ? he/him


Ok, good.

So the way the JDK?s built-in serialization mechanism allows custom implementation is by extending ObjectInputStream/ObjectOutputStream (and to that purpose it offers protected constructors of those two classes). ReflectionFactory offers access to non-public readObject/writeObject methods, but it does not currently offer a way to exploit the default field-based reflection when such methods are not explicitly declared.

Given that, I think that an appropriate mechanism to consider is having ReflectionFactory offer access to MethodHandles that can perform de/serialization using the default JDK field-based serialization, but still requiring the serialization library to extend ObjectInputStream/ObjectOutputStream ? i.e. those MethodHandles will invoke the appropriate OIS/OOS methods for writing fields ? but not offering any direct access to non-public fields. This would still be an interim mechanism, and it may still require significant work by serialization libraries that don?t wish to offer custom serializers for JDK classes and don?t wish to use --add-opens. 

Looking further ahead, a future JDK mechanism to support custom serialization would still be based on invoking public constructors. I.e., the same effect could be achieved today ? albeit with some more work ? by the serialization library offering custom serializers for JDK classes that invoke their public constructors (the difference being that such a future mechanism would make it easier to automatically identify the public constructor to be invoked, whereas today it would need to be individually determined on a per-class basis). Serialization libraries that want to be better prepared for that future and not do further significant work when it arrives, should use custom serializers for JDK classes that invoke public constructors rather than rely on the mechanism I proposed above or on --add-opens.

Whatever they choose to do, to assist in forming some future JDK mechanism that could support custom serialization, serialization libraries should report which JDK classes they commonly serialize and what public constructors they are missing, if any.

? Ron

From alanb at openjdk.org  Tue Jun 11 16:59:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jun 2024 16:59:12 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal
In-Reply-To: <5xWnT6Fmt0hBfXPXTfoqFIafe5TwMwKktLN2XPXa64g=.1c874bfc-229b-4286-82e2-fcd39977a040@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <TENQc1MzLc7pK_lsZ3sjsZAC7pckcqOGaorSt15ttzU=.8b00fe1f-8b7b-4333-934a-eeb6452699ad@github.com>
 <5xWnT6Fmt0hBfXPXTfoqFIafe5TwMwKktLN2XPXa64g=.1c874bfc-229b-4286-82e2-fcd39977a040@github.com>
Message-ID: <ibxiWR2nVv65XVlGKPEBEZwka1aQCj0guEn2zHaTdwQ=.dbceee59-7fcf-4765-9f95-97baa02b15fd@github.com>

On Tue, 11 Jun 2024 16:52:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Sure, happy to not add annotations in sun.jvmstat.monitor.remote (RemoteHost.java, RemoteVm.java).

Right, you can drop it from all the source files except for module-info.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2161219889

From weijun at openjdk.org  Tue Jun 11 17:07:16 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Jun 2024 17:07:16 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
Message-ID: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>

On Tue, 11 Jun 2024 16:18:23 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sean comments

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1301:

> 1299:                     }
> 1300:             };
> 1301:             if (acc == null) {

This is a comment to all the code changes in this PR. I would recommend we make use of the `allowSecurityManager()` call everywhere when the behavior is different, like this:

if (SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
    if (acc == null)
        return action.run();
    else
        return AccessController.doPrivileged(action, acc);
} else {
    if (subject == null)
        return action.run();
    else
        return Subject.doAs(subject, action);
}

This makes me much more confident.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:

> 1434:             } else {
> 1435:                 // ACC is present, we have a Subject and SM is permitted:
> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);

Why is it necessary to call both `doAs` and `doPrivileged`?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1438:

> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);
> 1437:             }
> 1438:         } catch (PrivilegedActionException pe) {

What is this catch block for? The cause of a `PrivilegedActionException` should not be a unchecked exception.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1453:

> 1451:                 throw new RuntimeException(cause);
> 1452:             }
> 1453:         } catch (Exception e) {

Is this block only for the `op.run()` line? Why not keep the old try-catch block around it and move the logic here?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1633:

> 1631:                     }
> 1632:                 } else {
> 1633:                     // ACC is present, we have a Subject and SM is permitted:

While extract the `action` variable? The old code on lines 1590-1592 has no problem.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 350:

> 348:     @SuppressWarnings("removal")
> 349:     private Subject getSubject() {
> 350:         Subject subject = null;

Just call `Subject.current()`. When SM is allowed, it is equivalent to `getSubject(AccessController.getContext())`.

src/java.management/share/classes/javax/management/monitor/Monitor.java line 718:

> 716:             // The monitor tasks will be executed within this context.
> 717:             //
> 718:             subject = Subject.current();

If `subject` is only used when SM is not allowed, you can put the assignment above to the else if next line.

src/java.management/share/classes/javax/management/monitor/Monitor.java line 1541:

> 1539:             if (ac == null) {
> 1540:                 // No SecurityManager:
> 1541:                 Subject.doAs(s, action);

What if `s` is null?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635218675
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635202721
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635205035
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635206172
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635208088
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635209275
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635212375
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635213527

From alanb at openjdk.org  Tue Jun 11 17:12:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jun 2024 17:12:13 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v2]
In-Reply-To: <QEZBeiY5plgbdgeBL_pRBBS1c7RSSYz3Ss_A6w3gyWQ=.6874b343-4c52-4480-8fe1-2ddac25dd142@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <QEZBeiY5plgbdgeBL_pRBBS1c7RSSYz3Ss_A6w3gyWQ=.6874b343-4c52-4480-8fe1-2ddac25dd142@github.com>
Message-ID: <FdoN4Bca6_Zg9kKPcabeDC_UKUNwqWTdsioH4inesAo=.47fdffb3-498e-458a-9987-b12324d43fe2@github.com>

On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No annotations for src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote

BTW: Are you going to include the update to the man page (jstatd.1) in the PR or is that for another update?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2161239976

From kevinw at openjdk.org  Tue Jun 11 17:12:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 17:12:13 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v2]
In-Reply-To: <QEZBeiY5plgbdgeBL_pRBBS1c7RSSYz3Ss_A6w3gyWQ=.6874b343-4c52-4480-8fe1-2ddac25dd142@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <QEZBeiY5plgbdgeBL_pRBBS1c7RSSYz3Ss_A6w3gyWQ=.6874b343-4c52-4480-8fe1-2ddac25dd142@github.com>
Message-ID: <A78QGJy9d_F3VjZ9p3ybyMPaXAKtl2LtTx1JVGym_Ok=.6e147f61-f019-4e0c-89a3-4605c75a960f@github.com>

On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No annotations for src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote

OK sure - I had thought the src annotations were useful but if not needed I am taking them out.

Yes, I was thinking to do a separate man page CR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2161244463

From naoto at openjdk.org  Tue Jun 11 17:18:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Jun 2024 17:18:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
Message-ID: <IkCDImPZqMUO8lTSYmq1eVu9VujFF-F5D4-gt7Hbt5A=.173876cd-1a2f-4713-a277-5a1cd5ee9703@github.com>

On Mon, 10 Jun 2024 19:45:14 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278:
>> 
>>> 276:         UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}".
>>> 277:         UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden.
>>> 278:         ENTITYFailedInitializeGrammar =  ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t
>> 
>> It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool.
>
> Yeah, I believe you're right. Noted as something else to file against the translation tool.

Just out of curiosity, do we know why `\t` was attached in the first place? I don't think it is with the original English properties.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1635231459

From david.lloyd at redhat.com  Tue Jun 11 17:19:04 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 11 Jun 2024 12:19:04 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
Message-ID: <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>

On Tue, Jun 11, 2024 at 11:58?AM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 11 Jun 2024, at 17:27, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> >
> >
> > On Tue, Jun 11, 2024 at 10:17?AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> > On 06/06/2024 18:37, David Lloyd wrote:
> >> Just bumping this one more time. I intend to start by opening a JIRA to
> add the two proposed methods to `ReflectionFactory`, and go from there. I
> guess that we might need a JEP for the proposed serialization restrictions,
> which is going to be considerably more involved, so I'm putting that off as
> a second step for now, pending further discussion.
> >>
> >
> > I don't think the JDK should be adding another backdoor for
> serialization libs to do deep reflection.
> >
> > I'm curious, does your serialization library uses the ReflectionFactory
> to get method handles to the readObject/writeObject methods (if they are
> defined)?
> >
> > Yes, all of the method-access methods on ReflectionFactory are used, not
> just for readObject/writeObject but also readObjectNoData, readResolve, and
> writeReplace, the constructor accessors, and the factory methods for
> OptionalDataException. We don't use the static initializer one though
> (maybe the ORB does, I'm not sure).
> >
> > --
> > - DML ? he/him
>
>
> Ok, good.
>
> So the way the JDK?s built-in serialization mechanism allows custom
> implementation is by extending ObjectInputStream/ObjectOutputStream (and to
> that purpose it offers protected constructors of those two classes).
> ReflectionFactory offers access to non-public readObject/writeObject
> methods, but it does not currently offer a way to exploit the default
> field-based reflection when such methods are not explicitly declared.
>
> Given that, I think that an appropriate mechanism to consider is having
> ReflectionFactory offer access to MethodHandles that can perform
> de/serialization using the default JDK field-based serialization, but still
> requiring the serialization library to extend
> ObjectInputStream/ObjectOutputStream ? i.e. those MethodHandles will invoke
> the appropriate OIS/OOS methods for writing fields ? but not offering any
> direct access to non-public fields. This would still be an interim
> mechanism, and it may still require significant work by serialization
> libraries that don?t wish to offer custom serializers for JDK classes and
> don?t wish to use --add-opens.


I thought that might be where Alan was headed with this. I would support
this solution; it would solve the problem for conformant serialization
libraries. If a class has a `readObject`/etc. then we use it - we wouldn't
care if it was "natural" or generated. This also gives us the option to
allow the user to use `opens` selectively to opt-in to special
optimizations, without a major penalty if they do not.

Is there already someone assigned for this task, or is it a
hot-off-the-presses new idea?

Looking further ahead, a future JDK mechanism to support custom
> serialization would still be based on invoking public constructors. I.e.,
> the same effect could be achieved today ? albeit with some more work ? by
> the serialization library offering custom serializers for JDK classes that
> invoke their public constructors (the difference being that such a future
> mechanism would make it easier to automatically identify the public
> constructor to be invoked, whereas today it would need to be individually
> determined on a per-class basis). Serialization libraries that want to be
> better prepared for that future and not do further significant work when it
> arrives, should use custom serializers for JDK classes that invoke public
> constructors rather than rely on the mechanism I proposed above or on
> --add-opens.
>

It would be great to see this. I've prototyped a few ideas for
constructor-based deserialization in the past (essentially, using
caller-sensitivity to control stream field access), but the issue always
comes down to needing the entire class hierarchy to participate and play
nicely, hence my suspicion that some amount of language/JDK changes would
be needed. I would support any new work in this direction either way
though; it gets rid of a lot of hackiness on the deserialization end.

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240611/7c116d22/attachment.htm>

From jlu at openjdk.org  Tue Jun 11 17:26:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Jun 2024 17:26:18 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <IkCDImPZqMUO8lTSYmq1eVu9VujFF-F5D4-gt7Hbt5A=.173876cd-1a2f-4713-a277-5a1cd5ee9703@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <IkCDImPZqMUO8lTSYmq1eVu9VujFF-F5D4-gt7Hbt5A=.173876cd-1a2f-4713-a277-5a1cd5ee9703@github.com>
Message-ID: <dwTM7lAxBa_Z6Diij907FtLkAiNb8Nbc0B2ZLYYIWVY=.df8c37f4-2e21-496c-bba9-29bc71d24689@github.com>

On Tue, 11 Jun 2024 17:15:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yeah, I believe you're right. Noted as something else to file against the translation tool.
>
> Just out of curiosity, do we know why `\t` was attached in the first place? I don't think it is with the original English properties.

I can see that in 2012, the original did not have `\t` while the translated files did. (Did not search before then).
Seems like this discrepancy originates from awhile ago.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1635242656

From jlu at openjdk.org  Tue Jun 11 17:30:44 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Jun 2024 17:30:44 GMT
Subject: RFR: 8333755: NumberFormat integer only parsing breaks when format has
 suffix
Message-ID: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8333920) which corrects a bug where NumberFormat cannot successfully parse values in integer only mode, when the format expects a suffix.

For example,

// a format that expects a currency suffix
var fmt = NumberFormat.getCurrencyInstance(Locale.FRANCE);
fmt.setParseIntegerOnly(true);
failFmt.parse("5,00 ?"); // throws ParseException when you would have expected 5 returned


When parsing in integer only mode, instead of breaking upon a decimal symbol encounter, we should store the index but continue to fully parse so that we can verify the entire string and increment our position to search for and match the suffix. Upon a successful suffix match, we can then set `ParsePosition.index` back to the stored decimal index.

It should be noted that CompactNumberFormat did previously have code that would traverse the rest of the String, to allow matching of the suffix. The difference is that NumberFormat returns the index upon decimal symbol encounter, while CompactNumberFormat was implemented to return the index reflected by the entire string traversal. Such differences cannot be standardized due to behavioral compatibility concerns.

Thus while parsing in integer only, CNF sets index to the `Position.fullPos()`, while DF sets index to the `Position.intPos()`.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/19664/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333755
  Stats: 180 lines in 5 files changed: 85 ins; 31 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/19664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19664/head:pull/19664

PR: https://git.openjdk.org/jdk/pull/19664

From djelinski at openjdk.org  Tue Jun 11 17:37:20 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Jun 2024 17:37:20 GMT
Subject: Integrated: 8333742: ProcessImpl and ProcessHandleImpl may mishandle
 processes that exit with code 259
In-Reply-To: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
References: <1CvkxMiIsaatbXRqxy6MIPKRisHyifLU5VCr7OA-Lso=.6a1a2f1a-bfbb-4e59-ab2e-1a367b8f6492@github.com>
Message-ID: <qsFGhncP6hm2UF50ewAPkbMkEtycy9a-Dn6dFN32jdg=.ac988d8c-bbc0-4ed4-b6d6-7e0266246c9d@github.com>

On Thu, 6 Jun 2024 18:40:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `GetExitCodeProcess` method is not reliable for checking if a process exited already; it returns 259 (STILL_ACTIVE) if the process hasn't exited yet, but the same value is returned when the process exited with code 259. In order to check if the process exited, we need to check if its handle is in a signaled state using one of the wait methods.
> 
> This PR fixes the onExit, exitValue, isAlive, and waitFor(timeout) methods to correctly handle the problematic exit code.
> 
> I haven't fixed the ProcessImpl.toString method. I'm not sure the problem is important enough to justify an extra JNI call in the (probably typical) still-alive case.
> 
> Tier1-3 testing clean. I modified the existing OnExitTest to cover this case.

This pull request has now been integrated.

Changeset: b77bd5fd
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b77bd5fd6a6f7ddbed90300fba790da4fb683275
Stats:     50 lines in 4 files changed: 19 ins; 16 del; 15 mod

8333742: ProcessImpl and ProcessHandleImpl may mishandle processes that exit with code 259

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/19586

From kvn at openjdk.org  Tue Jun 11 17:42:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 11 Jun 2024 17:42:11 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
 <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
 <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>
 <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>
Message-ID: <QakCNbZ66ev3PjuDj_1xDWhm6K6eo6oVArBeGWVNha0=.2ceec0c1-1a2f-46c4-929a-1a420353cbcb@github.com>

On Tue, 11 Jun 2024 17:30:37 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Thank you for explanation.
>> 
>> An other question. Is any other use of `longBuf` array after `implCompress0()` call which load values from it? Because Intrinsic code will not update it.
>
> There is no other use.. That array is there for the sole purpose of  holding the input as a long array before it gets xor-ed into the state.

okay

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635262207

From Alan.Bateman at oracle.com  Tue Jun 11 17:57:23 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Jun 2024 18:57:23 +0100
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
Message-ID: <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>



On 11/06/2024 18:19, David Lloyd wrote:
> :
>
> I thought that might be where Alan was headed with this. I would 
> support this solution; it would solve the problem for conformant 
> serialization libraries. If a class has a `readObject`/etc. then we 
> use it - we wouldn't care if it was "natural" or generated. This also 
> gives us the option to allow the user to use `opens` selectively to 
> opt-in to special optimizations, without a major penalty if they do not.
>
> Is there already someone assigned for this task

Not to my knowledge so you have cycles to prototype and have these 
methods return a MH that work like a "default" readObject/writeObject 
then it would help the discussion.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240611/974e48fd/attachment-0001.htm>

From ron.pressler at oracle.com  Tue Jun 11 17:57:54 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 11 Jun 2024 17:57:54 +0000
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
Message-ID: <1CDD03D4-FA8D-4648-AF03-CF87E68A5E76@oracle.com>



> On 11 Jun 2024, at 18:19, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> I would support this solution; it would solve the problem for conformant serialization libraries. If a class has a `readObject`/etc. then we use it - we wouldn't care if it was "natural" or generated. This also gives us the option to allow the user to use `opens` selectively to opt-in to special optimizations, without a major penalty if they do not.

Right. Excellent.

> 
> Is there already someone assigned for this task, or is it a hot-off-the-presses new idea?

It?s a new idea.

> It would be great to see this. I've prototyped a few ideas for constructor-based deserialization in the past (essentially, using caller-sensitivity to control stream field access), but the issue always comes down to needing the entire class hierarchy to participate and play nicely, hence my suspicion that some amount of language/JDK changes would be needed. I would support any new work in this direction either way though; it gets rid of a lot of hackiness on the deserialization end.


There?s no need to examine the class hierarchy. We can take this apart into two stages:

Any class designed for serialization (and the axiom of ?Serialization 2.0? is that only classes designed for serialization can be serialized) should offer a constructor that can recreate an object at an arbitrary (serializable) state, as well as access to whichever components make up that state. This should, ideally, be the situation today, but using this property today requires writing a custom serializer ? code that knows how to access the components of the state of a particular class when serializing and knows how to pass them to an appropriate constructor when deserializing.

What?s missing is a mechanism to automate this process. Some way to *generally* tell a class designed for serialization, ?please give me the components of your state? when serializing, and a way to *generally* find an appropriate public constructor to which you can say, ?here are your state components, now construct an object?. That is the broad idea outlined in Brian?s ?Toward Better Serialization?[1] (if such a mechanism is ultimately introduced, the concrete details will likely be different).

? Ron

[1]: https://openjdk.org/projects/amber/design-notes/towards-better-serialization


From kvn at openjdk.org  Tue Jun 11 18:04:07 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 11 Jun 2024 18:04:07 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <9k5Cf1pnyqps-ajlB7hVNb7w_XYmTNP7uTDKd7pePVE=.34f3b680-fe4f-4069-b8b2-a2f20cfb235e@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <9k5Cf1pnyqps-ajlB7hVNb7w_XYmTNP7uTDKd7pePVE=.34f3b680-fe4f-4069-b8b2-a2f20cfb235e@github.com>
Message-ID: <D59KR_dooXeD-mM3au_cpnCHGtP4R-HB9iT2eBE3WLU=.ec3fb5f6-6fde-4547-b976-8add81bc6596@github.com>

On Tue, 11 Jun 2024 09:55:11 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Some microbenchmark data (the percentages are improvements in ops/sec):
> Benchmark                                                                                                                                                                       Linux aarch64  Linux x64  MacOSX aarch64  MacOSX x64
> openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_256-length:16384-provider:DEFAULT         27.67%     20.60%          -0.00%      24.75%
> openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_256-length:64-provider:DEFAULT            11.95%      6.27%          -3.97%      12.72%
> openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_512-length:16384-provider:DEFAULT         18.00%     14.99%           0.01%      15.35%
> openjdk.bench.java.security.MessageDigests.digest-digesterName:SHA3_512-length:64-provider:DEFAULT            11.91%      5.87%          -3.39%      10.04%

@ferakocz what testing in Mach5 you ran? You need at least to run first 3 tiers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2161300019

From cjplummer at openjdk.org  Tue Jun 11 18:04:42 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Jun 2024 18:04:42 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
Message-ID: <ingMGDOjflPwzkCCYc6MKKiBsXikH9L11Bt_l18MALc=.5726d2a9-d503-45de-a657-becc134c7596@github.com>

On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double quotes

jdk.jconsole and jdk.jdi changes look fine.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2111108012

From kevinw at openjdk.org  Tue Jun 11 18:06:57 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 18:06:57 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v3]
In-Reply-To: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
Message-ID: <taFk6HuQZev2A6fLhYTvjy22NLKAM4b1q_YfYsjhFdA=.d26251bc-0983-424e-8dce-896b897fb89c@github.com>

> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
> 
> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Replace (C)
 - Remove annotations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19658/files
  - new: https://git.openjdk.org/jdk/pull/19658/files/72ac8818..58892d76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=01-02

  Stats: 24 lines in 9 files changed: 0 ins; 16 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19658/head:pull/19658

PR: https://git.openjdk.org/jdk/pull/19658

From duke at openjdk.org  Tue Jun 11 18:07:10 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 11 Jun 2024 18:07:10 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
 [v2]
In-Reply-To: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
Message-ID: <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>

> ### Summary
> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
> 
> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
> 
> **Testing**
> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
> - tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  Replace wrapper with casts.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19567/files
  - new: https://git.openjdk.org/jdk/pull/19567/files/dabc185b..fe5e16e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19567&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19567&range=00-01

  Stats: 36 lines in 10 files changed: 0 ins; 20 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19567/head:pull/19567

PR: https://git.openjdk.org/jdk/pull/19567

From duke at openjdk.org  Tue Jun 11 18:07:11 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 11 Jun 2024 18:07:11 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
Message-ID: <EcCKrc4IaStEyER-MQYccf2W0OWk2imMdBFbokRCOXc=.313c5c48-3743-4245-a021-83b63ba67362@github.com>

On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary
> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
> 
> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
> 
> **Testing**
> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
> - tier1

Ok I've got rid of the wrapper and replaced it with casts to unsigned char.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2161325222

From kevinw at openjdk.org  Tue Jun 11 18:07:53 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 18:07:53 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <Gg34s2AIlChqCxi942j__gd43RoyiDfMIt8bIdoJb7I=.759c6e64-00ff-408c-90b0-76d530958a7d@github.com>

On Tue, 11 Jun 2024 17:03:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1301:
> 
>> 1299:                     }
>> 1300:             };
>> 1301:             if (acc == null) {
> 
> This is a comment to all the code changes in this PR. I would recommend we make use of the `allowSecurityManager()` call everywhere when the behavior is different, like this:
> 
> if (SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>     if (acc == null)
>         return action.run();
>     else
>         return AccessController.doPrivileged(action, acc);
> } else {
>     if (subject == null)
>         return action.run();
>     else
>         return Subject.doAs(subject, action);
> }
> 
> This makes me much more confident.

Thanks I'll go through the above comments and update - some of the changes I see are unnecessary and from when I was trying migrating to callAs, and doPrivileged, and yes they can be simpler.

On the allowSecurityMananger check: 
If we check in e.g. RMIConnectionImpl constructor, and if SM is allowed we assign an ACC.
Later, we know if we have a non-null ACC then SM is allowed.  Are you saying we should then check allowSecurityManager  again?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635291389

From david.lloyd at redhat.com  Tue Jun 11 18:08:58 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 11 Jun 2024 13:08:58 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
Message-ID: <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>

On Tue, Jun 11, 2024 at 12:57?PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 11/06/2024 18:19, David Lloyd wrote:
>
> :
>
> I thought that might be where Alan was headed with this. I would support
> this solution; it would solve the problem for conformant serialization
> libraries. If a class has a `readObject`/etc. then we use it - we wouldn't
> care if it was "natural" or generated. This also gives us the option to
> allow the user to use `opens` selectively to opt-in to special
> optimizations, without a major penalty if they do not.
>
> Is there already someone assigned for this task
>
>
> Not to my knowledge so you have cycles to prototype and have these methods
> return a MH that work like a "default" readObject/writeObject then it would
> help the discussion.
>

I think I can come up with *at least* a prototype in the next week or two.
I have one concern though. The `readObject` method, when defined by users,
must by specification do one of two things before it may read values from
the stream:

* Call `OIS.defaultReadObject()`
* Call `OIS.readFields()`

In the latter case, we don't have a problem, but if the user class calls
`defaultReadObject` then we're back in the boat of having to reflectively
set the fields of the class. We could possibly solve this by creating a
*new* accessor which creates a parallel version of the method which
*always* sets fields reflectively, even if a `readObject` already exists on
the class. I'm not sure if there is a better solution. There is a similar
problem on the write side, however this involves reading fields rather than
writing them (obviously).

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240611/04c39684/attachment.htm>

From kevinw at openjdk.org  Tue Jun 11 18:11:55 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Jun 2024 18:11:55 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v4]
In-Reply-To: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
Message-ID: <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>

> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
> 
> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Remove annotations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19658/files
  - new: https://git.openjdk.org/jdk/pull/19658/files/58892d76..ed386505

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19658/head:pull/19658

PR: https://git.openjdk.org/jdk/pull/19658

From djelinski at openjdk.org  Tue Jun 11 18:25:15 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Jun 2024 18:25:15 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <O2rVUuax-qNUTH7KvYSn6MpNr_LnwE-agX5UsUMOzf0=.3ee66929-d073-4166-966a-9f6ee64b3d0a@github.com>

On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

src/java.base/share/classes/sun/security/provider/SHA3.java line 70:

> 68:     private long[] state = new long[DM*DM];
> 69: 
> 70:     // The following two arrays are allocated to size WIDTH bytes, but we only

Only one of the following arrays is of WIDTH length... outdated comment?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635306158

From djelinski at openjdk.org  Tue Jun 11 18:25:16 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Jun 2024 18:25:16 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <QakCNbZ66ev3PjuDj_1xDWhm6K6eo6oVArBeGWVNha0=.2ceec0c1-1a2f-46c4-929a-1a420353cbcb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
 <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
 <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>
 <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>
 <QakCNbZ66ev3PjuDj_1xDWhm6K6eo6oVArBeGWVNha0=.2ceec0c1-1a2f-46c4-929a-1a420353cbcb@github.com>
Message-ID: <BvlydzBw83D3-PSWvNXu_9Ds0LyC8AzzW9xzSi-uSwU=.f14416dc-d81b-42a0-823b-4d185fac382e@github.com>

On Tue, 11 Jun 2024 17:39:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> There is no other use.. That array is there for the sole purpose of  holding the input as a long array before it gets xor-ed into the state.
>
> okay

Could you try using MethodHandles instead of b2lLittle? Similar to what's used in ChaCha20:
https://github.com/openjdk/jdk/blob/b77bd5fd6a6f7ddbed90300fba790da4fb683275/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java#L132-L134

with MethodHandles you could drop longBuf, removing unnecessary allocation on the only platform where the intrinsic is implemented (MacOSX-aarch64)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635309517

From weijun at openjdk.org  Tue Jun 11 19:04:17 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Jun 2024 19:04:17 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <Gg34s2AIlChqCxi942j__gd43RoyiDfMIt8bIdoJb7I=.759c6e64-00ff-408c-90b0-76d530958a7d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <Gg34s2AIlChqCxi942j__gd43RoyiDfMIt8bIdoJb7I=.759c6e64-00ff-408c-90b0-76d530958a7d@github.com>
Message-ID: <ZP4s55UH9ubCxKJ2eDbjy5c6YGGbSalNWY7dCrw3WrU=.f22b8d9e-47ff-42f8-af42-1b3d46754ff6@github.com>

On Tue, 11 Jun 2024 18:04:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1301:
>> 
>>> 1299:                     }
>>> 1300:             };
>>> 1301:             if (acc == null) {
>> 
>> This is a comment to all the code changes in this PR. I would recommend we make use of the `allowSecurityManager()` call everywhere when the behavior is different, like this:
>> 
>> if (SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>>     if (acc == null)
>>         return action.run();
>>     else
>>         return AccessController.doPrivileged(action, acc);
>> } else {
>>     if (subject == null)
>>         return action.run();
>>     else
>>         return Subject.doAs(subject, action);
>> }
>> 
>> This makes me much more confident.
>
> Thanks I'll go through the above comments and update - some of the changes I see are unnecessary and from when I was trying migrating to callAs, and doPrivileged, and yes they can be simpler.
> 
> On the allowSecurityMananger check: 
> If we check in e.g. RMIConnectionImpl constructor, and if SM is allowed we assign an ACC.
> Later, we know if we have a non-null ACC then SM is allowed.  Are you saying we should then check allowSecurityManager  again?

Yes, the check is very light and it makes sure the old code and new code are fully separated. It's safe since it can be quite easy to see when SM is allowed there is no behavior change. In the near future when we finally remove the SM it will also be simple to remove the old code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635352326

From dnguyen at openjdk.org  Tue Jun 11 19:21:17 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Jun 2024 19:21:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <fjDM8CLc7UlLywSpW23R_oXriwUiQu6lPv9zulRvfUs=.3d7a5920-67d3-4270-a366-79df33e241ae@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
 <rxc7-Mprc8iDuw1jhUolYiMoV7l6QxCSbsgnnZ35n1U=.02728f1d-1099-4ec7-a855-1eefe95f90f3@github.com>
 <fjDM8CLc7UlLywSpW23R_oXriwUiQu6lPv9zulRvfUs=.3d7a5920-67d3-4270-a366-79df33e241ae@github.com>
Message-ID: <jbO8ccEzKKoAo9tNxRdfAaMeuN2A_18Qk_c19bJvg0o=.3b33dc8a-d611-4fdb-96e3-d513913d71aa@github.com>

On Tue, 11 Jun 2024 06:00:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> "Ausgabef?cher" is the best German translation here.
>
> The reason for going with "Bereich (area)" instead of "Fach (compartment)" is that an area is more general compared to a compartment. At least in German: every "Fach" is a "Bereich", but every "Bereich" is NOT a "Fach".

Thanks for the input @sormuras!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1635369067

From dnguyen at openjdk.org  Tue Jun 11 19:28:27 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Jun 2024 19:28:27 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert updated translation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19609/files
  - new: https://git.openjdk.org/jdk/pull/19609/files/32d69e89..e9e0bcea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609

PR: https://git.openjdk.org/jdk/pull/19609

From alanb at openjdk.org  Tue Jun 11 19:38:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Jun 2024 19:38:21 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v4]
In-Reply-To: <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>
Message-ID: <d3aggiAGNe4LBHeFafvI3QEbwXBrc-Z9BE1yKAa9lYs=.6bbb0616-b7b5-477b-9deb-9776c654148f@github.com>

On Tue, 11 Jun 2024 18:11:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove annotations

Changes look okay now. Will you update the CSR to align with the PR?

src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:

> 82: 
> 83:         System.err.println("Warning: jstatd is deprecated for removal in a future release.");
> 84: 

I think we've put "WARNING" in caps in other usages.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19658#pullrequestreview-2111296929
PR Review Comment: https://git.openjdk.org/jdk/pull/19658#discussion_r1635388247

From asemenyuk at openjdk.org  Tue Jun 11 20:01:20 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 11 Jun 2024 20:01:20 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
Message-ID: <b4_ag7ODt2hsNNfwRhoSKNQzldRPb-O_DagZiuFMIek=.b56751e1-5385-4a5e-a081-b1818cd30f2a@github.com>

On Tue, 11 Jun 2024 19:28:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert updated translation

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good

-------------

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2111344874
PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2161509207

From duke at openjdk.org  Tue Jun 11 20:08:14 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 11 Jun 2024 20:08:14 GMT
Subject: RFR: 8333867: SHA3 performance can be improved
In-Reply-To: <O2rVUuax-qNUTH7KvYSn6MpNr_LnwE-agX5UsUMOzf0=.3ee66929-d073-4166-966a-9f6ee64b3d0a@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <O2rVUuax-qNUTH7KvYSn6MpNr_LnwE-agX5UsUMOzf0=.3ee66929-d073-4166-966a-9f6ee64b3d0a@github.com>
Message-ID: <UjmefpKpAuthz3oyUoBkqzU5c8DcP4ZzkYXz43NOqJA=.7fde9576-06a8-4dc6-9554-13caef151a4b@github.com>

On Tue, 11 Jun 2024 18:18:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 70:
> 
>> 68:     private long[] state = new long[DM*DM];
>> 69: 
>> 70:     // The following two arrays are allocated to size WIDTH bytes, but we only
> 
> Only one of the following arrays is of WIDTH length... outdated comment?

Well, DM*DM*8 is WIDTH (DM=5 and WIDTH=200), so both arrays have 200 bytes, But I will update the comment to make it clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1635419497

From cjplummer at openjdk.org  Tue Jun 11 20:53:13 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Jun 2024 20:53:13 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v4]
In-Reply-To: <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>
Message-ID: <N_qKXnPBcA7-9rnMR8c3hWbaDpd_eIWHkHrfhOPvQI0=.f72d69b1-b02c-4044-a3d6-5e7c44846353@github.com>

On Tue, 11 Jun 2024 18:11:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove annotations

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19658#pullrequestreview-2111433619

From mullan at openjdk.org  Tue Jun 11 21:01:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Jun 2024 21:01:17 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>

On Tue, 11 Jun 2024 16:51:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:
> 
>> 1434:             } else {
>> 1435:                 // ACC is present, we have a Subject and SM is permitted:
>> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);
> 
> Why is it necessary to call both `doAs` and `doPrivileged`?

Can you just call `AccessController.doPrivileged(op, acc)` as in the original code? `Subject.doAs` requires a permission, which is why I assume you are wrapping it in a `doPrivileged` but you are asserting all of the permissions of the `java.management` module, which means you probably want to use limited doPriv and only assert the `getSubject` permission but that is getting complicated. I'd go back to the original call as it should work in the SM allow case.

> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 350:
> 
>> 348:     @SuppressWarnings("removal")
>> 349:     private Subject getSubject() {
>> 350:         Subject subject = null;
> 
> Just call `Subject.current()`. When SM is allowed, it is equivalent to `getSubject(AccessController.getContext())`.

For the same reason you should be able to just call `Subject.current` in the tests. I don't think you need the `SimpleStandard.useGetSubjectACC` property to toggle the testing of either old or replacement APIs as long as the test has runs in both SM allow and disallow (i.e., no SM prop set) modes. Would you agree Weijun?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635475145
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1635449088

From rriggs at openjdk.org  Tue Jun 11 21:08:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Jun 2024 21:08:12 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v2]
In-Reply-To: <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
Message-ID: <NaUKQOpdRTdfwTFuULhzLgeNFjaeOWf19-eRoB6jURw=.f7305acc-aa6d-4bfb-ba72-e97830b28aea@github.com>

On Mon, 10 Jun 2024 04:08:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obtain classloader in security manager friendly code path

This look ok.

The odd mix of coding styles and mixing of names (CD_) between static imports and local declarations is annoying but is pre-existing noise. It works better for constants than for unqualified method calls (for example, `ofConstantBootstrap`, what class is that in.)
Generally, its a bad idea to assume someone reading code is using an IDE,
source constructs that are not easily searchable or navigable with text tools make it harder to maintain.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19615#pullrequestreview-2111455328

From mullan at openjdk.org  Tue Jun 11 21:08:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Jun 2024 21:08:21 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v4]
In-Reply-To: <d3aggiAGNe4LBHeFafvI3QEbwXBrc-Z9BE1yKAa9lYs=.6bbb0616-b7b5-477b-9deb-9776c654148f@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>
 <d3aggiAGNe4LBHeFafvI3QEbwXBrc-Z9BE1yKAa9lYs=.6bbb0616-b7b5-477b-9deb-9776c654148f@github.com>
Message-ID: <wIhpHcj6H6xPj3tHaw9xDvxiUuvFr1DvT2MnUVxHqBo=.c6a93b7f-8dda-4fc5-8206-f71bdcb7574a@github.com>

On Tue, 11 Jun 2024 19:35:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove annotations
>
> src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:
> 
>> 82: 
>> 83:         System.err.println("Warning: jstatd is deprecated for removal in a future release.");
>> 84: 
> 
> I think we've put "WARNING" in caps in other usages.

I also think a period at the end is not necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19658#discussion_r1635481004

From mullan at openjdk.org  Tue Jun 11 21:12:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Jun 2024 21:12:12 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v4]
In-Reply-To: <wIhpHcj6H6xPj3tHaw9xDvxiUuvFr1DvT2MnUVxHqBo=.c6a93b7f-8dda-4fc5-8206-f71bdcb7574a@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>
 <d3aggiAGNe4LBHeFafvI3QEbwXBrc-Z9BE1yKAa9lYs=.6bbb0616-b7b5-477b-9deb-9776c654148f@github.com>
 <wIhpHcj6H6xPj3tHaw9xDvxiUuvFr1DvT2MnUVxHqBo=.c6a93b7f-8dda-4fc5-8206-f71bdcb7574a@github.com>
Message-ID: <LISaI-LJ9qv_-K2tcQi9-LTTf3QEehsNjswllnhl-40=.717b32eb-65bc-441c-8a63-0eb9e193627d@github.com>

On Tue, 11 Jun 2024 21:05:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:
>> 
>>> 82: 
>>> 83:         System.err.println("Warning: jstatd is deprecated for removal in a future release.");
>>> 84: 
>> 
>> I think we've put "WARNING" in caps in other usages.
>
> I also think a period at the end is not necessary.

For the Security Manager, the warning was worded a little differently:

"WARNING: The Security Manager is deprecated and will be removed in a future release"

I think that wording is more clear. The current wording could be confusing because JDK 24 is when jstatd is deprecated for removal, and not a future release. The wording above is more definitive for those that may not understand what "deprecated for removal" means. Thus, I suggest:

"WARNING: jstatd is deprecated and will be removed in a future release"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19658#discussion_r1635483989

From duke at openjdk.org  Tue Jun 11 22:01:17 2024
From: duke at openjdk.org (duke)
Date: Tue, 11 Jun 2024 22:01:17 GMT
Subject: Withdrawn: 8329532: Add an internal MemoryLayout transformer
In-Reply-To: <T2o8-ydusVWV-j-_mXmqnQEQ62b4JeAdgDCyX7-uNhA=.42fad3ee-75ff-44ab-bb89-a5c374dc63d4@github.com>
References: <T2o8-ydusVWV-j-_mXmqnQEQ62b4JeAdgDCyX7-uNhA=.42fad3ee-75ff-44ab-bb89-a5c374dc63d4@github.com>
Message-ID: <N5PYY3r-aIpwchDncm9wXywOuUSbUjJBdvKA0jYTNA0=.748c74d2-6228-49d7-8603-bde646335f3f@github.com>

On Tue, 2 Apr 2024 15:04:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add an internal layout transformer that could be used to transform MemoryLayout entities. For example, it would be possible to convert a struct layout to use network order ((big-endian) instead of native byte order (often little-endian). Another application is to remove naming recursively for composite layouts when caching shapes etc.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18582

From achung at openjdk.org  Tue Jun 11 22:54:19 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 11 Jun 2024 22:54:19 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
Message-ID: <tWMKY1f1KglIZZuTUdD9ZpYS8hmiiIeTv9nytEhFZWE=.201e7860-bc28-4ac4-8812-a8866d1801c1@github.com>

On Tue, 11 Jun 2024 19:28:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert updated translation

LGTM

-------------

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2111576337

From achung at openjdk.org  Tue Jun 11 22:54:21 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 11 Jun 2024 22:54:21 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <0xmUIRy1V_ts7yyfm1kMaQfbzU5YoJSWAzD3QDNLY7U=.8e0e163e-d0c6-4f22-a92d-79de8c58e8f6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
 <0xmUIRy1V_ts7yyfm1kMaQfbzU5YoJSWAzD3QDNLY7U=.8e0e163e-d0c6-4f22-a92d-79de8c58e8f6@github.com>
Message-ID: <P-vtaJDvvh15Fb-zFtwRbpDSNxovZZXzDiYfFO9Fa0g=.6570cfd3-6cc4-4100-bf53-0f7bd09820fb@github.com>

On Mon, 10 Jun 2024 20:37:41 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 32:
>> 
>>> 30: border.jobattributes=????
>>> 31: border.media=??
>>> 32: border.output=??
>> 
>> What triggered this ? Just someone noticing it and deciding there's a better translation ?
>> What does it say ?
>
> In the past, it was brought up in review that some of the words were translated to localized words that didn't exactly mean what the original English word meant. I believe Weijun Wang caught some of these in Chinese files in the past.  I'm assuming these are cases where the go team is improving the translation, but I also can't exactly tell. We do suggest changes to the go team, so maybe this is evidence of them improving their tool.

It was changed from "paper output" to just "output". Since the original English doesn't specify anything about paper, I guess the new translation is more general and fitting in this case.

The original inclusion of the border.output field was actually part of the output bin update on [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070) so it was actually not initially translated by the translation team.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1635559474

From achung at openjdk.org  Tue Jun 11 23:13:17 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 11 Jun 2024 23:13:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
Message-ID: <sc34YUtz7xCMiUCtBjFH8Gx9qMQ_6wN20ORFRkBMXZA=.cbdb0a2e-c35a-4a7a-b640-9d1a5dcb62b9@github.com>

On Mon, 10 Jun 2024 20:46:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert updated translation
>
> Did not look at each for translation accuracy (did some for Japanese), but looks good overall.
> It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!

An interesting note after looking at Phil's comment on the serviceui.properties change is that there is no Japanese update for that file. The translations on [here](https://github.com/openjdk/jdk/commit/c7d2a5c1c4e86955100f4c40170dc25222abd07f#diff-38c26a463e174224c6b9fc5007f3058482e533dc0f60f3275e21f9f2fc9acf8e) from the output bins update look good to me but maybe @naotoj should double check in case?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2161748245

From naoto at openjdk.org  Tue Jun 11 23:29:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Jun 2024 23:29:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
Message-ID: <8pnAwewRWdiqnLGBNNUGPwD7bjUsuVhUDtaPC8IJ7Bc=.c7ceb4be-dc7a-48ff-9ee2-7aa3d94b2ead@github.com>

On Mon, 10 Jun 2024 20:46:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert updated translation
>
> Did not look at each for translation accuracy (did some for Japanese), but looks good overall.
> It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!

> An interesting note after looking at Phil's comment on the serviceui.properties change is that there is no Japanese update for that file. The translations on [here](https://github.com/openjdk/jdk/commit/c7d2a5c1c4e86955100f4c40170dc25222abd07f#diff-38c26a463e174224c6b9fc5007f3058482e533dc0f60f3275e21f9f2fc9acf8e) from the output bins update look good to me but maybe @naotoj should double check in case?

I can confirm that English "Out&put trays:" to "?????(&P):" is OK

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2161765683

From duke at openjdk.org  Tue Jun 11 23:33:11 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 11 Jun 2024 23:33:11 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <ik6LMV8FAB73NLePraQmBRGaRRU5DKiXCWQ8V-9-_eE=.f845b63c-d723-4772-bed9-49a79ab9c167@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <sLLwY_A95pj3a62IYg3HTO7Lw6tI1SwF4qb4CT0mz10=.81db16a6-4e17-4d8b-b694-2b19605e5965@github.com>
 <yK7XjXIvol4vo8f2pLXgooWXQF_xP1mr26lfo0kNOKg=.69ee8193-42fb-4870-a030-e470af5789ed@github.com>
 <K9hwrh9iTTyV3Xr8NZNjquCQshofREdRROWsyWehpYA=.51ccfe5d-94a8-47ae-a935-bc5798556ba0@github.com>
 <ik6LMV8FAB73NLePraQmBRGaRRU5DKiXCWQ8V-9-_eE=.f845b63c-d723-4772-bed9-49a79ab9c167@github.com>
Message-ID: <CVuQTv85RtUFUPFvU6fUEsu-6XvefZxWGj6vkCNuMKQ=.78f35d80-fea8-4f00-b76d-b72b194fa5f9@github.com>

On Tue, 11 Jun 2024 16:08:18 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 TraceMergeStores are here,  but I can't understand these assembly codes
>> 
>> # JavaCode
>> 
>> class AbstractStringBuilder {
>>      private AbstractStringBuilder appendNull() {
>>         int count = this.count;
>>         ensureCapacityInternal(count + 4);
>>         byte[] val = this.value;
>>         if (isLatin1()) {
>>             val[count    ] = 'n';
>>             val[count + 1] = 'u';
>>             val[count + 2] = 'l';
>>             val[count + 3] = 'l';
>>         } else {
>>             StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
>>         }
>>         this.count = count + 4;
>>         return this;
>>     }
>> }
>> 
>> class StringUTF16 {
>>     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>>         putChar(value, i    , c1);
>>         putChar(value, i + 1, c2);
>>         putChar(value, i + 2, c3);
>>         putChar(value, i + 3, c4);
>>     }
>> }
>> 
>> 
>> # TraceMergeStores
>> 
>> [TraceMergeStores]: Replace
>>   78  StoreB  === 61 7 76 12  [[ 103 89 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:43 (line 71)
>>  103  StoreB  === 88 78 101 80  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:52 (line 72)
>> [TraceMergeStores]: with
>>   12  Parm  === 3  [[ 78 66 38 80 107 113 ]] Parm2: int !jvms: StringUTF16::putChar @ bci:-1 (line 69)
>>  113  StoreC  === 88 7 76 12  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5;
>
> @wenshao The output you have here is not at all the `TraceMergeStores`, but the assembly dump, probably from `PrintOptoAssembly`. In you entire log I never see a single occurance of `TraceMergeStores`, so presumably no such optimisation was done.
> 
> I suggest you play around with the examples from my PR https://github.com/openjdk/jdk/pull/16245, and the `TraceMergeStores` flag. That will give you some insight about how it works, and maybe give you a way into understanding why your examples are not optimized.

@eme64  Thank you for your patient reply. The multiple versions of TraceMergeStores are as follows

# 1 Current Version (Webrevs 3)

03: [Full](https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=03) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=02-03) ([27a3050a](https://git.openjdk.org/jdk/pull/19626/files/27a3050a73ec4a65edbdb23383237a08037e0462))

## 1.1 JavaCode

class AbstractStringBuilder {
     private AbstractStringBuilder appendNull() {
        int count = this.count;
        ensureCapacityInternal(count + 4);
        byte[] val = this.value;
        if (isLatin1()) {
            val[count    ] = 'n';
            val[count + 1] = 'u';
            val[count + 2] = 'l';
            val[count + 3] = 'l';
        } else {
            StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
        }
        this.count = count + 4;
        return this;
    }
}

class StringUTF16 {
    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
    }
}


## 1.2 TraceMergeStores

[TraceMergeStores]: Replace
  78  StoreB  === 61 7 76 12  [[ 103 89 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:43 (line 71)
 103  StoreB  === 88 78 101 80  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:52 (line 72)
[TraceMergeStores]: with
  12  Parm  === 3  [[ 78 66 38 80 107 113 ]] Parm2: int !jvms: StringUTF16::putChar @ bci:-1 (line 69)
 113  StoreC  === 88 7 76 12  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5;



# 2 Repleace StringUTF16.putChar (Webrevs 2)

02: [Full](https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=02) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=01-02) ([f96cde4e](https://git.openjdk.org/jdk/pull/19626/files/f96cde4e79e12e2ea46e6061f918a69f11d59985))

## 2.1 JavaCode

class AbstractStringBuilder {
     private AbstractStringBuilder appendNull() {
        int count = this.count;
        ensureCapacityInternal(count + 4);
        byte[] val = this.value;
        if (isLatin1()) {
            val[count    ] = 'n';
            val[count + 1] = 'u';
            val[count + 2] = 'l';
            val[count + 3] = 'l';
        } else {
            StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
        }
        this.count = count + 4;
        return this;
    }
}

class StringUTF16 {
    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
        i <<= 1;
        putChar0(value, i    , c1);
        putChar0(value, i + 2, c2);
        putChar0(value, i + 4, c3);
        putChar0(value, i + 6, c4);
    }

    private static void putChar0(byte[] value, int i, int c) {
        value[i    ] = (byte)(c >> HI_BYTE_SHIFT);
        value[i + 1] = (byte)(c >> LO_BYTE_SHIFT);
    }
}


## 2.2 TraceMergeStores

[TraceMergeStores]: Replace
  645  StoreB  === 629 509 643 583  [[ 671 657 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:8 (line 1586) StringUTF16::putCharsAt @ bci:7 (line 1569) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  671  StoreB  === 656 645 669 45  [[ 710 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:7 (line 1569) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  710  StoreB  === 656 671 708 584  [[ 735 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:8 (line 1586) StringUTF16::putCharsAt @ bci:15 (line 1570) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  735  StoreB  === 656 710 733 45  [[ 774 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:15 (line 1570) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  774  StoreB  === 656 735 772 585  [[ 800 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:8 (line 1586) StringUTF16::putCharsAt @ bci:24 (line 1571) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  800  StoreB  === 656 774 798 45  [[ 839 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:24 (line 1571) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  839  StoreB  === 656 800 837 585  [[ 865 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:8 (line 1586) StringUTF16::putCharsAt @ bci:34 (line 1572) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  865  StoreB  === 656 839 863 45  [[ 885 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:34 (line 1572) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
[TraceMergeStores]: with
 1801  ConL  === 0  [[ 1802 ]]  #long:30399761348886638
 1802  StoreL  === 656 509 643 1801  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  635  StoreB  === 619 499 633 573  [[ 661 647 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:8 (line 1586) StringUTF16::putCharsAt @ bci:7 (line 1569) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  661  StoreB  === 646 635 659 35  [[ 700 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:7 (line 1569) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  700  StoreB  === 646 661 698 574  [[ 725 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:8 (line 1586) StringUTF16::putCharsAt @ bci:15 (line 1570) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  725  StoreB  === 646 700 723 35  [[ 764 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:15 (line 1570) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  764  StoreB  === 646 725 762 575  [[ 790 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:8 (line 1586) StringUTF16::putCharsAt @ bci:24 (line 1571) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  790  StoreB  === 646 764 788 35  [[ 829 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:24 (line 1571) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  829  StoreB  === 646 790 827 575  [[ 855 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:8 (line 1586) StringUTF16::putCharsAt @ bci:34 (line 1572) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  855  StoreB  === 646 829 853 35  [[ 875 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:34 (line 1572) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
[TraceMergeStores]: with
 1785  ConL  === 0  [[ 1786 ]]  #long:30399761348886638
 1786  StoreL  === 646 499 633 1785  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;



# 3 Use SetLong
## 3.1 Java Code

class AbstractStringBuilder {
    static final long NULL_UTF16;
    static {
        byte[] bytes8 = new byte[8];
        StringUTF16.putCharsAt(bytes8, 0, 'n', 'u', 'l', 'l');
        NULL_UTF16 = getLong(bytes8, 0);
    }

    private static void setLong(byte[] array, int offset, long value) {
        array[offset]     = (byte) (value      );
        array[offset + 1] = (byte) (value >>  8);
        array[offset + 2] = (byte) (value >> 16);
        array[offset + 3] = (byte) (value >> 24);
        array[offset + 4] = (byte) (value >> 32);
        array[offset + 5] = (byte) (value >> 40);
        array[offset + 6] = (byte) (value >> 48);
        array[offset + 7] = (byte) (value >> 56);
    }

    private static long getLong(byte[] array, int offset) {
        return ((long) array[offset    ] & 0xff)
             | (((long) array[offset + 1] & 0xff) <<  8)
             | (((long) array[offset + 2] & 0xff) << 16)
             | (((long) array[offset + 3] & 0xff) << 24)
             | (((long) array[offset + 4] & 0xff) << 32)
             | (((long) array[offset + 5] & 0xff) << 40)
             | (((long) array[offset + 6] & 0xff) << 48)
             | (((long) array[offset + 7] & 0xff) << 56);
    }

    private AbstractStringBuilder appendNull() {
        int count = this.count;
        ensureCapacityInternal(count + 4);
        byte[] val = this.value;
        if (isLatin1()) {
            val[count    ] = 'n';
            val[count + 1] = 'u';
            val[count + 2] = 'l';
            val[count + 3] = 'l';
        } else {
            setLong(val, count << 1, NULL_UTF16);
        }
        this.count = count + 4;
        return this;
    }
}


## 3.2 TraceMergeStores

[TraceMergeStores]: Replace
  636  StoreB  === 620 509 634 601  [[ 665 651 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:5 (line 72) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616) StringBuilder::append @ bci:2 (line 179)
  665  StoreB  === 650 636 663 45  [[ 695 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:16 (line 73) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616) StringBuilder::append @ bci:2 (line 179)
  695  StoreB  === 650 665 693 674  [[ 723 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:27 (line 74) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616) StringBuilder::append @ bci:2 (line 179)
  723  StoreB  === 650 695 721 45  [[ 754 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:38 (line 75) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616) StringBuilder::append @ bci:2 (line 179)
  754  StoreB  === 650 723 752 733  [[ 784 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:49 (line 76) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616) StringBuilder::append @ bci:2 (line 179)
  784  StoreB  === 650 754 782 45  [[ 813 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:60 (line 77) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616) StringBuilder::append @ bci:2 (line 179)
  813  StoreB  === 650 784 811 733  [[ 841 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:72 (line 78) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616) StringBuilder::append @ bci:2 (line 179)
  841  StoreB  === 650 813 839 45  [[ 858 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:84 (line 79) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616) StringBuilder::append @ bci:2 (line 179)
[TraceMergeStores]: with
  585  ConL  === 0  [[ 654 625 1774 ]]  #long:30399761348886638
 1774  StoreL  === 650 509 634 585  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  626  StoreB  === 610 499 624 591  [[ 655 641 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:5 (line 72) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616)
  655  StoreB  === 640 626 653 35  [[ 685 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:16 (line 73) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616)
  685  StoreB  === 640 655 683 664  [[ 713 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:27 (line 74) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616)
  713  StoreB  === 640 685 711 35  [[ 744 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:38 (line 75) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616)
  744  StoreB  === 640 713 742 723  [[ 774 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:49 (line 76) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616)
  774  StoreB  === 640 744 772 35  [[ 803 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:60 (line 77) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616)
  803  StoreB  === 640 774 801 723  [[ 831 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:72 (line 78) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616)
  831  StoreB  === 640 803 829 35  [[ 848 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: AbstractStringBuilder::setLong @ bci:84 (line 79) AbstractStringBuilder::appendNull @ bci:60 (line 676) AbstractStringBuilder::append @ bci:5 (line 616)
[TraceMergeStores]: with
  575  ConL  === 0  [[ 644 615 1758 ]]  #long:30399761348886638
 1758  StoreL  === 640 499 624 575  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2161770382

From duke at openjdk.org  Wed Jun 12 00:50:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 00:50:18 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <0ITtauFjoDHBseEgjwjWCO9SQKAoNdsVDHWxnxqtVJA=.821f4035-a7c7-4a3d-9d1e-34b940cf5404@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

It seems that MergeStore in [WebRev2 f96cde4e](https://git.openjdk.org/jdk/pull/19626/files/f96cde4e79e12e2ea46e6061f918a69f11d59985) version is working, but I don?t know why the performance is not improved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2161856600

From almatvee at openjdk.org  Wed Jun 12 01:22:24 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 12 Jun 2024 01:22:24 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
 [v6]
In-Reply-To: <By9S_mSNwK-pKYIY3yKsnWQgjaEqh1yluvZLKw3SZ9k=.213bfa41-c608-49b8-8c52-8e6e086ebf26@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
 <By9S_mSNwK-pKYIY3yKsnWQgjaEqh1yluvZLKw3SZ9k=.213bfa41-c608-49b8-8c52-8e6e086ebf26@github.com>
Message-ID: <9MysvmJtKFdwAwoU_W_eo8vHS3YfUQXcQG4ROO6idT8=.88c07600-f86f-489a-8c3a-01e2a879c958@github.com>

On Thu, 6 Jun 2024 12:58:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Add support for WiX4 and WiX5 in jpackage.
>> 
>> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
>> 
>> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
>> 
>> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
>> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
>> 
>> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add WiX v5 to "error.no-wix-tools"

Looks good. No more questions or comments.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19318#pullrequestreview-2111715766

From syan at openjdk.org  Wed Jun 12 02:05:18 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Jun 2024 02:05:18 GMT
Subject: RFR: 8334057: JLinkReproducibleTest.java support receive
 test.tool.vm.opts
Message-ID: <KLCSi8ZqLBZYEMDi69_ZCdd0n11vIoVK1PwyibojxdI=.ab52f23c-f358-47bb-8121-abeb208470b8@github.com>

Hi all,
Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg.
I think it's necessory to receive jvm options from jtreg.
The change has been verified, only change the testacase, the risk is low.

-------------

Commit messages:
 - 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts

Changes: https://git.openjdk.org/jdk/pull/19669/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19669&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334057
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19669.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19669/head:pull/19669

PR: https://git.openjdk.org/jdk/pull/19669

From dholmes at openjdk.org  Wed Jun 12 03:06:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Jun 2024 03:06:13 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
 [v2]
In-Reply-To: <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
 <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>
Message-ID: <jaAWSJ2OscoxY7f3BTpKY1FydOEnMh6rT5J4sCgn2bY=.32880f05-7b95-400f-8ae8-f6f3e96c055b@github.com>

On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
>> 
>> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
>> 
>> **Testing**
>> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace wrapper with casts.

Okay. I hate the fact we have to do this, but okay. 

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19567#pullrequestreview-2111852338

From epeter at openjdk.org  Wed Jun 12 05:09:12 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 05:09:12 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <kV2D2nqMFwkyUv0LoG12a7XAogAPOYh0huzUnJoMpr0=.3e9103aa-659a-4e4e-99a1-326555ff4dde@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Nice, thanks for the extra logs. Ok, the optimization is at least working. Maybe not always fully. In 1.2 we see that only 2 stores were merged, those from lines 71 and 72. So that would be a potential loss of performance. That could be interesting to debug. Can you create a stand-alone reproducer, so just a single java file, where the code looks as similar as here, an where it produces the same kind of `TraceMergeStores` output? I could look into that.

Also: do you expect only the "not" `isLatin1()` case to merge the stores, or also in the `isLatin1()` case? It would be interesting here to extract the relevant (and only the relevant) assembly code. There we would be looking for the stores. These would be byte-stores if not merged, and fewer but larger stores if merged. Since the assembly is annotated with the methods, you can find it relatively easily. You will be looking for `mov` kinds of instructions that store register values into addresses. You can easily learn more about assembly and `mov` instructions online.

General explanations of `mov` instructions:
https://c9x.me/x86/html/file_module_x86_id_176.html
https://www.felixcloutier.com/x86/mov

About the suffixes, i.e. `movq` vs `movl` etc.
https://stackoverflow.com/questions/67690999/assembly-do-we-need-the-endings

I hope this helps ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162114560

From epeter at openjdk.org  Wed Jun 12 05:14:14 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 05:14:14 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <6DbLs2sdtDGx1O5ItaQgMJpAHOGGrWf60ALZqMn_vgI=.4c1fdb96-092d-4397-802b-d004d74806bf@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Ah, another issue is method inlining. It seems that in 1.2, the method is not inlined:
` 103  StoreB  === 88 78 101 80  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:52 (line 72)`
In the extra information I only see `StringUTF16::putChar @ bci:52 (line 72)`, so this method was not inlined. So of course there are only the 2 stores to be merged from `putChar`. Maybe you can do something about this with `@ForceInline`. 

In 2.2 I see there is more inlining:
`  865  StoreB  === 656 839 863 45  [[ 885 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar0 @ bci:19 (line 1587) StringUTF16::putCharsAt @ bci:34 (line 1572) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)`
Though I cannot seem to map it to your java code, maybe you pasted things together wrongly here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162118831

From jpai at openjdk.org  Wed Jun 12 05:39:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 05:39:19 GMT
Subject: RFR: 8222884: ConcurrentClassDescLookup.java times out
 intermittently
In-Reply-To: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>
References: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>
Message-ID: <Bg0gwCEIs33k4M1px2ij00V-qBvy-Dbot8lAnHYSHqQ=.e46a4a4c-1858-48e4-854a-d2956c132f67@github.com>

On Tue, 11 Jun 2024 13:09:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address intermittent failures in `test/jdk/java/io/Serializable/concurrentClassDescLookup/ConcurrentClassDescLookup.java`?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8222884. As noted in that issue, the test in its current form has a potential race. The test main thread launches 50 "successful lookup" tasks and 50 "failed lookup" tasks. Each task is a `Thread`. The test passes an `Object` instance shared by 50 of these tasks and each task when it starts execution in its `run()` method does a `wait()` on that `Object` instance. The test main thread then after launching 50 tasks, sleeps for a second (to let the 50 `Thread`s start execution and arrive at the `Object.wait()`) and then after waking up the main thread does a `notifyAll()` on that `Object` instance. In theory and likely in practice too, it's possible that (especially) for the last batch of 50 tasks (the "failing lookup" tasks), the `notifyAll()` might end up getting invoked before one or more task Thread(s) have actually done a `wait()`. That can then mean that one or more task `Thread`(s) will keep `wait()`ing indefinitely with no on
 e `notify()`ing the `Object` instance to proceed with the task execution.
> 
> The commit in this PR removes the use of `Object.wait()/notifyAll()` and instead uses a `CountdownLatch` to allow for a more deterministic barrier. The test continues to pass with this change. Additionally, this change was run against a CI setup, by Matthias, where it was previously failing intermittently. Matthias reports that it hasn't failed after this change.

Thank you Roger and Matthias for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19659#issuecomment-2162143042

From jpai at openjdk.org  Wed Jun 12 05:39:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 05:39:19 GMT
Subject: Integrated: 8222884: ConcurrentClassDescLookup.java times out
 intermittently
In-Reply-To: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>
References: <p9S8JaEWNbJNBeaHV6sLhRJNoOF4cEs40CKlw1OlgLk=.7ba44769-d5cf-4c93-920c-d52eac06da6c@github.com>
Message-ID: <6Eod_exdiLld6WnfrMPwHCFQUuoO9dNY2WcgPkbriLI=.aa38af47-e631-4a0f-a133-004d72458a69@github.com>

On Tue, 11 Jun 2024 13:09:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address intermittent failures in `test/jdk/java/io/Serializable/concurrentClassDescLookup/ConcurrentClassDescLookup.java`?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8222884. As noted in that issue, the test in its current form has a potential race. The test main thread launches 50 "successful lookup" tasks and 50 "failed lookup" tasks. Each task is a `Thread`. The test passes an `Object` instance shared by 50 of these tasks and each task when it starts execution in its `run()` method does a `wait()` on that `Object` instance. The test main thread then after launching 50 tasks, sleeps for a second (to let the 50 `Thread`s start execution and arrive at the `Object.wait()`) and then after waking up the main thread does a `notifyAll()` on that `Object` instance. In theory and likely in practice too, it's possible that (especially) for the last batch of 50 tasks (the "failing lookup" tasks), the `notifyAll()` might end up getting invoked before one or more task Thread(s) have actually done a `wait()`. That can then mean that one or more task `Thread`(s) will keep `wait()`ing indefinitely with no on
 e `notify()`ing the `Object` instance to proceed with the task execution.
> 
> The commit in this PR removes the use of `Object.wait()/notifyAll()` and instead uses a `CountdownLatch` to allow for a more deterministic barrier. The test continues to pass with this change. Additionally, this change was run against a CI setup, by Matthias, where it was previously failing intermittently. Matthias reports that it hasn't failed after this change.

This pull request has now been integrated.

Changeset: bd046d9b
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660
Stats:     36 lines in 1 file changed: 7 ins; 7 del; 22 mod

8222884: ConcurrentClassDescLookup.java times out intermittently

Reviewed-by: rriggs, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/19659

From duke at openjdk.org  Wed Jun 12 06:19:15 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 06:19:15 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <pK-x42kXkHiaUri1hVvImHAzwzFIrmjc2kp_-GMYGJo=.56386c42-4825-49c7-8c5e-d9fcc3b46dd8@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

In the case of isLatin1(), it can also be merged. I also found that false will merge the last four characters "alse" instead of the first four characters "fals".

below stand-alone reproducer:

* JavaCode

public class SBTraceStoreTest {
    static final StringBuilder buf = new StringBuilder(1024);

    static int append(boolean utf16, boolean appendNull) {
        buf.delete(0, buf.length());
        if (utf16) {
            buf.append('\u4e2d');
        }
        for (int i = 0; i < 10; i++) {
            if (appendNull) {
                buf.append((String) null)
                        .append((String) null);
            } else {
                buf.append(true)
                        .append(false);
            }
        }
        return buf.length();
    }

    public static void appendTest(boolean utf16, boolean appendNull) {
        for (int j = 0; j < 5; j++) {
            long start = System.currentTimeMillis();
            for (int i = 0; i < 100_000; ++i) {
                append(utf16, appendNull);
            }
            long millis = System.currentTimeMillis() - start;
            System.out.println("SBTraceStoreTest-" + (appendNull ? "appendNull" : "appendBool")
                    + (utf16 ? "UTF16" : "Latin1")
                    + " millis : " + millis);
        }
    }

    public static void main(String[] args) throws Exception {
        String test = System.getProperty("test");
        if (test == null) {
            test = "appendBoolUTF16";
        }
        switch (test) {
            case "appendNullLatin1":
                appendTest(false, true);
                break;
            case "appendNullUTF16":
                appendTest(true, true);
                break;
            case "appendBool":
                appendTest(false, false);
                appendTest(false, false);
                break;
            case "appendBoolLatin1":
                appendTest(false, false);
                break;
            case "appendBoolUTF16":
            default:
                appendTest(true, false);
                break;
        }
    }
}


* Produce

export JAVA_HOME=/Users/wenshao/Work/git/jdk/build/macosx-aarch64-server-fastdebug/jdk
javac SBTraceStoreTest.java
java -XX:+TraceMergeStores -Dtest=appendBoolLatin1 SBTraceStoreTest

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162188635

From epeter at openjdk.org  Wed Jun 12 07:34:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 07:34:17 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <Wg1t5Owj7VMlhOHoOngyPmosRZh9R4UdOsjZ89y_jOk=.44fa0145-0a64-4d00-9764-acdb1977a3e5@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Can you make this stand-alone reproducer even more stand alone, so that your different implementations are available as a choice? I don't want to have to check out different versions of your changes in the PR. Maybe we can just focus on a single example for now (appendBoolLatin1 ?), so that we can learn together what is going wrong in that case. Then you can take those learnings and analyze the other cases yourself ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162306966

From jpai at openjdk.org  Wed Jun 12 07:54:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 07:54:14 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
Message-ID: <h6V-G0Nl7RT17PdyK-MYgUKJ4IJxtqnNmiKMPpSLZcs=.72faf6cc-7320-4e98-9814-3238b2e72fa3@github.com>

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

Hello Chris, I just noticed that there have been (unrelated) changes in this file in the master. Could you please merge the latest master branch changes into this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2162345189

From jpai at openjdk.org  Wed Jun 12 08:10:17 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 08:10:17 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
Message-ID: <tBMLN33Tkp9Gg2kJu5BfraPi1Oejw9ImSKAIDQzqps8=.33aae81b-c742-4f19-8d2a-a0aa8b5f8622@github.com>

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1222:

> 1220:             // Math.round rounds toward infinity in conversion to long; adding 1.0 corrects for any
> 1221:             // downward rounding error in the division
> 1222:             maxExtraMinus1 = Math.round(1.0 + maxValue / DoubleZigguratTables.exponentialX0);

We had asked Guy Steele for his inputs on these proposed changes. Guy reviewed these changes and for this specific if/else block change, he notes that (I've paraphrased it):

> the (proposed new) computation of `maxExtraMinus1` looks okay to me: it?s always okay for maxExtraMinus1 to be a bit larger than you might expect; the only downside is that the (for) loop starting (on the next line) might take extra iterations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1636013052

From jpai at openjdk.org  Wed Jun 12 08:21:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 08:21:18 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
Message-ID: <I7TTiiAVgMXJLiUXnjq3TBkbvWmYoqcbit2PpSqmQ54=.b2666bdb-4a72-4a4d-94d2-78f90c0397f2@github.com>

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1214:

> 1212:         // We didn't use the upper part of U1 after all.  We'll probably be able to use it later.
> 1213:         if (maxValue <= DoubleZigguratTables.exponentialX0) {
> 1214:             return DoubleZigguratTables.exponentialX0;

Chris, could you explain why this change to this if block is necessary? Guy notes that (I've paraphrased):

> I can see that (without this proposed change here), if `maxValue` is not greater than `DoubleZigguratTables.exponentialX0`, then the subsequent computation for `maxExtraMinus1`, a few lines below using `Math.round()`, will compute 1 or 2 for the value of `maxExtraMinus1`. But with this proposed change, it just returns `DoubleZigguratTables.exponentialX0`, which by the contract of `computeNextExponentialSoftCapped` is okay (the doc says "{@code maxValue} is a "soft" cap in that a value larger than {@code maxValue} may be returned in order to save a calculation" and I remember that that is true). So that is also okay. The motivation for doing so would be that it saves computation time overall. The part I don't quite understand yet is the judgment that it will in fact save computation time overall. If you take advantage of the "soft cap" then it could cause additional iteration of the loop in `computeNextGaussian` where this `computeNextExponentialSoftCapped` method gets called. I'm u
 ncertain whether the change to this if block is guaranteed or likely to save computation time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1636024966

From duke at openjdk.org  Wed Jun 12 08:44:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 08:44:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <F-zUuTB0vkzHomKwEObxVo7V8RSi3sIaQXJf7CKDkVQ=.8add59a1-d8e7-4564-bc61-e1bc150a0197@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

below stand-alone reproducer,  But StringUTF16.putChar is an instrinsic method and cannot be simulated.

import java.nio.ByteOrder;
import java.util.Arrays;

public class AppendNullTest {
    public static class StringBuilder {
        byte[] value;
        byte coder;
        int count;

        public StringBuilder(boolean utf16) {
            value = new byte[0];
            coder = (byte) (utf16 ? 1 : 0);
        }

        public static boolean canEncode(char cp) {
            return cp <= 0xff;
        }

        private StringBuilder appendNull() throws Throwable {
            int count = this.count;
            ensureCapacityInternal(count + 4);
            byte[] val = this.value;
            if (isLatin1()) {
                val[count    ] = 'n';
                val[count + 1] = 'u';
                val[count + 2] = 'l';
                val[count + 3] = 'l';
            } else {
                StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
            }
            this.count = count + 4;
            return this;
        }

        public StringBuilder append(boolean b) throws Throwable {
            int count = this.count;
            int spaceNeeded = count + (b ? 4 : 5);
            ensureCapacityInternal(spaceNeeded);
            byte[] val = this.value;
            if (isLatin1()) {
                if (b) {
                    val[count    ] = 't';
                    val[count + 1] = 'r';
                    val[count + 2] = 'u';
                    val[count + 3] = 'e';
                } else {
                    val[count    ] = 'f';
                    val[count + 1] = 'a';
                    val[count + 2] = 'l';
                    val[count + 3] = 's';
                    val[count + 4] = 'e';
                }
            } else {
                if (b) {
                    StringUTF16.putCharsAt(val, count, 't', 'r', 'u', 'e');
                } else {
                    StringUTF16.putCharsAt(val, count, 'f', 'a', 'l', 's', 'e');
                }
            }
            this.count = spaceNeeded;
            return this;
        }

        private void ensureCapacityInternal(int minimumCapacity) {
            int oldCapacity = value.length >> coder;
            if (minimumCapacity - oldCapacity > 0) {
                value = Arrays.copyOf(value,
                        newCapacity(minimumCapacity) << coder);
            }
        }

        private int newCapacity(int minCapacity) {
            int oldLength = value.length;
            int newLength = minCapacity << coder;
            int growth = newLength - oldLength;
            int length = oldLength + Math.max(growth, oldLength + (2 << coder));
            return length >> coder;
        }

        final boolean isLatin1() {
            return coder == 0;
        }

        public void clear() {
            int count = 0;
            coder = 0;
        }
    }

    static class StringUTF16 {
        public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) throws Throwable {
            putChar(value, i    , c1);
            putChar(value, i + 1, c2);
            putChar(value, i + 2, c3);
            putChar(value, i + 3, c4);
        }

        public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4, char c5) throws Throwable {
            putChar(value, i    , c1);
            putChar(value, i + 1, c2);
            putChar(value, i + 2, c3);
            putChar(value, i + 3, c4);
            putChar(value, i + 4, c5);
        }

        private static final int HI_BYTE_SHIFT;
        private static final int LO_BYTE_SHIFT;
        static {
            if (ByteOrder.nativeOrder() == ByteOrder.BIG_ENDIAN) {
                HI_BYTE_SHIFT = 8;
                LO_BYTE_SHIFT = 0;
            } else {
                HI_BYTE_SHIFT = 0;
                LO_BYTE_SHIFT = 8;
            }
        }

        static void putChar(byte[] val, int index, int c) {
            index <<= 1;
            val[index++] = (byte)(c >> HI_BYTE_SHIFT);
            val[index]   = (byte)(c >> LO_BYTE_SHIFT);
        }
    }

    public static void main(String[] args) throws Throwable {
        StringBuilder sb = new StringBuilder(true);
        for (int i = 0; i < 1_000_000; i++) {
            sb.appendNull().appendNull().appendNull().appendNull().appendNull();
//            sb.append(true).append(false).append(true).append(false).append(true).append(false);
            sb.clear();
        }
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162441299

From amitkumar at openjdk.org  Wed Jun 12 08:48:14 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 12 Jun 2024 08:48:14 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
 [v2]
In-Reply-To: <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
 <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>
Message-ID: <8NPiv3DoixO427VpYioPjHqTV3mXEmUqHbIVUeK--NE=.e6c60f92-9f9f-4525-b216-d75ebb5dae41@github.com>

On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
>> 
>> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
>> 
>> **Testing**
>> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace wrapper with casts.

It was a good learning; You might want to update the copyright header for few of the files. 

Thanks,

-------------

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19567#pullrequestreview-2112359981

From jpai at openjdk.org  Wed Jun 12 09:26:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 09:26:19 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
Message-ID: <ydAPTl9qq1McwfqKeh39LRynljlcTemTzwg5man_3f4=.204d73ff-7182-411e-a95f-20b5258d0a5e@github.com>

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

test/jdk/jdk/internal/util/random/RandomSupportTest.java line 5:

> 3:  * @bug 8326227
> 4:  * @modules java.base/jdk.internal.util.random
> 5:  * @summary Verify that RandomSupport methods behave as specified

Nit - can you move this `@summary` line after the `@bug` line? It would then match the recommended tag order https://openjdk.org/jtreg/tag-spec.html#ORDER

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1636122002

From pminborg at openjdk.org  Wed Jun 12 09:38:21 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Jun 2024 09:38:21 GMT
Subject: Integrated: 8333886: Explicitly specify that asSlice and reinterpret
 return a memory segment backed by the same region of memory.
In-Reply-To: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
References: <JO640Ank532ZR4JbcYEos0VoIYMXQ-48RTLj4SWxiCA=.788fa709-ed0e-4cd1-8d0b-22211e4c061c@github.com>
Message-ID: <tDJ5t-a7xuPBgTXDW1bOaVppz8B1RRo3_0K4Cu6fzxw=.e3bbfcb9-deea-41a5-ab88-7c841f788623@github.com>

On Mon, 10 Jun 2024 15:45:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to explicitly state that returned segments form the `asSlice` and `reinterpret` method share memory regions with `this` memory segment.
> 
> Note: The term "subset"  means a true subset or the same set.

This pull request has now been integrated.

Changeset: c80e2eb3
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203
Stats:     21 lines in 1 file changed: 21 ins; 0 del; 0 mod

8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory.

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/19633

From jpai at openjdk.org  Wed Jun 12 09:38:22 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 09:38:22 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
Message-ID: <4ypNrlSXMpskXb_r2Swz29F-b-6fnmj816_VzZNf5SY=.73a76345-170f-47b8-bf2c-fe3a9718b745@github.com>

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

test/jdk/jdk/internal/util/random/RandomSupportTest.java line 32:

> 30:         for (double max = 1.0; max < 10.0; max++) {
> 31:             WorstCaseRandomGenerator rng = new WorstCaseRandomGenerator();
> 32:             assertTrue(RandomSupport.computeNextExponentialSoftCapped(rng, max) >= max);

Would you mind changing this to something like:

double val = RandomSupport.computeNextExponentialSoftCapped(rng, max);
assertTrue(val >= max, val + " isn't >= " + max);


That way if this test fails for any reason, then we get the necessary details on what the computed value is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1636139162

From sgehwolf at openjdk.org  Wed Jun 12 09:49:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Jun 2024 09:49:15 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v4]
In-Reply-To: <lMFT7CaN3OM9H4id1PrbMfXZgAEdKWmiDxFAYsWdJpA=.4d825564-347e-4b48-970a-e48d9af8f5a9@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <lMFT7CaN3OM9H4id1PrbMfXZgAEdKWmiDxFAYsWdJpA=.4d825564-347e-4b48-970a-e48d9af8f5a9@github.com>
Message-ID: <52rFNWs8r1zHN5eKvb6XfkT6rLtlFRNiKbmaDZbUyE0=.70728fb6-14cf-4d93-bb41-bae48d3d193f@github.com>

On Fri, 7 Jun 2024 12:59:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/40b2fbd8...02884c70

[tools/javac/annotations/typeAnnotations/api/ArrayCreationTree](https://github.com/jerboaa/jdk/actions/runs/9417350160#user-content-tools_javac_annotations_typeannotations_api_arraycreationtree) test failure in GHA on 32 bit Linux seems unrelated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2162580613

From jpai at openjdk.org  Wed Jun 12 10:10:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 10:10:13 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <xpWZgULhrLKWZbXr1R6J8nSH5VdOY4WFhpqBqmLUan4=.8ebf6158-d5ca-4936-921d-133e703163ba@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
 <iNJgT3Phdkio0yYKO8kq6RjiKGfgFyau98zLGr5Cnu0=.b460d62a-dea7-4825-8cef-81c903b32ee1@github.com>
 <xpWZgULhrLKWZbXr1R6J8nSH5VdOY4WFhpqBqmLUan4=.8ebf6158-d5ca-4936-921d-133e703163ba@github.com>
Message-ID: <m-pnIboOayQs3MDIfRjNPYh7IkLiCjyuglVeys3u22U=.020582b0-89ad-4db7-ab75-8eac418e67d3@github.com>

On Thu, 22 Feb 2024 05:40:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update: confirmed that the new test fails without the fix.
>
>> Update: confirmed that the new test fails without the fix.
> 
> Thanks for verifying the test checks the fix; I'll let others who have worked more directly on the random code review the actual fix.

> @jddarcy Added a regression test, and currently working on adjusting it (see https://github.com/Pr0methean/jdk/actions/runs/7984444127) to ensure we have a case that fails without the fix, passes with the fix, and is practical to run within the usual unit-test timeouts.

I gave this a try locally. It doesn't fail for me without the source code changes proposed in this PR. I see the following output from the test without the source code changes:


got 1.0 for max 1.0
got 2.0 for max 2.0
got 3.0 for max 3.0
got 4.0 for max 4.0
got 5.0 for max 5.0
got 6.0 for max 6.0
got 7.0 for max 7.0
got 11.353912041222094 for max 8.0
got 11.353912041222094 for max 9.0


With the proposed changes in this PR, the test continues to pass and I see this output:


got 7.569274694148063 for max 1.0
got 7.569274694148063 for max 2.0
got 7.569274694148063 for max 3.0
got 7.569274694148063 for max 4.0
got 7.569274694148063 for max 5.0
got 7.569274694148063 for max 6.0
got 7.569274694148063 for max 7.0
got 11.353912041222094 for max 8.0
got 11.353912041222094 for max 9.0

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2162623391

From stuefe at openjdk.org  Wed Jun 12 10:10:16 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 12 Jun 2024 10:10:16 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
 [v2]
In-Reply-To: <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
 <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>
Message-ID: <BF17c1zy2NXO-ynABFBFErA976Y5xLK6BmVDa01s7oI=.d9c14952-0be8-4bbf-a96c-589dd154f1c6@github.com>

On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
>> 
>> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
>> 
>> **Testing**
>> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace wrapper with casts.

Yes, unfortunate, but ok. Thank you for doing this.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19567#pullrequestreview-2112563225

From jwaters at openjdk.org  Wed Jun 12 10:31:16 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Jun 2024 10:31:16 GMT
Subject: RFR: 8332400: isspace argument should be a valid unsigned char
 [v2]
In-Reply-To: <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
 <2pNo3tm_nlTfafdvL9y44HA0ACrsCSJxf22AV2GfzVM=.cbdc4ee3-adcc-45e8-a201-a68693b281dc@github.com>
Message-ID: <wACS-tOpalHJk62snmD8HPqqKpq7E9vzzz_Jp64PsrE=.8fd65da8-baf0-4d30-9b63-7ead7630ecd3@github.com>

On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
>> 
>> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
>> 
>> **Testing**
>> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace wrapper with casts.

Had I seen this earlier I would have suggested more C++ styled casts to make which conversion exactly is happening clearer, but oh well. I agree that it's unfortunate that this has to be done

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19567#pullrequestreview-2112608501

From jpai at openjdk.org  Wed Jun 12 10:53:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Jun 2024 10:53:38 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
Message-ID: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>

Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?

The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:

https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html

To summarize those discussions, we had concluded that:
- `Deflater` and `Inflater` will implement the `AutoCloseable` interface
-  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
- `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
- Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
- However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.

New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.

I'll file a CSR shortly.

-------------

Commit messages:
 - fix whitespace
 - 8225763: Inflater and Deflater should implement AutoCloseable

Changes: https://git.openjdk.org/jdk/pull/19675/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8225763
  Stats: 724 lines in 6 files changed: 673 ins; 9 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/19675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675

PR: https://git.openjdk.org/jdk/pull/19675

From epeter at openjdk.org  Wed Jun 12 11:42:13 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 11:42:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <IZ82DfVqvATJKAgjYwrsnpq_NsZRqIMd3vWg9g4Xjhc=.514598f3-fa01-493d-aec0-48a1f8861bb3@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

I am now doing some work for you. Please read it very carefully, and try to retrace everything yourself. I expect you to do this kind of analysis yourself next time and present it to me (if you decide to continue working on this PR).

I run your test:
`./java -XX:+TraceMergeStores -Xbatch -XX:CompileCommand=printcompilation,*::* -XX:+PrintInlining AppendNullTest.java`

I see:

10329 1994    b  4       AppendNullTest$StringBuilder::appendNull (75 bytes)
[TraceMergeStores]: Replace
 404  StoreB  === 388 282 402 339  [[ 429 415 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; !jvms: AppendNullTest$StringUTF16::putChar @ bci:15 (line 115) AppendNullTest$StringUTF16::putCharsAt @ bci:3 (line 87) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25)
 429  StoreB  === 414 404 427 23  [[ 473 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; !jvms: AppendNullTest$StringUTF16::putChar @ bci:24 (line 116) AppendNullTest$StringUTF16::putCharsAt @ bci:3 (line 87) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25)
 473  StoreB  === 414 429 471 340  [[ 497 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; !jvms: AppendNullTest$StringUTF16::putChar @ bci:15 (line 115) AppendNullTest$StringUTF16::putCharsAt @ bci:11 (line 88) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25)
 497  StoreB  === 414 473 495 23  [[ 541 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; !jvms: AppendNullTest$StringUTF16::putChar @ bci:24 (line 116) AppendNullTest$StringUTF16::putCharsAt @ bci:11 (line 88) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25)
 541  StoreB  === 414 497 539 341  [[ 565 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; !jvms: AppendNullTest$StringUTF16::putChar @ bci:15 (line 115) AppendNullTest$StringUTF16::putCharsAt @ bci:20 (line 89) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25)
 565  StoreB  === 414 541 563 23  [[ 609 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; !jvms: AppendNullTest$StringUTF16::putChar @ bci:24 (line 116) AppendNullTest$StringUTF16::putCharsAt @ bci:20 (line 89) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25)
 609  StoreB  === 414 565 607 341  [[ 633 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; !jvms: AppendNullTest$StringUTF16::putChar @ bci:15 (line 115) AppendNullTest$StringUTF16::putCharsAt @ bci:29 (line 90) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25)
 633  StoreB  === 414 609 631 23  [[ 16 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; !jvms: AppendNullTest$StringUTF16::putChar @ bci:24 (line 116) AppendNullTest$StringUTF16::putCharsAt @ bci:29 (line 90) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25)
[TraceMergeStores]: with
 758  ConL  === 0  [[ 759 ]]  #long:30399761348886638
 759  StoreL  === 414 282 402 758  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=8;
                              @ 9   AppendNullTest$StringBuilder::ensureCapacityInternal (39 bytes)   inline (hot)
                                @ 24   AppendNullTest$StringBuilder::newCapacity (43 bytes)   failed to inline: too big
                                @ 32   java.util.Arrays::copyOf (33 bytes)   failed to inline: low call site frequency
                              @ 18   AppendNullTest$StringBuilder::isLatin1 (13 bytes)   inline (hot)
                              @ 63   AppendNullTest$StringUTF16::putCharsAt (33 bytes)   inline (hot)
                                @ 3   AppendNullTest$StringUTF16::putChar (26 bytes)   inline (hot)
                                @ 11   AppendNullTest$StringUTF16::putChar (26 bytes)   inline (hot)
                                @ 20   AppendNullTest$StringUTF16::putChar (26 bytes)   inline (hot)
                                @ 29   AppendNullTest$StringUTF16::putChar (26 bytes)   inline (hot)


So. We have a compilation of `AppendNullTest$StringBuilder::appendNull`. As you can see a number of things are inlined (recursively), and some are not inlined (with reasons why).
For example, `AppendNullTest$StringUTF16::putCharsAt` is inlined, and from that method, we inline `AppendNullTest$StringUTF16::putChar` 4 times.
So now this compilation unit has all of the combine code, and we start optimizing in C2.
We see that there is one successful `MergeStore` optimization, namely with the `StoreB` from `AppendNullTest$StringUTF16::putChar @ bci:15 (line 115)` and `AppendNullTest$StringUTF16::putChar @ bci:15 (line 115)`. Since the `putChar` was inlined 4 times, we have 4 pairs of them, in total 8 `StoreB`. These are combined together into a single `StoreL`. Success.

since you created a `StringBuilder sb = new StringBuilder(true);` where `isLatin1()` is always `false`, we actually will only compile the code in the `false` path, and add a `uncommon trap` on the `true` path. That is why we would not expect any optimizations to happen on the `true` path, we are not compiling it!

As a proof, I will run this:
`./java -XX:+TraceMergeStores -Xbatch -XX:CompileCommand=printcompilation,*::* -XX:+PrintInlining -XX:CompileCommand=printideal,*::appendNull AppendNullTest.java > log.log`

Now I can see this IR node in the `PrintIdeal` part of the log:
`322  CallStaticJava  === 318 281 309 8 9 (321 10 25 683 1 650 ) [[ 323 ]] # Static uncommon_trap(reason='unstable_if' action='reinterpret' debug_id='0')  void ( int ) C=0.000100 AppendNullTest$StringBuilder::isLatin1 @ bci:4 (line 77) reexecute AppendNullTest$StringBuilder::appendNull @ bci:18 (line 19) !jvms: AppendNullTest$StringBuilder::isLatin1 @ bci:4 (line 77) AppendNullTest$StringBuilder::appendNull @ bci:18 (line 19)`
It says `uncommon_trap(reason='unstable_if'...)`. Unstable if means we decide to only compile one side of the branch, if we ever encounter the other branch at runtime, we deoptimize, i.e. we drop out of the C2 code back to the interpreter.

Now let us look at the assembly code:
`./java -XX:+TraceMergeStores -Xbatch -XX:CompileCommand=printcompilation,*::* -XX:+PrintInlining -XX:CompileCommand=printideal,*::appendNull -XX:CompileCommand=print,*::appendNull AppendNullTest.java > log.log`

There are always two sections, one with the "OptoAssembly" and one with "Assembly". They correspond to each other, the former is more high level, the latter more low-level. I like to look at the "Assembly" one, because that is what we actually end up running on the hardware, in my case this is x86-64 assembly.
After looking a bit around, I found this section:

  0x00007f05ccc5d57a:   movslq %edx,%rdx                    ;*bastore {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - AppendNullTest$StringUTF16::putChar at 15 (line 115)
                                                            ; - AppendNullTest$StringUTF16::putCharsAt at 3 (line 87)
                                                            ; - AppendNullTest$StringBuilder::appendNull at 63 (line 25)
  0x00007f05ccc5d57d:   cmp    %r11d,%edi
  0x00007f05ccc5d580:   jae    0x00007f05ccc5d6fc
 ;; B7: #       out( N384 ) <- in( B6 )  Freq: 0.999995
  0x00007f05ccc5d586:   mov    %r10d,0xc(%rbx)              ;*putfield count {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - AppendNullTest$StringBuilder::appendNull at 70 (line 27)
  0x00007f05ccc5d58a:   movabs $0x6c006c0075006e,%r10
  0x00007f05ccc5d594:   mov    %r10,0x10(%r8,%rdx,1)        ;*synchronization entry
                                                            ; - AppendNullTest$StringBuilder::appendNull at -1 (line 16)

This is interesting, because `movabs $0x6c006c0075006e,%r10` loads the constant into the `r10` register, and this is the same constant that our `MergeStores` optimization generated, i.e. `0x6c006c0075006e == 30399761348886638`.
But there is more, I think (but not completely sure her) that the `cmp` is a bounds check on the `byte[]` array.

Side note: if we do "normal" accesses on byte arrays, we bounds check. If we use `Unsafe` there is usually no bounds check. The bounds check can sometimes incur some overhead of course, but generally they are very very predictable for the branch predictor (another low level detail of the CPU that you can read up on your own if you are interested).

Does this make sense so far, or do you have questions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162793445

From kevinw at openjdk.org  Wed Jun 12 11:52:22 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 11:52:22 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <9xkQA1A3p199VLywmpejXTJoRNmWEFYlAZs2xwU66YM=.5384477f-58db-44e5-af00-a9b4c33d190b@github.com>

On Tue, 11 Jun 2024 16:59:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management/share/classes/javax/management/monitor/Monitor.java line 1541:
> 
>> 1539:             if (ac == null) {
>> 1540:                 // No SecurityManager:
>> 1541:                 Subject.doAs(s, action);
> 
> What if `s` is null?

Subject.doAs accepts a null Subject, so that's OK?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636324060

From duke at openjdk.org  Wed Jun 12 11:54:15 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 12 Jun 2024 11:54:15 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <hUMj9-SHjn9oR21ije3f2YuAevrpNROsNWbjnzv4oAU=.632096ad-b8aa-4f8a-9033-e921d5f13615@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
 <hUMj9-SHjn9oR21ije3f2YuAevrpNROsNWbjnzv4oAU=.632096ad-b8aa-4f8a-9033-e921d5f13615@github.com>
Message-ID: <sV_Xi86HkHoavX4GInJG2SDCpiCg4DukkZa35II2Mok=.46c76a1b-85b5-41a3-ae3b-ecf23c482ea7@github.com>

On Tue, 4 Jun 2024 19:44:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> Also it would be helpful to compare the performance without biased locking in JDK11.

@naotoj The above contains the result of JDK11 with disabled and enabled biased locking. It seems the key is the biased locking. Now our application use DecimalFormat.format() seriously,  the performance is declining when migrate from JDK 11 to JDK 21.  Could you give some suggestion?Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2162813093

From epeter at openjdk.org  Wed Jun 12 12:02:13 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 12:02:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <eIqcAaIuxwSufQ_cIQb-WiHGNS7SLqfDHuvDr0_nQBQ=.b8c55231-5d89-44c6-aaf8-b1ca837c3159@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Going back to:

./java -XX:+TraceMergeStores -Xbatch -XX:CompileCommand=printcompilation,*::* -XX:+PrintInlining AppendNullTest.java > log.log


We have occurances of `TraceMergeStores` in these compilations:

9139 1992    b  4       AppendNullTest$StringBuilder::appendNull (75 bytes)
 -> as discussed above

9156 1996 %  b  4       AppendNullTest::main @ 11 (45 bytes)
 -> once main method is OSR compiled

  529  StoreB  === 513 408 527 464  [[ 554 540 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=9; !jvms: AppendNullTest$StringUTF16::putChar @ bci:15 (line 115) AppendNullTest$StringUTF16::putCharsAt @ bci:3 (line 87) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25) AppendNullTest::main @ bci:18 (line 123)
8 such StoreB get turned into StoreL. This also comes from the recursive inlining, ultimately from the same `putChar`.

 1154  StoreB  === 1139 3516 1152 464  [[ 1178 1164 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=9; !jvms: AppendNullTest$StringUTF16::putChar @ bci:15 (line 115) AppendNullTest$StringUTF16::putCharsAt @ bci:3 (line 87) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25) AppendNullTest::main @ bci:21 (line 123)
 Now the pattern repeats, because you have multiple `appendNull` calls in the `main` melthod.
 So a total of 5 such optimizations, since all the methods are inlined multiple times.

 
 That is all the optimizations that I see, where `MergeStores` happens. Now the question is if there are any compilations where we would expect the `MergeStores` to happen but they do not. That is more difficult.
 
I can for example see a previous compilation of the `main` method:

9151 1995    b  3       AppendNullTest::main (45 bytes)
                              @ 5   AppendNullTest$StringBuilder::<init> (26 bytes)   inline
                                @ 1   java.lang.Object::<init> (1 bytes)   inline
                              @ 18   AppendNullTest$StringBuilder::appendNull (75 bytes)   failed to inline: callee is too large
                              @ 21   AppendNullTest$StringBuilder::appendNull (75 bytes)   failed to inline: callee is too large
                              @ 24   AppendNullTest$StringBuilder::appendNull (75 bytes)   failed to inline: callee is too large
                              @ 27   AppendNullTest$StringBuilder::appendNull (75 bytes)   failed to inline: callee is too large
                              @ 30   AppendNullTest$StringBuilder::appendNull (75 bytes)   failed to inline: callee is too large
                              @ 35   AppendNullTest$StringBuilder::clear (3 bytes)   inline

I think it is obvious: if methods are not inlined, then we cannot optimize the code there. Instead, this is going to be method calls, where we call `appendNull` - with the overhead of a call of course. That could be another source of performance loss. Could be - it depends how often we execute this compiled code at runtime.
Of course `appendNull` is already comiled and optimized, so we would still expect to have `long` stores instead of `byte` stores.

So far goes the "theory". Now we need to test the theory with some performance measurements.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162828575

From duke at openjdk.org  Wed Jun 12 12:21:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 12:21:14 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <eIqcAaIuxwSufQ_cIQb-WiHGNS7SLqfDHuvDr0_nQBQ=.b8c55231-5d89-44c6-aaf8-b1ca837c3159@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <eIqcAaIuxwSufQ_cIQb-WiHGNS7SLqfDHuvDr0_nQBQ=.b8c55231-5d89-44c6-aaf8-b1ca837c3159@github.com>
Message-ID: <EZR84xoUqbLZDb__iFzpJ_B3vrh2L0YxjMzMHtyxo80=.793ddfdb-3837-470e-abd5-2b9f2fd4fede@github.com>

On Wed, 12 Jun 2024 11:59:47 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert
>
> Going back to:
> 
> ./java -XX:+TraceMergeStores -Xbatch -XX:CompileCommand=printcompilation,*::* -XX:+PrintInlining AppendNullTest.java > log.log
> 
> 
> We have occurances of `TraceMergeStores` in these compilations:
> 
> 9139 1992    b  4       AppendNullTest$StringBuilder::appendNull (75 bytes)
>  -> as discussed above
> 
> 9156 1996 %  b  4       AppendNullTest::main @ 11 (45 bytes)
>  -> once main method is OSR compiled
> 
>   529  StoreB  === 513 408 527 464  [[ 554 540 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=9; !jvms: AppendNullTest$StringUTF16::putChar @ bci:15 (line 115) AppendNullTest$StringUTF16::putCharsAt @ bci:3 (line 87) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25) AppendNullTest::main @ bci:18 (line 123)
> 8 such StoreB get turned into StoreL. This also comes from the recursive inlining, ultimately from the same `putChar`.
> 
>  1154  StoreB  === 1139 3516 1152 464  [[ 1178 1164 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=9; !jvms: AppendNullTest$StringUTF16::putChar @ bci:15 (line 115) AppendNullTest$StringUTF16::putCharsAt @ bci:3 (line 87) AppendNullTest$StringBuilder::appendNull @ bci:63 (line 25) AppendNullTest::main @ bci:21 (line 123)
>  Now the pattern repeats, because you have multiple `appendNull` calls in the `main` melthod.
>  So a total of 5 such optimizations, since all the methods are inlined multiple times.
> 
>  
>  That is all the optimizations that I see, where `MergeStores` happens. Now the question is if there are any compilations where we would expect the `MergeStores` to happen but they do not. That is more difficult.
>  
> I can for example see a previous compilation of the `main` method:
> 
> 9151 1995    b  3       AppendNullTest::main (45 bytes)
>                               @ 5   AppendNullTest$StringBuilder::<init> (26 bytes)   inline
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline
>                               @ 18   AppendNullTest$StringBuilder::appendNull (75 bytes)   failed to inline: callee is too large
>                               @ 21   AppendNullTest$StringBuilder::appendNull (75 bytes)   failed to inline: callee is too large
>                               @ 24   AppendNullTest$StringBuilder::appendNull (75 bytes)   failed to inline: callee is t...

Thank you very much @eme64 for your help and your patience.

I have another question. The StringUTF16.putChar method inside JDK is an intrinsic method, which seems to cause the putCharsAt method to be unable to merge to long stores.

Is it possible or necessary for C2 to continue to improve it?


class StringUTF16 {
    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
    }

    @IntrinsicCandidate
    // intrinsic performs no bounds checks
    static void putChar(byte[] val, int index, int c) {
        assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
        index <<= 1;
        val[index++] = (byte)(c >> HI_BYTE_SHIFT);
        val[index]   = (byte)(c >> LO_BYTE_SHIFT);
    }
}



[TraceMergeStores]: Replace
  78  StoreB  === 61 7 76 12  [[ 103 89 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:43 (line 71)
 103  StoreB  === 88 78 101 80  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:52 (line 72)
[TraceMergeStores]: with
  12  Parm  === 3  [[ 78 66 38 80 107 113 ]] Parm2: int !jvms: StringUTF16::putChar @ bci:-1 (line 69)
 113  StoreC  === 88 7 76 12  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162866205

From epeter at openjdk.org  Wed Jun 12 12:25:12 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 12:25:12 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <EZR84xoUqbLZDb__iFzpJ_B3vrh2L0YxjMzMHtyxo80=.793ddfdb-3837-470e-abd5-2b9f2fd4fede@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <eIqcAaIuxwSufQ_cIQb-WiHGNS7SLqfDHuvDr0_nQBQ=.b8c55231-5d89-44c6-aaf8-b1ca837c3159@github.com>
 <EZR84xoUqbLZDb__iFzpJ_B3vrh2L0YxjMzMHtyxo80=.793ddfdb-3837-470e-abd5-2b9f2fd4fede@github.com>
Message-ID: <F8KJirWSTnxsQJroleIVRlFciDf7vACJ5Kl5lB087z4=.17c862eb-89e8-405b-9275-144f28f1ec95@github.com>

On Wed, 12 Jun 2024 12:18:32 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> I have another question. The StringUTF16.putChar method inside JDK is an intrinsic method, which seems to cause the putCharsAt method to be unable to merge to long stores.

Can you show me an example, with the `-XX:CompileCommand=printcompilation,*::* -XX:+PrintInlining`?
And what happens when we intrinsify? What kind of intrinsification is it?

The example above is actually a compilation of `putChar`, and it is not inlined or intrinsified.
You can run with `-XX:CompileCommand=printcompilation,*::* -XX:+PrintInlining` to get those details.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162873819

From duke at openjdk.org  Wed Jun 12 12:29:15 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 12:29:15 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <k3bA50QmvwGAuagIUUMP5RGWNj4UzMDdBI9xXpnQJPA=.2fc30189-a9bb-4720-b44f-0f4c46ffcc6c@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

-XX:+TraceMergeStores -XX:CompileCommand=printcompilation,*::* -XX:+PrintInlining



@ 5   java.lang.AbstractStringBuilder::appendNull (75 bytes)   inline (hot)
  @ 9   java.lang.AbstractStringBuilder::ensureCapacityInternal (39 bytes)   inline (hot)
    @ 24   java.lang.AbstractStringBuilder::newCapacity (59 bytes)   failed to inline: too big
    @ 32   java.util.Arrays::copyOf (33 bytes)   inline (hot)
      @ 7   java.lang.Object::clone (0 bytes)   failed to inline: native method
      @ 7   java.lang.Object::clone (0 bytes)   (intrinsic)
      @ 25   java.lang.Math::min (11 bytes)   (intrinsic)
      @ 28   java.lang.System::arraycopy (0 bytes)   (intrinsic)
  @ 18   java.lang.AbstractStringBuilder::isLatin1 (19 bytes)   inline (hot)
  @ 63   java.lang.StringUTF16::putCharsAt (33 bytes)   inline (hot)
    @ 3   java.lang.StringUTF16::putChar (54 bytes)   (intrinsic)
    @ 11   java.lang.StringUTF16::putChar (54 bytes)   (intrinsic)
    @ 20   java.lang.StringUTF16::putChar (54 bytes)   (intrinsic)
    @ 29   java.lang.StringUTF16::putChar (54 bytes)   (intrinsic)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162882056

From redestad at openjdk.org  Wed Jun 12 12:35:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 12 Jun 2024 12:35:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <1Yb-zz1x9v9SIyKMKiF6k1hN1K0Mj4zYT3mzk6bfJlM=.0b36aa61-8a0d-40aa-b2a8-a521dd60005a@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

And what happens when you run that last thing with `-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_putCharStringU`?  I believe the intrinsic is basically a handcrafted merge optimization, and might very well be obsolete with the MergeStores optimization in place.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162893168

From duke at openjdk.org  Wed Jun 12 12:41:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 12:41:14 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <RKyg2ZAm3iKkQzSOzeaH1ojg3QpmoGaGRYtIxP3cQX4=.3c2de9be-97fa-452f-b90e-5d6a05fc6ca9@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

-XX:+TraceMergeStores -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_putCharStringU



[TraceMergeStores]: Replace
  644  StoreB  === 628 499 642 573  [[ 669 655 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:3 (line 1552) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  669  StoreB  === 654 644 667 35  [[ 720 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:3 (line 1552) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  720  StoreB  === 654 669 718 574  [[ 744 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:11 (line 1553) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  744  StoreB  === 654 720 742 35  [[ 796 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:11 (line 1553) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  796  StoreB  === 654 744 794 575  [[ 820 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:20 (line 1554) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  820  StoreB  === 654 796 818 35  [[ 872 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:20 (line 1554) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  872  StoreB  === 654 820 870 575  [[ 896 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:29 (line 1555) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
  896  StoreB  === 654 872 894 35  [[ 916 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:29 (line 1555) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
[TraceMergeStores]: with
 1826  ConL  === 0  [[ 1827 ]]  #long:30399761348886638
 1827  StoreL  === 654 499 642 1826  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  654  StoreB  === 638 509 652 583  [[ 679 665 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:3 (line 1552) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  679  StoreB  === 664 654 677 45  [[ 730 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:3 (line 1552) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  730  StoreB  === 664 679 728 584  [[ 754 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:11 (line 1553) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  754  StoreB  === 664 730 752 45  [[ 806 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:11 (line 1553) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  806  StoreB  === 664 754 804 585  [[ 830 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:20 (line 1554) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  830  StoreB  === 664 806 828 45  [[ 882 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:20 (line 1554) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  882  StoreB  === 664 830 880 585  [[ 906 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:29 (line 1555) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
  906  StoreB  === 664 882 904 45  [[ 926 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:29 (line 1555) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179)
[TraceMergeStores]: with
 1842  ConL  === 0  [[ 1843 ]]  #long:30399761348886638
 1843  StoreL  === 664 509 652 1842  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
 843  StoreB  === 828 699 841 11  [[ 868 854 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharSB @ bci:8 (line 1490) AbstractStringBuilder::append @ bci:72 (line 821)
 868  StoreB  === 853 843 866 845  [[ 882 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharSB @ bci:8 (line 1490) AbstractStringBuilder::append @ bci:72 (line 821)
[TraceMergeStores]: with
  11  Parm  === 3  [[ 832 845 787 679 614 92 578 168 178 228 549 278 292 843 890 977 ]] Parm1: int !jvms: AbstractStringBuilder::append @ bci:-1 (line 814)
 977  StoreC  === 853 699 841 11  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  78  StoreB  === 61 7 76 12  [[ 103 89 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:43 (line 71)
 103  StoreB  === 88 78 101 80  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: StringUTF16::putChar @ bci:52 (line 72)
[TraceMergeStores]: with
  12  Parm  === 3  [[ 78 66 38 80 107 113 ]] Parm2: int !jvms: StringUTF16::putChar @ bci:-1 (line 69)
 113  StoreC  === 88 7 76 12  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5;
[TraceMergeStores]: Replace
  617  StoreB  === 601 472 615 546  [[ 642 628 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:3 (line 1552) AbstractStringBuilder::appendNull @ bci:63 (line 647)
  642  StoreB  === 627 617 640 23  [[ 693 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:3 (line 1552) AbstractStringBuilder::appendNull @ bci:63 (line 647)
  693  StoreB  === 627 642 691 547  [[ 717 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:11 (line 1553) AbstractStringBuilder::appendNull @ bci:63 (line 647)
  717  StoreB  === 627 693 715 23  [[ 769 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:11 (line 1553) AbstractStringBuilder::appendNull @ bci:63 (line 647)
  769  StoreB  === 627 717 767 548  [[ 793 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:20 (line 1554) AbstractStringBuilder::appendNull @ bci:63 (line 647)
  793  StoreB  === 627 769 791 23  [[ 845 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:20 (line 1554) AbstractStringBuilder::appendNull @ bci:63 (line 647)
  845  StoreB  === 627 793 843 548  [[ 869 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:29 (line 1555) AbstractStringBuilder::appendNull @ bci:63 (line 647)
  869  StoreB  === 627 845 867 23  [[ 16 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:29 (line 1555) AbstractStringBuilder::appendNull @ bci:63 (line 647)
[TraceMergeStores]: with
 1006  ConL  === 0  [[ 1007 ]]  #long:30399761348886638
 1007  StoreL  === 627 472 615 1006  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
 1089  StoreB  === 1074 938 1087 1068  [[ 1116 1102 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharSB @ bci:8 (line 1490) AbstractStringBuilder::append @ bci:72 (line 821) StringBuilder::append @ bci:2 (line 246) SBTraceStoreTest::append @ bci:24 (line 14)
 1116  StoreB  === 1101 1089 1114 1092  [[ 1206 1159 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !orig=[1197] !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharSB @ bci:8 (line 1490) AbstractStringBuilder::append @ bci:72 (line 821) StringBuilder::append @ bci:2 (line 246) SBTraceStoreTest::append @ bci:24 (line 14)
[TraceMergeStores]: with
  298  ConI  === 0  [[ 1078 1028 918 570 556 507 458 448 375 1464 ]]  #int:20013
 1464  StoreC  === 1101 938 1087 298  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11;
SBTraceStoreTest-appendNullUTF16 millis : 22
SBTraceStoreTest-appendNullUTF16 millis : 7
[TraceMergeStores]: Replace
 1210  StoreB  === 1195 1059 1208 1189  [[ 1237 1223 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharSB @ bci:8 (line 1490) AbstractStringBuilder::append @ bci:72 (line 821) StringBuilder::append @ bci:2 (line 246) SBTraceStoreTest::append @ bci:24 (line 14) SBTraceStoreTest::appendTest @ bci:23 (line 31)
 1237  StoreB  === 1222 1210 1235 1213  [[ 1324 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !orig=[1315] !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharSB @ bci:8 (line 1490) AbstractStringBuilder::append @ bci:72 (line 821) StringBuilder::append @ bci:2 (line 246) SBTraceStoreTest::append @ bci:24 (line 14) SBTraceStoreTest::appendTest @ bci:23 (line 31)
[TraceMergeStores]: with
  423  ConI  === 0  [[ 1199 1149 1039 693 679 630 582 572 500 2597 ]]  #int:20013
 2597  StoreC  === 1222 1059 1208 423  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162905112

From alanb at openjdk.org  Wed Jun 12 12:42:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jun 2024 12:42:15 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <hUMj9-SHjn9oR21ije3f2YuAevrpNROsNWbjnzv4oAU=.632096ad-b8aa-4f8a-9033-e921d5f13615@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
 <hUMj9-SHjn9oR21ije3f2YuAevrpNROsNWbjnzv4oAU=.632096ad-b8aa-4f8a-9033-e921d5f13615@github.com>
Message-ID: <WGwBGBpt-pTEQWXZIM-dJDYozyi6dgJZqlniTRSv_a4=.99eb527e-efe0-4e95-a384-23fad5640cb3@github.com>

On Tue, 4 Jun 2024 19:44:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> Also it would be helpful to compare the performance without biased locking in JDK11.

@naotoj Has there been any discussion about adding overloads that take a StringBuilder?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2162907188

From redestad at openjdk.org  Wed Jun 12 12:55:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 12 Jun 2024 12:55:17 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <ulOkMa7G0OeDlEI_4uYBhkm2POhNNFbEBaNoEBNzqAw=.86a33b85-74a2-48e1-8ca9-cfd37504637d@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Good, disabling the intrinsic appears to enable the MergeStore optimization, and it looks like inlining happens here to get to 8-byte stores. What performance do you get now with that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162936067

From epeter at openjdk.org  Wed Jun 12 12:55:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 12:55:17 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <RKyg2ZAm3iKkQzSOzeaH1ojg3QpmoGaGRYtIxP3cQX4=.3c2de9be-97fa-452f-b90e-5d6a05fc6ca9@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <RKyg2ZAm3iKkQzSOzeaH1ojg3QpmoGaGRYtIxP3cQX4=.3c2de9be-97fa-452f-b90e-5d6a05fc6ca9@github.com>
Message-ID: <PVdz50kmypmehYlsKe6IF_6sNtB_fIVKEKZArNsjF1c=.5b82bbff-1f08-420e-b9c1-09cc8f9e513d@github.com>

On Wed, 12 Jun 2024 12:38:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert
>
> -XX:+TraceMergeStores -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_putCharStringU
> 
> 
> 
> [TraceMergeStores]: Replace
>   644  StoreB  === 628 499 642 573  [[ 669 655 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:3 (line 1552) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
>   669  StoreB  === 654 644 667 35  [[ 720 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:3 (line 1552) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
>   720  StoreB  === 654 669 718 574  [[ 744 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:11 (line 1553) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
>   744  StoreB  === 654 720 742 35  [[ 796 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ bci:11 (line 1553) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
>   796  StoreB  === 654 744 794 575  [[ 820 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:43 (line 71) StringUTF16::putCharsAt @ bci:20 (line 1554) AbstractStringBuilder::appendNull @ bci:63 (line 647) AbstractStringBuilder::append @ bci:5 (line 587)
>   820  StoreB  === 654 796 818 35  [[ 872 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10;  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar @ bci:52 (line 72) StringUTF16::putCharsAt @ ...

@wenshao @cl4es nice, so it is a problem that `putChar` is not inlined in these cases, but intfinsified. Now it would be interestig to see if we can get rid of the `putChar` intrinsic. That would have to happen in a separate RFE probably, and would require sufficient benchmarking.

But first: I would say @wenshao should run the benchmarks from above again with disabled intrinsic. We could expect to get a performance boost from that - but we want to prove it with the benchmark.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162937241

From kevinw at openjdk.org  Wed Jun 12 12:59:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 12:59:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
Message-ID: <PFV4VRqZZySQbDbgrvJx-FsZulLoQJ5RmDdK7Z7sHWo=.3d954a5b-7c37-4db7-97dd-c22e81bac1bb@github.com>

On Tue, 11 Jun 2024 20:58:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:
>> 
>>> 1434:             } else {
>>> 1435:                 // ACC is present, we have a Subject and SM is permitted:
>>> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);
>> 
>> Why is it necessary to call both `doAs` and `doPrivileged`?
>
> Can you just call `AccessController.doPrivileged(op, acc)` as in the original code? `Subject.doAs` requires a permission, which is why I assume you are wrapping it in a `doPrivileged` but you are asserting all of the permissions of the `java.management` module, which means you probably want to use limited doPriv and only assert the `getSubject` permission but that is getting complicated. I'd go back to the original call as it should work in the SM allow case.

Yes, this can be simpler, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636417433

From kevinw at openjdk.org  Wed Jun 12 12:59:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 12:59:16 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <3rT8VL9apE_LSNZucc9IuqST8Pcr7VQgxBGxbK-v5mU=.b9fc25a1-90a3-41bc-88e4-a7c12560d457@github.com>

On Tue, 11 Jun 2024 16:53:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1438:
> 
>> 1436:                 return AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> Subject.doAs(subject, op), acc);
>> 1437:             }
>> 1438:         } catch (PrivilegedActionException pe) {
> 
> What is this catch block for? The cause of a `PrivilegedActionException` should not be a unchecked exception.

Looks like the catch of PrivilegedActionException is no longer necessary, will be removed.
Was from from previously using a different doAs or call which needed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636417022

From redestad at openjdk.org  Wed Jun 12 13:08:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 12 Jun 2024 13:08:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <EdpIX6QengKlNaNEGprcb4Avq5dJssWShCn1TYbr1us=.ac5e5165-6d50-4192-b13f-620db30e1bc4@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Agreed we should look at obsoleting the `_putCharStringU` intrinsic. This is best done separately. If performance with the intrinsic disabled looks good here then I think this PR is good to go, even if temporarily subpar on the UTF16 tests. The microbenchmark will then serve as an extra verification step to show that disabling/removing the intrinsic is beneficial.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162962297

From duke at openjdk.org  Wed Jun 12 13:18:16 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 13:18:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <OXBohsDyRSWxjksOvhqmnTDfVPpACpHrbA0ceNBq3OI=.b0046784-e4e4-4875-aae6-649c7831f32b@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

`-XX:DisableIntrinsic=_putCharStringU` causes performance degradation. As written in the comments of StringUTF16.putChar, no bounds checks, this is similar to Unsafe.putChar


-XX:DisableIntrinsic=_putCharStringU
Benchmark                                  Mode  Cnt  Score   Error  Units
StringBuilders.toStringCharWithNull8Utf16  avgt   15  9.063 ? 0.130  ns/op


Benchmark                                  Mode  Cnt  Score   Error  Units
StringBuilders.toStringCharWithNull8Utf16  avgt   15  8.139 ? 0.018  ns/op



class StringUTF16 {
    @IntrinsicCandidate
    // intrinsic performs no bounds checks
    static void putChar(byte[] val, int index, int c) {
        assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
        index <<= 1;
        val[index++] = (byte)(c >> HI_BYTE_SHIFT);
        val[index]   = (byte)(c >> LO_BYTE_SHIFT);
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2162984481

From epeter at openjdk.org  Wed Jun 12 13:27:16 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 13:27:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <IuwZrjOzPjjCJaF86yDbxtquBG-FSK8RWUjcqtT1B0g=.41fbcaaf-4365-45f2-8935-77c2ca3b2cfa@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Fair enough. The code does say it "trusts the caller", which means the intrinsic does not do bounds check, and that may be quite the performance boost. @TobiHartmann also just pointed to this in a private conversation.

So it could be that we cannot just obsolete the `_putCharStringU`, because it gets used in all sorts of places that require it for performance.

But maybe we can avoid using it in your case. Or maybe we can change the intrinsic in such a way that it produces `StoreC` nodes which the `MergeStores` can actually combine with other `StoreC`.

What do you think @cl4es ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163005257

From asemenyuk at openjdk.org  Wed Jun 12 13:40:24 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 12 Jun 2024 13:40:24 GMT
Subject: Integrated: 8319457: Update jpackage to support WiX v4 and v5 on
 Windows
In-Reply-To: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
References: <w6AlsGx_jimxhrx9zw69GNbmAVh_0yEMTeV2cIHCsrE=.9e6e6d23-de8f-4d79-a662-d2bda14e7f57@github.com>
Message-ID: <1Fp8HJRpJ_0jYTqNyBkfYRQBQFYDjStZZ3PhbVkcRnA=.2c0af87f-77ff-44c7-8df1-21d2a77e7cff@github.com>

On Mon, 20 May 2024 21:14:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for WiX4 and WiX5 in jpackage.
> 
> jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).
> 
> Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:
> 
> - full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
> - partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;
> 
> The converter is a XSLT stylesheet. The default converter is `src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl`. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

This pull request has now been integrated.

Changeset: ba67ad63
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba67ad63ae7d7d399e41ab258576123fb6d9502c
Stats:     1485 lines in 22 files changed: 1198 ins; 94 del; 193 mod

8319457: Update jpackage to support WiX v4 and v5 on Windows

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/19318

From duke at openjdk.org  Wed Jun 12 13:41:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 13:41:18 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <3xHVqFiB0oOqTcFXnVItWpj_cmR3xPnERctp5D7dOiI=.c2b43675-9182-48dd-9e0e-d2c4449a7220@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

In the AbstractStringBuilder#appendNull method, is it possible to not check the bounds based on the information from ensureCapacityInternal?


class AbstractStringBuilder {
    private AbstractStringBuilder appendNull() {
        int count = this.count;
        ensureCapacityInternal(count + 4);
        byte[] val = this.value;
        if (isLatin1()) {
            val[count    ] = 'n';
            val[count + 1] = 'u';
            val[count + 2] = 'l';
            val[count + 3] = 'l';
        } else {
            StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
        }
        this.count = count + 4;
        return this;
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163035274

From redestad at openjdk.org  Wed Jun 12 13:54:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 12 Jun 2024 13:54:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <h-pW-DVgfX6OMwOeJ3w9WrzE7ddkrHbYp7utY7Rr3fk=.87ce581f-4dbb-46d3-a95a-20ae9b770861@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Rewriting the intrinsic to emit nodes that don't trip up the MergeStore pass seem like a reasonable thing to reach for, then. Perhaps some of these cases could be helped by a `@ForceInline` or two to get the inlining necessary to allow the JIT to eliminate all but the outer bounds checks, but that is probably too fragile in this area given how performance sensitive many of these methods are.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163065760

From kevinw at openjdk.org  Wed Jun 12 14:01:41 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 14:01:41 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
Message-ID: <BT09RXeaBTpejL4RPJGq4oiqeYmiP9JHCk8_JQQy0S4=.a2d629f4-eaee-4d9e-b53a-2f11cef6f697@github.com>

On Tue, 11 Jun 2024 16:55:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1633:
> 
>> 1631:                     }
>> 1632:                 } else {
>> 1633:                     // ACC is present, we have a Subject and SM is permitted:
> 
> While extract the `action` variable? The old code on lines 1590-1592 has no problem.

OK I can make this more like the original.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636515151

From kevinw at openjdk.org  Wed Jun 12 14:01:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 14:01:40 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v4]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  udpates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/56f9111e..422011e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=02-03

  Stats: 35 lines in 2 files changed: 6 ins; 23 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From redestad at openjdk.org  Wed Jun 12 14:05:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 12 Jun 2024 14:05:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <3xHVqFiB0oOqTcFXnVItWpj_cmR3xPnERctp5D7dOiI=.c2b43675-9182-48dd-9e0e-d2c4449a7220@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <3xHVqFiB0oOqTcFXnVItWpj_cmR3xPnERctp5D7dOiI=.c2b43675-9182-48dd-9e0e-d2c4449a7220@github.com>
Message-ID: <tmvGTSSzg0dYgvP1k3TfnnH5i83fWLo1aGRJbk6nKB8=.6eaf856d-84a2-43dd-a79b-2ed175a4e530@github.com>

On Wed, 12 Jun 2024 13:38:21 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In the AbstractStringBuilder#appendNull method, is it possible to not check the bounds based on the information from ensureCapacityInternal?

Perhaps you'd need something like a `Preconditions.checkIndex` in or before the 4-char `StringUTF16.putCharsAt` call to help eliminate excess bounds checks. Might work, but would be fragile and probably not easy to get right in all places.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163093085

From duke at openjdk.org  Wed Jun 12 14:08:25 2024
From: duke at openjdk.org (fitzsim)
Date: Wed, 12 Jun 2024 14:08:25 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
Message-ID: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>

8334048: -Xbootclasspath can not read some ZIP64 zip files

-------------

Commit messages:
 - 8334048: -Xbootclasspath can not read some ZIP64 zip files

Changes: https://git.openjdk.org/jdk/pull/19678/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19678&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334048
  Stats: 18 lines in 1 file changed: 11 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19678/head:pull/19678

PR: https://git.openjdk.org/jdk/pull/19678

From duke at openjdk.org  Wed Jun 12 14:08:43 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Jun 2024 14:08:43 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Fix clone(), accept review suggestions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19632/files
  - new: https://git.openjdk.org/jdk/pull/19632/files/873164ad..0a9f9624

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19632&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19632&range=00-01

  Stats: 34 lines in 1 file changed: 23 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19632/head:pull/19632

PR: https://git.openjdk.org/jdk/pull/19632

From kevinw at openjdk.org  Wed Jun 12 14:09:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 14:09:16 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
Message-ID: <tKMzL3ItOgRgLgi3gpfxeJhF1giLbogAKqEz0aizuxw=.36362158-215d-446e-8636-f22d88e63a7a@github.com>

On Tue, 11 Jun 2024 20:31:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 350:
>> 
>>> 348:     @SuppressWarnings("removal")
>>> 349:     private Subject getSubject() {
>>> 350:         Subject subject = null;
>> 
>> Just call `Subject.current()`. When SM is allowed, it is equivalent to `getSubject(AccessController.getContext())`.
>
> For the same reason you should be able to just call `Subject.current` in the tests. I don't think you need the `SimpleStandard.useGetSubjectACC` property to toggle the testing of either old or replacement APIs as long as the test has runs in both SM allow and disallow (i.e., no SM prop set) modes. Would you agree Weijun?

I thought there was a comment elsewhere suggesting using SM=allow to test with Subject.getSubject() and Subject.current(), and when SM not allowed, to only use Subject.current() ?
That was the reason for the property in the tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636536113

From redestad at openjdk.org  Wed Jun 12 14:16:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 12 Jun 2024 14:16:13 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v2]
In-Reply-To: <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
Message-ID: <x--RissonNj12NbJ5-VNf1snCj-QwD3sz5TNxvosOAM=.0a3eb495-2f21-421e-a12b-dc8b276f0cf3@github.com>

On Mon, 10 Jun 2024 04:08:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obtain classloader in security manager friendly code path

Agree with Roger that static imports should be used sparingly (possibly never with .*). 

If other reviewers are happy with the semantic shift in when/where class loading can/will happen and which class loader will be used then I won't object. I'm just not enough of an expert in this area to tell if there might be unintended side-effects we need to account for.

The added cost of spinning and calling these clinits means we might be better off reverting from a startup overhead perspective. JDK-8332457 was already a regression for some usage patterns.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19615#issuecomment-2163123616

From duke at openjdk.org  Wed Jun 12 14:19:16 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 14:19:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
Message-ID: <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>

On Tue, 11 Jun 2024 11:35:28 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

_putCharStringU will perform MergeStore but with bounds checking. Can the C2 optimizer perform MergeStore without bounds checking in this case?

StringUTF16.putChar does not have a bounds check, so there should be no bounds check after MergeStore?


class AbstractStringBuilder {
    private AbstractStringBuilder appendNull() {
        // ...
        StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
        // ...
    }
}

class StringUTF16 {
  	public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
    }

 	@IntrinsicCandidate
    // intrinsic performs no bounds checks
    static void putChar(byte[] val, int index, int c) {
        assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
        index <<= 1;
        val[index++] = (byte)(c >> HI_BYTE_SHIFT);
        val[index]   = (byte)(c >> LO_BYTE_SHIFT);
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163132228

From david.lloyd at redhat.com  Wed Jun 12 14:23:33 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 12 Jun 2024 09:23:33 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
 <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
Message-ID: <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>

On Tue, Jun 11, 2024 at 1:08?PM David Lloyd <david.lloyd at redhat.com> wrote:

>
>
> On Tue, Jun 11, 2024 at 12:57?PM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>>
>>
>> On 11/06/2024 18:19, David Lloyd wrote:
>>
>> :
>>
>> I thought that might be where Alan was headed with this. I would support
>> this solution; it would solve the problem for conformant serialization
>> libraries. If a class has a `readObject`/etc. then we use it - we wouldn't
>> care if it was "natural" or generated. This also gives us the option to
>> allow the user to use `opens` selectively to opt-in to special
>> optimizations, without a major penalty if they do not.
>>
>> Is there already someone assigned for this task
>>
>>
>> Not to my knowledge so you have cycles to prototype and have these
>> methods return a MH that work like a "default" readObject/writeObject then
>> it would help the discussion.
>>
>
> I think I can come up with *at least* a prototype in the next week or two.
> I have one concern though. The `readObject` method, when defined by users,
> must by specification do one of two things before it may read values from
> the stream:
>
> * Call `OIS.defaultReadObject()`
> * Call `OIS.readFields()`
>
> In the latter case, we don't have a problem, but if the user class calls
> `defaultReadObject` then we're back in the boat of having to reflectively
> set the fields of the class. We could possibly solve this by creating a
> *new* accessor which creates a parallel version of the method which
> *always* sets fields reflectively, even if a `readObject` already exists on
> the class. I'm not sure if there is a better solution. There is a similar
> problem on the write side, however this involves reading fields rather than
> writing them (obviously).
>

I have a *very* rough prototype up [1]. It adds two new accessor methods to
`ReflectionFactory`: `defaultReadObjectForSerialization` and
`defaultWriteObjectForSerialization`. It was easier than expected, due
largely to the classfile API, which is really nice.

These methods create an artificial `readObject`/`writeObject` method in a
hidden+nestmate class connected to the original class, which uses the
stream's `GetField`/`PutField` to access the stream data and normal field
operations to access the class fields. For usage, these methods can be used
when `read|writeObjectForSerialization` return `null`, *or* when
`defaultRead|WriteObject` is used.

There is additionally a constant bootstrap temporarily located on
`ReflectionFactory` to acquire a `MethodHandle` that can act as a setter
for final fields (there is no JVM-breaking magic here; it uses regular
public APIs to achieve this). However this constant bootstrap probably
needs to be put somewhere in `java.base` to actually be useful (my test
program needed `--add-reads` and `-add-opens` to make it work because
`ReflectionFactory` is located in `jdk.unsupported`). I was hesitant to put
it into `ConstantBootstraps` but maybe that's really the best place for it.

The outstanding problems are:
- Need to determine if this is a valid/approved approach
- Move the field-setter constant bootstrap method to `java.base` somewhere
(`j.l.i.ConstantBootstraps`?)
- Field setter constant bootstrap does not have adequate access checking;
couldn't figure out a good way to do it
- Field setter constant bootstrap also works for non-final fields, though
this is not used by the prototype
- Caching - yea or nay? For now it's left up to the caller (I think this is
consistent with existing methods but not sure)
- There are some `ClassDesc`, `MethodHandleDesc`, and `MethodTypeDesc` that
should be in constant fields
- Probably some normal code improvements & cleanups
- Documentation
- Real tests
- Probably a good idea to review the spec again to make sure no edge case
was missed

[1] https://github.com/dmlloyd/jdk/commit/serialization


-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240612/64f79fcc/attachment-0001.htm>

From dfuchs at openjdk.org  Wed Jun 12 14:26:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 14:26:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v4]
In-Reply-To: <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
Message-ID: <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>

On Wed, 12 Jun 2024 14:01:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   udpates

test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:

> 5:     permission javax.management.MBeanPermission "[domain:type=NB,name=2]", "addNotificationListener";
> 6:     permission javax.management.MBeanPermission "*", "removeNotificationListener";
> 7:     permission javax.security.auth.AuthPermission "doAs";

I suspect that this means a doPrivileged is missing somewhere. We should not require the application to posess new permissions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636573141

From epeter at openjdk.org  Wed Jun 12 14:26:16 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 14:26:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
Message-ID: <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>

On Wed, 12 Jun 2024 14:16:50 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert
>
> _putCharStringU will perform MergeStore but with bounds checking. Can the C2 optimizer perform MergeStore without bounds checking in this case?
> 
> StringUTF16.putChar does not have a bounds check, so there should be no bounds check after MergeStore?
> 
> 
> class AbstractStringBuilder {
>     private AbstractStringBuilder appendNull() {
>         // ...
>         StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
>         // ...
>     }
> }
> 
> class StringUTF16 {
>   	public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>         putChar(value, i    , c1);
>         putChar(value, i + 1, c2);
>         putChar(value, i + 2, c3);
>         putChar(value, i + 3, c4);
>     }
> 
>  	@IntrinsicCandidate
>     // intrinsic performs no bounds checks
>     static void putChar(byte[] val, int index, int c) {
>         assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
>         index <<= 1;
>         val[index++] = (byte)(c >> HI_BYTE_SHIFT);
>         val[index]   = (byte)(c >> LO_BYTE_SHIFT);
>     }
> }

@wenshao If you look at the tests in https://github.com/openjdk/jdk/pull/16245, you can see examples like this:
https://github.com/eme64/jdk/blob/93bf2ddc9b7f584724034aec6a4f8b9fe1b2dfda/test/hotspot/jtreg/compiler/c2/TestMergeStores.java#L501-L514
So yes, we can merge them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163150153

From alanb at openjdk.org  Wed Jun 12 14:27:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jun 2024 14:27:14 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
In-Reply-To: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
Message-ID: <KsrH-LhJu936M6WfWZmYIRdsaj7v1vzsNZWiWy09yjM=.bb0165ca-ec30-4f99-b0d6-5195f2741438@github.com>

On Wed, 12 Jun 2024 14:02:58 GMT, fitzsim <duke at openjdk.org> wrote:

> 8334048: -Xbootclasspath can not read some ZIP64 zip files

Are you planning to add tests? I don't think we should be changing this code with good tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2163152471

From alanb at openjdk.org  Wed Jun 12 14:34:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Jun 2024 14:34:15 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v4]
In-Reply-To: <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
 <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
Message-ID: <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>

On Wed, 12 Jun 2024 14:23:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   udpates
>
> test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:
> 
>> 5:     permission javax.management.MBeanPermission "[domain:type=NB,name=2]", "addNotificationListener";
>> 6:     permission javax.management.MBeanPermission "*", "removeNotificationListener";
>> 7:     permission javax.security.auth.AuthPermission "doAs";
> 
> I suspect that this means a doPrivileged is missing somewhere. We should not require the application to posess new permissions.

I think Daniel is right, can you remove this permission and paste in the debug output to see where this is happening?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636587055

From prasad.velagapudi at servicenow.com  Wed Jun 12 14:37:38 2024
From: prasad.velagapudi at servicenow.com (Prasad Velagapudi)
Date: Wed, 12 Jun 2024 14:37:38 +0000
Subject: Lambda Classes reachability from GC roots  in JDK11 and JDK17
In-Reply-To: <IA3PR08MB10201E03DC19654D6D44E300D95FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
References: <IA3PR08MB102017B9054EB292C95BC790195FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
 <IA3PR08MB10201E03DC19654D6D44E300D95FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
Message-ID: <IA3PR08MB102010A1725A1A5B69B186D4495C02@IA3PR08MB10201.namprd08.prod.outlook.com>

A gentle reminder on these questions? Could you please respond?

Regards,
Prasad.

From: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Date: Thursday, 6 June 2024 at 8:10?PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Lambda Classes reachability from GC roots in JDK11 and JDK17
Hello Lambda Experts,

I am looking for clarifications on the following questions.


  1.  I observed in my tests that lambda classes generated for inline lambda expressions (ex: LambdaUtil::print), are STRONGLY linked to defining class loader and never gets collected on GC. This behaviour is same in both JDK11 and JDK17. Can you please confirm is this accurate?
  2.  Also, I observed that the lambda classes generated for inline lambda expressions (ex: LambdaUtil::print) not adding additional overhead to Metaspace in JDK17 compared to that of JDK11 . Can you please confirm is this accurate?


Regards,
Prasad



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240612/361fc503/attachment.htm>

From kevinw at openjdk.org  Wed Jun 12 14:48:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 14:48:13 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v4]
In-Reply-To: <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
 <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
 <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>
Message-ID: <7L_k1ykC2z-E0uLtcdoycnvlmmBdmRc1vgr4LcbX_-E=.90918413-2ac0-4ef0-b995-3db004a028ca@github.com>

On Wed, 12 Jun 2024 14:31:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:
>> 
>>> 5:     permission javax.management.MBeanPermission "[domain:type=NB,name=2]", "addNotificationListener";
>>> 6:     permission javax.management.MBeanPermission "*", "removeNotificationListener";
>>> 7:     permission javax.security.auth.AuthPermission "doAs";
>> 
>> I suspect that this means a doPrivileged is missing somewhere. We should not require the application to posess new permissions.
>
> I think Daniel is right, can you remove this permission and paste in the debug output to see where this is happening?

Hmm I may have fixed that since changing the policy files, as I'm not seeing the problem without that AuthPermission any more.  Am just retesting everything before updating this...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636613493

From duke at openjdk.org  Wed Jun 12 14:55:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 14:55:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
Message-ID: <bOYt-VbEqltJ453GR2ONzGDaNzd2nIg6gec2vOcdCRY=.acd452bb-6cd2-4bf5-b359-daad2b87f63e@github.com>

On Wed, 12 Jun 2024 14:24:00 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> _putCharStringU will perform MergeStore but with bounds checking. Can the C2 optimizer perform MergeStore without bounds checking in this case?
>> 
>> StringUTF16.putChar does not have a bounds check, so there should be no bounds check after MergeStore?
>> 
>> 
>> class AbstractStringBuilder {
>>     private AbstractStringBuilder appendNull() {
>>         // ...
>>         StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
>>         // ...
>>     }
>> }
>> 
>> class StringUTF16 {
>>   	public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>>         putChar(value, i    , c1);
>>         putChar(value, i + 1, c2);
>>         putChar(value, i + 2, c3);
>>         putChar(value, i + 3, c4);
>>     }
>> 
>>  	@IntrinsicCandidate
>>     // intrinsic performs no bounds checks
>>     static void putChar(byte[] val, int index, int c) {
>>         assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
>>         index <<= 1;
>>         val[index++] = (byte)(c >> HI_BYTE_SHIFT);
>>         val[index]   = (byte)(c >> LO_BYTE_SHIFT);
>>     }
>> }
>
> @wenshao If you look at the tests in https://github.com/openjdk/jdk/pull/16245, you can see examples like this:
> https://github.com/eme64/jdk/blob/93bf2ddc9b7f584724034aec6a4f8b9fe1b2dfda/test/hotspot/jtreg/compiler/c2/TestMergeStores.java#L501-L514
> So yes, we can merge them.

@eme64 It seems like MergeStore didn't happen, is there something I did wrong?

class StringUTF16 {
    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        int address = Unsafe.ARRAY_BYTE_BASE_OFFSET + (i << 1);
        UNSAFE.putChar(value, address    , c1);
        UNSAFE.putChar(value, address + 2, c2);
        UNSAFE.putChar(value, address + 4, c3);
        UNSAFE.putChar(value, address + 6, c4);
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163242785

From dfuchs at openjdk.org  Wed Jun 12 14:58:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 14:58:11 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v4]
In-Reply-To: <7L_k1ykC2z-E0uLtcdoycnvlmmBdmRc1vgr4LcbX_-E=.90918413-2ac0-4ef0-b995-3db004a028ca@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
 <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
 <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>
 <7L_k1ykC2z-E0uLtcdoycnvlmmBdmRc1vgr4LcbX_-E=.90918413-2ac0-4ef0-b995-3db004a028ca@github.com>
Message-ID: <EA1pdX9zphjC043LsFOLmZL30ZCp2h_TvIZbSiXZ48w=.a615548a-7d3f-4588-a094-18403fe17d0e@github.com>

On Wed, 12 Jun 2024 14:44:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I think Daniel is right, can you remove this permission and paste in the debug output to see where this is happening?
>
> Hmm I may have fixed that since changing the policy files, as I'm not seeing the problem without that AuthPermission any more.  Am just retesting everything before updating this...

(Same with other policy files in which the permission was added of course)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636634416

From epeter at openjdk.org  Wed Jun 12 15:01:14 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 12 Jun 2024 15:01:14 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
Message-ID: <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>

On Wed, 12 Jun 2024 14:24:00 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> _putCharStringU will perform MergeStore but with bounds checking. Can the C2 optimizer perform MergeStore without bounds checking in this case?
>> 
>> StringUTF16.putChar does not have a bounds check, so there should be no bounds check after MergeStore?
>> 
>> 
>> class AbstractStringBuilder {
>>     private AbstractStringBuilder appendNull() {
>>         // ...
>>         StringUTF16.putCharsAt(val, count, 'n', 'u', 'l', 'l');
>>         // ...
>>     }
>> }
>> 
>> class StringUTF16 {
>>   	public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>>         putChar(value, i    , c1);
>>         putChar(value, i + 1, c2);
>>         putChar(value, i + 2, c3);
>>         putChar(value, i + 3, c4);
>>     }
>> 
>>  	@IntrinsicCandidate
>>     // intrinsic performs no bounds checks
>>     static void putChar(byte[] val, int index, int c) {
>>         assert index >= 0 && index < length(val) : "Trusted caller missed bounds check";
>>         index <<= 1;
>>         val[index++] = (byte)(c >> HI_BYTE_SHIFT);
>>         val[index]   = (byte)(c >> LO_BYTE_SHIFT);
>>     }
>> }
>
> @wenshao If you look at the tests in https://github.com/openjdk/jdk/pull/16245, you can see examples like this:
> https://github.com/eme64/jdk/blob/93bf2ddc9b7f584724034aec6a4f8b9fe1b2dfda/test/hotspot/jtreg/compiler/c2/TestMergeStores.java#L501-L514
> So yes, we can merge them.

> @eme64 It seems like MergeStore didn't happen, is there something I did wrong?

Yes ;)

@wenshao The issue is that the pattern matching is quite **limited**.
`putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4)`
This has 4 variables. This is not allowed for the optimization. You would have to pass in a `long` and split it via shifts.
A possible exception: if `putCharsAt` is inlined and outside it is a splitting of a `long` value with shift, then ... maybe ... this would be optimized with `MergeStores`.

There are only 2 **accepted** patterns:
- Multiple stores of constants -> constant is merged, which allows stores to be merged.
- Multiple stores which all store a "section" of a larger value:

You can see **examples** I listed at the beginning of the PR description in https://github.com/openjdk/jdk/pull/16245.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163261884

From duke at openjdk.org  Wed Jun 12 15:16:28 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 15:16:28 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v5]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <W8AddA-ubAXZwhB0gzEC7UNmnRv-vDvsLaAsza3HD3A=.d1538fff-a11c-487b-bc38-8d5d58f7ba7b@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimize to combining values into larger stores

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/27a3050a..dd97cff3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=03-04

  Stats: 18 lines in 1 file changed: 8 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From chen.l.liang at oracle.com  Wed Jun 12 15:23:06 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 12 Jun 2024 15:23:06 +0000
Subject: Lambda Classes reachability from GC roots  in JDK11 and JDK17
In-Reply-To: <SJ2PR10MB766938EC23727CFC9AECEF7CA2C02@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <IA3PR08MB102017B9054EB292C95BC790195FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
 <IA3PR08MB10201E03DC19654D6D44E300D95FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
 <IA3PR08MB102010A1725A1A5B69B186D4495C02@IA3PR08MB10201.namprd08.prod.outlook.com>
 <SJ2PR10MB766938EC23727CFC9AECEF7CA2C02@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <SJ2PR10MB7669962CEF287AA04C66F9E6A2C02@SJ2PR10MB7669.namprd10.prod.outlook.com>


________________________________
From: Chen Liang <chen.l.liang at oracle.com>
Sent: Wednesday, June 12, 2024 10:22 AM
To: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Subject: Re: Lambda Classes reachability from GC roots in JDK11 and JDK17

Hello Prasad,
I can confirm the first one is accurate for JDK 15 and later (see JEP 371: Hidden Classes). Lambda classes from LambdaMetafactory are strongly linked to the defining class (the lookupClass of the input Lookup) and its class loader, and is intended to stay this way. Unfortunately I am not sure about the VM, hope someone can pick up the metaspace part of your question. But I've heard that since lambda classes are bounded to the lookup class loader, they use less memory as they don't need to be tracked separately for garbage collection,

-Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Sent: Wednesday, June 12, 2024 9:37 AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Lambda Classes reachability from GC roots in JDK11 and JDK17


A gentle reminder on these questions? Could you please respond?



Regards,

Prasad.



From: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Date: Thursday, 6 June 2024 at 8:10?PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Lambda Classes reachability from GC roots in JDK11 and JDK17

Hello Lambda Experts,



I am looking for clarifications on the following questions.



  1.  I observed in my tests that lambda classes generated for inline lambda expressions (ex: LambdaUtil::print), are STRONGLY linked to defining class loader and never gets collected on GC. This behaviour is same in both JDK11 and JDK17. Can you please confirm is this accurate?
  2.  Also, I observed that the lambda classes generated for inline lambda expressions (ex: LambdaUtil::print) not adding additional overhead to Metaspace in JDK17 compared to that of JDK11 . Can you please confirm is this accurate?





Regards,

Prasad






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240612/aca8c13c/attachment-0001.htm>

From chen.l.liang at oracle.com  Wed Jun 12 15:44:20 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 12 Jun 2024 15:44:20 +0000
Subject: [External] : Re: Lambda Classes reachability from GC roots  in
 JDK11 and JDK17
In-Reply-To: <IA3PR08MB102018DACC1E040B910B148C295C02@IA3PR08MB10201.namprd08.prod.outlook.com>
References: <IA3PR08MB102017B9054EB292C95BC790195FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
 <IA3PR08MB10201E03DC19654D6D44E300D95FA2@IA3PR08MB10201.namprd08.prod.outlook.com>
 <IA3PR08MB102010A1725A1A5B69B186D4495C02@IA3PR08MB10201.namprd08.prod.outlook.com>
 <SJ2PR10MB766938EC23727CFC9AECEF7CA2C02@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <IA3PR08MB102018DACC1E040B910B148C295C02@IA3PR08MB10201.namprd08.prod.outlook.com>
Message-ID: <SJ2PR10MB7669925637E7898F55D4BD06A2C02@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Prasad,
1. The lambdas generated from Class::method, () -> {}, and instance::method are all from LambdaMetafactory (if you look at the BootstrapMethods attribute from javap -c -v output), so they always have the same behavior.
2. For JDK 11, according to https://github.com/openjdk/jdk/pull/12493 they were not strongly tied, but I personally don't know about the details back then.

Chen
________________________________
From: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Sent: Wednesday, June 12, 2024 10:35 AM
To: Chen Liang <chen.l.liang at oracle.com>
Subject: [External] : Re: Lambda Classes reachability from GC roots in JDK11 and JDK17


Thanks Chen for the reply..



Just to clarify, my first question was on the lambda classes loaded from Lambda expressions(Lexical Lambdas), not the classes created from LambdaMetafactory.



Suppose in this example the line StringFunction ask = LambdaExpressionsUtil::printLambdaTest; generates a Lambda class. So, I am curious to know, does this lambda class is STRONGLY tied to defining class loader in JDK11?





Example1 ::



interface StringFunction {

         String print(String str);

}



public class LambdaExpressionsUtil {



public static String printLambdaTest(String str) {

              System.out.println(str);

              return str;



  }



public static void main(String[] args) throws IllegalAccessException, LambdaConversionException, Throwable {

       StringFunction ask = LambdaExpressionsUtil::printLambdaTest;

       ask.print("Lambda Expression ask");

}

}







Regards,

Prasad





From: Chen Liang <chen.l.liang at oracle.com>
Date: Wednesday, 12 June 2024 at 8:52?PM
To: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Subject: Re: Lambda Classes reachability from GC roots in JDK11 and JDK17

[External Email]



________________________________

Hello Prasad,

I can confirm the first one is accurate for JDK 15 and later (see JEP 371: Hidden Classes). Lambda classes from LambdaMetafactory are strongly linked to the defining class (the lookupClass of the input Lookup) and its class loader, and is intended to stay this way. Unfortunately I am not sure about the VM, hope someone can pick up the metaspace part of your question. But I've heard that since lambda classes are bounded to the lookup class loader, they use less memory as they don't need to be tracked separately for garbage collection,



-Chen

________________________________

From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Sent: Wednesday, June 12, 2024 9:37 AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Lambda Classes reachability from GC roots in JDK11 and JDK17



A gentle reminder on these questions? Could you please respond?



Regards,

Prasad.



From: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Date: Thursday, 6 June 2024 at 8:10?PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Lambda Classes reachability from GC roots in JDK11 and JDK17

Hello Lambda Experts,



I am looking for clarifications on the following questions.



  1.  I observed in my tests that lambda classes generated for inline lambda expressions (ex: LambdaUtil::print), are STRONGLY linked to defining class loader and never gets collected on GC. This behaviour is same in both JDK11 and JDK17. Can you please confirm is this accurate?
  2.  Also, I observed that the lambda classes generated for inline lambda expressions (ex: LambdaUtil::print) not adding additional overhead to Metaspace in JDK17 compared to that of JDK11 . Can you please confirm is this accurate?





Regards,

Prasad






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240612/092e7d40/attachment-0001.htm>

From duke at openjdk.org  Wed Jun 12 16:01:16 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 16:01:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
Message-ID: <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>

On Wed, 12 Jun 2024 14:58:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @wenshao If you look at the tests in https://github.com/openjdk/jdk/pull/16245, you can see examples like this:
>> https://github.com/eme64/jdk/blob/93bf2ddc9b7f584724034aec6a4f8b9fe1b2dfda/test/hotspot/jtreg/compiler/c2/TestMergeStores.java#L501-L514
>> So yes, we can merge them.
>
>> @eme64 It seems like MergeStore didn't happen, is there something I did wrong?
> 
> Yes ;)
> 
> @wenshao The issue is that the pattern matching is quite **limited**.
> `putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4)`
> This has 4 variables. This is not allowed for the optimization. You would have to pass in a `long` and split it via shifts.
> A possible exception: if `putCharsAt` is inlined and outside it is a splitting of a `long` value with shift, then ... maybe ... this would be optimized with `MergeStores`.
> 
> There are only 2 **accepted** patterns:
> - Multiple stores of constants -> constant is merged, which allows stores to be merged.
> - Multiple stores which all store a "section" of a larger value:
> 
> You can see **examples** I listed at the beginning of the PR description in https://github.com/openjdk/jdk/pull/16245.

Thanks to @eme64 's patience and help, I found a way to use MergeStore without doing boundary checking.

It would be even better if Unsafe.putChar could be used for MergeStore in the future.

## 1. JavaCode

class StringUTF16 {
    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
        putChar1(value, i    , c1);
        putChar1(value, i + 1, c2);
        putChar1(value, i + 2, c3);
        putChar1(value, i + 3, c4);
    }

    public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4, char c5) {
        // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
        putChar1(value, i    , c1);
        putChar1(value, i + 1, c2);
        putChar1(value, i + 2, c3);
        putChar1(value, i + 3, c4);
        putChar1(value, i + 4, c5);
    }

    static void putChar1(byte[] value, int i, char c) {
        int address = Unsafe.ARRAY_BYTE_BASE_OFFSET + (i << 1);
        Unsafe.getUnsafe().putByte(value, address    , (byte)(c >> HI_BYTE_SHIFT));
        Unsafe.getUnsafe().putByte(value, address + 1, (byte)(c >> LO_BYTE_SHIFT));
    }
}


## 2. Benchmark Numbers
The performance numbers under MacBookPro M1 Max are as follows:

-Benchmark                                   Mode  Cnt  Score   Error  Units
-StringBuilders.toStringCharWithNull8Latin1  avgt   15  7.073 ? 0.010  ns/op
-StringBuilders.toStringCharWithNull8Utf16   avgt   15  9.298 ? 0.015  ns/op
-StringBuilders.toStringCharWithBool8Latin1  avgt   15  7.387 ? 0.021  ns/op
-StringBuilders.toStringCharWithBool8Utf16   avgt   15  9.615 ? 0.011  ns/op

+Benchmark                                   Mode  Cnt  Score   Error  Units
+StringBuilders.toStringCharWithNull8Latin1  avgt   15  5.628 ? 0.017  ns/op +25.67%
+StringBuilders.toStringCharWithNull8Utf16   avgt   15  6.873 ? 0.026  ns/op +35.28%
+StringBuilders.toStringCharWithBool8Latin1  avgt   15  6.480 ? 0.077  ns/op +13.99%
+StringBuilders.toStringCharWithBool8Utf16   avgt   15  7.456 ? 0.059  ns/op +28.95%


## 3.  TraceMergeStores

[TraceMergeStores]: Replace
 65  StoreB  === 54 7 64 12  [[ 87 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567)
 87  StoreB  === 54 65 86 81  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568)
[TraceMergeStores]: with
 12  Parm  === 3  [[ 81 65 59 44 90 ]] Parm2: int !jvms: StringUTF16::putChar1 @ bci:-1 (line 1566)
 90  StoreC  === 54 7 64 12  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4;
[TraceMergeStores]: Replace
  639  StoreB  === 628 494 638 576  [[ 663 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1551) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239)
  663  StoreB  === 628 639 662 34  [[ 705 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1551) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239)
  705  StoreB  === 628 663 704 577  [[ 729 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1552) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239)
  729  StoreB  === 628 705 728 34  [[ 771 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1552) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239)
  771  StoreB  === 628 729 770 578  [[ 795 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1553) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239)
  795  StoreB  === 628 771 794 34  [[ 838 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1553) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239)
  838  StoreB  === 628 795 837 579  [[ 861 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1554) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239)
  861  StoreB  === 628 838 860 34  [[ 1212 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1554) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239)
[TraceMergeStores]: with
 1275  ConL  === 0  [[ 1276 ]]  #long:28429475166421108
 1276  StoreL  === 628 494 638 1275  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  629  StoreB  === 618 484 628 566  [[ 653 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1551) AbstractStringBuilder::append @ bci:128 (line 788)
  653  StoreB  === 618 629 652 24  [[ 695 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1551) AbstractStringBuilder::append @ bci:128 (line 788)
  695  StoreB  === 618 653 694 567  [[ 719 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1552) AbstractStringBuilder::append @ bci:128 (line 788)
  719  StoreB  === 618 695 718 24  [[ 761 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1552) AbstractStringBuilder::append @ bci:128 (line 788)
  761  StoreB  === 618 719 760 568  [[ 785 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1553) AbstractStringBuilder::append @ bci:128 (line 788)
  785  StoreB  === 618 761 784 24  [[ 828 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1553) AbstractStringBuilder::append @ bci:128 (line 788)
  828  StoreB  === 618 785 827 569  [[ 851 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1554) AbstractStringBuilder::append @ bci:128 (line 788)
  851  StoreB  === 618 828 850 24  [[ 1202 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1554) AbstractStringBuilder::append @ bci:128 (line 788)
[TraceMergeStores]: with
 1259  ConL  === 0  [[ 1260 ]]  #long:28429475166421108
 1260  StoreL  === 618 484 628 1259  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  990  StoreB  === 917 949 989 870  [[ 1013 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1559) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
 1013  StoreB  === 917 990 1012 34  [[ 1054 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1559) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
 1054  StoreB  === 917 1013 1053 871  [[ 1077 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1560) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
 1077  StoreB  === 917 1054 1076 34  [[ 1118 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1560) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
 1118  StoreB  === 917 1077 1117 872  [[ 1141 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1561) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
 1141  StoreB  === 917 1118 1140 34  [[ 1181 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1561) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
 1181  StoreB  === 917 1141 1180 579  [[ 1205 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:38 (line 1562) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
 1205  StoreB  === 917 1181 1204 34  [[ 1212 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:38 (line 1562) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
[TraceMergeStores]: with
 1280  ConL  === 0  [[ 1281 ]]  #long:28429466576093281
 1281  StoreL  === 917 949 989 1280  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  980  StoreB  === 907 939 979 860  [[ 1003 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1559) AbstractStringBuilder::append @ bci:147 (line 790)
 1003  StoreB  === 907 980 1002 24  [[ 1044 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1559) AbstractStringBuilder::append @ bci:147 (line 790)
 1044  StoreB  === 907 1003 1043 861  [[ 1067 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1560) AbstractStringBuilder::append @ bci:147 (line 790)
 1067  StoreB  === 907 1044 1066 24  [[ 1108 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1560) AbstractStringBuilder::append @ bci:147 (line 790)
 1108  StoreB  === 907 1067 1107 862  [[ 1131 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1561) AbstractStringBuilder::append @ bci:147 (line 790)
 1131  StoreB  === 907 1108 1130 24  [[ 1171 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1561) AbstractStringBuilder::append @ bci:147 (line 790)
 1171  StoreB  === 907 1131 1170 569  [[ 1195 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:38 (line 1562) AbstractStringBuilder::append @ bci:147 (line 790)
 1195  StoreB  === 907 1171 1194 24  [[ 1202 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:38 (line 1562) AbstractStringBuilder::append @ bci:147 (line 790)
[TraceMergeStores]: with
 1264  ConL  === 0  [[ 1265 ]]  #long:28429466576093281
 1265  StoreL  === 907 939 979 1264  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  927  StoreB  === 917 494 926 869  [[ 949 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1558) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
  949  StoreB  === 917 927 948 34  [[ 1281 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1558) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239)
[TraceMergeStores]: with
  869  ConI  === 0  [[ 927 921 921 1284 ]]  #int:102
 1284  StoreC  === 917 494 926 869  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  917  StoreB  === 907 484 916 859  [[ 939 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1558) AbstractStringBuilder::append @ bci:147 (line 790)
  939  StoreB  === 907 917 938 24  [[ 1265 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=10; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1558) AbstractStringBuilder::append @ bci:147 (line 790)
[TraceMergeStores]: with
  859  ConI  === 0  [[ 917 911 911 1268 ]]  #int:102
 1268  StoreC  === 907 484 916 859  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=10;
[TraceMergeStores]: Replace
  78  StoreB  === 67 7 77 12  [[ 100 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1558)
 100  StoreB  === 67 78 99 94  [[ 138 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1558)
[TraceMergeStores]: with
  12  Parm  === 3  [[ 94 78 72 57 343 ]] Parm2: int !jvms: StringUTF16::putCharsAt @ bci:-1 (line 1558)
 343  StoreC  === 67 7 77 12  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4;
[TraceMergeStores]: Replace
 138  StoreB  === 67 343 137 13  [[ 160 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1559)
 160  StoreB  === 67 138 159 154  [[ 198 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1559)
[TraceMergeStores]: with
  13  Parm  === 3  [[ 154 138 72 344 ]] Parm3: int !jvms: StringUTF16::putCharsAt @ bci:-1 (line 1558)
 344  StoreC  === 67 343 137 13  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4;
[TraceMergeStores]: Replace
 198  StoreB  === 67 344 197 14  [[ 220 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1560)
 220  StoreB  === 67 198 219 214  [[ 259 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1560)
[TraceMergeStores]: with
  14  Parm  === 3  [[ 214 198 72 345 ]] Parm4: int !jvms: StringUTF16::putCharsAt @ bci:-1 (line 1558)
 345  StoreC  === 67 344 197 14  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4;
[TraceMergeStores]: Replace
 259  StoreB  === 67 345 258 15  [[ 281 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1561)
 281  StoreB  === 67 259 280 275  [[ 317 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1561)
[TraceMergeStores]: with
  15  Parm  === 3  [[ 275 259 72 346 ]] Parm5: int !jvms: StringUTF16::putCharsAt @ bci:-1 (line 1558)
 346  StoreC  === 67 345 258 15  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4;
[TraceMergeStores]: Replace
 317  StoreB  === 67 346 316 16  [[ 339 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:38 (line 1562)
 339  StoreB  === 67 317 338 333  [[ 22 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:38 (line 1562)
[TraceMergeStores]: with
  16  Parm  === 3  [[ 333 317 72 347 ]] Parm6: int !jvms: StringUTF16::putCharsAt @ bci:-1 (line 1558)
 347  StoreC  === 67 346 316 16  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4;
[TraceMergeStores]: Replace
 1023  StoreB  === 473 328 1072 196  [[ 955 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1551) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18)
  955  StoreB  === 473 1023 1024 128  [[ 871 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1551) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18)
  871  StoreB  === 473 955 956 193  [[ 785 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1552) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18)
  785  StoreB  === 473 871 872 128  [[ 695 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1552) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18)
  695  StoreB  === 473 785 786 194  [[ 594 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1553) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18)
  594  StoreB  === 473 695 696 128  [[ 474 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1553) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18)
  474  StoreB  === 473 594 595 195  [[ 336 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1554) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18)
  336  StoreB  === 473 474 475 128  [[ 1143 486 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1554) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18)
[TraceMergeStores]: with
 1372  ConL  === 0  [[ 1373 ]]  #long:28429475166421108
 1373  StoreL  === 473 328 1072 1372  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11;
[TraceMergeStores]: Replace
  924  StoreB  === 63 997 998 216  [[ 838 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1559) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
  838  StoreB  === 63 924 925 128  [[ 743 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1559) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
  743  StoreB  === 63 838 839 217  [[ 644 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1560) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
  644  StoreB  === 63 743 744 128  [[ 520 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1560) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
  520  StoreB  === 63 644 645 218  [[ 374 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1561) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
  374  StoreB  === 63 520 521 128  [[ 239 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1561) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
  239  StoreB  === 63 374 375 195  [[ 102 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:38 (line 1562) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
  102  StoreB  === 63 239 240 128  [[ 56 310 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:38 (line 1562) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
[TraceMergeStores]: with
 1383  ConL  === 0  [[ 1384 ]]  #long:28429466576093281
 1384  StoreL  === 63 997 998 1383  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11;
[TraceMergeStores]: Replace
 1046  StoreB  === 63 1143 1082 219  [[ 997 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1558) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
  997  StoreB  === 63 1046 1047 128  [[ 1384 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1558) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18)
[TraceMergeStores]: with
  219  ConI  === 0  [[ 1046 92 92 1387 ]]  #int:102
 1387  StoreC  === 63 1143 1082 219  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11;
[TraceMergeStores]: Replace
 1101  StoreB  === 544 390 1156 241  [[ 1028 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1551) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
 1028  StoreB  === 544 1101 1102 172  [[ 945 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1551) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  945  StoreB  === 544 1028 1029 238  [[ 858 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1552) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  858  StoreB  === 544 945 946 172  [[ 769 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1552) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  769  StoreB  === 544 858 859 239  [[ 664 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1553) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  664  StoreB  === 544 769 770 172  [[ 545 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1553) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  545  StoreB  === 544 664 665 240  [[ 398 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1554) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  398  StoreB  === 544 545 546 172  [[ 1230 557 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1554) AbstractStringBuilder::append @ bci:128 (line 788) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:76 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
[TraceMergeStores]: with
 1466  ConL  === 0  [[ 1467 ]]  #long:28429475166421108
 1467  StoreL  === 544 390 1156 1466  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11;
[TraceMergeStores]: Replace
  994  StoreB  === 78 1068 1069 263  [[ 912 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:11 (line 1559) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  912  StoreB  === 78 994 995 172  [[ 826 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:11 (line 1559) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  826  StoreB  === 78 912 913 264  [[ 729 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:20 (line 1560) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  729  StoreB  === 78 826 827 172  [[ 605 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:20 (line 1560) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  605  StoreB  === 78 729 730 265  [[ 457 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:29 (line 1561) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  457  StoreB  === 78 605 606 172  [[ 302 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:29 (line 1561) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  302  StoreB  === 78 457 458 240  [[ 132 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:38 (line 1562) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
  132  StoreB  === 78 302 303 172  [[ 475 70 370 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:38 (line 1562) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
[TraceMergeStores]: with
 1477  ConL  === 0  [[ 1478 ]]  #long:28429466576093281
 1478  StoreL  === 78 1068 1069 1477  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11;
[TraceMergeStores]: Replace
 1124  StoreB  === 78 1230 1165 266  [[ 1068 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:20 (line 1567) StringUTF16::putCharsAt @ bci:3 (line 1558) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
 1068  StoreB  === 78 1124 1125 172  [[ 1478 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=11; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; !jvms: StringUTF16::putChar1 @ bci:37 (line 1568) StringUTF16::putCharsAt @ bci:3 (line 1558) AbstractStringBuilder::append @ bci:147 (line 790) StringBuilder::append @ bci:2 (line 239) SBTraceStoreTest::append @ bci:80 (line 18) SBTraceStoreTest::appendTest @ bci:28 (line 32)
[TraceMergeStores]: with
  266  ConI  === 0  [[ 1124 114 114 1481 ]]  #int:102
 1481  StoreC  === 78 1230 1165 266  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=11;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2163403522

From duke at openjdk.org  Wed Jun 12 16:06:13 2024
From: duke at openjdk.org (fitzsim)
Date: Wed, 12 Jun 2024 16:06:13 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
In-Reply-To: <KsrH-LhJu936M6WfWZmYIRdsaj7v1vzsNZWiWy09yjM=.bb0165ca-ec30-4f99-b0d6-5195f2741438@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <KsrH-LhJu936M6WfWZmYIRdsaj7v1vzsNZWiWy09yjM=.bb0165ca-ec30-4f99-b0d6-5195f2741438@github.com>
Message-ID: <ouyYW63l44KpFc3fJM04pk9iTPA_NvDe1hWd3IvIoos=.a8252a7a-2773-4812-b670-198da630bd82@github.com>

On Wed, 12 Jun 2024 14:24:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are you planning to add tests? I don't think we should be changing this code with good tests.

Yes, I will write a test that replicates the failure.  So far I verified the bad-signature condition with GDB, but I agree there should be a test case too.  It may take me a while, so I will leave this pull request open in the meantime and then update it with the test case once it is written.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2163413857

From kevinw at openjdk.org  Wed Jun 12 16:07:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 16:07:29 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v5]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <zv6E7fQk-eDePVNpFwzU-HQ9KMz1ZOpbEFVi7dbfx-U=.99c2f9ac-22a3-49bc-b880-e7b8e2e927dd@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

   Undo test policy updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/422011e4..9664bef6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=03-04

  Stats: 5 lines in 3 files changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Wed Jun 12 16:11:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 16:11:28 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v6]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

   Undo test policy updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/9664bef6..6f072338

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Wed Jun 12 16:14:12 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Jun 2024 16:14:12 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v4]
In-Reply-To: <EA1pdX9zphjC043LsFOLmZL30ZCp2h_TvIZbSiXZ48w=.a615548a-7d3f-4588-a094-18403fe17d0e@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <GlPw6D7-tpwgAn-1dVarvbBp0Rg4SZB3emjhKv2JxEg=.566380b5-0b52-4ca7-bc33-0ac41600083b@github.com>
 <Cxkc7YwMWMaCNhXewZKFo-yGExt_vLTFIh-P6Qv01aY=.0889cbb0-22ba-4e10-9d99-bd8090007180@github.com>
 <af8MlY3bDlAOMVyit3E6fI-3nw5Vom8FuIBEJhj2bpA=.672f2f75-3c9f-4b09-8c5a-86c79429af6f@github.com>
 <7L_k1ykC2z-E0uLtcdoycnvlmmBdmRc1vgr4LcbX_-E=.90918413-2ac0-4ef0-b995-3db004a028ca@github.com>
 <EA1pdX9zphjC043LsFOLmZL30ZCp2h_TvIZbSiXZ48w=.a615548a-7d3f-4588-a094-18403fe17d0e@github.com>
Message-ID: <1eHH4vDatJuI7ltL0BrDz0bxGZt-6dZIbVrhvXnkPoM=.c5bcde86-60dc-40af-8c74-0bf0e36a3e84@github.com>

On Wed, 12 Jun 2024 14:55:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hmm I may have fixed that since changing the policy files, as I'm not seeing the problem without that AuthPermission any more.  Am just retesting everything before updating this...
>
> (Same with other policy files in which the permission was added of course)

Yes these no longer seem needed.  I added them in response to failures in an earlier version of the change, thanks for spotting this, I've undone the policy changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636753776

From dfuchs at openjdk.org  Wed Jun 12 16:56:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Jun 2024 16:56:15 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v6]
In-Reply-To: <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
Message-ID: <nXxazFJyr4lQazQITKV2BQI0A8mG2AJrpGtZQPF2_QQ=.5a5ec88c-6063-46d1-b067-cba2d45199b9@github.com>

On Wed, 12 Jun 2024 16:11:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Undo test policy updates

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1445:

> 1443:             } else {
> 1444:                 throw new PrivilegedActionException(e);
> 1445:             }

I assume there no chance that `Exception e` may already be a `PrivilegedActionException` here. You coud avoid casts by using instanceof patterns.

Suggestion:

            if (e instanceof RuntimeException rte) {
                throw  rte;
            } else {
                throw new PrivilegedActionException(e);
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1636791497

From sgehwolf at openjdk.org  Wed Jun 12 16:57:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Jun 2024 16:57:30 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
In-Reply-To: <Jd1IjGY4f5x21FEtT-G0v8Bz8E5Ufg4HoZvLK5C1q04=.bb931989-1eff-4e8c-8798-6d25bf36c211@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
 <Jd1IjGY4f5x21FEtT-G0v8Bz8E5Ufg4HoZvLK5C1q04=.bb931989-1eff-4e8c-8798-6d25bf36c211@github.com>
Message-ID: <2HKfxaPysSsNwikk5Kgqx3_mNarIC_DRycPLyP_Hlwk=.7253908b-6e5a-4d5c-a968-5af0d9db94ae@github.com>

On Thu, 6 Jun 2024 15:35:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> My aim will be to bring this into JDK 24 with a JEP then. Hopefully we can bring this to a successful conclusion that way.

@AlanBateman JEP draft is here:
https://openjdk.org/jeps/8333799

Could you please help review it? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2163504796

From jlu at openjdk.org  Wed Jun 12 17:06:25 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Jun 2024 17:06:25 GMT
Subject: RFR: 8333755: NumberFormat integer only parsing breaks when format
 has suffix [v2]
In-Reply-To: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
References: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
Message-ID: <lBSeDivDuuJMBghbWQlqmAY2_LaC3ghYYV8cLYgb-VI=.44f64375-5b04-4ec2-ac7e-0f45f0b9c591@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8333920) which corrects a bug where NumberFormat cannot successfully parse values in integer only mode, when the format expects a suffix.
> 
> For example,
> 
> // a format that expects a currency suffix
> var fmt = NumberFormat.getCurrencyInstance(Locale.FRANCE);
> fmt.setParseIntegerOnly(true);
> failFmt.parse("5,00 ?"); // throws ParseException when you would have expected 5 returned
> 
> 
> When parsing in integer only mode, instead of breaking upon a decimal symbol encounter, we should store the index but continue to fully parse so that we can verify the entire string and increment our position to search for and match the suffix. Upon a successful suffix match, we can then set `ParsePosition.index` back to the stored decimal index.
> 
> It should be noted that CompactNumberFormat did previously have code that would traverse the rest of the String, to allow matching of the suffix. The difference is that NumberFormat returns the index upon decimal symbol encounter, while CompactNumberFormat was implemented to return the index reflected by the entire string traversal. Such differences cannot be standardized due to behavioral compatibility concerns.
> 
> Thus while parsing in integer only, CNF sets index to the `Position.fullPos()`, while DF sets index to the `Position.intPos()`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  specification improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19664/files
  - new: https://git.openjdk.org/jdk/pull/19664/files/c692b4fc..8579a0f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19664&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19664&range=00-01

  Stats: 9 lines in 2 files changed: 4 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19664/head:pull/19664

PR: https://git.openjdk.org/jdk/pull/19664

From duke at openjdk.org  Wed Jun 12 17:34:30 2024
From: duke at openjdk.org (Rob Spoor)
Date: Wed, 12 Jun 2024 17:34:30 GMT
Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v14]
In-Reply-To: <bv5Ot2gQJyRlQ331BKSo7iTcaJ8M3PJQZMLn578pCqc=.4134f534-dce9-4a2a-b25d-8a4b9db95303@github.com>
References: <L9k4q8JueZijOZdDDqSNsJ4HOAPWsANxzW08PSFRxaw=.4e1ef057-523b-4413-80e7-6728f6197eb2@github.com>
 <bv5Ot2gQJyRlQ331BKSo7iTcaJ8M3PJQZMLn578pCqc=.4134f534-dce9-4a2a-b25d-8a4b9db95303@github.com>
Message-ID: <WWg5uUCKJKTQjgDIFuYleew_-8kyeyVBftQajiAoDUQ=.f6e28123-03c7-4ebb-a9ec-4e3c8dcc8ab3@github.com>

On Thu, 30 Nov 2023 14:34:32 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461)
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - Lowering upper boundary of gatherer composition testing to 512
>  - Javadoc clarifications for Gatherer type parameters,
>    correcting descriptions of Integrator type parameters,
>    and more consistently use "initializer function" instead
>    of "supplier function".
>  - Addressing trailing whitespace complaint
>  - Adding @implSpec for Gatherer.andThen, plus adds tests to verify the default impls for Gatherer-related interfaces
>  - Clarifying that Stream#gather is a stateful intermediate operation
>  - Improvements after feedback
>  - Unpacking the rethrown exceptions from Gatherers.mapConcurrent()
>  - Addressing last review feedback
>  - Apply suggestions from code review
>    
>    Integrates Paul Sandoz's feedback/changes
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - Minor improvements to Gatherer Javadoc
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/69413690...49c94c7f

src/java.base/share/classes/java/util/stream/Gatherer.java line 296:

> 294:      * @implSpec This method always returns the same instance.
> 295:      *
> 296:      * @see Gatherer#finisher()

Today I noticed that this is the wrong link. It should be `Gatherer#combiner()`, not `Gatherer#finisher()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1636853721

From naoto at openjdk.org  Wed Jun 12 17:52:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Jun 2024 17:52:13 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v4]
In-Reply-To: <WGwBGBpt-pTEQWXZIM-dJDYozyi6dgJZqlniTRSv_a4=.99eb527e-efe0-4e95-a384-23fad5640cb3@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <z4BAfy6JEU2n-f-fK8wYfCBha_Dz2KkFnHXr6_xspLA=.536d12e3-de8e-465d-98e6-721120317a4d@github.com>
 <hUMj9-SHjn9oR21ije3f2YuAevrpNROsNWbjnzv4oAU=.632096ad-b8aa-4f8a-9033-e921d5f13615@github.com>
 <WGwBGBpt-pTEQWXZIM-dJDYozyi6dgJZqlniTRSv_a4=.99eb527e-efe0-4e95-a384-23fad5640cb3@github.com>
Message-ID: <sijvQ29XVjDxIOzTo1Fjv3mu0Z2OrK1P5PHAIAIO8QQ=.30d4dd2f-da3a-4ce0-a681-8e26c012647b@github.com>

On Wed, 12 Jun 2024 12:40:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also it would be helpful to compare the performance without biased locking in JDK11.
>
> @naotoj Has there been any discussion about adding overloads that take a StringBuilder?

@AlanBateman yes, we've discussed this over time, but it wasn't a priority. I still have one issue open (https://bugs.openjdk.org/browse/JDK-8313205).

@lingjun-cg Sorry for the late reply. Since it involves a lot of classes, I would want to make sure it does not include any incompatibilities.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2163601075

From prappo at openjdk.org  Wed Jun 12 19:06:23 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 12 Jun 2024 19:06:23 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v3]
In-Reply-To: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
Message-ID: <kRFnma_gV1zp08P29IAto-KRPiqmDxBYYPIOeuRuHEM=.8529a01f-c08d-497e-b6d2-d1f18eb36f2e@github.com>

> Please review this fix for an intermittent test failure.
> 
> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
> 
> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
> 
> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Disable timeout in expect scripts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19627/files
  - new: https://git.openjdk.org/jdk/pull/19627/files/21f63a98..56d24203

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19627&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19627&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19627/head:pull/19627

PR: https://git.openjdk.org/jdk/pull/19627

From prappo at openjdk.org  Wed Jun 12 19:06:24 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 12 Jun 2024 19:06:24 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v2]
In-Reply-To: <MtieFYqWEbxpceQyHbTHdRaBvK4v4GTBtiNgkqO4UGU=.e6dc977d-8538-4e66-98f2-7a0485b35a4e@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
 <MtieFYqWEbxpceQyHbTHdRaBvK4v4GTBtiNgkqO4UGU=.e6dc977d-8538-4e66-98f2-7a0485b35a4e@github.com>
Message-ID: <CFkKN8JyfxpcKXeFOHJdVSw4ZDt3wJddPet9qv9yKCw=.c8054a72-fa6e-4053-83c9-2d7f6a23e061@github.com>

On Tue, 11 Jun 2024 09:01:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this fix for an intermittent test failure.
>> 
>> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
>> 
>> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
>> 
>> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change url as suggested in review

Preliminary testing on some affected configurations showed that even 20 seconds might not be enough. Initially, I suggested that it would be hard to imagine, yet here we are.

A good solution would be to disable `expect` timeout and, thus, fall back onto jtreg timeout. The default jtreg timeout is 120 seconds, and `IO.java` does not override it. Jtreg timeout can be adjusted by the `-timeout` command-line option.

I believe, this would be the most flexible solution for this timeout issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19627#issuecomment-2163715007

From prr at openjdk.org  Wed Jun 12 19:46:20 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Jun 2024 19:46:20 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
Message-ID: <vUUnGbZkSBcAhexcNbtiUu-9SzGrvcln2ejWHPLszkg=.2dcd07e7-cb81-4843-84bc-bbd2b84f4a72@github.com>

On Tue, 11 Jun 2024 19:28:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert updated translation

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2114049394

From duke at openjdk.org  Wed Jun 12 20:01:17 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Jun 2024 20:01:17 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <BvlydzBw83D3-PSWvNXu_9Ds0LyC8AzzW9xzSi-uSwU=.f14416dc-d81b-42a0-823b-4d185fac382e@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Xe2FiwiFgFz0Rrev-DVf3Q91jW-HVgtw-tERc-zGP8k=.51cff37f-0eb5-4d10-b4ea-377c6a0c493a@github.com>
 <DjYiqtnZzpJXlpEWp-9VXJpUUssB4uRmNVdITdad2eY=.e1db307f-a20a-4ca3-913a-410af70f7dcf@github.com>
 <NkdASu0tVw-1cMXHZBcIyJpMJB5-8UymyIr_1EVn5oQ=.6d2b827f-d092-4a18-b261-1ba462c1b989@github.com>
 <A0faVB9Xyr35KMP4sE6hycP0sDSIHMKtpLChplpiyy8=.b6a9e652-ec06-4333-9ca4-cf6da788c739@github.com>
 <-YcdoBVuk-Is-Tl2mjQI-xeAVjCeAKEdJPbPp85pRz0=.420cf6d7-7a2d-4c3b-9c89-1f107432b6c2@github.com>
 <QakCNbZ66ev3PjuDj_1xDWhm6K6eo6oVArBeGWVNha0=.2ceec0c1-1a2f-46c4-929a-1a420353cbcb@github.com>
 <BvlydzBw83D3-PSWvNXu_9Ds0LyC8AzzW9xzSi-uSwU=.f14416dc-d81b-42a0-823b-4d185fac382e@github.com>
Message-ID: <v1htLuA8OZ7qUFfjMLO7mYeVe8C5xQnjVgN5SDrLIaY=.731b1f56-77c3-4bca-8dcb-f91ae0b24985@github.com>

On Tue, 11 Jun 2024 18:21:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> okay
>
> Could you try using MethodHandles instead of b2lLittle? Similar to what's used in ChaCha20:
> https://github.com/openjdk/jdk/blob/b77bd5fd6a6f7ddbed90300fba790da4fb683275/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java#L132-L134
> 
> with MethodHandles you could drop longBuf, removing unnecessary allocation on the only platform where the intrinsic is implemented (MacOSX-aarch64)

b2lLittle() and l2bLittle() are using those MethodHandle stuff, but yes, it adds some more performance if I use them directly in this class, so I changed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1637007344

From duke at openjdk.org  Wed Jun 12 20:07:13 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Jun 2024 20:07:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
Message-ID: <IybE-l30-JTlE3lDXX3yKF3DcuSwEr_zhkeyAKe-wRM=.449faa51-2bfb-4b2a-88aa-c3fe88b41e83@github.com>

On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clone(), accept review suggestions.

tier1,2,3 mach5 tests all passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2163807516

From jlu at openjdk.org  Wed Jun 12 20:15:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Jun 2024 20:15:18 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
Message-ID: <xUXJHd1OOUlkCtLwTS_wmgx0FlcrHSE7cbwrmIsCVD4=.b96c0b4a-0028-4d33-8b44-f07b1f1ff039@github.com>

On Tue, 11 Jun 2024 19:28:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert updated translation

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2114131181

From naoto at openjdk.org  Wed Jun 12 20:32:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Jun 2024 20:32:13 GMT
Subject: RFR: 8333755: NumberFormat integer only parsing breaks when format
 has suffix [v2]
In-Reply-To: <lBSeDivDuuJMBghbWQlqmAY2_LaC3ghYYV8cLYgb-VI=.44f64375-5b04-4ec2-ac7e-0f45f0b9c591@github.com>
References: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
 <lBSeDivDuuJMBghbWQlqmAY2_LaC3ghYYV8cLYgb-VI=.44f64375-5b04-4ec2-ac7e-0f45f0b9c591@github.com>
Message-ID: <w-e24KVBE2qdfI6RrnMq4luMTtqnCrOIdcL8V974Gb0=.4eff9fb3-72f0-4a7b-8466-ec3d1ddf9bc2@github.com>

On Wed, 12 Jun 2024 17:06:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8333920) which corrects a bug where NumberFormat cannot successfully parse values in integer only mode, when the format expects a suffix.
>> 
>> For example,
>> 
>> // a format that expects a currency suffix
>> var fmt = NumberFormat.getCurrencyInstance(Locale.FRANCE);
>> fmt.setParseIntegerOnly(true);
>> failFmt.parse("5,00 ?"); // throws ParseException when you would have expected 5 returned
>> 
>> 
>> When parsing in integer only mode, instead of breaking upon a decimal symbol encounter, we should store the index but continue to fully parse so that we can verify the entire string and increment our position to search for and match the suffix. Upon a successful suffix match, we can then set `ParsePosition.index` back to the stored decimal index.
>> 
>> It should be noted that CompactNumberFormat did previously have code that would traverse the rest of the String, to allow matching of the suffix. The difference is that NumberFormat returns the index upon decimal symbol encounter, while CompactNumberFormat was implemented to return the index reflected by the entire string traversal. Such differences cannot be standardized due to behavioral compatibility concerns.
>> 
>> Thus while parsing in integer only, CNF sets index to the `Position.fullPos()`, while DF sets index to the `Position.intPos()`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   specification improvements

Looks good overall. Some minor nits follow.

src/java.base/share/classes/java/text/DecimalFormat.java line 2446:

> 2444:     // To track the full parse index as well as the integer portion
> 2445:     record Position(int intPos, int fullPos) {}
> 2446: 

The record name may be more descriptive. Also I would expect more description here, such as what it is and those params are.

src/java.base/share/classes/java/text/DecimalFormat.java line 2461:

> 2459:      * @return returns the position of the first unparseable character or
> 2460:      *         -1 in case of no valid number parsed
> 2461:      */

Needs modification accommodating `Position`.

test/jdk/java/text/Format/NumberFormat/StrictParseTest.java line 320:

> 318:     }
> 319: 
> 320:     // Overloaded method used for integer only parsing, where the expected

Is this method for `integer only` only?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19664#pullrequestreview-2114129703
PR Review Comment: https://git.openjdk.org/jdk/pull/19664#discussion_r1637021751
PR Review Comment: https://git.openjdk.org/jdk/pull/19664#discussion_r1637024103
PR Review Comment: https://git.openjdk.org/jdk/pull/19664#discussion_r1637040736

From rriggs at openjdk.org  Wed Jun 12 20:37:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Jun 2024 20:37:12 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v2]
In-Reply-To: <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
Message-ID: <eQ0iRCNkW-vgEDFwcHc8lrR7-Tw4tRap_1iz7TtnU_c=.c924cdc4-c256-4389-8a5e-4a322c1d2fa3@github.com>

On Mon, 10 Jun 2024 04:08:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obtain classloader in security manager friendly code path

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19615#pullrequestreview-2114166690

From kvn at openjdk.org  Wed Jun 12 20:44:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Jun 2024 20:44:12 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
Message-ID: <2A2bX3DvWER_CMpvud6qM5u7Y0Dd7uWzPg4rE74snsg=.b12cd3c5-e61d-45a7-a3bf-a2a48c92d257@github.com>

On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clone(), accept review suggestions.

I approve changes in c2.  You need second approval from core libs expert.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19632#pullrequestreview-2114179732

From kvn at openjdk.org  Wed Jun 12 20:44:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Jun 2024 20:44:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <IybE-l30-JTlE3lDXX3yKF3DcuSwEr_zhkeyAKe-wRM=.449faa51-2bfb-4b2a-88aa-c3fe88b41e83@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
 <IybE-l30-JTlE3lDXX3yKF3DcuSwEr_zhkeyAKe-wRM=.449faa51-2bfb-4b2a-88aa-c3fe88b41e83@github.com>
Message-ID: <vyDHER9T9gVTUfPZKMWvEGK622SjXkcB2RY7fBHpgUA=.6d4ec7d3-9567-4001-bfac-2fffa22207f6@github.com>

On Wed, 12 Jun 2024 20:04:40 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> tier1,2,3 mach5 tests all passed.

Thank you for testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2163863932

From liach at openjdk.org  Wed Jun 12 20:45:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Jun 2024 20:45:30 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
Message-ID: <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>

On Thu, 6 Jun 2024 10:16:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - reverted static initialization of ConstantPoolBuilder and CP entries
>  - fixed naming conventions

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 616:

> 614:             final ClassDesc classDesc = ClassDesc.of(className0);
> 615:             final ClassDesc superClassDesc = classDesc(speciesData.deriveSuperClass());
> 616:             return ClassFile.of().build(classDesc, clb -> {

We need a confirmation here that these BMH species are only initialized after LMF is ready. @cl4es Is a dependency on LMF from BMH safe?

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 771:

> 769:                     final int        TMODS = TRANSFORM_MODS.get(whichtm);
> 770:                     clb.withMethod(TNAME, methodDesc(TTYPE), (TMODS & ACC_PPP) | ACC_FINAL, mb -> {
> 771:                         mb.withFlags((TMODS & ACC_PPP) | ACC_FINAL)

Isn't this redundant as we've specified it in initial withMethod call already?

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 784:

> 782:                             // mix them up and load them for the transform helper:
> 783:                             List<Var> helperArgs = speciesData.deriveTransformHelperArguments(transformMethods.get(whichtm), whichtm, targs, tfields);
> 784:                             List<Class<?>> helperTypes = new ArrayList<>(helperArgs.size());

Can we convert helperTypes here to List<ClassDesc> so we construct invokeBasicType as MethodTypeDesc below?

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 564:

> 562:             clb.withFlags(ACC_PRIVATE | ACC_FINAL | ACC_SUPER)
> 563:                .withSuperclass(InvokerBytecodeGenerator.INVOKER_SUPER_DESC)
> 564:                .with(SourceFileAttribute.of(className.substring(className.lastIndexOf('/') + 1)));

Maybe we can keep the classDesc from ofInternalName and use its displayName.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 87:

> 85: 
> 86:     private static final String[] EMPTY_STRING_ARRAY = new String[0];
> 87:     private static final ClassDesc[] EMPTY_CLASSDESC_ARRAY = new ClassDesc[0];

Suggestion:

    private static final ClassDesc[] EMPTY_CLASSDESC_ARRAY = ConstantUtils.EMPTY_CLASSDESC;

Need an import.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 96:

> 94:         }
> 95:     };
> 96:     record MethodBody(Consumer<CodeBuilder> code) implements Consumer<MethodBuilder> {

Why do we have these 2 instead of a noop record field builder consumer (flags is already set in withField, and MethodBody should just be direct usage of withMethodBody)

Seems the problem is in CF implemetnation side. Then these should be part of CF implementation details.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 214:

> 212:             for (int i = 0; i < parameterCount; i++) {
> 213:                 argNames[i] = "arg$" + (i + 1);
> 214:                 argDescs[i] = classDesc(factoryType.parameterType(i));

We should declare global ad-hoc classDesc and methodDesc methods in ConstantUtils, that way if we speed up our conversions all users benefit and the generators don't need to define these conversions everywhere.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 470:

> 468:         MethodVisitor mv = cw.visitMethod(ACC_PRIVATE + ACC_FINAL,
> 469:                                           NAME_METHOD_WRITE_OBJECT, DESCR_METHOD_WRITE_OBJECT,
> 470:                                           null, SER_HOSTILE_EXCEPTIONS);

The exceptions attribute is now lost on the migrated methods. Is that ok? It's private and only accessed by reflection so I think there's no real impact.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 566:

> 564: 
> 565:     static ClassDesc implClassDesc(Class<?> cls) {
> 566:         return cls.isHidden() ? ReferenceClassDescImpl.ofValidatedBinaryName(cls.getName())

I recommend just returning null or a dummy value if the cls is hidden; in this case, implMethodClassDesc can safely be null, as implementation must go through condy.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 74:

> 72:     private static final ClassDesc CD_LambdaForm_Name = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/LambdaForm$Name;");
> 73:     private static final ClassDesc CD_Object_array  = ReferenceClassDescImpl.ofValidated("[Ljava/lang/Object;");
> 74:     private static final ClassDesc CD_LoopClauses_array = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/MethodHandleImpl$LoopClauses;");

Suggestion:

    private static final ClassDesc CD_LoopClauses = ReferenceClassDescImpl.ofValidated("Ljava/lang/invoke/MethodHandleImpl$LoopClauses;");

The use site anticipates this to be a class or interface instead of an array type.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 94:

> 92:     };
> 93: 
> 94:     record MethodBody(Consumer<CodeBuilder> code) implements Consumer<MethodBuilder> {

Same withMethodBody remark

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 281:

> 279:                     clb.withFlags(ACC_FINAL | ACC_SUPER)
> 280:                        .withSuperclass(INVOKER_SUPER_DESC)
> 281:                        .withVersion(CLASSFILE_VERSION, 0)

We can remove version (and maybe superclass) configuration as it's already the same as the defaults from CF API.
Suggestion:

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1148:

> 1146:     }
> 1147: 
> 1148:     private void emitPopInsn(CodeBuilder cob, BasicType type) {

We need a TypeKind-aware pop in CodeBuilder too :(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629360525
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629410742
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629414434
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629420425
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629437086
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629430093
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629439711
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629519618
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629533698
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629536765
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629537897
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1629542392
PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1637040340

From liach at openjdk.org  Wed Jun 12 20:48:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Jun 2024 20:48:41 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v3]
In-Reply-To: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
Message-ID: <j1iszrjg0NdE67tBj4mr2mG0Ncb6WZSTsd3WRWgNf2g=.017ba8cb-c243-40d5-aa5d-9d0fca894236@github.com>

> Please review this patch that fixes a critical issue that breaks some Proxy usages.
> 
> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear in method descriptors in the same class. The proposed way to bypass is to store the MethodType as its descriptor string in the bootstrap method arguments, and use MethodType.fromMethodDescriptorString to restore the arguments, which does not have this restriction and does not eagerly load the parameter classes. This case isn't covered by existing tests, so a new test has been added.

Chen Liang has updated the pull request incrementally with three additional commits since the last revision:

 - Fix bad stack map frame
 - Forgot to write field
 - Try to align with previous code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19615/files
  - new: https://git.openjdk.org/jdk/pull/19615/files/8448db2a..a57e0893

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19615&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19615&range=01-02

  Stats: 198 lines in 1 file changed: 88 ins; 32 del; 78 mod
  Patch: https://git.openjdk.org/jdk/pull/19615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19615/head:pull/19615

PR: https://git.openjdk.org/jdk/pull/19615

From vklang at openjdk.org  Wed Jun 12 20:52:30 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 12 Jun 2024 20:52:30 GMT
Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v14]
In-Reply-To: <WWg5uUCKJKTQjgDIFuYleew_-8kyeyVBftQajiAoDUQ=.f6e28123-03c7-4ebb-a9ec-4e3c8dcc8ab3@github.com>
References: <L9k4q8JueZijOZdDDqSNsJ4HOAPWsANxzW08PSFRxaw=.4e1ef057-523b-4413-80e7-6728f6197eb2@github.com>
 <bv5Ot2gQJyRlQ331BKSo7iTcaJ8M3PJQZMLn578pCqc=.4134f534-dce9-4a2a-b25d-8a4b9db95303@github.com>
 <WWg5uUCKJKTQjgDIFuYleew_-8kyeyVBftQajiAoDUQ=.f6e28123-03c7-4ebb-a9ec-4e3c8dcc8ab3@github.com>
Message-ID: <H79kO0-lmtifg26rMB8mWY2fiKjKwo74Do_3etevd5g=.907d146b-63f6-481a-b2e5-fd49f87233aa@github.com>

On Wed, 12 Jun 2024 17:31:09 GMT, Rob Spoor <duke at openjdk.org> wrote:

>> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
>> 
>>  - Lowering upper boundary of gatherer composition testing to 512
>>  - Javadoc clarifications for Gatherer type parameters,
>>    correcting descriptions of Integrator type parameters,
>>    and more consistently use "initializer function" instead
>>    of "supplier function".
>>  - Addressing trailing whitespace complaint
>>  - Adding @implSpec for Gatherer.andThen, plus adds tests to verify the default impls for Gatherer-related interfaces
>>  - Clarifying that Stream#gather is a stateful intermediate operation
>>  - Improvements after feedback
>>  - Unpacking the rethrown exceptions from Gatherers.mapConcurrent()
>>  - Addressing last review feedback
>>  - Apply suggestions from code review
>>    
>>    Integrates Paul Sandoz's feedback/changes
>>    
>>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>>  - Minor improvements to Gatherer Javadoc
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/69413690...49c94c7f
>
> src/java.base/share/classes/java/util/stream/Gatherer.java line 296:
> 
>> 294:      * @implSpec This method always returns the same instance.
>> 295:      *
>> 296:      * @see Gatherer#finisher()
> 
> Today I noticed that this is the wrong link. It should be `Gatherer#combiner()`, not `Gatherer#finisher()`.

@robtimus Thanks! I'll address that ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1637068982

From vklang at openjdk.org  Wed Jun 12 21:02:34 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 12 Jun 2024 21:02:34 GMT
Subject: RFR: 8334162: Gatherer.defaultCombiner has an erronous @see-link
Message-ID: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>

Erronous Javadoc reference addressed. This should be backported to 23.

-------------

Commit messages:
 - Updating Gatherer#defaultCombiner Javadoc to refer to Gatherer#combiner

Changes: https://git.openjdk.org/jdk/pull/19682/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334162
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19682/head:pull/19682

PR: https://git.openjdk.org/jdk/pull/19682

From mullan at openjdk.org  Wed Jun 12 21:06:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Jun 2024 21:06:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v6]
In-Reply-To: <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
Message-ID: <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>

On Wed, 12 Jun 2024 16:11:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Undo test policy updates

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1304:

> 1302:                 // No ACC, therefore no SM. May have a Subject:
> 1303:                 if (subject != null) {
> 1304:                     return Subject.doAs(subject, action);

Is it ever possible for subject to be `null` (passed in as `null` to the constructor) and an SM to be enabled? If so, then the call above to `Subject.doAs` would trigger a permission for an `AuthPermission("doAs")` permission. (This also may have been the case you were seeing in tests).

I think following Weijun's advice above is cleaner and safer, so you do one or the other depending on the allowSM setting, and not whether certain variables are null or not.

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 304:

> 302:     }
> 303: 
> 304:     @SuppressWarnings("removal")

Is this annotation needed? I see you have one below.

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 312:

> 310:             @SuppressWarnings("removal")
> 311:             final AccessControlContext acc = AccessController.getContext();
> 312:             //@SuppressWarnings("removal")

Remove this line?

src/java.management/share/classes/javax/management/monitor/Monitor.java line 1543:

> 1541:                 // No SecurityManager:
> 1542:                 Subject.doAs(s, action); // s is permitted to be null
> 1543:             } else {

Even though ac should never be null, I would keep the original check for ac == null inside the SM code path to be safe and consistent with the original code, and use only call doAs if allowSM is false, so like:


if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
    // No SecurityManager:
    Subject.doAs(s, action); // s is permitted to be null
} else {
    if (ac == null) {
        throw new SecurityException("AccessControlContext cannot be null");
    }
    // ACC means SM is permitted.
    AccessController.doPrivileged(action, ac);
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637086418
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637060238
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637060517
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637073809

From mullan at openjdk.org  Wed Jun 12 21:06:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Jun 2024 21:06:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <tKMzL3ItOgRgLgi3gpfxeJhF1giLbogAKqEz0aizuxw=.36362158-215d-446e-8636-f22d88e63a7a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <R5FGOL4A6D3cUdIs99UwvXBtp5pruUD3wpXaZMr3zaQ=.7b7e9265-1950-41ad-b5e2-e02bd7603f62@github.com>
 <tKMzL3ItOgRgLgi3gpfxeJhF1giLbogAKqEz0aizuxw=.36362158-215d-446e-8636-f22d88e63a7a@github.com>
Message-ID: <iV7z5vyop0OZ8GdczZSxblBpEqdhOR8nMnw-aLOiA0U=.60e5acb2-ebb8-4c30-91df-02bc9cd0ea71@github.com>

On Wed, 12 Jun 2024 14:06:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> For the same reason you should be able to just call `Subject.current` in the tests. I don't think you need the `SimpleStandard.useGetSubjectACC` property to toggle the testing of either old or replacement APIs as long as the test has runs in both SM allow and disallow (i.e., no SM prop set) modes. Would you agree Weijun?
>
> I thought there was a comment elsewhere suggesting using SM=allow to test with Subject.getSubject() and Subject.current(), and when SM not allowed, to only use Subject.current() ?
> That was the reason for the property in the tests.

Um, yes that was my comment :) Ok, let's leave the tests as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637054347

From dnguyen at openjdk.org  Wed Jun 12 21:11:52 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 12 Jun 2024 21:11:52 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v4]
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <DAEnGganAWoVga2j8IKfI2HiHDrKGn8lHExbWpMzNQU=.e3eea870-10b9-4eca-9cb4-85ee95ed70b3@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Undo translation for some words

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19609/files
  - new: https://git.openjdk.org/jdk/pull/19609/files/e9e0bcea..8c22d1db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609

PR: https://git.openjdk.org/jdk/pull/19609

From dnguyen at openjdk.org  Wed Jun 12 21:11:52 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 12 Jun 2024 21:11:52 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v4]
In-Reply-To: <Ss1KZ4NwolVYPiXv46jXJ05_pDMCkOY4GHYlq5stnCc=.135e6f50-206b-4f75-acf4-4574eaf84951@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
 <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
 <Ss1KZ4NwolVYPiXv46jXJ05_pDMCkOY4GHYlq5stnCc=.135e6f50-206b-4f75-acf4-4574eaf84951@github.com>
Message-ID: <tYq_jOkBddmXa1PV50hifwtXBOKDhobAVEX4PKO7U40=.518cf1f2-8c4f-4789-b51a-fa1bb4b62ccd@github.com>

On Mon, 10 Jun 2024 23:11:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> @jonathan-gibbons I just realized that this change to the German file matches the file with the Japanese and Chinese localized files. By that I mean the "backwards" translations are also present for the Japanese and Chinese files.
>> 
>> However, the previous versions of the Japanese and Chinese files don't have these bits translated. So in summary, I can revert the German file back to German but the Japanese and Chinese files will still be English for these parts because I wouldn't know what to revert them to in their local language.
>> 
>> As a result, I actually think it might be better to change this German file as shown in the current version of the PR just to remain consistent with the other localized versions of this file. We can still bring this up to the go team as an issue, but I think this is the best solution now for this drop at least.
>
> No one else except people reading this PR will spot inconsistencies between translations in different languages. So inconsistencies across languages will not be obvious to end users.
> 
> But anyone (end-user) using the tool in any one of these languages is likely to spot inconsistencies in the translations for that one language.

@jonathan-gibbons I have gone back and manually undid some of the English translations back to its former German word. Most occurrences of this are `<flag>` to `<Kennzeichen>`, but some others were changed back as well. Could you re-review this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1637092298

From liach at openjdk.org  Wed Jun 12 21:13:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Jun 2024 21:13:14 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
In-Reply-To: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
Message-ID: <PZJaGrsZUTy1oCYZRdiXIijqI41RKLccrugdHeZvVp4=.a1f5526a-e57b-4404-8419-293bae9bb8cb@github.com>

On Wed, 12 Jun 2024 10:45:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
> 
> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
> 
> To summarize those discussions, we had concluded that:
> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
> 
> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
> 
> I'll file a CSR shortly.

src/java.base/share/classes/java/util/zip/Deflater.java line 904:

> 902:     public void close() {
> 903:         synchronized (zsRef) {
> 904:             // check if already closed

Should we comment `// in case subclasses override the closed check in end()` instead? Otherwise the duplicate comments and checks are confusing.

src/java.base/share/classes/java/util/zip/Inflater.java line 724:

> 722:     public void close() {
> 723:         synchronized (zsRef) {
> 724:             // check if already closed

Same remark, we should mention subclass override close risk

test/jdk/java/util/zip/DeflaterClose.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

Same for `InflaterClose.java`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1637091530
PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1637092387
PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1637092809

From rriggs at openjdk.org  Wed Jun 12 21:35:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Jun 2024 21:35:13 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v3]
In-Reply-To: <j1iszrjg0NdE67tBj4mr2mG0Ncb6WZSTsd3WRWgNf2g=.017ba8cb-c243-40d5-aa5d-9d0fca894236@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <j1iszrjg0NdE67tBj4mr2mG0Ncb6WZSTsd3WRWgNf2g=.017ba8cb-c243-40d5-aa5d-9d0fca894236@github.com>
Message-ID: <IXbVtFtnFpZa26_tN5O80NyPbUSUUbD9k6WEep_kVt0=.6ab332a4-82a4-4ee8-8184-af56c5db6fb8@github.com>

On Wed, 12 Jun 2024 20:48:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> Since the problematic patch from before cannot be backed out, this patch aims to emulate the old behavior before. A diff between before the problematic patch and this patch is available at https://gist.github.com/7565b2091008f561eb0ada019bc5e517, generated by running `git diff 326dbb1b139dd1ec1b8605339b91697cdf49da9a -- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java`.
>
> Chen Liang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix bad stack map frame
>  - Forgot to write field
>  - Try to align with previous code

Once a PR is in review doing a bunch of renames hides the real change in a bunch of inconsequential changes and can extend the review.
The "Ce" suffix would read better as "CE".

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 95:

> 93: 
> 94:     private static final String
> 95:             NAME_LOOKUP_ACCESSOR = "proxyClassLookup";

Join these if there's only 1.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19615#pullrequestreview-2114238459
PR Review Comment: https://git.openjdk.org/jdk/pull/19615#discussion_r1637104525

From duke at openjdk.org  Wed Jun 12 21:41:39 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 21:41:39 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v6]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <sHOCYNXxECcF_eE0ETK9Ts2O8MY8cOdY9v9dUbtydbA=.350e9563-2edb-4b40-b981-8c7e1b3e7a02@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  StringLatin1 & StringUTF16 use the same logic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/dd97cff3..67be25c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=04-05

  Stats: 63 lines in 3 files changed: 31 ins; 10 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From jlu at openjdk.org  Wed Jun 12 21:58:25 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Jun 2024 21:58:25 GMT
Subject: RFR: 8333755: NumberFormat integer only parsing breaks when format
 has suffix [v3]
In-Reply-To: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
References: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
Message-ID: <Voq1u-9oSRB7-FoTMp2iuqjxVtciVqjItjnfzkXqBPY=.80919b1e-df7f-45d8-8f1a-aa0f199050ac@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8333920) which corrects a bug where NumberFormat cannot successfully parse values in integer only mode, when the format expects a suffix.
> 
> For example,
> 
> // a format that expects a currency suffix
> var fmt = NumberFormat.getCurrencyInstance(Locale.FRANCE);
> fmt.setParseIntegerOnly(true);
> failFmt.parse("5,00 ?"); // throws ParseException when you would have expected 5 returned
> 
> 
> When parsing in integer only mode, instead of breaking upon a decimal symbol encounter, we should store the index but continue to fully parse so that we can verify the entire string and increment our position to search for and match the suffix. Upon a successful suffix match, we can then set `ParsePosition.index` back to the stored decimal index.
> 
> It should be noted that CompactNumberFormat did previously have code that would traverse the rest of the String, to allow matching of the suffix. The difference is that NumberFormat returns the index upon decimal symbol encounter, while CompactNumberFormat was implemented to return the index reflected by the entire string traversal. Such differences cannot be standardized due to behavioral compatibility concerns.
> 
> Thus while parsing in integer only, CNF sets index to the `Position.fullPos()`, while DF sets index to the `Position.intPos()`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19664/files
  - new: https://git.openjdk.org/jdk/pull/19664/files/8579a0f6..6dc2c567

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19664&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19664&range=01-02

  Stats: 30 lines in 2 files changed: 13 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/19664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19664/head:pull/19664

PR: https://git.openjdk.org/jdk/pull/19664

From jlu at openjdk.org  Wed Jun 12 21:58:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Jun 2024 21:58:26 GMT
Subject: RFR: 8333755: NumberFormat integer only parsing breaks when format
 has suffix [v2]
In-Reply-To: <w-e24KVBE2qdfI6RrnMq4luMTtqnCrOIdcL8V974Gb0=.4eff9fb3-72f0-4a7b-8466-ec3d1ddf9bc2@github.com>
References: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
 <lBSeDivDuuJMBghbWQlqmAY2_LaC3ghYYV8cLYgb-VI=.44f64375-5b04-4ec2-ac7e-0f45f0b9c591@github.com>
 <w-e24KVBE2qdfI6RrnMq4luMTtqnCrOIdcL8V974Gb0=.4eff9fb3-72f0-4a7b-8466-ec3d1ddf9bc2@github.com>
Message-ID: <YWKHjLyt_TbB2Tlfo9Fk5XPrq9owhuFeI2ZB8gbMG0c=.e4bd479f-b3e5-46f2-bc5e-c5f35345f6a9@github.com>

On Wed, 12 Jun 2024 20:12:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   specification improvements
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 2446:
> 
>> 2444:     // To track the full parse index as well as the integer portion
>> 2445:     record Position(int intPos, int fullPos) {}
>> 2446: 
> 
> The record name may be more descriptive. Also I would expect more description here, such as what it is and those params are.

Thanks for the review Naoto.

Renamed to `NumericPosition`, as well as added further descritpion. Hesitant to rename to anything longer/detail too much, for what is essentially a limited scope helper class.

> test/jdk/java/text/Format/NumberFormat/StrictParseTest.java line 320:
> 
>> 318:     }
>> 319: 
>> 320:     // Overloaded method used for integer only parsing, where the expected
> 
> Is this method for `integer only` only?

A leftover comment, now removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19664#discussion_r1637152902
PR Review Comment: https://git.openjdk.org/jdk/pull/19664#discussion_r1637152781

From liach at openjdk.org  Wed Jun 12 22:00:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Jun 2024 22:00:45 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v2]
In-Reply-To: <x--RissonNj12NbJ5-VNf1snCj-QwD3sz5TNxvosOAM=.0a3eb495-2f21-421e-a12b-dc8b276f0cf3@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <PEtRy9k0Bv_kT8LlKgQfdF_qFikzAY5AN5YUlngPepU=.7050b493-15d9-4559-ac9b-1169ea1d14c9@github.com>
 <x--RissonNj12NbJ5-VNf1snCj-QwD3sz5TNxvosOAM=.0a3eb495-2f21-421e-a12b-dc8b276f0cf3@github.com>
Message-ID: <skiDW9CFjXK-Al3uE1fzyUHfIUMoZGkzkKSeIjBC9MQ=.7adbe353-660c-434c-8941-2c39d58dd564@github.com>

On Wed, 12 Jun 2024 14:13:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Obtain classloader in security manager friendly code path
>
> Agree with Roger that static imports should be used sparingly (possibly never with .*). 
> 
> If other reviewers are happy with the semantic shift in when/where class loading can/will happen and which class loader will be used then I won't object. I'm just not enough of an expert in this area to tell if there might be unintended side-effects we need to account for.
> 
> The added cost of spinning and calling these clinits means we might be better off reverting from a startup overhead perspective. JDK-8332457 was already a regression for some usage patterns.

Sorry, I didn't immediately communicate that I decided to follow @cl4es's suggestion and to stay closer to before JDK-8332457. Here is the diff of this patch against the patch immediately before 8332457: https://gist.github.com/liach/7565b2091008f561eb0ada019bc5e517 (as of commit a510b1f4c7e7ba090afacf633be2dc3f5edf98c9) (Also see updated PR description)
This should serve better as a comparison for whether the restoration had been faithful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19615#issuecomment-2163969418

From liach at openjdk.org  Wed Jun 12 22:00:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Jun 2024 22:00:45 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v4]
In-Reply-To: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
Message-ID: <7btOfU-ojHjUgLo03OmBP27LDjtIbKiwEJ4IAYhhZXk=.054cb7a9-8685-4a89-b84c-e8b3a122db96@github.com>

> Please review this patch that fixes a critical issue that breaks some Proxy usages.
> 
> Since the problematic patch from before cannot be backed out, this patch aims to emulate the old behavior before. A diff between before the problematic patch and this patch is available at https://gist.github.com/7565b2091008f561eb0ada019bc5e517, generated by running `git diff 326dbb1b139dd1ec1b8605339b91697cdf49da9a -- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java`.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  More rename and code style cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19615/files
  - new: https://git.openjdk.org/jdk/pull/19615/files/a57e0893..a510b1f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19615&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19615&range=02-03

  Stats: 43 lines in 1 file changed: 6 ins; 4 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/19615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19615/head:pull/19615

PR: https://git.openjdk.org/jdk/pull/19615

From duke at openjdk.org  Wed Jun 12 22:52:17 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 12 Jun 2024 22:52:17 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
Message-ID: <Uim46vxIpXkPJg4o4T912wA5D_2HDhiqURbIzaAhJ4Y=.be680711-22e1-4a96-9716-0d125f5969fa@github.com>

On Thu, 6 Jun 2024 13:24:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - reverted static initialization of ConstantPoolBuilder and CP entries
>>  - fixed naming conventions
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 566:
> 
>> 564: 
>> 565:     static ClassDesc implClassDesc(Class<?> cls) {
>> 566:         return cls.isHidden() ? ReferenceClassDescImpl.ofValidatedBinaryName(cls.getName())
> 
> I recommend just returning null or a dummy value if the cls is hidden; in this case, implMethodClassDesc can safely be null, as implementation must go through condy.

Relevant?issue:
- https://github.com/openjdk/jdk/pull/18810

[JDK?8330467]: https://bugs.openjdk.org/browse/JDK-8330467

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1637204601

From duke at openjdk.org  Wed Jun 12 23:26:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 12 Jun 2024 23:26:38 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v7]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <3IAgJ4rtmDwOO31NvnRBV8nv18Qhelm9BHlNNtl6SAw=.13138a98-c2fd-490b-9e2f-2d8246a0b28c@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/67be25c7..7b3cf602

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From jpai at openjdk.org  Thu Jun 13 01:34:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 01:34:18 GMT
Subject: RFR: 8334162: Gatherer.defaultCombiner has an erronous @see-link
In-Reply-To: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
References: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
Message-ID: <N_14uq7eeuNGMmEDG_Kp4fFMWTLsPIk7B837zAQ28as=.66f9d03d-f3cd-4443-bffd-9869ae45b166@github.com>

On Wed, 12 Jun 2024 20:58:28 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Erronous Javadoc reference addressed. This should be backported to 23.

Hello Viktor, the change looks fine to me. The copyright year on the file will need an update before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19682#pullrequestreview-2114507628

From duke at openjdk.org  Thu Jun 13 02:06:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 13 Jun 2024 02:06:42 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v8]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <JiQEOXo6zrzVGIhJBbrYVJY4Kl5OOo2T-E2LUYVkUBU=.607a0258-52de-4f9f-9b2f-41d1542c7c26@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - rename benchmark
 - code format & use long address

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/7b3cf602..22d45124

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=06-07

  Stats: 43 lines in 3 files changed: 8 ins; 2 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From duke at openjdk.org  Thu Jun 13 03:47:41 2024
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 13 Jun 2024 03:47:41 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v4]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <xbzjWts7lAJXPezpXscqjCZmFYwDef9SxvtVfEyLNWM=.59cd704d-1e4d-4ec4-97b7-f09c141deca5@github.com>

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
> 
> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.

Chris Hennick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'openjdk:master' into patch-2
 - Bug fix: add-exports was for wrong package
 - Tweak boundary cases and add unit test
 - Bug fix: Math is in java.lang, not java.util
 - Fix a possible rounding error in RandomSupport::computeNextExponential
   
   This provides a slightly more accurate bounding limit for computeNextExponentialSoftCapped when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`.

-------------

Changes: https://git.openjdk.org/jdk/pull/17703/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17703&range=03
  Stats: 41 lines in 2 files changed: 36 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17703/head:pull/17703

PR: https://git.openjdk.org/jdk/pull/17703

From alanb at openjdk.org  Thu Jun 13 06:24:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Jun 2024 06:24:12 GMT
Subject: RFR: 8334162: Gatherer.defaultCombiner has an erronous @see-link
In-Reply-To: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
References: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
Message-ID: <juBG7tuV_YTdnW1fMNFBj0NbWhIGtPQr-aL_QLEoDTQ=.0a1b43f6-3de2-4271-9f8b-9488f2f6590a@github.com>

On Wed, 12 Jun 2024 20:58:28 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Erronous Javadoc reference addressed. This should be backported to 23.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19682#pullrequestreview-2114807878

From alanb at openjdk.org  Thu Jun 13 06:32:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Jun 2024 06:32:14 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v3]
In-Reply-To: <kRFnma_gV1zp08P29IAto-KRPiqmDxBYYPIOeuRuHEM=.8529a01f-c08d-497e-b6d2-d1f18eb36f2e@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
 <kRFnma_gV1zp08P29IAto-KRPiqmDxBYYPIOeuRuHEM=.8529a01f-c08d-497e-b6d2-d1f18eb36f2e@github.com>
Message-ID: <Io9jUt26qgk45gXwzUwk0ftV4pTEwxcO66OpzcIB-kU=.75d8a748-ddcd-4e4d-992a-a57e0f424083@github.com>

On Wed, 12 Jun 2024 19:06:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this fix for an intermittent test failure.
>> 
>> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
>> 
>> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
>> 
>> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable timeout in expect scripts

test/jdk/java/io/IO/IO.java line 192:

> 190:     // adapted from https://junit.org/junit5/docs/current/user-guide/#extensions-lifecycle-callbacks-timing-extension
> 191: 
> 192:     public static class TimingExtension implements BeforeTestExecutionCallback,

In passing, this feels like infrastructure that we could use in several areas as it regularly comes up as to how long specific tests take (the "seconds" line recorded by jtreg in the .jtr file is too coarse grain when there are many tests in the same source file).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19627#discussion_r1637622775

From jpai at openjdk.org  Thu Jun 13 06:50:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 06:50:14 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v2]
In-Reply-To: <CFkKN8JyfxpcKXeFOHJdVSw4ZDt3wJddPet9qv9yKCw=.c8054a72-fa6e-4053-83c9-2d7f6a23e061@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
 <MtieFYqWEbxpceQyHbTHdRaBvK4v4GTBtiNgkqO4UGU=.e6dc977d-8538-4e66-98f2-7a0485b35a4e@github.com>
 <CFkKN8JyfxpcKXeFOHJdVSw4ZDt3wJddPet9qv9yKCw=.c8054a72-fa6e-4053-83c9-2d7f6a23e061@github.com>
Message-ID: <S7Xeiy4UUkMRTCJPFU5g4qjB9UwHntJSYEDcgqTr92U=.fd080c51-cdd8-4e29-8303-d9f419fc5c54@github.com>

On Wed, 12 Jun 2024 19:02:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Preliminary testing on some affected configurations showed that even 20 seconds might not be enough. Initially, I suggested that it would be hard to imagine, yet here we are.

I haven't seen the jtreg launch command or the jtr files for these timeout failures, but in the past on systems that Matthias has run into similar issues, it was observed that those systems run with a very high `-concurrency` value (which implies too many test processes running at the same time) which could cause slowness. I don't know if that's what is a contributing factor here. 

> A good solution would be to disable expect timeout and, thus, fall back onto jtreg timeout. 

I think that's a better solution. That removes the part where we have to guess what's the best/appropriate timeout value to use in the test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19627#issuecomment-2164662278

From jpai at openjdk.org  Thu Jun 13 07:02:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 07:02:12 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v3]
In-Reply-To: <Io9jUt26qgk45gXwzUwk0ftV4pTEwxcO66OpzcIB-kU=.75d8a748-ddcd-4e4d-992a-a57e0f424083@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
 <kRFnma_gV1zp08P29IAto-KRPiqmDxBYYPIOeuRuHEM=.8529a01f-c08d-497e-b6d2-d1f18eb36f2e@github.com>
 <Io9jUt26qgk45gXwzUwk0ftV4pTEwxcO66OpzcIB-kU=.75d8a748-ddcd-4e4d-992a-a57e0f424083@github.com>
Message-ID: <e2xm7ijzywuA485rePaHp09t1gYsQ7nX9p61J2vgClY=.d24587c5-72c4-4628-b4d2-db351444db12@github.com>

On Thu, 13 Jun 2024 06:29:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disable timeout in expect scripts
>
> test/jdk/java/io/IO/IO.java line 192:
> 
>> 190:     // adapted from https://junit.org/junit5/docs/current/user-guide/#extensions-lifecycle-callbacks-timing-extension
>> 191: 
>> 192:     public static class TimingExtension implements BeforeTestExecutionCallback,
> 
> In passing, this feels like infrastructure that we could use in several areas as it regularly comes up as to how long specific tests take (the "seconds" line recorded by jtreg in the .jtr file is too coarse grain when there are many tests in the same source file).

Looking briefly at this, I think we should be able to provide this as a feature of jtreg's support of `junit` test itself. I've created https://bugs.openjdk.org/browse/CODETOOLS-7903751 to investigate this support in jtreg.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19627#discussion_r1637663845

From jpai at openjdk.org  Thu Jun 13 07:05:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 07:05:26 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v2]
In-Reply-To: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
Message-ID: <7AuIOTXCqGrsP2EB-6dSzGPa4Ojj6T28sRKAeifB2lk=.07dd8809-8b01-4fd2-86c8-37f7ca0913b2@github.com>

> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
> 
> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
> 
> To summarize those discussions, we had concluded that:
> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
> 
> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
> 
> I'll file a CSR shortly.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  convert the tests to junit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19675/files
  - new: https://git.openjdk.org/jdk/pull/19675/files/6e32965d..79e68e91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=00-01

  Stats: 406 lines in 2 files changed: 64 ins; 99 del; 243 mod
  Patch: https://git.openjdk.org/jdk/pull/19675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675

PR: https://git.openjdk.org/jdk/pull/19675

From jpai at openjdk.org  Thu Jun 13 07:05:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 07:05:26 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v2]
In-Reply-To: <PZJaGrsZUTy1oCYZRdiXIijqI41RKLccrugdHeZvVp4=.a1f5526a-e57b-4404-8419-293bae9bb8cb@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <PZJaGrsZUTy1oCYZRdiXIijqI41RKLccrugdHeZvVp4=.a1f5526a-e57b-4404-8419-293bae9bb8cb@github.com>
Message-ID: <p7-Hy-6vupMPCJdWKiv0jlqS4a6y2EKpGvRcngcxt3I=.31ad83a9-5f64-4331-ac25-9adfca37b629@github.com>

On Wed, 12 Jun 2024 21:08:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   convert the tests to junit
>
> test/jdk/java/util/zip/DeflaterClose.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Same for `InflaterClose.java`.

Hello Chen, these tests were actually introduced in a RFR back in 2019, so the original year is correct. I've now converted these tests to junit and updated the PR and updated the copyright years as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1637667063

From epeter at openjdk.org  Thu Jun 13 07:39:13 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 13 Jun 2024 07:39:13 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
 <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
Message-ID: <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>

On Wed, 12 Jun 2024 15:58:59 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>>> @eme64 It seems like MergeStore didn't happen, is there something I did wrong?
>> 
>> Yes ;)
>> 
>> @wenshao The issue is that the pattern matching is quite **limited**.
>> `putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4)`
>> This has 4 variables. This is not allowed for the optimization. You would have to pass in a `long` and split it via shifts.
>> A possible exception: if `putCharsAt` is inlined and outside it is a splitting of a `long` value with shift, then ... maybe ... this would be optimized with `MergeStores`.
>> 
>> There are only 2 **accepted** patterns:
>> - Multiple stores of constants -> constant is merged, which allows stores to be merged.
>> - Multiple stores which all store a "section" of a larger value:
>> 
>> You can see **examples** I listed at the beginning of the PR description in https://github.com/openjdk/jdk/pull/16245.
>
> Thanks to @eme64 's patience and help, I found a way to use MergeStore without doing boundary checking.
> 
> It would be even better if Unsafe.putChar could be used for MergeStore in the future.
> 
> ## 1. JavaCode
> 
> class StringUTF16 {
>     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>         // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
>         putChar1(value, i    , c1);
>         putChar1(value, i + 1, c2);
>         putChar1(value, i + 2, c3);
>         putChar1(value, i + 3, c4);
>     }
> 
>     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4, char c5) {
>         // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
>         putChar1(value, i    , c1);
>         putChar1(value, i + 1, c2);
>         putChar1(value, i + 2, c3);
>         putChar1(value, i + 3, c4);
>         putChar1(value, i + 4, c5);
>     }
> 
>     static void putChar1(byte[] value, int i, char c) {
>         int address = Unsafe.ARRAY_BYTE_BASE_OFFSET + (i << 1);
>         Unsafe.getUnsafe().putByte(value, address    , (byte)(c >> HI_BYTE_SHIFT));
>         Unsafe.getUnsafe().putByte(value, address + 1, (byte)(c >> LO_BYTE_SHIFT));
>     }
> }
> 
> 
> ## 2. Benchmark Numbers
> The performance numbers under MacBookPro M1 Max are as follows:
> 
> -Benchmark                                   Mode  Cnt  Score   Error  Units
> -StringBuilders.toStringCharWithNull8Latin1  avgt   15  7.073 ? 0.010  ns/op
> -StringBuilders.toStringCharWithNull8Utf16   avgt   15  9.298 ? 0.015  ns/op
> -StringBuilders.toStringCharWithBool8Latin1  avgt   15  7.387 ? 0.021  ns/op
> -StringBuilders.toStringCharWithBool8Utf16   avgt   15  9.615 ? 0.011  ns/op
> 
> +Benchmark                                   Mode  Cnt  Score   Error  Units
> +StringBuilders.toStringCharWithNull8Latin1  avgt   15  5.628 ? 0.017  ns/op +25.67%
> +StringBuilders.toStringCharWithNull8Utf16   avgt   15  6.873 ? 0.026  ns/op +35.28%
> +StringBuilders.toStringCharWithBool8Latin1  avgt   15  6.480 ? 0.077  ns/op +13.99%
> +StringBuilders.toStringCharWithBool8Utf16   avgt   15  7.456 ? 0.059  ns/op +28.95%
> 
> 
> ## 3.  TraceMergeStores
> 
> [TraceMergeStores]: Replace
>  65  StoreB  === 54 7 64 12  [[ 87 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: StringUTF16::putChar1 @ bci:20 (li...

@wenshao I'm glad we figured it out a bit, and I hope you learned a thing or two :)

> It would be even better if Unsafe.putChar could be used for MergeStore in the future.

The `_putCharStringU` intrinsic uses `LibraryCallKit::inline_string_char_access`. It seems to generate IR nodes, I speculate it could be `StoreC`. We'd have to do more digging to see why that pattern is not accepted by `MergeStore`.

@wenshao I'm not sure if everything is right with the bounds checking, but I leave this to the library folks to review. What you will definately need is benchmarking not just on `M1`, but also `x86-64` and other `aarch64` architectures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2164851377

From alanb at openjdk.org  Thu Jun 13 08:08:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Jun 2024 08:08:14 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v3]
In-Reply-To: <e2xm7ijzywuA485rePaHp09t1gYsQ7nX9p61J2vgClY=.d24587c5-72c4-4628-b4d2-db351444db12@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
 <kRFnma_gV1zp08P29IAto-KRPiqmDxBYYPIOeuRuHEM=.8529a01f-c08d-497e-b6d2-d1f18eb36f2e@github.com>
 <Io9jUt26qgk45gXwzUwk0ftV4pTEwxcO66OpzcIB-kU=.75d8a748-ddcd-4e4d-992a-a57e0f424083@github.com>
 <e2xm7ijzywuA485rePaHp09t1gYsQ7nX9p61J2vgClY=.d24587c5-72c4-4628-b4d2-db351444db12@github.com>
Message-ID: <E6FRrZ0tLjsZFzBOe4Ctgl5iNpqP4m6EX2qqsAjMcDg=.8dd53439-36f9-430f-9ff9-299fc3cbeeac@github.com>

On Thu, 13 Jun 2024 06:59:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/io/IO/IO.java line 192:
>> 
>>> 190:     // adapted from https://junit.org/junit5/docs/current/user-guide/#extensions-lifecycle-callbacks-timing-extension
>>> 191: 
>>> 192:     public static class TimingExtension implements BeforeTestExecutionCallback,
>> 
>> In passing, this feels like infrastructure that we could use in several areas as it regularly comes up as to how long specific tests take (the "seconds" line recorded by jtreg in the .jtr file is too coarse grain when there are many tests in the same source file).
>
> Looking briefly at this, I think we should be able to provide this as a feature of jtreg's support of `junit` test itself. I've created https://bugs.openjdk.org/browse/CODETOOLS-7903751 to investigate this support in jtreg.

This is something that I discussed with Christen Stein about. We've tossed around some ideas, he created CODETOOLS-7903752 so we may have a dup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19627#discussion_r1637772922

From jpai at openjdk.org  Thu Jun 13 08:12:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 08:12:12 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v3]
In-Reply-To: <E6FRrZ0tLjsZFzBOe4Ctgl5iNpqP4m6EX2qqsAjMcDg=.8dd53439-36f9-430f-9ff9-299fc3cbeeac@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
 <kRFnma_gV1zp08P29IAto-KRPiqmDxBYYPIOeuRuHEM=.8529a01f-c08d-497e-b6d2-d1f18eb36f2e@github.com>
 <Io9jUt26qgk45gXwzUwk0ftV4pTEwxcO66OpzcIB-kU=.75d8a748-ddcd-4e4d-992a-a57e0f424083@github.com>
 <e2xm7ijzywuA485rePaHp09t1gYsQ7nX9p61J2vgClY=.d24587c5-72c4-4628-b4d2-db351444db12@github.com>
 <E6FRrZ0tLjsZFzBOe4Ctgl5iNpqP4m6EX2qqsAjMcDg=.8dd53439-36f9-430f-9ff9-299fc3cbeeac@github.com>
Message-ID: <XrxqfFwvODDGPCrOxIYaEd2vXneBUK6FzLkKlqEx_4w=.edb8faf4-ee2d-4e27-98a1-844a5571380b@github.com>

On Thu, 13 Jun 2024 08:05:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Looking briefly at this, I think we should be able to provide this as a feature of jtreg's support of `junit` test itself. I've created https://bugs.openjdk.org/browse/CODETOOLS-7903751 to investigate this support in jtreg.
>
> This is something that I discussed with Christen Stein about. We've tossed around some ideas, he created CODETOOLS-7903752 so we may have a dup.

I've closed mine as the duplicate of the other.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19627#discussion_r1637778998

From forax at univ-mlv.fr  Thu Jun 13 08:16:38 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 13 Jun 2024 10:16:38 +0200 (CEST)
Subject: Gatherer and primitive specialization
Message-ID: <1416122669.48988404.1718266598860.JavaMail.zimbra@univ-eiffel.fr>

Hello,
the Gatherer API do not provide primitive specialization while intermediate methods like map(), flatMap() or mapMulti() do.

Unlike collectors where it is okay to not be specialized because most collectors mutate a collection that is not specialized too,
gatherers can process/transform values so having boxing in the middle of those kind of computations is a performance pothole.

I think there is a trick that can be used, we do not need to specialize all the functions of the Gatherer API but only the integrator.
All other functions are called a few time when a stream is processed so they may not need specialization, only the integrator is called a lot.

regards,
R?mi

From redestad at openjdk.org  Thu Jun 13 08:36:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 13 Jun 2024 08:36:13 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v4]
In-Reply-To: <7btOfU-ojHjUgLo03OmBP27LDjtIbKiwEJ4IAYhhZXk=.054cb7a9-8685-4a89-b84c-e8b3a122db96@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <7btOfU-ojHjUgLo03OmBP27LDjtIbKiwEJ4IAYhhZXk=.054cb7a9-8685-4a89-b84c-e8b3a122db96@github.com>
Message-ID: <xjoHRL7ltpC3Fcm08hD3Z6BP1R86KQ-JvcujsIP0-pQ=.5c1bdbd1-6c92-4535-85d8-8aceb905c53c@github.com>

On Wed, 12 Jun 2024 22:00:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> Since the problematic patch from before cannot be backed out, this patch aims to emulate the old behavior before. A diff between before the problematic patch and this patch is available at https://gist.github.com/7565b2091008f561eb0ada019bc5e517, generated by running `git diff 326dbb1b139dd1ec1b8605339b91697cdf49da9a -- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More rename and code style cleanup

I think this looks better as you're reverting the problematic changes while retaining most of the benefits of JDK-8332457.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 676:

> 674:          * @param method          The method for which to create a proxy
> 675:          */
> 676:         private ProxyMethod(Method method, String methodFieldName) {

Could we pass the `FieldRefEntry` directly? I don't see when we'd create a `ProxyMethod` without later calling `methodField()`. I think this would also remove the need to make `ProxyMethod` non-static.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19615#pullrequestreview-2115128124
PR Review Comment: https://git.openjdk.org/jdk/pull/19615#discussion_r1637805452

From redestad at openjdk.org  Thu Jun 13 09:30:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 13 Jun 2024 09:30:19 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
Message-ID: <r5Tiy1ujWNM3o6svQyBjU2-7SwMCwy16s3xCKZ6z0iA=.0c3cc3d8-c2c3-478d-b27c-8d6c7ea01e99@github.com>

On Thu, 6 Jun 2024 11:41:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - reverted static initialization of ConstantPoolBuilder and CP entries
>>  - fixed naming conventions
>
> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 616:
> 
>> 614:             final ClassDesc classDesc = ClassDesc.of(className0);
>> 615:             final ClassDesc superClassDesc = classDesc(speciesData.deriveSuperClass());
>> 616:             return ClassFile.of().build(classDesc, clb -> {
> 
> We need a confirmation here that these BMH species are only initialized after LMF is ready. @cl4es Is a dependency on LMF from BMH safe?

LMF will BMH and `ClassSpecializer`, but does not call into this code normally as the simple bound method handle needed by LMF is statically defined (`BoundMethodHandle.Species_L`). To be perfectly safe - and to keep lambda/indy/condy bootstrap overheads to a minumum - I'll continue recommending the desugaring of lambdas in java.lang.invoke

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1637893254

From clanger at openjdk.org  Thu Jun 13 09:53:38 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 09:53:38 GMT
Subject: RFR: 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails:
 "reported cputime less than expected"
Message-ID: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>

It seems the error is gone meanwhile. So we can reenable the test.

-------------

Commit messages:
 - JDK-8211847

Changes: https://git.openjdk.org/jdk/pull/19691/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19691&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8211847
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19691/head:pull/19691

PR: https://git.openjdk.org/jdk/pull/19691

From redestad at openjdk.org  Thu Jun 13 09:54:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 13 Jun 2024 09:54:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v8]
In-Reply-To: <JiQEOXo6zrzVGIhJBbrYVJY4Kl5OOo2T-E2LUYVkUBU=.607a0258-52de-4f9f-9b2f-41d1542c7c26@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <JiQEOXo6zrzVGIhJBbrYVJY4Kl5OOo2T-E2LUYVkUBU=.607a0258-52de-4f9f-9b2f-41d1542c7c26@github.com>
Message-ID: <Vjuj_jb6e10neab80hXDoCtked0g1Iedre45s7-p9A8=.acf15ea1-211b-43df-a3cf-629b099c1888@github.com>

On Thu, 13 Jun 2024 02:06:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename benchmark
>  - code format & use long address

Replacing `StringUTF16.putChar` with an `Unsafe.putByte` construct seems safe since the former already depends on bounds checks having been done elsewhere. Replacing `byte[]` stores with `Unsafe.putByte` requires a thorough examination as that would drop implicit bounds checks.  

On my M1 laptop I get similar numbers:

Name                                 Cnt  Base   Error   Test   Error  Unit  Change
StringBuilders.appendWithBool8Latin1  15 7,500 ? 0,072  6,112 ? 0,049 ns/op   1,23x (p = 0,000*)
StringBuilders.appendWithBool8Utf16   15 9,650 ? 0,021  7,304 ? 0,047 ns/op   1,32x (p = 0,000*)
StringBuilders.appendWithNull8Latin1  15 7,118 ? 0,033  5,158 ? 0,062 ns/op   1,38x (p = 0,000*)
StringBuilders.appendWithNull8Utf16   15 9,336 ? 0,083  6,870 ? 0,069 ns/op   1,36x (p = 0,000*)
  * = significant


On a linux-x64 workstation some of the micros regress, though:

Name                                 Cnt   Base    Error    Test   Error  Unit  Change
StringBuilders.appendWithBool8Latin1  15 10.781 ?  0.236  16.279 ? 1.087 ns/op   0.66x (p = 0.000*)
StringBuilders.appendWithBool8Utf16   15 22.942 ?  0.405  23.733 ? 0.792 ns/op   0.97x (p = 0.001*)
StringBuilders.appendWithNull8Latin1  15 24.313 ? 10.479  24.397 ? 7.483 ns/op   1.00x (p = 0.979 )
StringBuilders.appendWithNull8Utf16   15 38.704 ?  5.972  27.542 ? 5.620 ns/op   1.41x (p = 0.000*)
  * = significant


`-XX:+TraceMergeStores` seem to indicate the merging happens as it should in each case:


[TraceMergeStores]: Replace
 2493  StoreB  === 1387 5370 2980 2939  [[ 1962 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=13; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact[2] *, idx=13; !jvms: StringLatin1::putCharsAt @ bci:50 (line 834) AbstractStringBuilder::appendNull @ bci:34 (line 642) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179) StringBuilders::appendWithNull8Latin1 @ bci:38 (line 267) StringBuilders_appendWithNull8Latin1_jmhTest::appendWithNull8Latin1_avgt_jmhStub @ bci:17 (line 190)
 1962  StoreB  === 1387 2493 2494 2442  [[ 1388 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=13; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact[2] *, idx=13; !jvms: StringLatin1::putCharsAt @ bci:62 (line 835) AbstractStringBuilder::appendNull @ bci:34 (line 642) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179) StringBuilders::appendWithNull8Latin1 @ bci:38 (line 267) StringBuilders_appendWithNull8Latin1_jmhTest::appendWithNull8Latin1_avgt_jmhStub @ bci:17 (line 190)
 1388  StoreB  === 1387 1962 1963 1341  [[ 833 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=13; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact[2] *, idx=13; !jvms: StringLatin1::putCharsAt @ bci:77 (line 836) AbstractStringBuilder::appendNull @ bci:34 (line 642) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179) StringBuilders::appendWithNull8Latin1 @ bci:38 (line 267) StringBuilders_appendWithNull8Latin1_jmhTest::appendWithNull8Latin1_avgt_jmhStub @ bci:17 (line 190)
  833  StoreB  === 1387 1388 1389 1341  [[ 5311 425 1400 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=13; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact[2] *, idx=13; !jvms: StringLatin1::putCharsAt @ bci:92 (line 837) AbstractStringBuilder::appendNull @ bci:34 (line 642) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179) StringBuilders::appendWithNull8Latin1 @ bci:38 (line 267) StringBuilders_appendWithNull8Latin1_jmhTest::appendWithNull8Latin1_avgt_jmhStub @ bci:17 (line 190)
[TraceMergeStores]: with
 6207  ConI  === 0  [[ 6208 6210 ]]  #int:1819047278
 6210  StoreI  === 1387 5370 2980 6207  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact[2] *, idx=13; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact[2] *, idx=13;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2165167049

From prappo at openjdk.org  Thu Jun 13 10:07:48 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 13 Jun 2024 10:07:48 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v4]
In-Reply-To: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
Message-ID: <Gx5ayeW7fJwf2pjAh9U-GPxLTjFjlVbqJ3r7TX8LGcw=.c8ac05fc-0272-4365-97bb-78c6d303dfdb@github.com>

> Please review this fix for an intermittent test failure.
> 
> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
> 
> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
> 
> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.

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 8333358
 - Add a comment for future maintainers
 - Disable timeout in expect scripts
 - Change url as suggested in review
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19627/files
  - new: https://git.openjdk.org/jdk/pull/19627/files/56d24203..aad8b491

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19627&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19627&range=02-03

  Stats: 12646 lines in 467 files changed: 4452 ins; 7038 del; 1156 mod
  Patch: https://git.openjdk.org/jdk/pull/19627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19627/head:pull/19627

PR: https://git.openjdk.org/jdk/pull/19627

From stuefe at openjdk.org  Thu Jun 13 10:11:11 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 13 Jun 2024 10:11:11 GMT
Subject: RFR: 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails:
 "reported cputime less than expected"
In-Reply-To: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>
References: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>
Message-ID: <2__TlA-Bd5OA7rQmB2-VteUwaIeBat15e_z4DZT7I7Y=.1edf3098-460b-4547-bf1e-a62505a278c5@github.com>

On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> It seems the error is gone meanwhile. So we can reenable the test.

Okay. Any idea what fixed the test?

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19691#pullrequestreview-2115358316

From prappo at openjdk.org  Thu Jun 13 10:20:11 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 13 Jun 2024 10:20:11 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v2]
In-Reply-To: <S7Xeiy4UUkMRTCJPFU5g4qjB9UwHntJSYEDcgqTr92U=.fd080c51-cdd8-4e29-8303-d9f419fc5c54@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
 <MtieFYqWEbxpceQyHbTHdRaBvK4v4GTBtiNgkqO4UGU=.e6dc977d-8538-4e66-98f2-7a0485b35a4e@github.com>
 <CFkKN8JyfxpcKXeFOHJdVSw4ZDt3wJddPet9qv9yKCw=.c8054a72-fa6e-4053-83c9-2d7f6a23e061@github.com>
 <S7Xeiy4UUkMRTCJPFU5g4qjB9UwHntJSYEDcgqTr92U=.fd080c51-cdd8-4e29-8303-d9f419fc5c54@github.com>
Message-ID: <9Hp8P2PBvK0Jq9yXWD_7cTdqkRtiGHygcfjpzU9xuIQ=.8ddcc6d2-543d-4962-b87b-741103d0129d@github.com>

On Thu, 13 Jun 2024 06:47:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> in the past on systems that Matthias has run into similar issues, it was observed that those systems run with a very high `-concurrency` value (which implies too many test processes running at the same time) which could cause slowness

In jtr files from those systems, I didn't see any `-concurrency` values, which I believe are not recorded there, but I saw `test.timeout.factor=9.0`, which is by itself is very telling.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19627#issuecomment-2165229988

From clanger at openjdk.org  Thu Jun 13 10:26:14 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 10:26:14 GMT
Subject: RFR: 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails:
 "reported cputime less than expected"
In-Reply-To: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>
References: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>
Message-ID: <Bvgz3YwTnLOihsbSM2cOjITco9tmRyNZ5mf1G_6A2fk=.201fcc6f-1547-4cb8-9043-04ff66213adf@github.com>

On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> It seems the error is gone meanwhile. So we can reenable the test.

Maybe [this one](https://github.com/openjdk/jdk/commit/4d9042043ecade75d50c25574a445e6b8ef43618)? But just guessing...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19691#issuecomment-2165243238

From kevinw at openjdk.org  Thu Jun 13 10:27:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 10:27:40 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v7]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <9f_IZR1qUiOuViO8nPYmL-CexyVL4jVw3zYgbA_OKMQ=.6b72482a-c04f-475c-917a-686773878ce2@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Annotation in checkAccess

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/6f072338..32f52c52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Thu Jun 13 10:27:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 10:27:40 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v6]
In-Reply-To: <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
 <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
Message-ID: <j4z7TNP7Gm72-0hSG-9GiwsKlYz74pD0Y3LGBH6oonY=.35c77de6-d145-42ef-a09f-e8503cb6cd1e@github.com>

On Wed, 12 Jun 2024 20:42:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Undo test policy updates
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 312:
> 
>> 310:             @SuppressWarnings("removal")
>> 311:             final AccessControlContext acc = AccessController.getContext();
>> 312:             //@SuppressWarnings("removal")
> 
> Remove this line?

Now the assignment to Subject is split into two alternatives, this annotation doesn't work (without the variable declaration).
Yes I can remove this and can go with just one annotation for the method.
I am expecting to remove the deprecated methods here in a followup change after SM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1637973185

From vklang at openjdk.org  Thu Jun 13 10:51:41 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 13 Jun 2024 10:51:41 GMT
Subject: RFR: 8334162: Gatherer.defaultCombiner has an erronous @see-link
 [v2]
In-Reply-To: <N_14uq7eeuNGMmEDG_Kp4fFMWTLsPIk7B837zAQ28as=.66f9d03d-f3cd-4443-bffd-9869ae45b166@github.com>
References: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
 <N_14uq7eeuNGMmEDG_Kp4fFMWTLsPIk7B837zAQ28as=.66f9d03d-f3cd-4443-bffd-9869ae45b166@github.com>
Message-ID: <bf2Ov3MR-7pQ12gK6hwC2ZHzztQmVPX6XswITqRZo0M=.a6494d32-2033-4706-b8a9-d00f9e91d5cf@github.com>

On Thu, 13 Jun 2024 01:31:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tweaking the copyright year to reflect initial year AND current
>>  - Updating copyright year
>
> Hello Viktor, the change looks fine to me. The copyright year on the file will need an update before integrating.

@jaikiran Done!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19682#issuecomment-2165292052

From vklang at openjdk.org  Thu Jun 13 10:51:41 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 13 Jun 2024 10:51:41 GMT
Subject: RFR: 8334162: Gatherer.defaultCombiner has an erronous @see-link
 [v2]
In-Reply-To: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
References: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
Message-ID: <_jq5n022dbhqecLweBqFGp61_nB_DAU15Q9s9QAhR1I=.fc753267-9b1c-4a0b-9498-732ce84e00d4@github.com>

> Erronous Javadoc reference addressed. This should be backported to 23.

Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:

 - Tweaking the copyright year to reflect initial year AND current
 - Updating copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19682/files
  - new: https://git.openjdk.org/jdk/pull/19682/files/0218c212..fbfdfcba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19682&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19682&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19682/head:pull/19682

PR: https://git.openjdk.org/jdk/pull/19682

From viktor.klang at oracle.com  Thu Jun 13 10:52:03 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 13 Jun 2024 10:52:03 +0000
Subject: [External] : Gatherer and primitive specialization
In-Reply-To: <1416122669.48988404.1718266598860.JavaMail.zimbra@univ-eiffel.fr>
References: <1416122669.48988404.1718266598860.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB577437C15F63263BD414BA2CFFC12@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi R?mi,

Given that Collector has not been specialized since it was introduced, we opted to not specialize Gatherer eagerly as Valhalla Value Classes may also move the needle a bit regarding the need for specialization in general.

It was also not clear how far to take such specialization?since Gatherers have both input types and output types, should they be specialized in two axes or only one?

It also has implications on composition of Gatherers.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Remi Forax <forax at univ-mlv.fr>
Sent: Thursday, 13 June 2024 10:16
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Cc: Viktor Klang <viktor.klang at oracle.com>
Subject: [External] : Gatherer and primitive specialization

Hello,
the Gatherer API do not provide primitive specialization while intermediate methods like map(), flatMap() or mapMulti() do.

Unlike collectors where it is okay to not be specialized because most collectors mutate a collection that is not specialized too,
gatherers can process/transform values so having boxing in the middle of those kind of computations is a performance pothole.

I think there is a trick that can be used, we do not need to specialize all the functions of the Gatherer API but only the integrator.
All other functions are called a few time when a stream is processed so they may not need specialization, only the integrator is called a lot.

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/0ebbf9fa/attachment.htm>

From jpai at openjdk.org  Thu Jun 13 10:51:41 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 10:51:41 GMT
Subject: RFR: 8334162: Gatherer.defaultCombiner has an erronous @see-link
 [v2]
In-Reply-To: <_jq5n022dbhqecLweBqFGp61_nB_DAU15Q9s9QAhR1I=.fc753267-9b1c-4a0b-9498-732ce84e00d4@github.com>
References: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
 <_jq5n022dbhqecLweBqFGp61_nB_DAU15Q9s9QAhR1I=.fc753267-9b1c-4a0b-9498-732ce84e00d4@github.com>
Message-ID: <kJ5t9JEvm5iSZKOh8f8omqd6ItxrZBuT_8LHqzNp_J0=.ae5728de-f470-4d9e-96e8-7a218cf6ea1f@github.com>

On Thu, 13 Jun 2024 10:48:15 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Erronous Javadoc reference addressed. This should be backported to 23.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tweaking the copyright year to reflect initial year AND current
>  - Updating copyright year

The copyright year update to `2023, 2024` looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19682#pullrequestreview-2115439115

From duke at openjdk.org  Thu Jun 13 11:53:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 13 Jun 2024 11:53:14 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v8]
In-Reply-To: <JiQEOXo6zrzVGIhJBbrYVJY4Kl5OOo2T-E2LUYVkUBU=.607a0258-52de-4f9f-9b2f-41d1542c7c26@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <JiQEOXo6zrzVGIhJBbrYVJY4Kl5OOo2T-E2LUYVkUBU=.607a0258-52de-4f9f-9b2f-41d1542c7c26@github.com>
Message-ID: <RTCK2mqLBvzsEP2cRESgPeNzaHWrOOsSPuoWi9A-4Fo=.2ac2ab25-ce5c-4ec2-a9ce-7f5e9e46a6d4@github.com>

On Thu, 13 Jun 2024 02:06:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename benchmark
>  - code format & use long address

I also found that the `StringBuilders.appendWithBool8Latin1` case has performance regression on Intel? Xeon? Emerald Rapids and AMD EPYCTM Genoa.

I haven't found the reason yet

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2165434407

From kevinw at openjdk.org  Thu Jun 13 13:07:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 13:07:38 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v8]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <7RTa-HMjPLmHbLnrBLjdk4xNg-xc5fvJpQ7o2EceSbs=.b5b59386-71f7-414b-a40d-37e1ba7141fc@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Exception handling per Daniel comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/32f52c52..1ad97750

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=06-07

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Thu Jun 13 13:07:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 13:07:38 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v6]
In-Reply-To: <nXxazFJyr4lQazQITKV2BQI0A8mG2AJrpGtZQPF2_QQ=.5a5ec88c-6063-46d1-b067-cba2d45199b9@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
 <nXxazFJyr4lQazQITKV2BQI0A8mG2AJrpGtZQPF2_QQ=.5a5ec88c-6063-46d1-b067-cba2d45199b9@github.com>
Message-ID: <sRtC0SCJDl4SQEqfnRXzZNxS_tSMS-Eke8kPAguhvlc=.a3243221-0aeb-496f-a5e7-e8a6890bbac9@github.com>

On Wed, 12 Jun 2024 16:41:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Undo test policy updates
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1445:
> 
>> 1443:             } else {
>> 1444:                 throw new PrivilegedActionException(e);
>> 1445:             }
> 
> I assume there no chance that `Exception e` may already be a `PrivilegedActionException` here. You coud avoid casts by using instanceof patterns.
> 
> Suggestion:
> 
>             if (e instanceof RuntimeException rte) {
>                 throw  rte;
>             } else {
>                 throw new PrivilegedActionException(e);
>             }

ok yes will do that.  SecurityException was another carryover from before simplifying the updated calls, think it's no longer needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1638181708

From clanger at openjdk.org  Thu Jun 13 13:17:24 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 13:17:24 GMT
Subject: RFR: 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails:
 "reported cputime less than expected"
In-Reply-To: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>
References: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>
Message-ID: <jXXIO47HiTc7W6vED2q0Z9LkYmDHrod_jXA6zPTSj_U=.9eaac1aa-fb91-4cc0-8bac-609f10264cc3@github.com>

On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> It seems the error is gone meanwhile. So we can reenable the test.

Trivial fix of test listing, so

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19691#issuecomment-2165639694

From clanger at openjdk.org  Thu Jun 13 13:17:24 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Jun 2024 13:17:24 GMT
Subject: Integrated: 8211847: [aix] java/lang/ProcessHandle/InfoTest.java
 fails: "reported cputime less than expected"
In-Reply-To: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>
References: <BABf9Xzms8ah0dXgcUdhdBySFV0zx99CA5RuqslhlVY=.ca4de39d-41c0-4843-8698-2603bf637c06@github.com>
Message-ID: <yGg1Tk9uBwG3VtQWjrsJRl7HY7OnUNXC69EDOAjwm2s=.fbf4cf10-a425-4677-ae2d-986f5a42a012@github.com>

On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> It seems the error is gone meanwhile. So we can reenable the test.

This pull request has now been integrated.

Changeset: f5213671
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5213671f7b636b32bb93c78e43696a61cd69bae
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported cputime less than expected"

Reviewed-by: stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/19691

From david.lloyd at redhat.com  Thu Jun 13 13:22:43 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 13 Jun 2024 08:22:43 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
 <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
 <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
Message-ID: <CANghgrRy0t27+Pwk-TZW3Pji-zOR7FLoqPBjcHZ+QBS5T3dK7A@mail.gmail.com>

On Wed, Jun 12, 2024 at 9:23?AM David Lloyd <david.lloyd at redhat.com> wrote:

>
>
> On Tue, Jun 11, 2024 at 1:08?PM David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>>
>>
>> On Tue, Jun 11, 2024 at 12:57?PM Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>>>
>>>
>>> On 11/06/2024 18:19, David Lloyd wrote:
>>>
>>> :
>>>
>>> I thought that might be where Alan was headed with this. I would support
>>> this solution; it would solve the problem for conformant serialization
>>> libraries. If a class has a `readObject`/etc. then we use it - we wouldn't
>>> care if it was "natural" or generated. This also gives us the option to
>>> allow the user to use `opens` selectively to opt-in to special
>>> optimizations, without a major penalty if they do not.
>>>
>>> Is there already someone assigned for this task
>>>
>>>
>>> Not to my knowledge so you have cycles to prototype and have these
>>> methods return a MH that work like a "default" readObject/writeObject then
>>> it would help the discussion.
>>>
>>
>> I think I can come up with *at least* a prototype in the next week or
>> two. I have one concern though. The `readObject` method, when defined by
>> users, must by specification do one of two things before it may read values
>> from the stream:
>>
>> * Call `OIS.defaultReadObject()`
>> * Call `OIS.readFields()`
>>
>> In the latter case, we don't have a problem, but if the user class calls
>> `defaultReadObject` then we're back in the boat of having to reflectively
>> set the fields of the class. We could possibly solve this by creating a
>> *new* accessor which creates a parallel version of the method which
>> *always* sets fields reflectively, even if a `readObject` already exists on
>> the class. I'm not sure if there is a better solution. There is a similar
>> problem on the write side, however this involves reading fields rather than
>> writing them (obviously).
>>
>
> I have a *very* rough prototype up [1]. It adds two new accessor methods
> to `ReflectionFactory`: `defaultReadObjectForSerialization` and
> `defaultWriteObjectForSerialization`. It was easier than expected, due
> largely to the classfile API, which is really nice.
>
> These methods create an artificial `readObject`/`writeObject` method in a
> hidden+nestmate class connected to the original class, which uses the
> stream's `GetField`/`PutField` to access the stream data and normal field
> operations to access the class fields. For usage, these methods can be used
> when `read|writeObjectForSerialization` return `null`, *or* when
> `defaultRead|WriteObject` is used.
>
> There is additionally a constant bootstrap temporarily located on
> `ReflectionFactory` to acquire a `MethodHandle` that can act as a setter
> for final fields (there is no JVM-breaking magic here; it uses regular
> public APIs to achieve this). However this constant bootstrap probably
> needs to be put somewhere in `java.base` to actually be useful (my test
> program needed `--add-reads` and `-add-opens` to make it work because
> `ReflectionFactory` is located in `jdk.unsupported`). I was hesitant to put
> it into `ConstantBootstraps` but maybe that's really the best place for it.
>
> The outstanding problems are:
> - Need to determine if this is a valid/approved approach
> - Move the field-setter constant bootstrap method to `java.base` somewhere
> (`j.l.i.ConstantBootstraps`?)
> - Field setter constant bootstrap does not have adequate access checking;
> couldn't figure out a good way to do it
> - Field setter constant bootstrap also works for non-final fields, though
> this is not used by the prototype
> - Caching - yea or nay? For now it's left up to the caller (I think this
> is consistent with existing methods but not sure)
> - There are some `ClassDesc`, `MethodHandleDesc`, and `MethodTypeDesc`
> that should be in constant fields
> - Probably some normal code improvements & cleanups
> - Documentation
> - Real tests
> - Probably a good idea to review the spec again to make sure no edge case
> was missed
>

I've updated with a few commits today which solve (I think) the access
control issue, moves constant descriptors to constants in a holder class,
moves the bootstrap to `ConstantBootstraps`, just says "no" to caching, and
cleans up a few other minor issues. I guess I'll go ahead and update
JDK-8333796 to reference this new strategy and start preparing to put up a
PR, unless someone raises an objection to the final approach taken here.

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/6bdbd465/attachment.htm>

From Alan.Bateman at oracle.com  Thu Jun 13 13:39:18 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 Jun 2024 14:39:18 +0100
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
 <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
 <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
Message-ID: <2569c451-b686-427e-8a29-80c3239d9831@oracle.com>

On 12/06/2024 15:23, David Lloyd wrote:
>
> :
> .
>
> I have a *very* rough prototype up [1]. It adds two new accessor 
> methods to `ReflectionFactory`: `defaultReadObjectForSerialization` 
> and `defaultWriteObjectForSerialization`. It was easier than expected, 
> due largely to the classfile API, which is really nice.
>
> These methods create an artificial `readObject`/`writeObject` method 
> in a hidden+nestmate class connected to the original class, which uses 
> the stream's `GetField`/`PutField` to access the stream data and 
> normal field operations to access the class fields. For usage, these 
> methods can be used when `read|writeObjectForSerialization` return 
> `null`, *or* when `defaultRead|WriteObject` is used.
>
Good to hear you've got a prototype to discuss. I don't think I can look 
at what you have in your own repo but I do have a question. Do the 
defaultXXX methods return a method handle or do they fail/null when 
there are read/writeObject methods? Asking if they will bypass these 
methods.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/c195da93/attachment-0001.htm>

From kevinw at openjdk.org  Thu Jun 13 13:39:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 13:39:25 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v9]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <YwvOPk8JDr_75MVpgAdFttbjdllt73WQCwBo8h_uSGM=.83dbf3f3-e6f5-4a48-9627-808477368fa4@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  ServerNotifForwarder getSubject update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/1ad97750..f70047a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=07-08

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From david.lloyd at redhat.com  Thu Jun 13 13:48:55 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 13 Jun 2024 08:48:55 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <2569c451-b686-427e-8a29-80c3239d9831@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
 <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
 <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
 <2569c451-b686-427e-8a29-80c3239d9831@oracle.com>
Message-ID: <CANghgrQf3CZPvMQvVboFiKHu7_vLf43OXiXgcDScFxAXYH4K7w@mail.gmail.com>

On Thu, Jun 13, 2024 at 8:39?AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 12/06/2024 15:23, David Lloyd wrote:
>
>
> :
> .
>
> I have a *very* rough prototype up [1]. It adds two new accessor methods
> to `ReflectionFactory`: `defaultReadObjectForSerialization` and
> `defaultWriteObjectForSerialization`. It was easier than expected, due
> largely to the classfile API, which is really nice.
>
> These methods create an artificial `readObject`/`writeObject` method in a
> hidden+nestmate class connected to the original class, which uses the
> stream's `GetField`/`PutField` to access the stream data and normal field
> operations to access the class fields. For usage, these methods can be used
> when `read|writeObjectForSerialization` return `null`, *or* when
> `defaultRead|WriteObject` is used.
>
> Good to hear you've got a prototype to discuss. I don't think I can look
> at what you have in your own repo but I do have a question. Do the
> defaultXXX methods return a method handle or do they fail/null when there
> are read/writeObject methods? Asking if they will bypass these methods.
>

They will still return a method handle in this case. The method handle
doesn't *bypass* the provided methods - per se - for example if the fields
in question are `transient` then these methods would not access them. But,
I could not think of any other way to deal with the
`defaultReadObject`/`defaultWriteObject` situation than to allow
serialization libraries to do this (where the OIS/OOS implementation is
being asked by the serialized class to read or write the field values
from/to the serialization stream). Maybe you have another idea?

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/2c085aa2/attachment.htm>

From Alan.Bateman at oracle.com  Thu Jun 13 14:00:38 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 Jun 2024 15:00:38 +0100
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrRy0t27+Pwk-TZW3Pji-zOR7FLoqPBjcHZ+QBS5T3dK7A@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
 <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
 <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
 <CANghgrRy0t27+Pwk-TZW3Pji-zOR7FLoqPBjcHZ+QBS5T3dK7A@mail.gmail.com>
Message-ID: <06f6ca27-85f2-4b8b-a8fc-92b1eaa998c9@oracle.com>

On 13/06/2024 14:22, David Lloyd wrote:
> :
>
> I've updated with a few commits today which solve (I think) the access 
> control issue, moves constant descriptors to constants in a holder 
> class, moves the bootstrap to `ConstantBootstraps`, just says "no" to 
> caching, and cleans up a few other minor issues. I guess I'll go ahead 
> and update JDK-8333796 to reference this new strategy and start 
> preparing to put up a PR, unless someone raises an objection to the 
> final approach taken here.
>
Just to set expectations on a possible PR, this is not a change that can 
be rushed in. It's controversial to extend this backdoor and may make it 
hard for this backdoor to be removed in the future.? I think we will 
also need to get the security/vulnerability folks to go over this.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/ec02a1c6/attachment-0001.htm>

From liach at openjdk.org  Thu Jun 13 14:02:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Jun 2024 14:02:16 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v4]
In-Reply-To: <xjoHRL7ltpC3Fcm08hD3Z6BP1R86KQ-JvcujsIP0-pQ=.5c1bdbd1-6c92-4535-85d8-8aceb905c53c@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <7btOfU-ojHjUgLo03OmBP27LDjtIbKiwEJ4IAYhhZXk=.054cb7a9-8685-4a89-b84c-e8b3a122db96@github.com>
 <xjoHRL7ltpC3Fcm08hD3Z6BP1R86KQ-JvcujsIP0-pQ=.5c1bdbd1-6c92-4535-85d8-8aceb905c53c@github.com>
Message-ID: <oA9v-5v9fKfPNyugtomVCThvUxvWQ9qj0FgaccrfgaU=.2194d0ea-4b35-4ff7-85e3-5eaa9b0c1ffc@github.com>

On Thu, 13 Jun 2024 08:27:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More rename and code style cleanup
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 676:
> 
>> 674:          * @param method          The method for which to create a proxy
>> 675:          */
>> 676:         private ProxyMethod(Method method, String methodFieldName) {
> 
> Could we pass the `FieldRefEntry` directly? I don't see when we'd create a `ProxyMethod` without later calling `methodField()`. I think this would also remove the need to make `ProxyMethod` non-static.

Good suggestion. However, ProxyMethod will stay non-static, for the field ref is still bound to class Constant Pool and bytecode generation reuses many non-static CP items from ProxyGenerator. Will update the patch in gist as I push too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19615#discussion_r1638272389

From liach at openjdk.org  Thu Jun 13 14:11:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Jun 2024 14:11:49 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v4]
In-Reply-To: <oA9v-5v9fKfPNyugtomVCThvUxvWQ9qj0FgaccrfgaU=.2194d0ea-4b35-4ff7-85e3-5eaa9b0c1ffc@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <7btOfU-ojHjUgLo03OmBP27LDjtIbKiwEJ4IAYhhZXk=.054cb7a9-8685-4a89-b84c-e8b3a122db96@github.com>
 <xjoHRL7ltpC3Fcm08hD3Z6BP1R86KQ-JvcujsIP0-pQ=.5c1bdbd1-6c92-4535-85d8-8aceb905c53c@github.com>
 <oA9v-5v9fKfPNyugtomVCThvUxvWQ9qj0FgaccrfgaU=.2194d0ea-4b35-4ff7-85e3-5eaa9b0c1ffc@github.com>
Message-ID: <_H_-0SGJfdp-0EfBjhiNlyL8oXOprndXgaLi1qSxr10=.f7c0ea57-d5f0-44db-88d5-71a645759cba@github.com>

On Thu, 13 Jun 2024 13:59:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 676:
>> 
>>> 674:          * @param method          The method for which to create a proxy
>>> 675:          */
>>> 676:         private ProxyMethod(Method method, String methodFieldName) {
>> 
>> Could we pass the `FieldRefEntry` directly? I don't see when we'd create a `ProxyMethod` without later calling `methodField()`. I think this would also remove the need to make `ProxyMethod` non-static.
>
> Good suggestion. However, ProxyMethod will stay non-static, for the field ref is still bound to class Constant Pool and bytecode generation reuses many non-static CP items from ProxyGenerator. Will update the patch in gist as I push too.

The `methodField` reference is now created within the ProxyMethod constructor. The gist linked in the PR description has also been updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19615#discussion_r1638287881

From liach at openjdk.org  Thu Jun 13 14:11:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Jun 2024 14:11:48 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v5]
In-Reply-To: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
Message-ID: <9AW2LHJmnkUALw9OaT2lLPDri-hR6qw61_8bx_zdGlo=.672dc82f-8bb4-4105-9361-13b81f5ff545@github.com>

> Please review this patch that fixes a critical issue that breaks some Proxy usages.
> 
> Since the problematic patch from before cannot be backed out, this patch aims to emulate the old behavior before. A diff between before the problematic patch and this patch is available at https://gist.github.com/7565b2091008f561eb0ada019bc5e517, generated by running `git diff 326dbb1b139dd1ec1b8605339b91697cdf49da9a -- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java`.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  methodField can be initialized eagerly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19615/files
  - new: https://git.openjdk.org/jdk/pull/19615/files/a510b1f4..5668afc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19615&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19615&range=03-04

  Stats: 13 lines in 1 file changed: 2 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19615/head:pull/19615

PR: https://git.openjdk.org/jdk/pull/19615

From jpai at openjdk.org  Thu Jun 13 14:12:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 14:12:16 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v2]
In-Reply-To: <PZJaGrsZUTy1oCYZRdiXIijqI41RKLccrugdHeZvVp4=.a1f5526a-e57b-4404-8419-293bae9bb8cb@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <PZJaGrsZUTy1oCYZRdiXIijqI41RKLccrugdHeZvVp4=.a1f5526a-e57b-4404-8419-293bae9bb8cb@github.com>
Message-ID: <fdicvPQZTo6_QkZfHKBMgP2c4D0CdLvwDn2vqYZ8NYo=.885bccb4-f7f2-4c57-b359-fcb3ae969ee9@github.com>

On Wed, 12 Jun 2024 21:07:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   convert the tests to junit
>
> src/java.base/share/classes/java/util/zip/Deflater.java line 904:
> 
>> 902:     public void close() {
>> 903:         synchronized (zsRef) {
>> 904:             // check if already closed
> 
> Should we comment `// in case subclasses override the closed check in end()` instead? Otherwise the duplicate comments and checks are confusing.

Hello Chen, we want the close() to be idempotent irrespective of whether or not end() is overridden. That check in close() and the code comment on that line is to indicate that. If the comment is adding to confusion, I can remove it - I don't think it's a must to have it to understand the check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1638288513

From jpai at openjdk.org  Thu Jun 13 14:18:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 14:18:20 GMT
Subject: RFR: 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL
 macro in java launcher [v2]
In-Reply-To: <2ljA_wbHn-RLVyWR3VrIKme5JmvzdWnrCVEEtQVeok4=.d9486ad8-ca69-40ac-b25a-25a83ef1cb70@github.com>
References: <NoAAbQZLfZe9g2rEGOX1U1S2rR0QE1lIZ229VfOnNT8=.c1b88267-e23d-48c3-9047-edffd19b2559@github.com>
 <2ljA_wbHn-RLVyWR3VrIKme5JmvzdWnrCVEEtQVeok4=.d9486ad8-ca69-40ac-b25a-25a83ef1cb70@github.com>
Message-ID: <Tb1gGQ6YkNsb1mrZWG0jpLAjE7ayU0hkzGSu9V4bO0M=.1e9d8bf2-5e12-43ab-8ee1-781f410c4f25@github.com>

On Thu, 6 Jun 2024 13:28:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to remove the `CHECK_EXCEPTION_NULL_FAIL` macro from the `java` launcher code?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8333714. As noted in that JBS issue, in a recent PR discussion, it was suggested https://github.com/openjdk/jdk/pull/18786#issuecomment-2147452633 that this macro should be removed and the failure of a JNI specified operation (the ones for which this macro is being used) should be determined based on a `NULL` value returned from that function. The commit in this PR removes this macros and updates the call sites to do a `NULL` check.
>> 
>> Given the nature of this change, no new tests have been added. tier1, tier2 and tier3 testing passed successfully with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comments

Any reviews for this please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19576#issuecomment-2165803780

From david.lloyd at redhat.com  Thu Jun 13 14:35:12 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 13 Jun 2024 09:35:12 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <06f6ca27-85f2-4b8b-a8fc-92b1eaa998c9@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
 <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
 <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
 <CANghgrRy0t27+Pwk-TZW3Pji-zOR7FLoqPBjcHZ+QBS5T3dK7A@mail.gmail.com>
 <06f6ca27-85f2-4b8b-a8fc-92b1eaa998c9@oracle.com>
Message-ID: <CANghgrRGRTnab+sXyUfcCXX1OvvdM_s6r6WFTz_FX1wSdJuh9w@mail.gmail.com>

On Thu, Jun 13, 2024 at 9:01?AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 13/06/2024 14:22, David Lloyd wrote:
>
> :
>
> I've updated with a few commits today which solve (I think) the access
> control issue, moves constant descriptors to constants in a holder class,
> moves the bootstrap to `ConstantBootstraps`, just says "no" to caching, and
> cleans up a few other minor issues. I guess I'll go ahead and update
> JDK-8333796 to reference this new strategy and start preparing to put up a
> PR, unless someone raises an objection to the final approach taken here.
>
> Just to set expectations on a possible PR, this is not a change that can
> be rushed in. It's controversial to extend this backdoor and may make it
> hard for this backdoor to be removed in the future.  I think we will also
> need to get the security/vulnerability folks to go over this.
>

Of course. I've tried to design the change with due consideration to
security, but I recognize that this is a tricky area and there may be
tricky aspects to it as a consequence.

It might be helpful to think of it not as a backdoor, but as a somewhat
more obscure front door. :-) When a user declares a class to be
`Serializable`, they are opting in to aspects of the serialization
specification that imply that their private fields are accessible beyond
the scope of the JLS. These accesses are not fully open-ended: they're
governed by the serialization spec which has some specific allowances and
restrictions. So, my intention is to allow no more than what the
specification allows.

That said, it might be desirable to extend a few extra protections beyond
what is already specified and what is being proposed. I'm certainly open to
all of that kind of discussion, and discussion of other alternative
solutions.

The pull request number is 19702 [1]. It is a draft for now to enable
further, more specific discussion.

[1] https://github.com/openjdk/jdk/pull/19702

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/0f0ae02c/attachment.htm>

From forax at univ-mlv.fr  Thu Jun 13 15:20:27 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 13 Jun 2024 17:20:27 +0200 (CEST)
Subject: [External] : Gatherer and primitive specialization
In-Reply-To: <MW4PR10MB577437C15F63263BD414BA2CFFC12@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <1416122669.48988404.1718266598860.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB577437C15F63263BD414BA2CFFC12@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1124789304.49419120.1718292027082.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Sent: Thursday, June 13, 2024 12:52:03 PM
> Subject: Re: [External] : Gatherer and primitive specialization

> Hi R?mi,

> Given that Collector has not been specialized since it was introduced, we opted
> to not specialize Gatherer eagerly as Valhalla Value Classes may also move the
> needle a bit regarding the need for specialization in general.

As i said previously, most collectors uses collections so until collections are specialized, specializing the collector API is not that useful. 
A gatherer unlike a Collector can just transform values, thus specializing it is more useful. 

For Valhalla, we are at year 10 and value classes are not there yet, specialization of generics is in my opinion 10 years ahead. 
I'm not complaining, if we had rush value classes, everybody will have regret it, but those things take a lot of time. 

> It was also not clear how far to take such specialization?since Gatherers have
> both input types and output types, should they be specialized in two axes or
> only one?

If it's like mapMulti, it's the two axis, you have 4 x 4 possible types (Object,int, long, double). 
And because the integrator uses an interface for being greedy or not, it's 16 times 2. 

> It also has implications on composition of Gatherers.

If we have something like a Gatherer.ofInt() (like with Iterator or Spliterator), we need 4 andThen() (or one andThen with a pattern matching with 4 cases) so it has implications but it's not a road block. 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: Remi Forax <forax at univ-mlv.fr>
> Sent: Thursday, 13 June 2024 10:16
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Cc: Viktor Klang <viktor.klang at oracle.com>
> Subject: [External] : Gatherer and primitive specialization
> Hello,
> the Gatherer API do not provide primitive specialization while intermediate
> methods like map(), flatMap() or mapMulti() do.

> Unlike collectors where it is okay to not be specialized because most collectors
> mutate a collection that is not specialized too,
> gatherers can process/transform values so having boxing in the middle of those
> kind of computations is a performance pothole.

> I think there is a trick that can be used, we do not need to specialize all the
> functions of the Gatherer API but only the integrator.
> All other functions are called a few time when a stream is processed so they may
> not need specialization, only the integrator is called a lot.

> regards,
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/c8b51cf0/attachment-0001.htm>

From alanb at openjdk.org  Thu Jun 13 15:56:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Jun 2024 15:56:12 GMT
Subject: RFR: 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL
 macro in java launcher [v2]
In-Reply-To: <2ljA_wbHn-RLVyWR3VrIKme5JmvzdWnrCVEEtQVeok4=.d9486ad8-ca69-40ac-b25a-25a83ef1cb70@github.com>
References: <NoAAbQZLfZe9g2rEGOX1U1S2rR0QE1lIZ229VfOnNT8=.c1b88267-e23d-48c3-9047-edffd19b2559@github.com>
 <2ljA_wbHn-RLVyWR3VrIKme5JmvzdWnrCVEEtQVeok4=.d9486ad8-ca69-40ac-b25a-25a83ef1cb70@github.com>
Message-ID: <0cNWJEkyKnXQYRFTFHx4ENU7OAap0eb5-8H_G1XL1ZA=.fca2fcea-e101-4729-beb7-95e7b9d7d7c4@github.com>

On Thu, 6 Jun 2024 13:28:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to remove the `CHECK_EXCEPTION_NULL_FAIL` macro from the `java` launcher code?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8333714. As noted in that JBS issue, in a recent PR discussion, it was suggested https://github.com/openjdk/jdk/pull/18786#issuecomment-2147452633 that this macro should be removed and the failure of a JNI specified operation (the ones for which this macro is being used) should be determined based on a `NULL` value returned from that function. The commit in this PR removes this macros and updates the call sites to do a `NULL` check.
>> 
>> Given the nature of this change, no new tests have been added. tier1, tier2 and tier3 testing passed successfully with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comments

This looks okay, it makes these invokeXXX functions easier to read and avoids any confusion on return NULL vs. pending exception.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19576#pullrequestreview-2116198827

From paul.sandoz at oracle.com  Thu Jun 13 16:03:18 2024
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2024 16:03:18 +0000
Subject: [External] : Gatherer and primitive specialization
In-Reply-To: <1124789304.49419120.1718292027082.JavaMail.zimbra@univ-eiffel.fr>
References: <1416122669.48988404.1718266598860.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB577437C15F63263BD414BA2CFFC12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1124789304.49419120.1718292027082.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <61B6F5B9-5425-4DC2-8DA9-CACE59DD0B77@oracle.com>



> On Jun 13, 2024, at 8:20 AM, forax at univ-mlv.fr wrote:
> 
> 
> 
> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Thursday, June 13, 2024 12:52:03 PM
> Subject: Re: [External] : Gatherer and primitive specialization
> Hi R?mi,
> 
> Given that Collector has not been specialized since it was introduced, we opted to not specialize Gatherer eagerly as Valhalla Value Classes may also move the needle a bit regarding the need for specialization in general.
> 
> As i said previously, most collectors uses collections so until collections are specialized, specializing the collector API is not that useful.
> A gatherer unlike a Collector can just transform values, thus specializing it is more useful.
> 
> For Valhalla, we are at year 10 and value classes are not there yet, specialization of generics is in my opinion 10 years ahead.
> I'm not complaining, if we had rush value classes, everybody will have regret it, but those things take a lot of time.
> 

Also we may benefit from stack flattening with the boxed primitives. I would hold off on any such explicit specialization (the pressure on Streams was too great, less so for Gatherers IMO). Gatherers may provide a useful way to explore the effectiveness of using primitive boxes that don?t have identity.

Paul.   

From liach at openjdk.org  Thu Jun 13 16:05:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Jun 2024 16:05:13 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v2]
In-Reply-To: <fdicvPQZTo6_QkZfHKBMgP2c4D0CdLvwDn2vqYZ8NYo=.885bccb4-f7f2-4c57-b359-fcb3ae969ee9@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <PZJaGrsZUTy1oCYZRdiXIijqI41RKLccrugdHeZvVp4=.a1f5526a-e57b-4404-8419-293bae9bb8cb@github.com>
 <fdicvPQZTo6_QkZfHKBMgP2c4D0CdLvwDn2vqYZ8NYo=.885bccb4-f7f2-4c57-b359-fcb3ae969ee9@github.com>
Message-ID: <4ZAtxGml8V5dVJ2osQQkEzDQsAGwcZgl7AJpG9e8gFo=.dfbb2286-5037-45d2-bef9-3098c0f9695e@github.com>

On Thu, 13 Jun 2024 14:09:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/Deflater.java line 904:
>> 
>>> 902:     public void close() {
>>> 903:         synchronized (zsRef) {
>>> 904:             // check if already closed
>> 
>> Should we comment `// in case subclasses override the closed check in end()` instead? Otherwise the duplicate comments and checks are confusing.
>
> Hello Chen, we want the close() to be idempotent irrespective of whether or not end() is overridden. That check in close() and the code comment on that line is to indicate that. If the comment is adding to confusion, I can remove it - I don't think it's a must to have it to understand the check.

I mean, we have updated the default implementation of end() to be idempotent. It now just appears confusing to readers that close() **seems to** perform redundant checks for idempotence until they realize subclasses can override end() to make it non-idempotent.

My suggestion is that our comment should say why we have this check here even though there's already an identical check in end().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1638471725

From vklang at openjdk.org  Thu Jun 13 16:33:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 13 Jun 2024 16:33:17 GMT
Subject: Integrated: 8334162: Gatherer.defaultCombiner has an erronous
 @see-link
In-Reply-To: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
References: <zFQlSeDwbvW4yAgD929t7M3p6XQs3zMlhxUhPvyHM38=.1e04a5af-b453-4d55-97ef-baad3d8c39fa@github.com>
Message-ID: <iS-TXGWWmfPusrZbTRn_B9IZwmBqW-T-TzZOO18VW3Q=.41541120-9786-4059-87f0-5613ff53e21b@github.com>

On Wed, 12 Jun 2024 20:58:28 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Erronous Javadoc reference addressed. This should be backported to 23.

This pull request has now been integrated.

Changeset: cff048c7
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cff048c7354dd947a3946d262f4752a55b7e2a43
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8334162: Gatherer.defaultCombiner has an erronous @see-link

Reviewed-by: jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19682

From vklang at openjdk.org  Thu Jun 13 16:52:20 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 13 Jun 2024 16:52:20 GMT
Subject: [jdk23] RFR: 8334162: Gatherer.defaultCombiner has an erronous
 @see-link
Message-ID: <ZDOOT-52YHEDBhc_jSsq1uUq42k5WBWORiNZdO1UtN8=.89d1d905-66f5-4102-818d-1b321c31e016@github.com>

Making sure that the Javadoc is correct for Gatherer

-------------

Commit messages:
 - Backport cff048c7354dd947a3946d262f4752a55b7e2a43

Changes: https://git.openjdk.org/jdk/pull/19704/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19704&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334162
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19704.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19704/head:pull/19704

PR: https://git.openjdk.org/jdk/pull/19704

From iris at openjdk.org  Thu Jun 13 16:56:12 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 13 Jun 2024 16:56:12 GMT
Subject: [jdk23] RFR: 8334162: Gatherer.defaultCombiner has an erronous
 @see-link
In-Reply-To: <ZDOOT-52YHEDBhc_jSsq1uUq42k5WBWORiNZdO1UtN8=.89d1d905-66f5-4102-818d-1b321c31e016@github.com>
References: <ZDOOT-52YHEDBhc_jSsq1uUq42k5WBWORiNZdO1UtN8=.89d1d905-66f5-4102-818d-1b321c31e016@github.com>
Message-ID: <c3k5ZfQHK069GrbB6ijbzE8idKj0wF17jR9pTxFV_9I=.5ec11eb0-dad4-46cc-bb62-0caec01516f6@github.com>

On Thu, 13 Jun 2024 16:47:43 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Making sure that the Javadoc is correct for Gatherer

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19704#pullrequestreview-2116350395

From jpai at openjdk.org  Thu Jun 13 17:00:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Jun 2024 17:00:14 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v2]
In-Reply-To: <4ZAtxGml8V5dVJ2osQQkEzDQsAGwcZgl7AJpG9e8gFo=.dfbb2286-5037-45d2-bef9-3098c0f9695e@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <PZJaGrsZUTy1oCYZRdiXIijqI41RKLccrugdHeZvVp4=.a1f5526a-e57b-4404-8419-293bae9bb8cb@github.com>
 <fdicvPQZTo6_QkZfHKBMgP2c4D0CdLvwDn2vqYZ8NYo=.885bccb4-f7f2-4c57-b359-fcb3ae969ee9@github.com>
 <4ZAtxGml8V5dVJ2osQQkEzDQsAGwcZgl7AJpG9e8gFo=.dfbb2286-5037-45d2-bef9-3098c0f9695e@github.com>
Message-ID: <F6ytw67xkxXd8dNNGpKFa9tHOtFY3f9DrP3JTF5FM-g=.094b2593-3de6-4744-b342-3d3826b21329@github.com>

On Thu, 13 Jun 2024 16:02:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> My suggestion is that our comment should say why we have this check here even though there's already an identical check in end().

I now see what you mean. I'll update this appropriately tomorrow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1638559184

From vklang at openjdk.org  Thu Jun 13 17:01:16 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 13 Jun 2024 17:01:16 GMT
Subject: [jdk23] Integrated: 8334162: Gatherer.defaultCombiner has an erronous
 @see-link
In-Reply-To: <ZDOOT-52YHEDBhc_jSsq1uUq42k5WBWORiNZdO1UtN8=.89d1d905-66f5-4102-818d-1b321c31e016@github.com>
References: <ZDOOT-52YHEDBhc_jSsq1uUq42k5WBWORiNZdO1UtN8=.89d1d905-66f5-4102-818d-1b321c31e016@github.com>
Message-ID: <hy0FmmhCYvw2Tq6eGdelgXgnfrhsKexxTPziXTMgNQw=.906e6298-8c1e-4140-80c3-269b83994eec@github.com>

On Thu, 13 Jun 2024 16:47:43 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Making sure that the Javadoc is correct for Gatherer

This pull request has now been integrated.

Changeset: 5230786a
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5230786a0d2185d8db3f7a3843f3ae33f94f7215
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8334162: Gatherer.defaultCombiner has an erronous @see-link

Reviewed-by: iris
Backport-of: cff048c7354dd947a3946d262f4752a55b7e2a43

-------------

PR: https://git.openjdk.org/jdk/pull/19704

From liach at openjdk.org  Thu Jun 13 17:55:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Jun 2024 17:55:38 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position 0x2
 for location CLASS
Message-ID: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>

Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.

In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.

-------------

Commit messages:
 - 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS

Changes: https://git.openjdk.org/jdk/pull/19708/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19708&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333748
  Stats: 156 lines in 3 files changed: 104 ins; 21 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/19708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19708/head:pull/19708

PR: https://git.openjdk.org/jdk/pull/19708

From duke at openjdk.org  Thu Jun 13 18:13:25 2024
From: duke at openjdk.org (Vanitha B P)
Date: Thu, 13 Jun 2024 18:13:25 GMT
Subject: RFR: 8325525: Create jtreg test case for JDK-8325203
Message-ID: <JIasinDL2M84-haLaLLxS9CpuyMHMAome0X3ZLUWARQ=.d01fdb93-d307-476d-81aa-00185088245a@github.com>

Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue.

The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated.

-------------

Commit messages:
 - Whitespace Fixes 2
 - Fixed whitespaces
 - Fixed whitespaces for 8325525:Create jtreg test case for JDK-8325203
 - 8325525: Create jtreg test case for JDK-8325203
 - 8325525: Create jtreg test case for JDK-8325203

Changes: https://git.openjdk.org/jdk/pull/19536/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325525
  Stats: 241 lines in 2 files changed: 241 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19536.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19536/head:pull/19536

PR: https://git.openjdk.org/jdk/pull/19536

From naoto at openjdk.org  Thu Jun 13 18:52:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Jun 2024 18:52:13 GMT
Subject: RFR: 8333755: NumberFormat integer only parsing breaks when format
 has suffix [v3]
In-Reply-To: <Voq1u-9oSRB7-FoTMp2iuqjxVtciVqjItjnfzkXqBPY=.80919b1e-df7f-45d8-8f1a-aa0f199050ac@github.com>
References: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
 <Voq1u-9oSRB7-FoTMp2iuqjxVtciVqjItjnfzkXqBPY=.80919b1e-df7f-45d8-8f1a-aa0f199050ac@github.com>
Message-ID: <Sy5INfJhRqaZWil1gnITO6mFlot6cyavtObkFvfpSfU=.773f3ca8-d15e-4fb1-95fd-f3dccf6e8b6a@github.com>

On Wed, 12 Jun 2024 21:58:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8333920) which corrects a bug where NumberFormat cannot successfully parse values in integer only mode, when the format expects a suffix.
>> 
>> For example,
>> 
>> // a format that expects a currency suffix
>> var fmt = NumberFormat.getCurrencyInstance(Locale.FRANCE);
>> fmt.setParseIntegerOnly(true);
>> failFmt.parse("5,00 ?"); // throws ParseException when you would have expected 5 returned
>> 
>> 
>> When parsing in integer only mode, instead of breaking upon a decimal symbol encounter, we should store the index but continue to fully parse so that we can verify the entire string and increment our position to search for and match the suffix. Upon a successful suffix match, we can then set `ParsePosition.index` back to the stored decimal index.
>> 
>> It should be noted that CompactNumberFormat did previously have code that would traverse the rest of the String, to allow matching of the suffix. The difference is that NumberFormat returns the index upon decimal symbol encounter, while CompactNumberFormat was implemented to return the index reflected by the entire string traversal. Such differences cannot be standardized due to behavioral compatibility concerns.
>> 
>> Thus while parsing in integer only, CNF sets index to the `Position.fullPos()`, while DF sets index to the `Position.intPos()`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19664#pullrequestreview-2116669878

From jlu at openjdk.org  Thu Jun 13 19:32:15 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jun 2024 19:32:15 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
Message-ID: <e0kp5SiQXQM3opXP1RtEayfyfHVF5gO6SezjeVcMuZA=.4de0add9-95bf-44da-b9ca-314dc81d59a2@github.com>

On Wed, 5 Jun 2024 03:59:24 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

After an initial pass, at first glance I don't see compatibility concerns since there no behavioral changes to the public/protected members of the Format/Format.FieldDelegate classes/subclasses and we have left the abstract methods untouched. This change allows internally for StringBuilder to be utilized via the proxy and the newly added package-private methods added to NumberFormat.

Since we are already in the scope of Format, I think something to consider is whether we might want to include the other possible classes, such as DateFormat.format(Date) in this change as well. Although it might get quite messy if corresponding changes are made to all Format subclasses where possible; just like this change, I'm sure it would kick off a chain of buffer to proxy changes everywhere.

I'm sure there is more discussion to be had in general.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 885:

> 883:     }
> 884: 
> 885:     private StringBuilderBufferProxy format(BigInteger number, StringBuilderBufferProxy result,

While the DecimalFormat and CompactNumberFormat BigInteger and BigDecimal `format` methods will always return a StringBuffer, we must change the method signatures to use the proxy, otherwise we would need to define alternate methods all the way at the `Format.FieldDelegate` level. So I think this is a lesser of two evils.

src/java.base/share/classes/java/text/StringBuilderBufferProxy.java line 30:

> 28:  * Provide the least interfaces that support both:
> 29:  * NumberFormat#format((double|long), StringBuilder, FieldPosition)
> 30:  * and NumberFormat#format(double, StringBuffer, FieldPosition)

Shouldn't this be `NumberFormat#format((double|long), StringBuffer, FieldPosition)`?

src/java.base/share/classes/java/text/StringBuilderBufferProxy.java line 150:

> 148:     class StringBufferImpl implements StringBuilderBufferProxy {
> 149: 
> 150:         private StringBuffer sb;

Should this be `final`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2116341710
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1638667165
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1638686606
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1638540586

From liach at openjdk.org  Thu Jun 13 19:36:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Jun 2024 19:36:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <e0kp5SiQXQM3opXP1RtEayfyfHVF5gO6SezjeVcMuZA=.4de0add9-95bf-44da-b9ca-314dc81d59a2@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
 <e0kp5SiQXQM3opXP1RtEayfyfHVF5gO6SezjeVcMuZA=.4de0add9-95bf-44da-b9ca-314dc81d59a2@github.com>
Message-ID: <M2djYu3ZpocXPMnBkdIzcNtzR0PdJ4fP8O2nx4YujnE=.e1bfcaee-570f-448f-90a4-db2925f6672a@github.com>

On Thu, 13 Jun 2024 16:51:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/StringBuilderBufferProxy.java line 150:
> 
>> 148:     class StringBufferImpl implements StringBuilderBufferProxy {
>> 149: 
>> 150:         private StringBuffer sb;
> 
> Should this be `final`?

In fact, we should just make them sealed interfaces implemented by 2 records.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1638781424

From liach at openjdk.org  Thu Jun 13 19:43:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Jun 2024 19:43:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
Message-ID: <9n9ZOdzKHksCMCCA1ql1LEpyYYQH9thg0112PwgmXx4=.d58e5a15-2a14-4954-b161-5c9b02f5e556@github.com>

On Wed, 5 Jun 2024 03:59:24 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

src/java.base/share/classes/java/text/StringBuilderBufferProxy.java line 108:

> 106:     }
> 107: 
> 108:     class StringBuilderImpl implements StringBuilderBufferProxy {

Avoid adding nested classes to interfaces, which are public. These classes are publicly accessible under reflection, and we want to avoid more of such occurrences. See https://bugs.openjdk.org/browse/JDK-8308040?focusedId=14581402&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14581402

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1638789017

From naoto at openjdk.org  Thu Jun 13 19:43:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Jun 2024 19:43:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
Message-ID: <6kmKgt5QX3KBTmpN4R5D9-XWbiUkP7ieQF00DZc48Es=.5f0e517a-06e2-4392-984d-754d287b0ac5@github.com>

On Wed, 5 Jun 2024 03:59:24 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

I second Justin's suggestion here. The change should benefit every implementation in the JDK, not only NumberFormat. Also, I might suggest renaming the new class, as it is kind of long/redundant. How about using something as simple as "StringBuf"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2166636712

From valeriep at openjdk.org  Thu Jun 13 20:28:16 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 13 Jun 2024 20:28:16 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
Message-ID: <YINw_j9qbVQjElu5BRO10mo7oRHFB2xdNdXclxzV2I0=.9183cc29-ce1f-4d41-a5ae-c61f825b11e8@github.com>

On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clone(), accept review suggestions.

src/java.base/share/classes/sun/security/provider/SHA3.java line 73:

> 71:     // The following array is allocated to size WIDTH bytes, but we only
> 72:     // ever use the first blockSize bytes it (for bytes <-> long conversions)
> 73:     private byte[] byteState = new byte[WIDTH];

Since we are storing the state in longs now, this "byte <-> long" conversion can be made through a local variable, right? Is there a reason for having this `byteState` field with size WIDTH bytes?

src/java.base/share/classes/sun/security/provider/SHA3.java line 121:

> 119:         }
> 120:         implCompress(buffer, 0);
> 121:         int availableBytes = buffer.length;

change to `blockSize` as in `implCompress0(...)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1638832540
PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1637350489

From kevinw at openjdk.org  Thu Jun 13 20:54:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 20:54:25 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Separate SM allowed and not allowed cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/f70047a4..09c2e38f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=08-09

  Stats: 52 lines in 1 file changed: 31 ins; 8 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Thu Jun 13 20:57:19 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Jun 2024 20:57:19 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v3]
In-Reply-To: <ZP4s55UH9ubCxKJ2eDbjy5c6YGGbSalNWY7dCrw3WrU=.f22b8d9e-47ff-42f8-af42-1b3d46754ff6@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <x2VlWjHwHh-WQNtG7Gp-no1Z3nY5myRfMXmm8RuBc1E=.ee188434-e145-423a-8ed5-541bcc7db53d@github.com>
 <PMhI0_FjsKRduDAqFnmfgmBos-yCA0-mzkilwvQ8QKA=.914d2793-01b1-42e2-afa3-0aeb68cf3350@github.com>
 <Gg34s2AIlChqCxi942j__gd43RoyiDfMIt8bIdoJb7I=.759c6e64-00ff-408c-90b0-76d530958a7d@github.com>
 <ZP4s55UH9ubCxKJ2eDbjy5c6YGGbSalNWY7dCrw3WrU=.f22b8d9e-47ff-42f8-af42-1b3d46754ff6@github.com>
Message-ID: <MUzM9SZNcW0eWNXIXnhh_UEZQNY-RXyO7DBUHfYhdRU=.ba2b03e2-02ca-47b9-830c-f1dce08d29d5@github.com>

On Tue, 11 Jun 2024 19:01:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Thanks I'll go through the above comments and update - some of the changes I see are unnecessary and from when I was trying migrating to callAs, and doPrivileged, and yes they can be simpler.
>> 
>> On the allowSecurityMananger check: 
>> If we check in e.g. RMIConnectionImpl constructor, and if SM is allowed we assign an ACC.
>> Later, we know if we have a non-null ACC then SM is allowed.  Are you saying we should then check allowSecurityManager  again?
>
> Not "then check" but "first check", as shown in my example above. I understand you can infer whether SM is allowed by looking at the values if `acc` and `subject`, but IMO it's not worth doing. The check is very light and this coding style makes sure the old code and new code are cleanly separated. It's easy to code because you don't modify existing code and only add new code in else blocks. In the near future when we finally remove the SM it will also be simple to remove old code.

I'm trying that out in this update.  It looks OK 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1638932678

From rgiulietti at openjdk.org  Thu Jun 13 20:58:17 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 13 Jun 2024 20:58:17 GMT
Subject: Integrated: 8333599: Improve description of \b matcher in
 j.u.r.Pattern
In-Reply-To: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
References: <vaUAws794qS1OwZ1MeJGSecgFNnvpbOy170_Kbmqr1c=.ca707752-a439-444e-b367-8a4aa8fe7379@github.com>
Message-ID: <ssYzZWGclOMhGp_52Flli0UBVz164b669yuqLJaDT5w=.a4e505a7-754e-4633-b5aa-ca471a8d274c@github.com>

On Thu, 6 Jun 2024 18:16:14 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A documentation-only change to match the original intent and the implemented behavior.

This pull request has now been integrated.

Changeset: bb7ef030
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb7ef03077fb91169b5505e3500093b848aece0f
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8333599: Improve description of \b matcher in j.u.r.Pattern

Reviewed-by: smarks, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19583

From dnguyen at openjdk.org  Thu Jun 13 21:32:24 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 13 Jun 2024 21:32:24 GMT
Subject: Integrated: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <PHwvH3AGCvU714vSF5eogwl7u7smKE8mEXNNBx_jZHw=.00a7eff2-a020-4ff5-b82f-2a14b33ba35a@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

This pull request has now been integrated.

Changeset: c4702ca8
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a
Stats:     237 lines in 38 files changed: 133 ins; 57 del; 47 mod

8333827: JDK 23 RDP1 L10n resource files update

Reviewed-by: achung, jlu, naoto, joehw, prappo, cjplummer, asemenyuk, prr

-------------

PR: https://git.openjdk.org/jdk/pull/19609

From dnguyen at openjdk.org  Thu Jun 13 21:45:37 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 13 Jun 2024 21:45:37 GMT
Subject: [jdk23] RFR: 8333827: JDK 23 RDP1 L10n resource files update
Message-ID: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>

Hi all,

This pull request contains a backport of commit [c4702ca8](https://github.com/openjdk/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Damon Nguyen on 13 Jun 2024 and was reviewed by Alisen Chung, Justin Lu, Naoto Sato, Joe Wang, Pavel Rappo, Chris Plummer, Alexey Semenyuk and Phil Race.

Thanks!

-------------

Commit messages:
 - Backport c4702ca8c026e2d265aca0126fd3fb7bc5bb392a

Changes: https://git.openjdk.org/jdk/pull/19713/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19713&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333827
  Stats: 237 lines in 38 files changed: 133 ins; 57 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/19713.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19713/head:pull/19713

PR: https://git.openjdk.org/jdk/pull/19713

From jlu at openjdk.org  Thu Jun 13 21:45:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jun 2024 21:45:37 GMT
Subject: [jdk23] RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
References: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
Message-ID: <BElwil0jmH0ze0istvpnHeChiUH_VkQTR2Fpekk6wAc=.b3a49075-4e5b-4819-8f43-698207725e09@github.com>

On Thu, 13 Jun 2024 21:38:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c4702ca8](https://github.com/openjdk/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Damon Nguyen on 13 Jun 2024 and was reviewed by Alisen Chung, Justin Lu, Naoto Sato, Joe Wang, Pavel Rappo, Chris Plummer, Alexey Semenyuk and Phil Race.
> 
> Thanks!

Clean backport of L10n resource drop required for JDK23

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19713#pullrequestreview-2117082417

From naoto at openjdk.org  Thu Jun 13 21:48:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Jun 2024 21:48:14 GMT
Subject: [jdk23] RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
References: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
Message-ID: <OIOxdjppmbkch2qDdWkZwpdRD9TLTMxAx7pD2fIZVTs=.a99b7fee-5dfc-4b3e-aac5-e524b5888da7@github.com>

On Thu, 13 Jun 2024 21:38:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c4702ca8](https://github.com/openjdk/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Damon Nguyen on 13 Jun 2024 and was reviewed by Alisen Chung, Justin Lu, Naoto Sato, Joe Wang, Pavel Rappo, Chris Plummer, Alexey Semenyuk and Phil Race.
> 
> Thanks!

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19713#pullrequestreview-2117085705

From dnguyen at openjdk.org  Thu Jun 13 21:51:17 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 13 Jun 2024 21:51:17 GMT
Subject: [jdk23] Integrated: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
References: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
Message-ID: <2L_EtBxkTfdXVo8_kwbYVDyrQb9T5YRNQXwM03orLko=.be85bc8d-836c-49b1-9663-149f79562338@github.com>

On Thu, 13 Jun 2024 21:38:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c4702ca8](https://github.com/openjdk/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Damon Nguyen on 13 Jun 2024 and was reviewed by Alisen Chung, Justin Lu, Naoto Sato, Joe Wang, Pavel Rappo, Chris Plummer, Alexey Semenyuk and Phil Race.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a7964453
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7964453cf5203229d4a5b5231b7fc86da5d4af8
Stats:     237 lines in 38 files changed: 133 ins; 57 del; 47 mod

8333827: JDK 23 RDP1 L10n resource files update

Reviewed-by: jlu, naoto
Backport-of: c4702ca8c026e2d265aca0126fd3fb7bc5bb392a

-------------

PR: https://git.openjdk.org/jdk/pull/19713

From sspitsyn at openjdk.org  Fri Jun 14 01:17:17 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 14 Jun 2024 01:17:17 GMT
Subject: RFR: 8330702: Update failure handler to don't generate Error
 message if cores actions are empty
In-Reply-To: <rDvdKl90aCp8AXBSFjWULjZxRwVYjnIH65s8CPBCL_M=.65ca8ddb-17e2-4e4e-9911-3dd176d6a9e7@github.com>
References: <rDvdKl90aCp8AXBSFjWULjZxRwVYjnIH65s8CPBCL_M=.65ca8ddb-17e2-4e4e-9911-3dd176d6a9e7@github.com>
Message-ID: <HlHO99MlHom40r5nlxeOOU8RGic0YBlVEbzDG502feo=.bff2c1cc-8db1-4091-af6d-caa2e9e2b834@github.com>

On Thu, 30 May 2024 02:28:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The message is generated if cores (or any other tools) section doesn't exist or is empty. However, there is no any tool for cores processing now defined. So ERROR message is generating, confusing users.
> The fix is to don't print error for empty toolset which is the valid case. The message is still generate is tool is not defined to get error message in the case of miswriting.

This looks okay to me.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19470#pullrequestreview-2117249931

From duke at openjdk.org  Fri Jun 14 01:17:29 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 14 Jun 2024 01:17:29 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v9]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <_d_wvsAh608KlyZSUP0TTP9nTMX6n4OnZkkov1jxbCI=.71d3f785-0da6-4978-a75e-4142d893f92c@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimization for x64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/22d45124..b5ad8e70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=07-08

  Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From jpai at openjdk.org  Fri Jun 14 01:39:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Jun 2024 01:39:11 GMT
Subject: RFR: 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL
 macro in java launcher [v2]
In-Reply-To: <2ljA_wbHn-RLVyWR3VrIKme5JmvzdWnrCVEEtQVeok4=.d9486ad8-ca69-40ac-b25a-25a83ef1cb70@github.com>
References: <NoAAbQZLfZe9g2rEGOX1U1S2rR0QE1lIZ229VfOnNT8=.c1b88267-e23d-48c3-9047-edffd19b2559@github.com>
 <2ljA_wbHn-RLVyWR3VrIKme5JmvzdWnrCVEEtQVeok4=.d9486ad8-ca69-40ac-b25a-25a83ef1cb70@github.com>
Message-ID: <vG9NLci5bTGXzpgpS-eIWP0xYRrY4cbyHpd2ReFUju8=.5f497041-6151-4bb0-930e-87d0fcce0d4d@github.com>

On Thu, 6 Jun 2024 13:28:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to remove the `CHECK_EXCEPTION_NULL_FAIL` macro from the `java` launcher code?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8333714. As noted in that JBS issue, in a recent PR discussion, it was suggested https://github.com/openjdk/jdk/pull/18786#issuecomment-2147452633 that this macro should be removed and the failure of a JNI specified operation (the ones for which this macro is being used) should be determined based on a `NULL` value returned from that function. The commit in this PR removes this macros and updates the call sites to do a `NULL` check.
>> 
>> Given the nature of this change, no new tests have been added. tier1, tier2 and tier3 testing passed successfully with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comments

Thank you for the review Alan. I'll integrate this in a few hours.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19576#issuecomment-2167053874

From duke at openjdk.org  Fri Jun 14 03:19:48 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 14 Jun 2024 03:19:48 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v6]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <nFfGXQutLZFBZyY3wXFWfhOyxI6owEY7yWYinIQm09s=.a88ff8ac-2a73-4262-a02f-656bcea468fc@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/1ab65e18..d590f132

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=04-05

  Stats: 467 lines in 11 files changed: 222 ins; 188 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From duke at openjdk.org  Fri Jun 14 03:34:13 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 14 Jun 2024 03:34:13 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <6kmKgt5QX3KBTmpN4R5D9-XWbiUkP7ieQF00DZc48Es=.5f0e517a-06e2-4392-984d-754d287b0ac5@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
 <6kmKgt5QX3KBTmpN4R5D9-XWbiUkP7ieQF00DZc48Es=.5f0e517a-06e2-4392-984d-754d287b0ac5@github.com>
Message-ID: <acPv0AiTqob7XLTogkIj8Jgtk5yW1axTP56-3HY_fPI=.ef730fad-2590-40aa-81a7-5fc00d3c3205@github.com>

On Thu, 13 Jun 2024 19:40:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I second Justin's suggestion here. The change should benefit every implementation in the JDK, not only NumberFormat. Also, I might suggest renaming the new class, as it is kind of long/redundant. How about using something as simple as "StringBuf"?

Thanks for your comment. The long name bother me for a while. I have changed it to ""StringBuf".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2167144044

From duke at openjdk.org  Fri Jun 14 03:34:14 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 14 Jun 2024 03:34:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <9n9ZOdzKHksCMCCA1ql1LEpyYYQH9thg0112PwgmXx4=.d58e5a15-2a14-4954-b161-5c9b02f5e556@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
 <9n9ZOdzKHksCMCCA1ql1LEpyYYQH9thg0112PwgmXx4=.d58e5a15-2a14-4954-b161-5c9b02f5e556@github.com>
Message-ID: <ps1QZ3ekkIPzYDiz6l9ZocAYd58LtFLQdOiJR6JvsJc=.ebff4e5f-78a0-4142-a0a6-e4c67030743b@github.com>

On Thu, 13 Jun 2024 19:40:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/StringBuilderBufferProxy.java line 108:
> 
>> 106:     }
>> 107: 
>> 108:     class StringBuilderImpl implements StringBuilderBufferProxy {
> 
> Avoid adding nested classes to interfaces, which are public. These classes are publicly accessible under reflection, and we want to avoid more of such occurrences. See https://bugs.openjdk.org/browse/JDK-8308040?focusedId=14581402&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14581402

Thanks for your suggestion. I split this class into 2 classes: one is the interface, the other is the factory class with package-private.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1639179219

From duke at openjdk.org  Fri Jun 14 04:07:15 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 14 Jun 2024 04:07:15 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <e0kp5SiQXQM3opXP1RtEayfyfHVF5gO6SezjeVcMuZA=.4de0add9-95bf-44da-b9ca-314dc81d59a2@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
 <e0kp5SiQXQM3opXP1RtEayfyfHVF5gO6SezjeVcMuZA=.4de0add9-95bf-44da-b9ca-314dc81d59a2@github.com>
Message-ID: <aNc3-Dw5QwYdUz3QpeB9Kd680i9r2DEoESYA3MrQ2LY=.44ee92cb-2d76-41b9-8262-3af4328bc0ba@github.com>

On Thu, 13 Jun 2024 17:53:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 885:
> 
>> 883:     }
>> 884: 
>> 885:     private StringBuilderBufferProxy format(BigInteger number, StringBuilderBufferProxy result,
> 
> While the DecimalFormat and CompactNumberFormat BigInteger and BigDecimal `format` methods will always return a StringBuffer, we must change the method signatures to use the proxy, otherwise we would need to define alternate methods all the way at the `Format.FieldDelegate` level. So I think this is a lesser of two evils.

I'm not sure what you mean. Would you suggest add two new methods that accept StringBuilderBufferProxy and keep the origin methods that accept StringBuffer? Like this:

    interface FieldDelegate {

        public void formatted(Format.Field attr, Object value, int start,
                              int end, StringBuffer buffer);

        public void formatted(int fieldID, Format.Field attr, Object value,
                              int start, int end, StringBuffer buffer);

        public void formatted(Format.Field attr, Object value, int start,
                              int end, StringBuilderBufferProxy buffer);

        public void formatted(int fieldID, Format.Field attr, Object value,
                              int start, int end, StringBuilderBufferProxy buffer);
    }

But DecimalFormat#subformatNumber is a common method that only accept StringBuilderBufferProxy, and CompactNumberFormat#format(BigDecimal) call it, so CompactNumberFormat#format(BigDecimal) need change signature.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1639197282

From dholmes at openjdk.org  Fri Jun 14 04:26:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Jun 2024 04:26:17 GMT
Subject: RFR: 8333962: Obsolete OldSize
In-Reply-To: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
Message-ID: <l7DB39wCkKilE8X0gVRLmFq07fbreiBLWzryhDLjj-M=.99220f98-71f1-4233-a525-f79d691143b1@github.com>

On Tue, 11 Jun 2024 08:17:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.

Al seems reasonable.

Thanks.

src/hotspot/share/runtime/arguments.cpp line 543:

> 541:   { "UseNeon",                      JDK_Version::undefined(), JDK_Version::jdk(23), JDK_Version::jdk(24) },
> 542:   { "ScavengeBeforeFullGC",         JDK_Version::undefined(), JDK_Version::jdk(23), JDK_Version::jdk(24) },
> 543: 

Please remove blank line. but you need to sync with master to get recent updates to this table.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19647#pullrequestreview-2117402095
PR Review Comment: https://git.openjdk.org/jdk/pull/19647#discussion_r1639203788

From aturbanov at openjdk.org  Fri Jun 14 05:58:12 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 14 Jun 2024 05:58:12 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
Message-ID: <aj_JZwbKHtrr6yjsmjNU1nAoJBGmAKgC5mJMR6BVfx4=.6b322db3-5c6c-461a-b586-2c7560433b27@github.com>

On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix clone(), accept review suggestions.

src/java.base/share/classes/sun/security/provider/SHA3.java line 152:

> 150:      */
> 151:     void implReset() {
> 152:         Arrays.fill(state,0L);

Suggestion:

        Arrays.fill(state, 0L);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639301465

From alanb at openjdk.org  Fri Jun 14 06:52:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Jun 2024 06:52:27 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
In-Reply-To: <2HKfxaPysSsNwikk5Kgqx3_mNarIC_DRycPLyP_Hlwk=.7253908b-6e5a-4d5c-a968-5af0d9db94ae@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
 <Jd1IjGY4f5x21FEtT-G0v8Bz8E5Ufg4HoZvLK5C1q04=.bb931989-1eff-4e8c-8798-6d25bf36c211@github.com>
 <2HKfxaPysSsNwikk5Kgqx3_mNarIC_DRycPLyP_Hlwk=.7253908b-6e5a-4d5c-a968-5af0d9db94ae@github.com>
Message-ID: <mCQ63s2R90MfME2IcNJo0uRcyBhdh5SyXHcDciviM9w=.81e78abe-23fb-46e8-80c3-eb809d70ed09@github.com>

On Wed, 12 Jun 2024 16:54:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Could you please help review it? Thanks!

Yes, on my list.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2167341692

From duke at openjdk.org  Fri Jun 14 08:55:16 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 14 Jun 2024 08:55:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v9]
In-Reply-To: <_d_wvsAh608KlyZSUP0TTP9nTMX6n4OnZkkov1jxbCI=.71d3f785-0da6-4978-a75e-4142d893f92c@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <_d_wvsAh608KlyZSUP0TTP9nTMX6n4OnZkkov1jxbCI=.71d3f785-0da6-4978-a75e-4142d893f92c@github.com>
Message-ID: <Ur4UgXmOL8jPUzeEPwPcExaS9Afi8UL3SkubSaR9fAY=.e42ebca9-f59a-46a6-9a27-8ff6fd206938@github.com>

On Fri, 14 Jun 2024 01:17:29 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimization for x64

The performance regression issue under x64 has been resolved. The following code will affect the running performance under x64:
* x64 slow version

int count = this.count;
ensureCapacityInternal(count + 4);


* x64 faster version, WebRev 08: [Full](https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=08) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=07-08) ([b5ad8e70](https://git.openjdk.org/jdk/pull/19626/files/b5ad8e70928c547d134d0e4a532441cad9a7e4a2))

ensureCapacityInternal(count + 4);
int count = this.count;


I don't know why, but this solved the problem.

The performance numbers for various platforms are as follows

## aliyun ecs.c8a
* CPU AMD EPYCTM Genoa
* Platform x64

-Benchmark                             Mode  Cnt   Score   Error  Units #master (a6fc2f8)
-StringBuilders.appendWithBool8Latin1  avgt   15   7.270 ? 0.013  ns/op
-StringBuilders.appendWithBool8Utf16   avgt   15  10.860 ? 0.044  ns/op
-StringBuilders.appendWithNull8Latin1  avgt   15  5.490  ? 0.007  ns/op
-StringBuilders.appendWithNull8Utf16   avgt   15  26.203 ? 0.294  ns/op

+Benchmark                             Mode  Cnt   Score   Error  Units # Web 08 (b5ad8e70)
+StringBuilders.appendWithBool8Latin1  avgt   15   6.035 ? 0.062  ns/op +20%
+StringBuilders.appendWithBool8Utf16   avgt   15  10.072 ? 0.032  ns/op +7.82%
+StringBuilders.appendWithNull8Latin1  avgt   15   5.491 ? 0.021  ns/op -0.01$
+StringBuilders.appendWithNull8Utf16   avgt   15   7.701 ? 0.036  ns/op +240.25%


## aliyun ecs.c8i
* CPU Intel? Xeon? Emerald
* Platform x64

-Benchmark                             Mode  Cnt   Score   Error  Units #master (a6fc2f8)
-StringBuilders.appendWithBool8Latin1  avgt   15   7.466 ? 0.012  ns/op
-StringBuilders.appendWithBool8Utf16   avgt   15  15.220 ? 0.005  ns/op
-StringBuilders.appendWithNull8Latin1  avgt   15  22.084 ? 0.331  ns/op
-StringBuilders.appendWithNull8Utf16   avgt   15  25.717 ? 0.106  ns/op

+Benchmark                             Mode  Cnt   Score   Error  Units # Web 08 (b5ad8e70)
+StringBuilders.appendWithBool8Latin1  avgt   15   6.706 ? 0.011  ns/op +11.33%
+StringBuilders.appendWithBool8Utf16   avgt   15  11.610 ? 0.140  ns/op +31.09%
+StringBuilders.appendWithNull8Latin1  avgt   15  19.345 ? 0.050  ns/op +14.15%
+StringBuilders.appendWithNull8Utf16   avgt   15  22.765 ? 0.045  ns/op +12.96%


## MacBook M1 Max
* CPU Apple M1 Max
* Platform aarch64

-Benchmark                             Mode  Cnt  Score   Error  Units #master (a6fc2f8)
-StringBuilders.appendWithBool8Latin1  avgt   15  7.647 ? 0.014  ns/op
-StringBuilders.appendWithBool8Utf16   avgt   15  9.620 ? 0.022  ns/op
-StringBuilders.appendWithNull8Latin1  avgt   15  7.208 ? 0.127  ns/op
-StringBuilders.appendWithNull8Utf16   avgt   15  9.455 ? 0.167  ns/op

+Benchmark                             Mode  Cnt  Score   Error  Units # Web 08 (b5ad8e70)
+StringBuilders.appendWithBool8Latin1  avgt   15  5.932 ? 0.026  ns/op +28.91%
+StringBuilders.appendWithBool8Utf16   avgt   15  7.432 ? 0.015  ns/op +29.44$
+StringBuilders.appendWithNull8Latin1  avgt   15  5.461 ? 0.015  ns/op +31.99%
+StringBuilders.appendWithNull8Utf16   avgt   15  6.966 ? 0.015  ns/op +35.73%


## aliyun ecs.c8y
* CPU Yitian710 aarch64
* Platform aarch64

-Benchmark                             Mode  Cnt   Score   Error  Units
-StringBuilders.appendWithBool8Latin1  avgt   15  12.127 ? 1.241  ns/op
-StringBuilders.appendWithBool8Utf16   avgt   15  20.954 ? 1.668  ns/op
-StringBuilders.appendWithNull8Latin1  avgt   15  10.838 ? 0.244  ns/op
-StringBuilders.appendWithNull8Utf16   avgt   15  14.391 ? 0.063  ns/op


+Benchmark                             Mode  Cnt   Score   Error  Units
+StringBuilders.appendWithBool8Latin1  avgt   15   9.299 ? 0.079  ns/op +30.41%
+StringBuilders.appendWithBool8Utf16   avgt   15  11.688 ? 0.004  ns/op +79.27%
+StringBuilders.appendWithNull8Latin1  avgt   15   8.516 ? 0.258  ns/op +27.26%
+StringBuilders.appendWithNull8Utf16   avgt   15  11.020 ? 0.004  ns/op +30.58%


## aws.c5
* Platform aarch64

-Benchmark                             Mode  Cnt   Score   Error  Units
-StringBuilders.appendWithBool8Latin1  avgt   15  10.278 ? 0.071  ns/op
-StringBuilders.appendWithBool8Utf16   avgt   15  24.355 ? 0.418  ns/op
-StringBuilders.appendWithNull8Latin1  avgt   15  33.104 ? 0.589  ns/op
-StringBuilders.appendWithNull8Utf16   avgt   15  35.762 ? 7.580  ns/op

+Benchmark                             Mode  Cnt   Score   Error  Units
+StringBuilders.appendWithBool8Latin1  avgt   15   9.812 ? 0.075  ns/op
+StringBuilders.appendWithBool8Utf16   avgt   15  17.812 ? 0.006  ns/op
+StringBuilders.appendWithNull8Latin1  avgt   15  34.773 ? 2.897  ns/op
+StringBuilders.appendWithNull8Utf16   avgt   15  33.187 ? 1.604  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2167566396

From sgehwolf at openjdk.org  Fri Jun 14 09:10:28 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Jun 2024 09:10:28 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v32]
In-Reply-To: <mCQ63s2R90MfME2IcNJo0uRcyBhdh5SyXHcDciviM9w=.81e78abe-23fb-46e8-80c3-eb809d70ed09@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
 <Jd1IjGY4f5x21FEtT-G0v8Bz8E5Ufg4HoZvLK5C1q04=.bb931989-1eff-4e8c-8798-6d25bf36c211@github.com>
 <2HKfxaPysSsNwikk5Kgqx3_mNarIC_DRycPLyP_Hlwk=.7253908b-6e5a-4d5c-a968-5af0d9db94ae@github.com>
 <mCQ63s2R90MfME2IcNJo0uRcyBhdh5SyXHcDciviM9w=.81e78abe-23fb-46e8-80c3-eb809d70ed09@github.com>
Message-ID: <GoQZSfHLdX_9Fk_cOcgX2E7jmWDcoPSrGnNJMiSvDiA=.d23cbb97-eb3d-483f-b9b9-b22c014b4897@github.com>

On Fri, 14 Jun 2024 06:49:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Yes, on my list.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2167591811

From duke at openjdk.org  Fri Jun 14 09:35:19 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 14 Jun 2024 09:35:19 GMT
Subject: Integrated: 8332400: isspace argument should be a valid unsigned char
In-Reply-To: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
References: <duROL6NCG5rXpSi0HqlW5P39y6GOx3le81i_64UoiRs=.853c988b-b898-4608-af48-4bdefe10e38d@github.com>
Message-ID: <bZeMq7CRrz0nNtV7HDYQaM5HEZf4drY1tsPUfjG4y64=.b78623d0-33a2-4db1-8600-0f0959deb8b9@github.com>

On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary
> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).  `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". 
> 
> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. 
> 
> **Testing**
> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly.
> - tier1

This pull request has now been integrated.

Changeset: cc64aeac
Author:    Robert Toyonaga <rtoyonag at redhat.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc64aeac47917f20a6d70e9796f0de9aa165ce62
Stats:     17 lines in 8 files changed: 0 ins; 0 del; 17 mod

8332400: isspace argument should be a valid unsigned char

Reviewed-by: dholmes, amitkumar, stuefe, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/19567

From cstein at openjdk.org  Fri Jun 14 09:42:33 2024
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 14 Jun 2024 09:42:33 GMT
Subject: RFR: 8331552: Update to use jtreg 7.4
Message-ID: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>

Please review the change to update to using `jtreg` **7.4**.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Testing: _tier1-tier5 pending..._

-------------

Commit messages:
 - 8331552: Update to use jtreg 7.4

Changes: https://git.openjdk.org/jdk/pull/19052/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19052&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331552
  Stats: 12 lines in 8 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/19052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19052/head:pull/19052

PR: https://git.openjdk.org/jdk/pull/19052

From duke at openjdk.org  Fri Jun 14 09:50:15 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 14 Jun 2024 09:50:15 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <aj_JZwbKHtrr6yjsmjNU1nAoJBGmAKgC5mJMR6BVfx4=.6b322db3-5c6c-461a-b586-2c7560433b27@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
 <aj_JZwbKHtrr6yjsmjNU1nAoJBGmAKgC5mJMR6BVfx4=.6b322db3-5c6c-461a-b586-2c7560433b27@github.com>
Message-ID: <MZB9Hp3-gnZnC-Q-Cq1guLAec_FRQwMj39VR8mZ8EL0=.b91ffc05-dd3d-49db-8919-af15375fcd1d@github.com>

On Fri, 14 Jun 2024 05:56:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix clone(), accept review suggestions.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 152:
> 
>> 150:      */
>> 151:     void implReset() {
>> 152:         Arrays.fill(state,0L);
> 
> Suggestion:
> 
>         Arrays.fill(state, 0L);

Thanks! Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639572679

From duke at openjdk.org  Fri Jun 14 09:50:14 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 14 Jun 2024 09:50:14 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <YINw_j9qbVQjElu5BRO10mo7oRHFB2xdNdXclxzV2I0=.9183cc29-ce1f-4d41-a5ae-c61f825b11e8@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
 <YINw_j9qbVQjElu5BRO10mo7oRHFB2xdNdXclxzV2I0=.9183cc29-ce1f-4d41-a5ae-c61f825b11e8@github.com>
Message-ID: <wcJ6GKdi7u7cnPWXmmVM0csgsMqCAVKnvv3rh_JbbHQ=.a09faac2-4840-48b0-b7ad-d8bcffbacc4a@github.com>

On Thu, 13 Jun 2024 20:25:22 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix clone(), accept review suggestions.
>
> src/java.base/share/classes/sun/security/provider/SHA3.java line 73:
> 
>> 71:     // The following array is allocated to size WIDTH bytes, but we only
>> 72:     // ever use the first blockSize bytes it (for bytes <-> long conversions)
>> 73:     private byte[] byteState = new byte[WIDTH];
> 
> Since we are storing the state in longs now, this "byte <-> long" conversion can be made through a local variable, right? Is there a reason for having this `byteState` field with size WIDTH bytes?

This is interesting: if I use WIDTH (or in blockSize) long arrays in the local level, the performance drops a few per cents. Even more when I only declare the local array in the block in which it is used. However, since we really only need 8 bytes, if I allocate that at the beginning of the function, I don't see that performance drop. So I rewrote the output loop in the function and got rid of the class level declaration.

> src/java.base/share/classes/sun/security/provider/SHA3.java line 121:
> 
>> 119:         }
>> 120:         implCompress(buffer, 0);
>> 121:         int availableBytes = buffer.length;
> 
> change to `blockSize` as in `implCompress0(...)`?

Yes, thanks, I wanted to, just forgot.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639572500
PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1639572413

From kevinw at openjdk.org  Fri Jun 14 10:18:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 10:18:26 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v6]
In-Reply-To: <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
 <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
Message-ID: <CgpksYGeTTwXCgwafY7b1MKTXRWfO_mwaC3bjlt-GCs=.3aecbacb-b5a0-4cbe-9c12-5848f81d4a42@github.com>

On Wed, 12 Jun 2024 21:03:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Undo test policy updates
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1304:
> 
>> 1302:                 // No ACC, therefore no SM. May have a Subject:
>> 1303:                 if (subject != null) {
>> 1304:                     return Subject.doAs(subject, action);
> 
> Is it ever possible for acc to be `null` and `subject` not `null` and an SM to be enabled? Doesn't look like it, but if it ever could be, then the call above to `Subject.doAs` would trigger a permission check for an `AuthPermission("doAs")` permission.
> 
> I think following Weijun's advice above is cleaner and safer, so you do one or the other depending on the allowSM setting, and not whether certain variables are null or not.

Right, the only possible assignment to acc in this file is if we were given a Subject, and SM is permitted.

In future there will be a Subject, which can be null.  While we handle SM, we still use the ACC if RMIConnectionImpl was created with a Subject.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639610678

From ayang at openjdk.org  Fri Jun 14 10:19:47 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 14 Jun 2024 10:19:47 GMT
Subject: RFR: 8333962: Obsolete OldSize [v2]
In-Reply-To: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
Message-ID: <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>

> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  obsolete-old-size

-------------

Changes: https://git.openjdk.org/jdk/pull/19647/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19647&range=01
  Stats: 192 lines in 15 files changed: 7 ins; 168 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/19647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19647/head:pull/19647

PR: https://git.openjdk.org/jdk/pull/19647

From duke at openjdk.org  Fri Jun 14 10:39:45 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 14 Jun 2024 10:39:45 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v3]
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Accept more review suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19632/files
  - new: https://git.openjdk.org/jdk/pull/19632/files/0a9f9624..4fcdd09f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19632&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19632&range=01-02

  Stats: 21 lines in 1 file changed: 2 ins; 8 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/19632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19632/head:pull/19632

PR: https://git.openjdk.org/jdk/pull/19632

From ihse at openjdk.org  Fri Jun 14 10:51:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Jun 2024 10:51:17 GMT
Subject: RFR: 8331552: Update to use jtreg 7.4
In-Reply-To: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
References: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
Message-ID: <-YWkhRJhUGImRoIujOxkT8oL3voSNK0s1ERO8r6b60E=.fc9ff806-5eda-4f50-a5f5-11b5616923d4@github.com>

On Thu, 2 May 2024 09:48:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using `jtreg` **7.4**.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> Testing: _tier1-tier5 pending..._

Looks good to me. I assume that you have run an extensive set of tests to verify that this does not break, even in higher tiers?

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19052#pullrequestreview-2118094672

From ihse at openjdk.org  Fri Jun 14 10:55:22 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Jun 2024 10:55:22 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <Imr43NIlLR5rtSR9afHcUyS-oWMBu5IIUxwlRbYPMzM=.316722a5-4548-427b-bc60-f4dd35207770@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
 <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
 <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>
 <Imr43NIlLR5rtSR9afHcUyS-oWMBu5IIUxwlRbYPMzM=.316722a5-4548-427b-bc60-f4dd35207770@github.com>
Message-ID: <XrI8ouN-1BPdfxStwisnI4NAY11mpHXcEtuvnuO3MXY=.5b0a33d6-ebcf-4213-9f1e-0f7b217688ca@github.com>

On Fri, 7 Jun 2024 13:34:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I find the extra trailing newlines through below shell command:
>> 
>> for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i | grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done
>> 
>> 
>> There are only two files has been found:
>> 
>> ./test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile
>> ./test/jdk/java/rmi/reliability/benchmark/bench/Makefile
>
> Ah, I had not realized that there was more than 1 newline. GitHub's UI confused me here, so we're good to go

GitHub's UI assumes the final line has an line break. If it is missing, it displays a red ? at the end of the last line. If there is an empty line showing up in the UI, then it is an additional empty line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1639649265

From weijun at openjdk.org  Fri Jun 14 12:12:16 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Jun 2024 12:12:16 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
Message-ID: <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>

On Thu, 13 Jun 2024 20:54:25 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Separate SM allowed and not allowed cases

I don't quite understand why there is no more `noPermissionsACC` in `Monotor.java`. This looks like the only behavior change when SM is allowed. The other source change looks fine to me.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1461:

> 1459:                 throw rte;
> 1460:             } else {
> 1461:                 throw new PrivilegedActionException(e);

The 4 lines above seems unnecessary now. Plus, do not wrap `PrivilegedActionException` inside `PrivilegedActionException`.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 353:

> 351:         } else {
> 352:             return Subject.getSubject(AccessController.getContext());
> 353:         }

`Subject.current()` should work for both cases. See the impl of it.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2118220033
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639720192
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639721194

From kevinw at openjdk.org  Fri Jun 14 12:44:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 12:44:13 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
Message-ID: <cp-kNjl5sDRtOtdqgru1Vvs7zS3cQ4yq1lAnzQlrBXw=.e09c9e03-46b5-4fca-856d-cc064f09e495@github.com>

On Fri, 14 Jun 2024 12:09:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I don't quite understand why there is no more `noPermissionsACC` in `Monotor.java`. This looks like the only behavior change when SM is allowed. The other source change looks fine to me.

Does noPermissionsACC add anything?  Maybe I'm rushing the removal of ACCs where I can.

Start sets acc to the current context (when SM permitted, use Subject otherwise)
Set acc to noPermissionsACC when stop is called (or forget the Subject).

acc is accessed within the run method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2167949489

From kevinw at openjdk.org  Fri Jun 14 12:47:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 12:47:13 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
Message-ID: <KeRilLtCKTM3jP18PozO7NI_Ieo-_uh-3mWO27Rt1oQ=.756806c0-5f3b-4ec2-879e-fdec75ff85ad@github.com>

On Fri, 14 Jun 2024 12:04:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Separate SM allowed and not allowed cases
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 353:
> 
>> 351:         } else {
>> 352:             return Subject.getSubject(AccessController.getContext());
>> 353:         }
> 
> `Subject.current()` should work for both cases. See the impl of it.

ok!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639766973

From jpai at openjdk.org  Fri Jun 14 12:51:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Jun 2024 12:51:20 GMT
Subject: Integrated: 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL
 macro in java launcher
In-Reply-To: <NoAAbQZLfZe9g2rEGOX1U1S2rR0QE1lIZ229VfOnNT8=.c1b88267-e23d-48c3-9047-edffd19b2559@github.com>
References: <NoAAbQZLfZe9g2rEGOX1U1S2rR0QE1lIZ229VfOnNT8=.c1b88267-e23d-48c3-9047-edffd19b2559@github.com>
Message-ID: <sdrmIn4W3MZHARKygsvL9MefUZWvAj-NCYxOwOwM1OA=.e4df0db9-8107-4dc3-8f87-98ee0b869ea8@github.com>

On Thu, 6 Jun 2024 11:53:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to remove the `CHECK_EXCEPTION_NULL_FAIL` macro from the `java` launcher code?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8333714. As noted in that JBS issue, in a recent PR discussion, it was suggested https://github.com/openjdk/jdk/pull/18786#issuecomment-2147452633 that this macro should be removed and the failure of a JNI specified operation (the ones for which this macro is being used) should be determined based on a `NULL` value returned from that function. The commit in this PR removes this macros and updates the call sites to do a `NULL` check.
> 
> Given the nature of this change, no new tests have been added. tier1, tier2 and tier3 testing passed successfully with these changes.

This pull request has now been integrated.

Changeset: efab48c0
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/efab48c06554476eae7a7bd946dee033d16a9c38
Stats:     68 lines in 1 file changed: 37 ins; 9 del; 22 mod

8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL macro in java launcher

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19576

From liach at openjdk.org  Fri Jun 14 12:56:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Jun 2024 12:56:23 GMT
Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]
In-Reply-To: <XrI8ouN-1BPdfxStwisnI4NAY11mpHXcEtuvnuO3MXY=.5b0a33d6-ebcf-4213-9f1e-0f7b217688ca@github.com>
References: <uA8J-a0-Od9DRGamgBSbEzlT-vQCFet7Eum59D6g4Ac=.9c7d4b3b-8965-41eb-8ef7-d9bbe6aeabbf@github.com>
 <PRfpHw2R8A0NN3QwkIJpAglG-KemsWQE8PxRaRSjTWk=.a25289b1-700d-4f47-b27a-ab9be090ace0@github.com>
 <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com>
 <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com>
 <Ms6uTAArfVPUDggZQo6QUuNPK1ID2DzXoGsIPXXSfrY=.4dc28d0b-5182-44c3-b541-f4e52d9e3107@github.com>
 <uMKKYGsy68R8ttE1g60mKuEpWsNC0C2PH64ILheHAiU=.a717a6fc-fe72-40e7-8b52-3df8355cb4e1@github.com>
 <Imr43NIlLR5rtSR9afHcUyS-oWMBu5IIUxwlRbYPMzM=.316722a5-4548-427b-bc60-f4dd35207770@github.com>
 <XrI8ouN-1BPdfxStwisnI4NAY11mpHXcEtuvnuO3MXY=.5b0a33d6-ebcf-4213-9f1e-0f7b217688ca@github.com>
Message-ID: <Qn8Aq3YacG6k1osKLwjfakXahNky2MoXOCkcjKq8wy8=.f72a9420-4d53-4505-9e10-22bd97773668@github.com>

On Fri, 14 Jun 2024 10:52:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ah, I had not realized that there was more than 1 newline. GitHub's UI confused me here, so we're good to go
>
> GitHub's UI assumes the final line has an line break. If it is missing, it displays a red ? at the end of the last line. If there is an empty line showing up in the UI, then it is an additional empty line.

In this case, GitHub is actually not showing up extra empty lines, that they appear the same as the single line break in the end of the file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1639783594

From erikj at openjdk.org  Fri Jun 14 12:56:23 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 14 Jun 2024 12:56:23 GMT
Subject: RFR: 8331552: Update to use jtreg 7.4
In-Reply-To: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
References: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
Message-ID: <Lw5hiQMCpWyfjueoBhj-8gw0_40ePNV-qDohejw2a7Q=.dc5bae5b-ef5f-42b7-9130-8d9a03c99f16@github.com>

On Thu, 2 May 2024 09:48:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using `jtreg` **7.4**.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> Testing: _tier1-tier5 pending..._

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19052#pullrequestreview-2118319536

From kevinw at openjdk.org  Fri Jun 14 13:14:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 13:14:20 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <KeRilLtCKTM3jP18PozO7NI_Ieo-_uh-3mWO27Rt1oQ=.756806c0-5f3b-4ec2-879e-fdec75ff85ad@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <KeRilLtCKTM3jP18PozO7NI_Ieo-_uh-3mWO27Rt1oQ=.756806c0-5f3b-4ec2-879e-fdec75ff85ad@github.com>
Message-ID: <30Q_v5zgWDNzJUXQo5uBAih3kIK-nLIVAS0_xF3XMoM=.aa810cbb-7e2e-4820-8639-1f910f3aa8e1@github.com>

On Fri, 14 Jun 2024 12:44:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 353:
>> 
>>> 351:         } else {
>>> 352:             return Subject.getSubject(AccessController.getContext());
>>> 353:         }
>> 
>> `Subject.current()` should work for both cases. See the impl of it.
>
> It will work to get the Subject yes.
> Do I not need the SM-enabled case, in case there some complex ACC in place? (combiner)

OK if it was actually getting specifically the ACC to use it maybe, but this just needs to resolve a Subject.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639806380

From kevinw at openjdk.org  Fri Jun 14 13:18:43 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 13:18:43 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v11]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <D5aPpZ1ztgkqOrAsBLdKwhswV1LaZq768JnTrlTL-_0=.df10967f-337d-4a59-92ed-0f61ce7afcc2@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  ServerNotifForwarder simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/09c2e38f..242af991

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=09-10

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Fri Jun 14 13:32:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 13:32:35 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v12]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <B6JqYnJx2aAVySUD-ta0R33GCCa9UEFN8KUJ8MPZ7rQ=.a7d36422-1323-4a0a-9215-fe05a48d2942@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Monitor update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/242af991..d5f68b02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=10-11

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Fri Jun 14 13:32:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 13:32:35 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v6]
In-Reply-To: <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <UfbHbHmERqKrWXhjn_VY4hysejiaffocwcXbrdtBOTE=.a6d76ad7-d8d0-4902-b8fc-7923114354ef@github.com>
 <9-rVW9nfDDLnACIukXpJiHoqoDQ-YBZKCpnjOF4e-F0=.ff6642c0-505c-4f1a-badf-3d7a72c333f5@github.com>
Message-ID: <PeQtD6VTA4AfMW-PkeciZpCfvP7LVR3Pq23bHz-RKfE=.81507ef5-4981-4061-b32f-447748ac1a36@github.com>

On Wed, 12 Jun 2024 20:52:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Undo test policy updates
>
> src/java.management/share/classes/javax/management/monitor/Monitor.java line 1543:
> 
>> 1541:                 // No SecurityManager:
>> 1542:                 Subject.doAs(s, action); // s is permitted to be null
>> 1543:             } else {
> 
> Even though ac should never be null, I would keep the original check for ac == null inside the SM code path to be safe and consistent with the original code, and use only call doAs if allowSM is false, so like:
> 
> 
> if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>     // No SecurityManager:
>     Subject.doAs(s, action); // s is permitted to be null
> } else {
>     if (ac == null) {
>         throw new SecurityException("AccessControlContext cannot be null");
>     }
>     // ACC means SM is permitted.
>     AccessController.doPrivileged(action, ac);
> }

ok done!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639833457

From kevinw at openjdk.org  Fri Jun 14 14:03:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 14:03:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
Message-ID: <5q2H_Fgz9nY_ykqrqhsfSXv8zQgpfkEOmdUpaAwN3Q0=.d58059e5-d408-4356-824d-413eda97a347@github.com>

On Fri, 14 Jun 2024 12:03:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Separate SM allowed and not allowed cases
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1461:
> 
>> 1459:                 throw rte;
>> 1460:             } else {
>> 1461:                 throw new PrivilegedActionException(e);
> 
> The 4 lines above seems unnecessary now. Plus, do not wrap `PrivilegedActionException` inside `PrivilegedActionException`.

It needs to recognise and throw RuntimeException so that a SecurityException isn't wrapped in a PrivilegedActionException (which gets caught by those blocks of code which call extractException(pe) and  look at what Exception it contains).

(test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java tests this)

I can add a check to make sure PrivilgedActionException doesn't get wrapped.  Daniel I think mentioned this also.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639876260

From weijun at openjdk.org  Fri Jun 14 14:51:18 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Jun 2024 14:51:18 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <cp-kNjl5sDRtOtdqgru1Vvs7zS3cQ4yq1lAnzQlrBXw=.e09c9e03-46b5-4fca-856d-cc064f09e495@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <cp-kNjl5sDRtOtdqgru1Vvs7zS3cQ4yq1lAnzQlrBXw=.e09c9e03-46b5-4fca-856d-cc064f09e495@github.com>
Message-ID: <ALogI3wbbzp9cQ-2KJKwXjcPLsWa5wkqUdX8N5qgCyc=.ff71b0c6-ba82-4231-867f-3b88b9497db8@github.com>

On Fri, 14 Jun 2024 12:41:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Does noPermissionsACC add anything?

I don't know. My principal for this code change is that nothing is changed for the SM-is-allowed case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2168203868

From weijun at openjdk.org  Fri Jun 14 14:54:22 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Jun 2024 14:54:22 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <5q2H_Fgz9nY_ykqrqhsfSXv8zQgpfkEOmdUpaAwN3Q0=.d58059e5-d408-4356-824d-413eda97a347@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <5q2H_Fgz9nY_ykqrqhsfSXv8zQgpfkEOmdUpaAwN3Q0=.d58059e5-d408-4356-824d-413eda97a347@github.com>
Message-ID: <12KzjRFhvphnxSWCNUA5wqcZgOqD4gKNjGf2rfqZMN8=.77983b3e-10b0-4742-86c3-b940f59d4e46@github.com>

On Fri, 14 Jun 2024 14:00:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1461:
>> 
>>> 1459:                 throw rte;
>>> 1460:             } else {
>>> 1461:                 throw new PrivilegedActionException(e);
>> 
>> The 4 lines above seems unnecessary now. Plus, do not wrap `PrivilegedActionException` inside `PrivilegedActionException`.
>
> It needs to recognise and throw RuntimeException so that a SecurityException isn't wrapped in a PrivilegedActionException (which gets caught by those blocks of code which call extractException(pe) and  look at what Exception it contains).
> 
> (test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java tests this)
> 
> I can add a check to make sure PrivilgedActionException doesn't get wrapped.  Daniel I think mentioned this also.

I still don't understand how a SecurityException could be wrapped into a PAE without these lines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639950681

From kevinw at openjdk.org  Fri Jun 14 15:21:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 15:21:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <12KzjRFhvphnxSWCNUA5wqcZgOqD4gKNjGf2rfqZMN8=.77983b3e-10b0-4742-86c3-b940f59d4e46@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <5q2H_Fgz9nY_ykqrqhsfSXv8zQgpfkEOmdUpaAwN3Q0=.d58059e5-d408-4356-824d-413eda97a347@github.com>
 <12KzjRFhvphnxSWCNUA5wqcZgOqD4gKNjGf2rfqZMN8=.77983b3e-10b0-4742-86c3-b940f59d4e46@github.com>
Message-ID: <2SJaGWGbzMoPydmzRN5rE_9uEWjNlCY_tFQCU06AcTw=.286f68b1-50ec-4223-b56b-b59f20ebdfc1@github.com>

On Fri, 14 Jun 2024 14:51:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> It needs to recognise and throw RuntimeException so that a SecurityException isn't wrapped in a PrivilegedActionException (which gets caught by those blocks of code which call extractException(pe) and  look at what Exception it contains).
>> 
>> (test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java tests this)
>> 
>> I can add a check to make sure PrivilgedActionException doesn't get wrapped.  Daniel I think mentioned this also.
>
> I still don't understand how a SecurityException could be wrapped into a PAE without these lines.

I misunderstood the comment, yes I think I can remove this block now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1639983304

From kevinw at openjdk.org  Fri Jun 14 15:26:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Jun 2024 15:26:54 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v13]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Unnecessary catches to remove

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/d5f68b02..13d9202f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=11-12

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From lmesnik at openjdk.org  Fri Jun 14 15:35:25 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 14 Jun 2024 15:35:25 GMT
Subject: Integrated: 8330702: Update failure handler to don't generate Error
 message if cores actions are empty
In-Reply-To: <rDvdKl90aCp8AXBSFjWULjZxRwVYjnIH65s8CPBCL_M=.65ca8ddb-17e2-4e4e-9911-3dd176d6a9e7@github.com>
References: <rDvdKl90aCp8AXBSFjWULjZxRwVYjnIH65s8CPBCL_M=.65ca8ddb-17e2-4e4e-9911-3dd176d6a9e7@github.com>
Message-ID: <1GboUj_AdcJeyF1gi8Km6mPYs5ph3oiN7DjN8_wc5n8=.18ff2151-3eb3-4ad9-b268-c43d7136a241@github.com>

On Thu, 30 May 2024 02:28:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The message is generated if cores (or any other tools) section doesn't exist or is empty. However, there is no any tool for cores processing now defined. So ERROR message is generating, confusing users.
> The fix is to don't print error for empty toolset which is the valid case. The message is still generate is tool is not defined to get error message in the case of miswriting.

This pull request has now been integrated.

Changeset: 548e95a6
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/548e95a689d63e97ddbdfe7dd7df3a2e3377046c
Stats:     9 lines in 2 files changed: 5 ins; 0 del; 4 mod

8330702: Update failure handler to don't generate Error message if cores actions are empty

Reviewed-by: sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/19470

From liach at openjdk.org  Fri Jun 14 17:02:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Jun 2024 17:02:40 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v2]
In-Reply-To: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
Message-ID: <bBEJNOFm1d8dtYtNMorLWhE5NVt2XSY5orJodx0FCno=.d1babf90-203c-4f1a-b0e3-745eafddee7a@github.com>

> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
> 
> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - I am a dumbass
 - Retain strict flag for Method, even though it's obsolete

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19708/files
  - new: https://git.openjdk.org/jdk/pull/19708/files/1cf092f4..84506788

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19708&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19708&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19708/head:pull/19708

PR: https://git.openjdk.org/jdk/pull/19708

From duke at openjdk.org  Fri Jun 14 17:28:47 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 14 Jun 2024 17:28:47 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v10]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <Z5QZG6wvjuQHy4ouxvqHV7mRiErEwZdxS7i0GPlKyHM=.2d7da8a1-773f-4e6e-8f8c-5ff3d080ec16@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  copyright 2024

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/b5ad8e70..1a012f1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=08-09

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From valeriep at openjdk.org  Fri Jun 14 17:51:13 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Jun 2024 17:51:13 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v2]
In-Reply-To: <wcJ6GKdi7u7cnPWXmmVM0csgsMqCAVKnvv3rh_JbbHQ=.a09faac2-4840-48b0-b7ad-d8bcffbacc4a@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <lDGxLyg7zdiGmxJIr-ewn8bWUJd6uoGprd9TUQxHo8c=.6fb5aef2-e997-44c4-8f75-f611b87e14cb@github.com>
 <YINw_j9qbVQjElu5BRO10mo7oRHFB2xdNdXclxzV2I0=.9183cc29-ce1f-4d41-a5ae-c61f825b11e8@github.com>
 <wcJ6GKdi7u7cnPWXmmVM0csgsMqCAVKnvv3rh_JbbHQ=.a09faac2-4840-48b0-b7ad-d8bcffbacc4a@github.com>
Message-ID: <Bsy4Uck2TL50fWnQ1lSkfyNzvajeQUTjv0X1bpb_xEc=.992868c9-9783-4c42-a684-b7bc6c74c489@github.com>

On Fri, 14 Jun 2024 09:47:31 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/SHA3.java line 73:
>> 
>>> 71:     // The following array is allocated to size WIDTH bytes, but we only
>>> 72:     // ever use the first blockSize bytes it (for bytes <-> long conversions)
>>> 73:     private byte[] byteState = new byte[WIDTH];
>> 
>> Since we are storing the state in longs now, this "byte <-> long" conversion can be made through a local variable, right? Is there a reason for having this `byteState` field with size WIDTH bytes?
>
> This is interesting: if I use WIDTH (or in blockSize) long arrays in the local level, the performance drops a few per cents. Even more when I only declare the local array in the block in which it is used. However, since we really only need 8 bytes, if I allocate that at the beginning of the function, I don't see that performance drop. So I rewrote the output loop in the function and got rid of the class level declaration.

Interesting...
Good that we go with the local 8-byte approach, it improves the readability also.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1640166504

From valeriep at openjdk.org  Fri Jun 14 18:07:12 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Jun 2024 18:07:12 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v3]
In-Reply-To: <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>
Message-ID: <r1l2EtsFvRtkfN4XOlZb_h7wOJkuVGJXYtkber3YlH4=.5666c201-14ca-4cbf-91b5-f5f4d8e35d18@github.com>

On Fri, 14 Jun 2024 10:39:45 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accept more review suggestions

src/java.base/share/classes/sun/security/provider/SHA3.java line 137:

> 135:             asLittleEndian.set(out, ofs, state[numLongs - 1]);
> 136:         } else {
> 137:             asLittleEndian.set(byteState, 0, state[numLongs - 1]);

So, is the performance better placing the `byteState` declaration up there at line 111 instead of here? It's only used in this block...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19632#discussion_r1640180265

From valeriep at openjdk.org  Fri Jun 14 18:15:16 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Jun 2024 18:15:16 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v3]
In-Reply-To: <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
 <Pf0FY7qnaAAS8PyNdHuymTc2dGx8iN6fAJTgViMAO4E=.809ceac7-16ee-4033-a9b0-a2c61e0dd96c@github.com>
Message-ID: <lqIk2-MeCSnlG3TjY7c7TBXn7YcEMRp_WvoNxzDItNw=.9b29f117-2c49-46be-bb20-c184dc3e2e8b@github.com>

On Fri, 14 Jun 2024 10:39:45 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accept more review suggestions

Looks good

-------------

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19632#pullrequestreview-2118989182

From ihse at openjdk.org  Fri Jun 14 19:31:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Jun 2024 19:31:37 GMT
Subject: RFR: 8333268: Fixes for static build
Message-ID: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>

This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:

1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).

2) Remove the work-arounds to exclude duplicated symbols.

3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.

The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

-------------

Commit messages:
 - Merge branch 'master' into static-linking-progress
 - Move the exported JVM_IsStaticallyLinked to a better location
 - Use runtime lookup of static vs dynamic instead of #ifdef STATIC_BUILD
 - Copy fix for init_system_properties_values on linux
 - Make sure we do not try to build static libraries on Windows
 - 8333268: Fixes for static build

Changes: https://git.openjdk.org/jdk/pull/19478/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333268
  Stats: 440 lines in 28 files changed: 203 ins; 74 del; 163 mod
  Patch: https://git.openjdk.org/jdk/pull/19478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19478/head:pull/19478

PR: https://git.openjdk.org/jdk/pull/19478

From ihse at openjdk.org  Fri Jun 14 19:31:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Jun 2024 19:31:37 GMT
Subject: RFR: 8333268: Fixes for static build
In-Reply-To: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
Message-ID: <P32-FWD7brdEivGnFEvOsk5z2BajBIAseIVn_EM7Hw0=.bce78cf4-a2d0-4b4a-b287-6953350e90c5@github.com>

On Thu, 30 May 2024 13:00:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
> 
> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
> 
> 2) Remove the work-arounds to exclude duplicated symbols.
> 
> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
> 
> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Some open questions:

* Do `os::lookup_function` need to be implemented on Windows too, for symmetry, even if it is only used on Unix platforms?

* Many of the changes in Hotspot boils down to `os::dll_load` doing the wrong thing when running with a static build. Perhaps we should provide a better function that knows how to find and load a symbol for both static and dynamic builds, and use that instead of making a lot of tests for static/dynamic on each location we need to look up a symbol from some other JDK library.

* I managed to replace most of the #ifdef STATIC_BUILD with runtime checks. There are some places remaining though. Apart from the #ifdefs needed for JNI/JVMTI, which will need spec changes to address, there are code in java_md_macosx.m, jio.c and awt_Mlib.c that I did not manage to turn into runtime checks. They will need some more thorough work than just changing an `#ifdef` to an `if () {`.

* And of course, the code in the build system to share all .o files except the two linktype files is still under development...

I moved this away from Draft state, since I think it needs some visibility, especially since it touches several different parts of the code base, and such reviews tend to take time.

I think the code here is good and basically okay to integrate. This patch will not on it's own solve the entire problem of building a proper static launcher, but it takes several important steps along the way. I think the changes here are reasonable to integrate into mainline at this point.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19478#issuecomment-2140743300
PR Comment: https://git.openjdk.org/jdk/pull/19478#issuecomment-2168635393

From ihse at openjdk.org  Fri Jun 14 19:41:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Jun 2024 19:41:10 GMT
Subject: RFR: 8333268: Fixes for static build
In-Reply-To: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
Message-ID: <NnDIe2LJxYesrpN5Ivzi_Bji_uYNg8VmqAu-iZHeO5w=.c8e4cbe4-a979-461a-8e21-dd34477dd6f4@github.com>

On Thu, 30 May 2024 13:00:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
> 
> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
> 
> 2) Remove the work-arounds to exclude duplicated symbols.
> 
> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
> 
> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

The GHA tests fails when building gtest on Linux. This will require some investigation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19478#issuecomment-2168647325

From duke at openjdk.org  Sat Jun 15 02:09:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 02:09:38 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal
Message-ID: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>

The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).

This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.

The following code comments the allocated objects to be removed.


class FloatToDecimal {
    public static String toString(float v) {
        // allocate object FloatToDecimal
        return new FloatToDecimal().toDecimalString(v);
    }

    public static Appendable appendTo(float v, Appendable app)
            throws IOException {
        // allocate object FloatToDecimal
        return new FloatToDecimal().appendDecimalTo(v, app);
    }

    private Appendable appendDecimalTo(float v, Appendable app)
            throws IOException {
        switch (toDecimal(v)) {
            case NON_SPECIAL:
                // allocate object char[]
                char[] chars = new char[index + 1];
                for (int i = 0; i < chars.length; ++i) {
                    chars[i] = (char) bytes[i];
                }
                if (app instanceof StringBuilder builder) {
                    return builder.append(chars);
                }
                if (app instanceof StringBuffer buffer) {
                    return buffer.append(chars);
                }
                for (char c : chars) {
                    app.append(c);
                }
                return app;
            // ...
        }
    }
}

class DoubleToDecimal {
    public static String toString(double v) {
        // allocate object DoubleToDecimal
        return new DoubleToDecimal(false).toDecimalString(v);
    }

    public static Appendable appendTo(double v, Appendable app)
            throws IOException {
        // allocate object DoubleToDecimal
        return new DoubleToDecimal(false).appendDecimalTo(v, app);
    }

    private Appendable appendDecimalTo(double v, Appendable app)
            throws IOException {
        switch (toDecimal(v, null)) {
            case NON_SPECIAL:
                // allocate object char[]
                char[] chars = new char[index + 1];
                for (int i = 0; i < chars.length; ++i) {
                    chars[i] = (char) bytes[i];
                }
                if (app instanceof StringBuilder builder) {
                    return builder.append(chars);
                }
                if (app instanceof StringBuffer buffer) {
                    return buffer.append(chars);
                }
                for (char c : chars) {
                    app.append(c);
                }
                return app;
            // ...
        }
    }
}

-------------

Commit messages:
 - Reduce object allocation for FloatToDecimal and DoubleToDecimal

Changes: https://git.openjdk.org/jdk/pull/19730/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334328
  Stats: 641 lines in 5 files changed: 293 ins; 211 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Sat Jun 15 02:36:11 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 02:36:11 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <I2eexIWNJgD8qAb-o5KCV2vBsts16Qdtm6xUN_2yZ1Y=.1afed891-5f31-40e7-af38-bd12dc282c4f@github.com>

On Sat, 15 Jun 2024 01:59:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

The performance numbers under `MacBookPro M1 Pro` & `MacBookPro 2018 i9` are as follows:

## Apple MacBookPro 2018
* CPU Intel i9 (x64)

-Benchmark                               Mode  Cnt    Score   Error  Units
-StringBuilders.appendWithFloat8Latin1   avgt   15  381.206 ? 8.681  ns/op
-StringBuilders.appendWithFloat8Utf16    avgt   15  366.549 ? 1.775  ns/op
-StringBuilders.appendWithDouble8Latin1  avgt   15  570.085 ? 8.040  ns/op
-StringBuilders.appendWithDouble8Utf16   avgt   15  501.409 ? 5.750  ns/op

+Benchmark                               Mode  Cnt    Score    Error  Units (Webrevs 00 4c810154)
+StringBuilders.appendWithFloat8Latin1   avgt   15  226.236 ?  3.350  ns/op +68.49%
+StringBuilders.appendWithFloat8Utf16    avgt   15  299.072 ? 19.895  ns/op +22.56%
+StringBuilders.appendWithDouble8Latin1  avgt   15  328.887 ?  5.865  ns/op +73.33%
+StringBuilders.appendWithDouble8Utf16   avgt   15  390.618 ? 30.142  ns/op +28.36%


## MacBook M1 Pro
* CPU Apple M1 Pro (aarch64)

-Benchmark                               Mode  Cnt    Score    Error  Units base
-StringBuilders.appendWithFloat8Latin1   avgt   15  317.144 ? 11.325  ns/op
-StringBuilders.appendWithFloat8Utf16    avgt   15  316.980 ? 17.955  ns/op
-StringBuilders.appendWithDouble8Latin1  avgt   15  440.853 ? 13.067  ns/op
-StringBuilders.appendWithDouble8Utf16   avgt   15  418.896 ?  4.610  ns/op


+Benchmark                               Mode  Cnt    Score    Error  Units (Webrevs 00 4c810154)
+StringBuilders.appendWithFloat8Latin1   avgt   15  168.231 ?  4.749  ns/op +88.51%
+StringBuilders.appendWithFloat8Utf16    avgt   15  213.981 ?  3.274  ns/op +48.13%
+StringBuilders.appendWithDouble8Latin1  avgt   15  241.536 ?  0.993  ns/op +82.52%
+StringBuilders.appendWithDouble8Utf16   avgt   15  284.863 ? 10.381  ns/op +47.05%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19730#issuecomment-2169061500

From liach at openjdk.org  Sat Jun 15 04:19:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 15 Jun 2024 04:19:13 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <ZhesgJkFoPjHOXnYIdQXFvVAxi78Kw8zZ5vjYk7fQ_M=.89b599fe-f787-43d8-88b7-01251c2b7b95@github.com>

On Sat, 15 Jun 2024 01:59:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 888:

> 886:      */
> 887:     public AbstractStringBuilder append(float f) {
> 888:         ensureCapacityInternal(count + FloatToDecimal.MAX_CHARS);

This might cause failure in edge cases where the array size reaches the limit. Might need some review on how big an impact this would be.

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 41:

> 39: public final class DoubleToDecimal extends ToDecimal {
> 40:     public static DoubleToDecimal LATIN1 = new DoubleToDecimal(ToDecimal.LATIN1);
> 41:     public static DoubleToDecimal UTF16  = new DoubleToDecimal(ToDecimal.UTF16);

Suggestion:

    public static final DoubleToDecimal LATIN1 = new DoubleToDecimal(ToDecimal.LATIN1);
    public static final DoubleToDecimal UTF16  = new DoubleToDecimal(ToDecimal.UTF16);

For constant folding.

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 44:

> 42: 
> 43:     /*
> 44:      * For full details about this code see the following references:

We should copy these comments to `ToDecimal`; otherwise, it's not obvious what references are being made in comments there.

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 41:

> 39: public sealed class ToDecimal permits DoubleToDecimal, FloatToDecimal{
> 40:     static final byte LATIN1 = 0;
> 41:     static final byte UTF16  = 1;

@cl4es All these string latin1 vs utf16 infrastructure are duplicates of those in StringLatin1 and StringUTF16 in java.lang. Should we move those String internals to jdk.internal packages so it's more accessible to such coder-aware special optimizations, like we did with ConstantDesc?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1640634700
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1640634754
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1640742561
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1640632467

From duke at openjdk.org  Sat Jun 15 04:57:20 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 04:57:20 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal
In-Reply-To: <ZhesgJkFoPjHOXnYIdQXFvVAxi78Kw8zZ5vjYk7fQ_M=.89b599fe-f787-43d8-88b7-01251c2b7b95@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <ZhesgJkFoPjHOXnYIdQXFvVAxi78Kw8zZ5vjYk7fQ_M=.89b599fe-f787-43d8-88b7-01251c2b7b95@github.com>
Message-ID: <Wsg_MJrnVxb3WhRrD50tbX0DUVYFTA_jfBQBRxGmAds=.6ccf5c71-8b3c-4bc3-a67b-5fe50de8f59f@github.com>

On Sat, 15 Jun 2024 03:02:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 888:
> 
>> 886:      */
>> 887:     public AbstractStringBuilder append(float f) {
>> 888:         ensureCapacityInternal(count + FloatToDecimal.MAX_CHARS);
> 
> This might cause failure in edge cases where the array size reaches the limit. Might need some review on how big an impact this would be.

The maximum length of float to decimal is 15, and the maximum length of double to decimal is 24. The original exception handling was because the Appendable#append(char) method threw an IOException, which is no longer necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1640755241

From duke at openjdk.org  Sat Jun 15 05:05:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 05:05:38 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v2]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <V4zeOvF-_irPg5KUyk57UQvhSuTUAUVznhlKAYgPvcE=.14b2eae7-6457-4f0f-a45e-859892f06499@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
  
  Co-authored-by: Chen Liang <liangchenblue at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/4c810154..b7c3586e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Sat Jun 15 05:10:36 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 05:10:36 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v3]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <bbqqxa9JEyTy4-uNo5-L445Y3auHdcayOP1-Badpsrg=.287aa76c-c8b8-4918-b962-20050134d1fa@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add final modifier & comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/b7c3586e..95097e1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=01-02

  Stats: 15 lines in 2 files changed: 10 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From dholmes at openjdk.org  Sat Jun 15 05:12:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 15 Jun 2024 05:12:15 GMT
Subject: RFR: 8333962: Obsolete OldSize [v2]
In-Reply-To: <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
 <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
Message-ID: <eDaHUlPPWSTYvNZmB6J6HeieREWM8ErG0BFre32v6aQ=.984ccd13-b3ac-4516-aa6b-24dfed96cd22@github.com>

On Fri, 14 Jun 2024 10:19:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   obsolete-old-size

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/runtime/arguments.cpp line 37:

> 35: #include "gc/shared/gcArguments.hpp"
> 36: #include "gc/shared/gcConfig.hpp"
> 37: #include "gc/shared/genArguments.hpp"

Why is this needed?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19647#pullrequestreview-2120074670
PR Review Comment: https://git.openjdk.org/jdk/pull/19647#discussion_r1640761871

From duke at openjdk.org  Sat Jun 15 05:30:48 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 05:30:48 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v4]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <8qJmhf8vBotd8tWz7yLFmzhuKE6zu_dIantwSXngF6E=.cf85b0df-49fe-48a0-8c5e-2006402d16e4@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use JLA replace Unsafe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/95097e1f..761e1087

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=02-03

  Stats: 33 lines in 1 file changed: 1 ins; 24 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Sat Jun 15 05:30:48 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 05:30:48 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v4]
In-Reply-To: <ZhesgJkFoPjHOXnYIdQXFvVAxi78Kw8zZ5vjYk7fQ_M=.89b599fe-f787-43d8-88b7-01251c2b7b95@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <ZhesgJkFoPjHOXnYIdQXFvVAxi78Kw8zZ5vjYk7fQ_M=.89b599fe-f787-43d8-88b7-01251c2b7b95@github.com>
Message-ID: <L46dwTOhtN0KYNaZYUfaHukM--ZCBmrkfzD_i6wkTJs=.a6036b24-f69c-453d-84fa-05464039d94e@github.com>

On Sat, 15 Jun 2024 02:45:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use JLA replace Unsafe
>
> src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 41:
> 
>> 39: public sealed class ToDecimal permits DoubleToDecimal, FloatToDecimal{
>> 40:     static final byte LATIN1 = 0;
>> 41:     static final byte UTF16  = 1;
> 
> @cl4es All these string latin1 vs utf16 infrastructure are duplicates of those in StringLatin1 and StringUTF16 in java.lang. Should we move those String internals to jdk.internal packages so it's more accessible to such coder-aware special optimizations, like we did with ConstantDesc?

I have used JavaLangAccess instead of Usnafe

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1640769814

From duke at openjdk.org  Sat Jun 15 05:39:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 05:39:42 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v5]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <Xkxgr2mPC5Onpl-VSA1f-W-3y7GAPg-3vzaQlfzKkZg=.a297efd4-6a48-4b34-b8b0-fd55ac868887@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/761e1087..d28e83a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Sat Jun 15 05:50:40 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 05:50:40 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v6]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <6RaAjGjbpIpie9akGOMskkILjFgLR08MbgspQx5pv34=.f1219e28-86bd-4745-a841-c219886346ed@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/d28e83a9..8a649c72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=04-05

  Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From ayang at openjdk.org  Sat Jun 15 08:54:14 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 15 Jun 2024 08:54:14 GMT
Subject: RFR: 8333962: Obsolete OldSize [v2]
In-Reply-To: <eDaHUlPPWSTYvNZmB6J6HeieREWM8ErG0BFre32v6aQ=.984ccd13-b3ac-4516-aa6b-24dfed96cd22@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
 <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
 <eDaHUlPPWSTYvNZmB6J6HeieREWM8ErG0BFre32v6aQ=.984ccd13-b3ac-4516-aa6b-24dfed96cd22@github.com>
Message-ID: <--FcnwH_fA8e27VK3SwN0vJZZW8yZsyxh2I2jul-Enk=.3cd55bc7-b0ac-4ef6-93a1-b880ff255bd3@github.com>

On Sat, 15 Jun 2024 05:09:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   obsolete-old-size
>
> src/hotspot/share/runtime/arguments.cpp line 37:
> 
>> 35: #include "gc/shared/gcArguments.hpp"
>> 36: #include "gc/shared/gcConfig.hpp"
>> 37: #include "gc/shared/genArguments.hpp"
> 
> Why is this needed?

`Arguments::set_heap_size` accesses `OldSize`, which is declared in this header.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19647#discussion_r1640921256

From syan at openjdk.org  Sat Jun 15 10:00:35 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 15 Jun 2024 10:00:35 GMT
Subject: RFR: 8334333: Run test MissingResourceCauseTestRun.java with root user
 fails
Message-ID: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>

Hi all,
Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
The change has been verified, only change the testcase, no risk.

-------------

Commit messages:
 - 8334333: Run test MissingResourceCauseTestRun.java with root user fails

Changes: https://git.openjdk.org/jdk/pull/19732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334333
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19732/head:pull/19732

PR: https://git.openjdk.org/jdk/pull/19732

From duke at openjdk.org  Sat Jun 15 11:24:40 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 11:24:40 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v7]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <S669aANd5fcgqKEQtUlPzn8dn3aygG7u8E-6N4vpwfo=.95bc8062-f0e2-482b-af50-1c6ebcb02eba@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  ToDecimal remove `public` modifier & code format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/8a649c72..9a4cf5ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=05-06

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Sat Jun 15 13:27:41 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 15 Jun 2024 13:27:41 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v8]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  code format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/9a4cf5ac..5a432c9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=06-07

  Stats: 17 lines in 3 files changed: 0 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From weijun at openjdk.org  Sun Jun 16 01:57:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 16 Jun 2024 01:57:23 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v13]
In-Reply-To: <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
Message-ID: <sRb3ETsM2lP1ZBPr7zlspeHqYQMjA07Wb6YbcJhCyLQ=.5534d0b1-08dc-45f0-83a1-8ef097838878@github.com>

On Fri, 14 Jun 2024 15:26:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unnecessary catches to remove

src/java.management/share/classes/javax/management/monitor/Monitor.java line 1542:

> 1540:             if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
> 1541:                 // No SecurityManager permitted:
> 1542:                 Subject.doAs(s, action); // s is permitted to be null

While `s` is permitted to be null, calling `Subject.doAs(null, action)` actually sets the current subject to null while calling `action`. This is not same as directly calling `action` where the current subject (could be non null) is used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1641593366

From jpai at openjdk.org  Sun Jun 16 06:36:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Jun 2024 06:36:00 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v3]
In-Reply-To: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
Message-ID: <KqGzPBLAm2OLjIlyxoikQw_-EPBHPkQjojjKxXRNts8=.2576c1c8-1c5c-4965-8bd8-001f71267a66@github.com>

> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
> 
> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
> 
> To summarize those discussions, we had concluded that:
> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
> 
> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
> 
> I'll file a CSR shortly.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Chen's suggestion - improve code comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19675/files
  - new: https://git.openjdk.org/jdk/pull/19675/files/79e68e91..4a52fe2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675

PR: https://git.openjdk.org/jdk/pull/19675

From jpai at openjdk.org  Sun Jun 16 11:44:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Jun 2024 11:44:24 GMT
Subject: RFR: 8331552: Update to use jtreg 7.4
In-Reply-To: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
References: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
Message-ID: <Epe_zHAcXHuHMTF9il2gI-MNKep1LzYvUUCnl6o4uhU=.c23b3abb-9dcf-444f-88e9-ce36039a4c76@github.com>

On Thu, 2 May 2024 09:48:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using `jtreg` **7.4**.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> Testing: _tier1-tier5 pending..._

Looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19052#pullrequestreview-2121354181

From jpai at openjdk.org  Sun Jun 16 11:47:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Jun 2024 11:47:24 GMT
Subject: RFR: 8331552: Update to use jtreg 7.4
In-Reply-To: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
References: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
Message-ID: <D7Yp_tZfukwv5xOFURvLsqZvkPneK-P0mmca_GPYDSg=.4cd029d0-cc47-490b-8721-6f85d6ca255c@github.com>

On Thu, 2 May 2024 09:48:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using `jtreg` **7.4**.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> Testing: _tier1-tier5 pending..._

Hello Christian, it would be better to merge latest master branch into this PR before integrating this. It looks like it currently uses `master` from more than a month back.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19052#issuecomment-2171466397

From duke at openjdk.org  Sun Jun 16 14:26:33 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 16 Jun 2024 14:26:33 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks
Message-ID: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>

[8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.

-------------

Commit messages:
 - code format
 - add `setIntRL` & `setIntRLU`
 - add comments
 - add comments
 - copyright
 - add MergeStore Benchmark

Changes: https://git.openjdk.org/jdk/pull/19734/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334342
  Stats: 870 lines in 1 file changed: 870 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19734/head:pull/19734

PR: https://git.openjdk.org/jdk/pull/19734

From duke at openjdk.org  Sun Jun 16 14:26:33 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 16 Jun 2024 14:26:33 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks
In-Reply-To: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
Message-ID: <sCgGgiTFZAQ1-yc8QRgTh1kkHkxWaJqLi3jfJqYneDw=.7cf00853-5163-40a3-97d5-bd07148771d4@github.com>

On Sun, 16 Jun 2024 07:17:16 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> [8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.

# 1. Cases MergeStore does not work

>From the results of running the test, the following method MergeStore does not work


getIntB    
getIntBU   
getIntL    
getIntLU   
getIntRB   
getIntRBU  
getIntRL   
getIntRLU  
getLongB   
getLongBU  
getLongL   
getLongLU  
getLongRB  
getLongRBU 
getLongRL  
getLongRLU 
putChars4UC
setIntB    
setIntBU 
setIntRB    
setIntRBU   
setLongB
setLongBU  
setLongRB  
setLongRBU 


@eme64 Please help me find out what the reason is and whether it can be improved.

# 2. Performance numbers

The names of these cases have the following `B/L/V/U` suffixes, which are:

B BigEndian
L LittleEndian
V VarHandle
U Unsafe
R reverseBytes


## 2.1 MacBook M1 Pro (aarch64)

Benchmark                    Mode  Cnt      Score    Error  Units
MergeStoreBench.getIntB      avgt   15   6286.579 ? 20.457  ns/op
MergeStoreBench.getIntBU     avgt   15   5225.216 ?  8.330  ns/op
MergeStoreBench.getIntBV     avgt   15   1210.682 ?  9.729  ns/op
MergeStoreBench.getIntL      avgt   15   6164.693 ? 10.310  ns/op
MergeStoreBench.getIntLU     avgt   15   5143.012 ? 14.522  ns/op
MergeStoreBench.getIntLV     avgt   15   2559.030 ?  3.875  ns/op
MergeStoreBench.getIntRB     avgt   15   6878.932 ? 33.494  ns/op
MergeStoreBench.getIntRBU    avgt   15   5767.165 ?  5.969  ns/op
MergeStoreBench.getIntRL     avgt   15   6627.529 ? 16.028  ns/op
MergeStoreBench.getIntRLU    avgt   15   5751.723 ? 23.192  ns/op
MergeStoreBench.getIntRU     avgt   15   2545.811 ?  3.665  ns/op
MergeStoreBench.getIntU      avgt   15   2540.611 ?  1.315  ns/op
MergeStoreBench.getLongB     avgt   15  12089.536 ? 14.140  ns/op
MergeStoreBench.getLongBU    avgt   15   9781.314 ? 71.234  ns/op
MergeStoreBench.getLongBV    avgt   15   2592.388 ?  4.432  ns/op
MergeStoreBench.getLongL     avgt   15  12024.902 ? 12.263  ns/op
MergeStoreBench.getLongLU    avgt   15   9678.164 ? 66.240  ns/op
MergeStoreBench.getLongLV    avgt   15   2558.131 ?  4.451  ns/op
MergeStoreBench.getLongRB    avgt   15  12085.246 ? 13.510  ns/op
MergeStoreBench.getLongRBU   avgt   15   9764.272 ? 12.714  ns/op
MergeStoreBench.getLongRL    avgt   15  12030.738 ? 22.437  ns/op
MergeStoreBench.getLongRLU   avgt   15   9653.951 ? 29.618  ns/op
MergeStoreBench.getLongRU    avgt   15   2546.557 ?  2.935  ns/op
MergeStoreBench.getLongU     avgt   15   2540.195 ?  2.042  ns/op
MergeStoreBench.putChars4    avgt   15   8489.149 ? 12.100  ns/op
MergeStoreBench.putChars4UB  avgt   15   3829.348 ?  7.844  ns/op
MergeStoreBench.putChars4UC  avgt   15   4483.231 ?  2.922  ns/op
MergeStoreBench.setIntB      avgt   15   5098.299 ?  5.857  ns/op
MergeStoreBench.setIntBU     avgt   15   5100.068 ?  7.315  ns/op
MergeStoreBench.setIntBV     avgt   15   1225.125 ?  1.650  ns/op
MergeStoreBench.setIntL      avgt   15   2765.106 ?  4.291  ns/op
MergeStoreBench.setIntLU     avgt   15   2574.478 ?  6.680  ns/op
MergeStoreBench.setIntLV     avgt   15   5106.786 ?  1.659  ns/op
MergeStoreBench.setIntRB     avgt   15   5372.028 ? 38.223  ns/op
MergeStoreBench.setIntRBU    avgt   15   5413.775 ? 10.059  ns/op
MergeStoreBench.setIntRL     avgt   15   5289.971 ?  4.359  ns/op
MergeStoreBench.setIntRLU    avgt   15   5125.193 ?  1.667  ns/op
MergeStoreBench.setIntRU     avgt   15   5102.132 ? 10.858  ns/op
MergeStoreBench.setIntU      avgt   15   5104.280 ? 53.560  ns/op
MergeStoreBench.setLongB     avgt   15  10249.911 ? 12.840  ns/op
MergeStoreBench.setLongBU    avgt   15  10231.282 ?  6.696  ns/op
MergeStoreBench.setLongBV    avgt   15   2665.162 ?  5.059  ns/op
MergeStoreBench.setLongL     avgt   15   6306.266 ?  7.843  ns/op
MergeStoreBench.setLongLU    avgt   15   2878.446 ? 62.543  ns/op
MergeStoreBench.setLongLV    avgt   15   2663.849 ?  1.446  ns/op
MergeStoreBench.setLongRB    avgt   15  10250.651 ? 16.368  ns/op
MergeStoreBench.setLongRBU   avgt   15  10237.918 ? 14.213  ns/op
MergeStoreBench.setLongRL    avgt   15   6645.274 ?  9.166  ns/op
MergeStoreBench.setLongRLU   avgt   15   3227.096 ?  2.098  ns/op
MergeStoreBench.setLongRU    avgt   15   2609.076 ?  3.404  ns/op
MergeStoreBench.setLongU     avgt   15   2593.581 ?  1.021  ns/op


## 2.2 MacBook 2018 i9 (x64)
* CPU Intel i9

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getIntB      avgt   15  11342.301 ? 176.256  ns/op
MergeStoreBench.getIntBU     avgt   15   7151.310 ?  75.508  ns/op
MergeStoreBench.getIntBV     avgt   15    280.465 ?   2.483  ns/op
MergeStoreBench.getIntL      avgt   15  11124.116 ? 132.253  ns/op
MergeStoreBench.getIntLU     avgt   15   7126.255 ?  33.276  ns/op
MergeStoreBench.getIntLV     avgt   15   1840.656 ?  25.828  ns/op
MergeStoreBench.getIntRB     avgt   15  12084.764 ? 126.922  ns/op
MergeStoreBench.getIntRBU    avgt   15   7822.741 ? 136.473  ns/op
MergeStoreBench.getIntRL     avgt   15  11370.996 ? 150.874  ns/op
MergeStoreBench.getIntRLU    avgt   15   7638.077 ?  86.311  ns/op
MergeStoreBench.getIntRU     avgt   15   2278.221 ?  19.787  ns/op
MergeStoreBench.getIntU      avgt   15   2063.943 ?  10.099  ns/op
MergeStoreBench.getLongB     avgt   15  22398.302 ? 479.694  ns/op
MergeStoreBench.getLongBU    avgt   15  13656.548 ? 212.759  ns/op
MergeStoreBench.getLongBV    avgt   15    757.250 ?  13.629  ns/op
MergeStoreBench.getLongL     avgt   15  20721.523 ? 186.996  ns/op
MergeStoreBench.getLongLU    avgt   15  13647.936 ? 147.855  ns/op
MergeStoreBench.getLongLV    avgt   15   1855.380 ?  30.576  ns/op
MergeStoreBench.getLongRB    avgt   15  22258.859 ? 363.429  ns/op
MergeStoreBench.getLongRBU   avgt   15  13688.325 ? 111.394  ns/op
MergeStoreBench.getLongRL    avgt   15  20736.818 ? 134.670  ns/op
MergeStoreBench.getLongRLU   avgt   15  13648.559 ? 218.167  ns/op
MergeStoreBench.getLongRU    avgt   15   2962.730 ?  61.445  ns/op
MergeStoreBench.getLongU     avgt   15   2881.851 ?  31.687  ns/op
MergeStoreBench.putChars4    avgt   15   5842.259 ? 166.988  ns/op
MergeStoreBench.putChars4UB  avgt   15   3621.801 ?  36.636  ns/op
MergeStoreBench.putChars4UC  avgt   15   7728.219 ? 599.829  ns/op
MergeStoreBench.setIntB      avgt   15   9754.119 ? 100.943  ns/op
MergeStoreBench.setIntBU     avgt   15  12094.327 ?  88.931  ns/op
MergeStoreBench.setIntBV     avgt   15    546.581 ?  11.151  ns/op
MergeStoreBench.setIntL      avgt   15   2241.645 ?  21.620  ns/op
MergeStoreBench.setIntLU     avgt   15   5032.690 ?  39.638  ns/op
MergeStoreBench.setIntLV     avgt   15    727.206 ?   9.519  ns/op
MergeStoreBench.setIntRB     avgt   15  10787.160 ? 187.849  ns/op
MergeStoreBench.setIntRBU    avgt   15  12464.270 ? 121.011  ns/op
MergeStoreBench.setIntRL     avgt   15   5250.418 ?  85.523  ns/op
MergeStoreBench.setIntRLU    avgt   15   7677.631 ?  80.561  ns/op
MergeStoreBench.setIntRU     avgt   15   1011.738 ?   8.791  ns/op
MergeStoreBench.setIntU      avgt   15    791.924 ?  14.517  ns/op
MergeStoreBench.setLongB     avgt   15  17833.690 ? 127.313  ns/op
MergeStoreBench.setLongBU    avgt   15  26447.098 ? 168.301  ns/op
MergeStoreBench.setLongBV    avgt   15   1071.447 ?   8.947  ns/op
MergeStoreBench.setLongL     avgt   15   3724.440 ?  35.119  ns/op
MergeStoreBench.setLongLU    avgt   15   5339.593 ?  45.358  ns/op
MergeStoreBench.setLongLV    avgt   15   1069.890 ?  16.179  ns/op
MergeStoreBench.setLongRB    avgt   15  18908.125 ? 262.767  ns/op
MergeStoreBench.setLongRBU   avgt   15  27622.437 ? 689.809  ns/op
MergeStoreBench.setLongRL    avgt   15   4338.138 ? 115.879  ns/op
MergeStoreBench.setLongRLU   avgt   15   4585.764 ? 102.305  ns/op
MergeStoreBench.setLongRU    avgt   15   1121.779 ?  36.325  ns/op
MergeStoreBench.setLongU     avgt   15   1075.340 ?  17.020  ns/op


## 2.3 Aliyun ecs.c8a (x64)
* CPU AMD EPYCTM Genoa

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getIntB      avgt   15  11976.614 ?  19.245  ns/op
MergeStoreBench.getIntBU     avgt   15   9054.386 ?  12.848  ns/op
MergeStoreBench.getIntBV     avgt   15    304.320 ?   0.412  ns/op
MergeStoreBench.getIntL      avgt   15  10755.574 ? 360.835  ns/op
MergeStoreBench.getIntLU     avgt   15   8889.977 ?  17.342  ns/op
MergeStoreBench.getIntLV     avgt   15   2229.743 ?   3.334  ns/op
MergeStoreBench.getIntRB     avgt   15  12356.363 ?  17.140  ns/op
MergeStoreBench.getIntRBU    avgt   15  11132.557 ?  21.023  ns/op
MergeStoreBench.getIntRL     avgt   15  11218.259 ?  15.377  ns/op
MergeStoreBench.getIntRLU    avgt   15   9356.533 ?  16.075  ns/op
MergeStoreBench.getIntRU     avgt   15   2511.578 ?   4.710  ns/op
MergeStoreBench.getIntU      avgt   15   2497.917 ?   3.230  ns/op
MergeStoreBench.getLongB     avgt   15  26910.266 ?  54.383  ns/op
MergeStoreBench.getLongBU    avgt   15  14217.696 ?  20.862  ns/op
MergeStoreBench.getLongBV    avgt   15    602.235 ?   0.678  ns/op
MergeStoreBench.getLongL     avgt   15  26889.931 ?  43.526  ns/op
MergeStoreBench.getLongLU    avgt   15  14547.062 ?  39.383  ns/op
MergeStoreBench.getLongLV    avgt   15   2228.017 ?   3.593  ns/op
MergeStoreBench.getLongRB    avgt   15  26901.754 ?  29.490  ns/op
MergeStoreBench.getLongRBU   avgt   15  14212.233 ?  17.917  ns/op
MergeStoreBench.getLongRL    avgt   15  26904.774 ?  53.650  ns/op
MergeStoreBench.getLongRLU   avgt   15  14531.530 ?  26.863  ns/op
MergeStoreBench.getLongRU    avgt   15   3066.434 ?   5.223  ns/op
MergeStoreBench.getLongU     avgt   15   3056.801 ?   4.346  ns/op
MergeStoreBench.putChars4    avgt   15  13433.247 ?  19.357  ns/op
MergeStoreBench.putChars4UB  avgt   15   4209.355 ?  10.661  ns/op
MergeStoreBench.putChars4UC  avgt   15   3388.720 ?   7.222  ns/op
MergeStoreBench.setIntB      avgt   15   8044.968 ?  10.066  ns/op
MergeStoreBench.setIntBU     avgt   15  10359.992 ?  41.852  ns/op
MergeStoreBench.setIntBV     avgt   15    598.579 ?   2.360  ns/op
MergeStoreBench.setIntL      avgt   15   2548.295 ?   5.228  ns/op
MergeStoreBench.setIntLU     avgt   15   6179.865 ?  70.419  ns/op
MergeStoreBench.setIntLV     avgt   15    603.562 ?   1.408  ns/op
MergeStoreBench.setIntRB     avgt   15   9743.462 ?  22.873  ns/op
MergeStoreBench.setIntRBU    avgt   15  10673.845 ?  21.662  ns/op
MergeStoreBench.setIntRL     avgt   15   6216.996 ?   7.323  ns/op
MergeStoreBench.setIntRLU    avgt   15   8407.392 ? 108.065  ns/op
MergeStoreBench.setIntRU     avgt   15    635.986 ?   1.449  ns/op
MergeStoreBench.setIntU      avgt   15    610.444 ?   1.139  ns/op
MergeStoreBench.setLongB     avgt   15  17226.045 ?  32.847  ns/op
MergeStoreBench.setLongBU    avgt   15  21476.791 ?  90.608  ns/op
MergeStoreBench.setLongBV    avgt   15   1184.335 ?   1.624  ns/op
MergeStoreBench.setLongL     avgt   15   3352.579 ?   4.849  ns/op
MergeStoreBench.setLongLU    avgt   15   6227.171 ?   9.784  ns/op
MergeStoreBench.setLongLV    avgt   15   1194.549 ?   2.399  ns/op
MergeStoreBench.setLongRB    avgt   15  17967.391 ?  41.726  ns/op
MergeStoreBench.setLongRBU   avgt   15  21428.757 ?  25.568  ns/op
MergeStoreBench.setLongRL    avgt   15   4035.273 ?   6.881  ns/op
MergeStoreBench.setLongRLU   avgt   15   4858.090 ?  16.189  ns/op
MergeStoreBench.setLongRU    avgt   15   1169.711 ?   2.061  ns/op
MergeStoreBench.setLongU     avgt   15   1196.299 ?   1.978  ns/op


## 2.4 Aliyun ecs.c8i (x64)
CPU CPU Intel? Xeon? Emerald

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getIntB      avgt   15  10515.469 ?  21.610  ns/op
MergeStoreBench.getIntBU     avgt   15   9269.025 ?  16.736  ns/op
MergeStoreBench.getIntBV     avgt   15    255.475 ?   0.853  ns/op
MergeStoreBench.getIntL      avgt   15   9699.152 ?  57.865  ns/op
MergeStoreBench.getIntLU     avgt   15   8984.031 ?  13.596  ns/op
MergeStoreBench.getIntLV     avgt   15   2570.119 ?   1.924  ns/op
MergeStoreBench.getIntRB     avgt   15  11281.847 ?   3.579  ns/op
MergeStoreBench.getIntRBU    avgt   15  10323.475 ?  14.128  ns/op
MergeStoreBench.getIntRL     avgt   15  10566.386 ?   2.524  ns/op
MergeStoreBench.getIntRLU    avgt   15   9432.976 ?   2.876  ns/op
MergeStoreBench.getIntRU     avgt   15   2327.557 ?   0.471  ns/op
MergeStoreBench.getIntU      avgt   15   2311.914 ?   1.782  ns/op
MergeStoreBench.getLongB     avgt   15  21682.355 ?  30.503  ns/op
MergeStoreBench.getLongBU    avgt   15  14674.931 ?   3.452  ns/op
MergeStoreBench.getLongBV    avgt   15    652.253 ?   1.555  ns/op
MergeStoreBench.getLongL     avgt   15  21583.633 ?  28.439  ns/op
MergeStoreBench.getLongLU    avgt   15  14350.307 ?  31.842  ns/op
MergeStoreBench.getLongLV    avgt   15   2575.151 ?   0.376  ns/op
MergeStoreBench.getLongRB    avgt   15  21678.521 ?   5.962  ns/op
MergeStoreBench.getLongRBU   avgt   15  14678.208 ?  23.997  ns/op
MergeStoreBench.getLongRL    avgt   15  21576.705 ?   2.667  ns/op
MergeStoreBench.getLongRLU   avgt   15  14341.769 ?  22.908  ns/op
MergeStoreBench.getLongRU    avgt   15   2986.505 ?   0.574  ns/op
MergeStoreBench.getLongU     avgt   15   2940.918 ?   0.348  ns/op
MergeStoreBench.putChars4    avgt   15  10438.053 ?  15.578  ns/op
MergeStoreBench.putChars4UB  avgt   15   3015.499 ?   7.300  ns/op
MergeStoreBench.putChars4UC  avgt   15   5317.663 ?   3.992  ns/op
MergeStoreBench.setIntB      avgt   15   6885.979 ?  11.822  ns/op
MergeStoreBench.setIntBU     avgt   15  10131.264 ?  30.389  ns/op
MergeStoreBench.setIntBV     avgt   15    898.844 ?   3.806  ns/op
MergeStoreBench.setIntL      avgt   15   2885.903 ?   3.228  ns/op
MergeStoreBench.setIntLU     avgt   15   5282.482 ?  59.298  ns/op
MergeStoreBench.setIntLV     avgt   15    949.442 ?   2.543  ns/op
MergeStoreBench.setIntRB     avgt   15   8152.273 ?  11.990  ns/op
MergeStoreBench.setIntRBU    avgt   15  10604.720 ?  19.430  ns/op
MergeStoreBench.setIntRL     avgt   15   5989.979 ?   4.767  ns/op
MergeStoreBench.setIntRLU    avgt   15   7261.499 ? 120.307  ns/op
MergeStoreBench.setIntRU     avgt   15    960.782 ?   2.784  ns/op
MergeStoreBench.setIntU      avgt   15    989.716 ?   1.030  ns/op
MergeStoreBench.setLongB     avgt   15  15865.777 ?  32.450  ns/op
MergeStoreBench.setLongBU    avgt   15  22843.580 ?  48.434  ns/op
MergeStoreBench.setLongBV    avgt   15   1814.973 ?   7.079  ns/op
MergeStoreBench.setLongL     avgt   15   4346.312 ?   1.318  ns/op
MergeStoreBench.setLongLU    avgt   15   5399.475 ?  35.513  ns/op
MergeStoreBench.setLongLV    avgt   15   1903.106 ?  22.995  ns/op
MergeStoreBench.setLongRB    avgt   15  16980.234 ?  34.819  ns/op
MergeStoreBench.setLongRBU   avgt   15  24924.078 ?  49.285  ns/op
MergeStoreBench.setLongRL    avgt   15   4483.791 ?   6.976  ns/op
MergeStoreBench.setLongRLU   avgt   15   5004.085 ?   3.843  ns/op
MergeStoreBench.setLongRU    avgt   15   1818.725 ?  21.406  ns/op
MergeStoreBench.setLongU     avgt   15   1940.593 ?  21.824  ns/op


## 2.5 Aliyun ecs.c8y (aarch64)
* CPU Aliyun Yitian 710

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getIntB      avgt   15   7693.088 ?   3.311  ns/op
MergeStoreBench.getIntBU     avgt   15   6569.492 ?   4.363  ns/op
MergeStoreBench.getIntBV     avgt   15   1360.788 ?   0.185  ns/op
MergeStoreBench.getIntL      avgt   15   6869.948 ?   0.459  ns/op
MergeStoreBench.getIntLU     avgt   15   6059.390 ?  10.758  ns/op
MergeStoreBench.getIntLV     avgt   15   2753.969 ?   0.147  ns/op
MergeStoreBench.getIntRB     avgt   15   8176.169 ? 108.856  ns/op
MergeStoreBench.getIntRBU    avgt   15   7262.778 ?   2.157  ns/op
MergeStoreBench.getIntRL     avgt   15   7691.955 ?   2.307  ns/op
MergeStoreBench.getIntRLU    avgt   15   6687.164 ?  11.958  ns/op
MergeStoreBench.getIntRU     avgt   15   2816.706 ?   1.032  ns/op
MergeStoreBench.getIntU      avgt   15   2855.242 ?   0.395  ns/op
MergeStoreBench.getLongB     avgt   15  13808.276 ?   5.076  ns/op
MergeStoreBench.getLongBU    avgt   15  11786.525 ?   6.141  ns/op
MergeStoreBench.getLongBV    avgt   15   2792.010 ?   0.671  ns/op
MergeStoreBench.getLongL     avgt   15  13296.684 ?  17.836  ns/op
MergeStoreBench.getLongLU    avgt   15  11210.969 ?   5.916  ns/op
MergeStoreBench.getLongLV    avgt   15   2759.405 ?   0.240  ns/op
MergeStoreBench.getLongRB    avgt   15  13812.198 ?   2.658  ns/op
MergeStoreBench.getLongRBU   avgt   15  11786.747 ?   5.149  ns/op
MergeStoreBench.getLongRL    avgt   15  13300.198 ?  16.842  ns/op
MergeStoreBench.getLongRLU   avgt   15  11208.050 ?   9.084  ns/op
MergeStoreBench.getLongRU    avgt   15   2835.510 ?   0.462  ns/op
MergeStoreBench.getLongU     avgt   15   2864.473 ?   0.705  ns/op
MergeStoreBench.putChars4    avgt   15   8895.844 ?   6.508  ns/op
MergeStoreBench.putChars4UB  avgt   15   5495.596 ?   1.519  ns/op
MergeStoreBench.putChars4UC  avgt   15   5110.665 ?   6.025  ns/op
MergeStoreBench.setIntB      avgt   15   6062.162 ?   4.247  ns/op
MergeStoreBench.setIntBU     avgt   15   6665.214 ?  13.035  ns/op
MergeStoreBench.setIntBV     avgt   15   1362.756 ?   0.087  ns/op
MergeStoreBench.setIntL      avgt   15   2823.779 ?   0.791  ns/op
MergeStoreBench.setIntLU     avgt   15   2766.163 ?   0.179  ns/op
MergeStoreBench.setIntLV     avgt   15   5508.486 ?   1.444  ns/op
MergeStoreBench.setIntRB     avgt   15   7591.497 ?   6.000  ns/op
MergeStoreBench.setIntRBU    avgt   15   7748.780 ?   4.463  ns/op
MergeStoreBench.setIntRL     avgt   15   5517.300 ?   7.851  ns/op
MergeStoreBench.setIntRLU    avgt   15   5622.521 ?   1.091  ns/op
MergeStoreBench.setIntRU     avgt   15   5581.834 ?   1.102  ns/op
MergeStoreBench.setIntU      avgt   15   5463.442 ?   0.682  ns/op
MergeStoreBench.setLongB     avgt   15  13516.164 ?   5.466  ns/op
MergeStoreBench.setLongBU    avgt   15  13614.626 ?  20.629  ns/op
MergeStoreBench.setLongBV    avgt   15   2796.317 ?   0.953  ns/op
MergeStoreBench.setLongL     avgt   15   5549.128 ?  28.272  ns/op
MergeStoreBench.setLongLU    avgt   15   4130.981 ?   1.344  ns/op
MergeStoreBench.setLongLV    avgt   15   2785.515 ?   0.318  ns/op
MergeStoreBench.setLongRB    avgt   15  14287.192 ?  10.265  ns/op
MergeStoreBench.setLongRBU   avgt   15  14499.620 ?  10.026  ns/op
MergeStoreBench.setLongRL    avgt   15   6671.064 ?  21.088  ns/op
MergeStoreBench.setLongRLU   avgt   15   4831.917 ?  11.497  ns/op
MergeStoreBench.setLongRU    avgt   15   3197.165 ?   0.768  ns/op
MergeStoreBench.setLongU     avgt   15   2799.934 ?   1.945  ns/op


## 2.6 Orange Pi 5 Plus (aarch64)
* Rockchip RK3588S (8nm LP process)
* http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getIntB      avgt   15  14310.070 ?  80.699  ns/op
MergeStoreBench.getIntBU     avgt   15  12523.180 ?  30.688  ns/op
MergeStoreBench.getIntBV     avgt   15   1846.502 ?   5.312  ns/op
MergeStoreBench.getIntL      avgt   15  12956.229 ?  24.863  ns/op
MergeStoreBench.getIntLU     avgt   15  11325.391 ?  38.825  ns/op
MergeStoreBench.getIntLV     avgt   15   3768.575 ?  20.082  ns/op
MergeStoreBench.getIntRB     avgt   15  15539.092 ?  40.245  ns/op
MergeStoreBench.getIntRBU    avgt   15  13862.743 ?  54.321  ns/op
MergeStoreBench.getIntRL     avgt   15  14186.647 ?  35.623  ns/op
MergeStoreBench.getIntRLU    avgt   15  12573.647 ?  23.523  ns/op
MergeStoreBench.getIntRU     avgt   15   4368.234 ?  23.460  ns/op
MergeStoreBench.getIntU      avgt   15   3700.248 ?  17.718  ns/op
MergeStoreBench.getLongB     avgt   15  26513.593 ?  84.012  ns/op
MergeStoreBench.getLongBU    avgt   15  22001.241 ?  47.761  ns/op
MergeStoreBench.getLongBV    avgt   15   4148.252 ?  15.058  ns/op
MergeStoreBench.getLongL     avgt   15  25282.815 ? 130.802  ns/op
MergeStoreBench.getLongLU    avgt   15  21206.815 ?  85.923  ns/op
MergeStoreBench.getLongLV    avgt   15   3777.233 ?   7.117  ns/op
MergeStoreBench.getLongRB    avgt   15  26485.481 ?  40.748  ns/op
MergeStoreBench.getLongRBU   avgt   15  21973.762 ?  32.260  ns/op
MergeStoreBench.getLongRL    avgt   15  25299.502 ?  59.614  ns/op
MergeStoreBench.getLongRLU   avgt   15  21178.624 ?  65.400  ns/op
MergeStoreBench.getLongRU    avgt   15   4388.503 ?  15.022  ns/op
MergeStoreBench.getLongU     avgt   15   3721.682 ?   3.202  ns/op
MergeStoreBench.putChars4    avgt   15  18617.889 ? 194.877  ns/op
MergeStoreBench.putChars4UB  avgt   15  11140.563 ?  35.977  ns/op
MergeStoreBench.putChars4UC  avgt   15  10913.407 ?  30.633  ns/op
MergeStoreBench.setIntB      avgt   15  11670.307 ?  30.119  ns/op
MergeStoreBench.setIntBU     avgt   15  13614.156 ?  79.641  ns/op
MergeStoreBench.setIntBV     avgt   15   1856.985 ?   3.735  ns/op
MergeStoreBench.setIntL      avgt   15   5094.994 ? 143.111  ns/op
MergeStoreBench.setIntLU     avgt   15   4653.661 ?  13.918  ns/op
MergeStoreBench.setIntLV     avgt   15   7364.007 ?  23.713  ns/op
MergeStoreBench.setIntRL     avgt   15   7745.408 ?  19.505  ns/op
MergeStoreBench.setIntRLU    avgt   15   8262.371 ?  17.381  ns/op
MergeStoreBench.setIntRU     avgt   15   7361.715 ?  15.911  ns/op
MergeStoreBench.setIntU      avgt   15   7360.358 ?  18.326  ns/op
MergeStoreBench.setLongB     avgt   15  29724.536 ? 111.106  ns/op
MergeStoreBench.setLongBU    avgt   15  28497.008 ? 141.615  ns/op
MergeStoreBench.setLongBV    avgt   15   5722.789 ?  32.736  ns/op
MergeStoreBench.setLongL     avgt   15  10547.782 ?  31.164  ns/op
MergeStoreBench.setLongLU    avgt   15   8291.086 ?  39.928  ns/op
MergeStoreBench.setLongLV    avgt   15   4614.304 ?  24.229  ns/op
MergeStoreBench.setLongRB    avgt   15  33607.418 ? 293.440  ns/op
MergeStoreBench.setLongRBU   avgt   15  30414.981 ?  74.164  ns/op
MergeStoreBench.setLongRL    avgt   15  13901.427 ?  79.116  ns/op
MergeStoreBench.setLongRLU   avgt   15   9751.634 ? 337.882  ns/op
MergeStoreBench.setLongRU    avgt   15   6305.701 ?  13.433  ns/op
MergeStoreBench.setLongU     avgt   15   5174.620 ?  27.848  ns/op


## 2.7 AWS ecs c5.xlarge (x64)

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getIntB      avgt   15  13079.509 ?  31.297  ns/op
MergeStoreBench.getIntBU     avgt   15   9462.475 ?  21.237  ns/op
MergeStoreBench.getIntBV     avgt   15    427.081 ?  11.493  ns/op
MergeStoreBench.getIntL      avgt   15  12265.667 ? 155.913  ns/op
MergeStoreBench.getIntLU     avgt   15   9444.551 ?   6.117  ns/op
MergeStoreBench.getIntLV     avgt   15   2424.707 ?   3.046  ns/op
MergeStoreBench.getIntRB     avgt   15  13399.629 ?  21.861  ns/op
MergeStoreBench.getIntRBU    avgt   15  10146.871 ?  29.528  ns/op
MergeStoreBench.getIntRL     avgt   15  13079.355 ?   4.712  ns/op
MergeStoreBench.getIntRLU    avgt   15  10074.582 ?  21.369  ns/op
MergeStoreBench.getIntRU     avgt   15   2965.584 ?   8.777  ns/op
MergeStoreBench.getIntU      avgt   15   2725.438 ?   3.373  ns/op
MergeStoreBench.getLongB     avgt   15  26115.043 ?  45.099  ns/op
MergeStoreBench.getLongBU    avgt   15  17887.028 ?  31.958  ns/op
MergeStoreBench.getLongBV    avgt   15   1003.857 ?   3.478  ns/op
MergeStoreBench.getLongL     avgt   15  26121.420 ?  56.763  ns/op
MergeStoreBench.getLongLU    avgt   15  17838.494 ?  33.942  ns/op
MergeStoreBench.getLongLV    avgt   15   2422.744 ?   2.451  ns/op
MergeStoreBench.getLongRB    avgt   15  26099.347 ?   7.375  ns/op
MergeStoreBench.getLongRBU   avgt   15  17892.774 ?  36.187  ns/op
MergeStoreBench.getLongRL    avgt   15  26113.364 ?  42.866  ns/op
MergeStoreBench.getLongRLU   avgt   15  17828.021 ?   5.329  ns/op
MergeStoreBench.getLongRU    avgt   15   3848.432 ?   0.722  ns/op
MergeStoreBench.getLongU     avgt   15   3784.374 ?   6.472  ns/op
MergeStoreBench.putChars4    avgt   15   9816.198 ?  26.355  ns/op
MergeStoreBench.putChars4UB  avgt   15   4706.135 ?   4.254  ns/op
MergeStoreBench.putChars4UC  avgt   15  10203.688 ?  56.176  ns/op
MergeStoreBench.setIntB      avgt   15  12799.623 ?  28.007  ns/op
MergeStoreBench.setIntBU     avgt   15  15187.730 ?  40.084  ns/op
MergeStoreBench.setIntBV     avgt   15    889.277 ?  11.389  ns/op
MergeStoreBench.setIntL      avgt   15   2970.163 ?   5.265  ns/op
MergeStoreBench.setIntLU     avgt   15   6769.524 ?  18.502  ns/op
MergeStoreBench.setIntLV     avgt   15    945.737 ?   2.444  ns/op
MergeStoreBench.setIntRB     avgt   15  14046.973 ?  32.796  ns/op
MergeStoreBench.setIntRBU    avgt   15  16527.209 ?  82.575  ns/op
MergeStoreBench.setIntRL     avgt   15   7020.496 ? 179.054  ns/op
MergeStoreBench.setIntRLU    avgt   15  10178.358 ?  19.539  ns/op
MergeStoreBench.setIntRU     avgt   15   1343.150 ?   6.356  ns/op
MergeStoreBench.setIntU      avgt   15   1037.694 ?   2.379  ns/op
MergeStoreBench.setLongB     avgt   15  22693.643 ?  42.961  ns/op
MergeStoreBench.setLongBU    avgt   15  35717.196 ? 104.769  ns/op
MergeStoreBench.setLongBV    avgt   15   1753.671 ?  26.216  ns/op
MergeStoreBench.setLongL     avgt   15   4150.631 ?   1.421  ns/op
MergeStoreBench.setLongLU    avgt   15   7141.568 ?  27.922  ns/op
MergeStoreBench.setLongLV    avgt   15   1678.193 ?   5.627  ns/op
MergeStoreBench.setLongRB    avgt   15  24545.267 ?   6.587  ns/op
MergeStoreBench.setLongRBU   avgt   15  36050.753 ?  65.961  ns/op
MergeStoreBench.setLongRL    avgt   15   5557.854 ?   8.769  ns/op
MergeStoreBench.setLongRLU   avgt   15   6155.434 ?  50.697  ns/op
MergeStoreBench.setLongRU    avgt   15   1751.805 ?  26.192  ns/op
MergeStoreBench.setLongU     avgt   15   1701.889 ?   9.799  ns/op


## 2.8 AWS c7g.xlarge (aarch64)
* [AWS Graviton3 Processor](https://aws.amazon.com/ec2/graviton/)

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getIntB      avgt   15   8043.459 ?   4.801  ns/op
MergeStoreBench.getIntBU     avgt   15   7056.463 ?   3.285  ns/op
MergeStoreBench.getIntBV     avgt   15    780.570 ?   0.033  ns/op
MergeStoreBench.getIntL      avgt   15   7666.043 ?  10.795  ns/op
MergeStoreBench.getIntLU     avgt   15   6379.222 ?  13.369  ns/op
MergeStoreBench.getIntLV     avgt   15   3179.702 ?   0.235  ns/op
MergeStoreBench.getIntRB     avgt   15   8892.801 ?   7.461  ns/op
MergeStoreBench.getIntRBU    avgt   15   7822.666 ?   0.944  ns/op
MergeStoreBench.getIntRL     avgt   15   8385.029 ? 255.203  ns/op
MergeStoreBench.getIntRLU    avgt   15   6995.686 ?   1.382  ns/op
MergeStoreBench.getIntRU     avgt   15   2361.462 ?   0.125  ns/op
MergeStoreBench.getIntU      avgt   15   2232.425 ?   0.121  ns/op
MergeStoreBench.getLongB     avgt   15  15212.747 ?  72.866  ns/op
MergeStoreBench.getLongBU    avgt   15  12521.436 ?  10.604  ns/op
MergeStoreBench.getLongBV    avgt   15   1570.044 ?   0.614  ns/op
MergeStoreBench.getLongL     avgt   15  14723.614 ?   2.207  ns/op
MergeStoreBench.getLongLU    avgt   15  12038.660 ?  17.515  ns/op
MergeStoreBench.getLongLV    avgt   15   3180.912 ?   0.213  ns/op
MergeStoreBench.getLongRB    avgt   15  15168.386 ?   3.612  ns/op
MergeStoreBench.getLongRBU   avgt   15  12513.044 ?   6.066  ns/op
MergeStoreBench.getLongRL    avgt   15  14725.218 ?   2.830  ns/op
MergeStoreBench.getLongRLU   avgt   15  12030.288 ?  17.871  ns/op
MergeStoreBench.getLongRU    avgt   15   3198.287 ?   0.195  ns/op
MergeStoreBench.getLongU     avgt   15   3187.308 ?   0.211  ns/op
MergeStoreBench.putChars4    avgt   15  10401.393 ?  12.031  ns/op
MergeStoreBench.putChars4UB  avgt   15   3677.934 ?   2.670  ns/op
MergeStoreBench.putChars4UC  avgt   15   5744.121 ?  82.141  ns/op
MergeStoreBench.setIntB      avgt   15   7043.439 ?   2.165  ns/op
MergeStoreBench.setIntBU     avgt   15   7981.350 ?   0.716  ns/op
MergeStoreBench.setIntBV     avgt   15    784.619 ?   0.029  ns/op
MergeStoreBench.setIntL      avgt   15   3189.311 ?   0.710  ns/op
MergeStoreBench.setIntLU     avgt   15   3272.439 ?   3.194  ns/op
MergeStoreBench.setIntLV     avgt   15   1565.925 ?   0.146  ns/op
MergeStoreBench.setIntRB     avgt   15   8625.077 ?   1.519  ns/op
MergeStoreBench.setIntRBU    avgt   15   8105.421 ?  27.598  ns/op
MergeStoreBench.setIntRL     avgt   15   6300.870 ?   0.364  ns/op
MergeStoreBench.setIntRLU    avgt   15   6336.852 ?   1.972  ns/op
MergeStoreBench.setIntRU     avgt   15   1716.681 ?  28.187  ns/op
MergeStoreBench.setIntU      avgt   15   1567.628 ?   0.316  ns/op
MergeStoreBench.setLongB     avgt   15  14894.383 ?  12.716  ns/op
MergeStoreBench.setLongBU    avgt   15  16058.865 ?  17.127  ns/op
MergeStoreBench.setLongBV    avgt   15   1575.499 ?   0.678  ns/op
MergeStoreBench.setLongL     avgt   15   6856.932 ?  25.268  ns/op
MergeStoreBench.setLongLU    avgt   15   3385.389 ?   3.971  ns/op
MergeStoreBench.setLongLV    avgt   15   1569.862 ?   0.616  ns/op
MergeStoreBench.setLongRB    avgt   15  15452.243 ?   6.443  ns/op
MergeStoreBench.setLongRBU   avgt   15  15453.597 ?  10.201  ns/op
MergeStoreBench.setLongRL    avgt   15   7176.426 ?   4.363  ns/op
MergeStoreBench.setLongRLU   avgt   15   3211.004 ?   1.041  ns/op
MergeStoreBench.setLongRU    avgt   15   1575.034 ?   0.267  ns/op
MergeStoreBench.setLongU     avgt   15   1569.837 ?   0.461  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2171146882

From duke at openjdk.org  Sun Jun 16 14:45:11 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 16 Jun 2024 14:45:11 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v2]
In-Reply-To: <GqClPnYoe_m09iMqUkGge5KXTcILeop4NmBhZPKEPxc=.4917ae11-3cad-40d0-a09d-d025e6391532@github.com>
References: <NTuestJIqqBcmJg7R1xSWxUjeGPQdeXthA0GaIzPiBY=.ab21a23d-7be4-4bfd-8336-4584e6f3b342@github.com>
 <GqClPnYoe_m09iMqUkGge5KXTcILeop4NmBhZPKEPxc=.4917ae11-3cad-40d0-a09d-d025e6391532@github.com>
Message-ID: <s3_0Xwrs6MlbXqyyfRtFQfrmnfZBNpai-CXqtITAIw4=.25d3f440-1cb4-4648-b1ba-921dc5394b11@github.com>

On Mon, 10 Jun 2024 03:51:40 GMT, Glavo <duke at openjdk.org> wrote:

>> Things have changed since https://github.com/openjdk/jdk/pull/14636 was closed, so let me reopen it.
>> 
>> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE caused a startup regression. In order to not have any more revert patches, it makes sense to optimize BALE.
>> 
>> The optimization of https://github.com/openjdk/jdk/pull/16245 allows the traditional expression to have good performance, but BA and BALE save us from having to copy these lengthy expressions everywhere. So it makes sense to keep them.
>> 
>> Now here's the question, should I rewrite this PR without `Unsafe`? I'll do some research (e.g. does `Unsafe` have better performance during warmup?), but I'd also like to take some advice.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

I submitted a PR #19734 with a set of performance benchmarks for Batch operations that should provide performance numbers that you can use to improve ByteArray and ByteArrayLittleEndian.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19616#issuecomment-2171694467

From redestad at openjdk.org  Sun Jun 16 21:28:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 16 Jun 2024 21:28:13 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v8]
In-Reply-To: <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>
Message-ID: <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>

On Sat, 15 Jun 2024 13:27:41 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code format

Just suggesting some improvements

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 185:

> 183:      * Returns
> 184:      *     Combine type and size, the first byte is size, the second byte is type
> 185:      *

Suggestion:

     *  Returns size in the lower byte, type in the high byte, where type is

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 190:

> 188:      *     PLUS_INF        iff v is POSITIVE_INFINITY
> 189:      *     MINUS_INF       iff v is NEGATIVE_INFINITY
> 190:      *     NAN             iff v is NaN

Suggestion:

     *     NAN             iff v is NaN
     *     otherwise NON_SPECIAL

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 169:

> 167:     }
> 168: 
> 169:     /* Using the deprecated constructor enhances performance */

Enhances performance over what, `new String(str, 0, index, StandardCharsets.US_ASCII)`? Please specify.

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 171:

> 169:     /* Using the deprecated constructor enhances performance */
> 170:     @SuppressWarnings("deprecation")
> 171:     static String charsToString(byte[] str, int index) {

This should be named something like `asciiBytesToString` now. Perhaps `ToDecimal.LATIN1` can be renamed `ASCII`, too.

test/micro/org/openjdk/bench/java/lang/StringBuilders.java line 244:

> 242: 
> 243:     @Benchmark
> 244:     public int appendWithFloat8Latin1() {

It would be interesting with a mixed micro to explore effects of increased number of implementors (looping over an array with `sbLatin1` and `sbUtf16`, and appending both floats and doubles in the same loop) 

`buf.delete(0, buf.length())` could be replaced with `buf.setLength(0)` in these. Might reduce a bit of overhead and focus micros .

-------------

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19730#pullrequestreview-2121584681
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1641984296
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1641984363
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1641979604
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1641979428
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1641980537

From duke at openjdk.org  Sun Jun 16 23:40:41 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 16 Jun 2024 23:40:41 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v9]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <FBY-8jrza1c8V6wV_ed2uSF6ysSgYd_54n0QjsAkjfI=.0840baf8-a093-423e-98ed-571ee4e078d7@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/5a432c9e..fac64f63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=07-08

  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Sun Jun 16 23:52:41 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 16 Jun 2024 23:52:41 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v10]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <T_6NB7nKA6r6_GTpZwz0ggV7Q0_0jxFw9pRpxqFAieY=.276032b6-87a8-4d87-be6c-5d193bf51827@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  charsToString -> asciiBytesToString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/fac64f63..ceb7baf9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=08-09

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Sun Jun 16 23:52:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 16 Jun 2024 23:52:42 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v8]
In-Reply-To: <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>
 <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
Message-ID: <YOPG2cS8_mluAaPcnFP3CqdVbA6yDn51yJlH8LUBQKQ=.aa7493d5-919d-4db2-a3d1-32e27eb995bb@github.com>

On Sun, 16 Jun 2024 21:02:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code format
>
> src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 169:
> 
>> 167:     }
>> 168: 
>> 169:     /* Using the deprecated constructor enhances performance */
> 
> Enhances performance over what, `new String(str, 0, index, StandardCharsets.US_ASCII)`? Please specify.

The previous version of the code is like this, which will affect Float.toString and Double.toString. If changed, it is necessary to add the Benchmark of Float.toString and Double.toString, so I don?t want to change this in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1642014965

From duke at openjdk.org  Mon Jun 17 00:00:26 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 00:00:26 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v11]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <P3OSbJFUM643pdg0vuYX3RbWix1mqGmHV7gI7ggbozY=.3ab9b072-e43d-4cb0-b033-8080642dea74@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  benchmark `delete` -> `setLength`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/ceb7baf9..d2d20bbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Mon Jun 17 01:00:29 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 01:00:29 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v12]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <K4ApRKeVG5hmv7dNK8typYIuRnHSsOgW5rdYxBCOW14=.ab67852c-2ca9-40cc-b7df-e5057e05e7bb@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove use deprecated method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/d2d20bbb..05d5b5cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=10-11

  Stats: 14 lines in 3 files changed: 6 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Mon Jun 17 01:00:29 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 01:00:29 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v8]
In-Reply-To: <YOPG2cS8_mluAaPcnFP3CqdVbA6yDn51yJlH8LUBQKQ=.aa7493d5-919d-4db2-a3d1-32e27eb995bb@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>
 <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
 <YOPG2cS8_mluAaPcnFP3CqdVbA6yDn51yJlH8LUBQKQ=.aa7493d5-919d-4db2-a3d1-32e27eb995bb@github.com>
Message-ID: <973fU6vmDRyPhDdZqjUdR3C_1yBcyl-MbQx-mCcygnI=.708eba9c-0c50-420f-aad2-1fcdc286cc5d@github.com>

On Sun, 16 Jun 2024 23:49:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 169:
>> 
>>> 167:     }
>>> 168: 
>>> 169:     /* Using the deprecated constructor enhances performance */
>> 
>> Enhances performance over what, `new String(str, 0, index, StandardCharsets.US_ASCII)`? Please specify.
>
> The previous version of the code is like this, which will affect Float.toString and Double.toString. If changed, it is necessary to add the Benchmark of Float.toString and Double.toString, so I don?t want to change this in this PR.

I followed your suggestion and changed it, but Coding uses ISO_8859_1. The performance of ISO_8859_1 is faster than that of the previously abandoned method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1642037877

From duke at openjdk.org  Mon Jun 17 01:26:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 01:26:42 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v11]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <JeZ23sb1CpGPE9c0LJ3yH30ubDjheF62SazvMYh7CFc=.6abdece8-72db-479a-bb70-f5ef227cd584@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  `delete` -> `setLength`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/1a012f1c..3db11b21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From dholmes at openjdk.org  Mon Jun 17 04:53:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Jun 2024 04:53:12 GMT
Subject: RFR: 8333962: Obsolete OldSize [v2]
In-Reply-To: <--FcnwH_fA8e27VK3SwN0vJZZW8yZsyxh2I2jul-Enk=.3cd55bc7-b0ac-4ef6-93a1-b880ff255bd3@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
 <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
 <eDaHUlPPWSTYvNZmB6J6HeieREWM8ErG0BFre32v6aQ=.984ccd13-b3ac-4516-aa6b-24dfed96cd22@github.com>
 <--FcnwH_fA8e27VK3SwN0vJZZW8yZsyxh2I2jul-Enk=.3cd55bc7-b0ac-4ef6-93a1-b880ff255bd3@github.com>
Message-ID: <3di2So2Uj6-xau81y4dtdpAG2_GlIHNUd8KTyEHUtTs=.df3c5bab-cd31-4c9b-b905-265e8beb2d10@github.com>

On Sat, 15 Jun 2024 08:51:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 37:
>> 
>>> 35: #include "gc/shared/gcArguments.hpp"
>>> 36: #include "gc/shared/gcConfig.hpp"
>>> 37: #include "gc/shared/genArguments.hpp"
>> 
>> Why is this needed?
>
> `Arguments::set_heap_size` accesses `OldSize`, which is declared in this header.

Got it. Thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19647#discussion_r1642158519

From duke at openjdk.org  Mon Jun 17 04:58:41 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 04:58:41 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v13]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Utf16 case remove `append first utf16 char`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/05d5b5cf..b8e80428

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=11-12

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Mon Jun 17 05:53:45 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 05:53:45 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v12]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <d7kEmw8X84iZgGkLLa7XYSVipLSkiLZUz2p83dL_TEw=.941a9357-530b-4ec7-b815-7079302a990f@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Utf16 case remove `append first utf16 char`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/3db11b21..fa72999a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From jlu at openjdk.org  Mon Jun 17 06:08:13 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jun 2024 06:08:13 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <aNc3-Dw5QwYdUz3QpeB9Kd680i9r2DEoESYA3MrQ2LY=.44ee92cb-2d76-41b9-8262-3af4328bc0ba@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
 <e0kp5SiQXQM3opXP1RtEayfyfHVF5gO6SezjeVcMuZA=.4de0add9-95bf-44da-b9ca-314dc81d59a2@github.com>
 <aNc3-Dw5QwYdUz3QpeB9Kd680i9r2DEoESYA3MrQ2LY=.44ee92cb-2d76-41b9-8262-3af4328bc0ba@github.com>
Message-ID: <bpmfCLXsEQncEBlb6Xr1ZKw4RpgZSuSpaAtIDUFLjso=.896f73a0-bc81-4168-85c7-70d5b5702bc3@github.com>

On Fri, 14 Jun 2024 04:04:48 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/CompactNumberFormat.java line 885:
>> 
>>> 883:     }
>>> 884: 
>>> 885:     private StringBuilderBufferProxy format(BigInteger number, StringBuilderBufferProxy result,
>> 
>> While the DecimalFormat and CompactNumberFormat BigInteger and BigDecimal `format` methods will always return a StringBuffer, we must change the method signatures to use the proxy, otherwise we would need to define alternate methods all the way at the `Format.FieldDelegate` level. So I think this is a lesser of two evils.
>
> I'm not sure what you mean. Would you suggest add two new methods that accept StringBuilderBufferProxy and keep the origin methods that accept StringBuffer? Like this:
> 
>     interface FieldDelegate {
> 
>         public void formatted(Format.Field attr, Object value, int start,
>                               int end, StringBuffer buffer);
> 
>         public void formatted(int fieldID, Format.Field attr, Object value,
>                               int start, int end, StringBuffer buffer);
> 
>         public void formatted(Format.Field attr, Object value, int start,
>                               int end, StringBuilderBufferProxy buffer);
> 
>         public void formatted(int fieldID, Format.Field attr, Object value,
>                               int start, int end, StringBuilderBufferProxy buffer);
>     }
> 
> But DecimalFormat#subformatNumber is a common method that only accept StringBuilderBufferProxy, and CompactNumberFormat#format(BigDecimal) call it, so CompactNumberFormat#format(BigDecimal) need change signature.

Ah, no, I was only making a observation. I agree that adding another set of methods to FieldDelegate to support both buffer and proxy is not ideal. And as you pointed out, `format(BigDecimal...` calls other methods that are reliant on proxy anyways.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1642223921

From cstein at openjdk.org  Mon Jun 17 06:21:12 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 17 Jun 2024 06:21:12 GMT
Subject: RFR: 8331431: Update to use jtreg 7.4
In-Reply-To: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
References: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
Message-ID: <0uNmeiETRIRQQ36f2H_cMJ9jygo2A9-MuhJHnhyZmCw=.f3e4fd02-f00c-4961-9347-c959a0ee9e35@github.com>

On Thu, 2 May 2024 09:48:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using `jtreg` **7.4**.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> Tested: tier 1 ? tier 5

Update the title to use the correct JBS issue number.

> Looks good to me. I assume that you have run an extensive set of tests to verify that this does not break, even in higher tiers?

Yes. See below.

> Hello Christian, it would be better to merge latest master branch into this PR before integrating this. It looks like it currently uses master from more than a month back.

Latest tier 1-5 tests were run against late last week's HEAD revision. So, all looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19052#issuecomment-2172374402

From smarks at openjdk.org  Mon Jun 17 06:55:12 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 17 Jun 2024 06:55:12 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v3]
In-Reply-To: <KqGzPBLAm2OLjIlyxoikQw_-EPBHPkQjojjKxXRNts8=.2576c1c8-1c5c-4965-8bd8-001f71267a66@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <KqGzPBLAm2OLjIlyxoikQw_-EPBHPkQjojjKxXRNts8=.2576c1c8-1c5c-4965-8bd8-001f71267a66@github.com>
Message-ID: <qH3lX4QwE6GsYK3BwwfftRi71X60e6-4fSnX5Z3O0Rc=.97501c4c-26e3-4082-af57-3db7136401a5@github.com>

On Sun, 16 Jun 2024 06:36:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
>> 
>> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
>> 
>> To summarize those discussions, we had concluded that:
>> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
>> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
>> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
>> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
>> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
>> 
>> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
>> 
>> I'll file a CSR shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's suggestion - improve code comment

Hi Jai, thanks for picking this up. Several points of discussion here. Nothing fatal, but as I said in 2019 :-) just a few wrinkles to iron out. I looked mainly at Deflater, but I think the issues also all apply to Inflater too.

1) class specification

I think the class specification needs to be clearer about the positioning of end() and close(). The end() method has done the real work of "closing" since the classes were introduced. We're retrofitting them to to have a close() method that's essentially just a synonym for end(), and it's still perfectly legal for clients and subclasses to call end() instead of close(). I think we need to say that close() is present mainly to support AutoCloseable and try-with-resources.

2) end() specification

I don't think that "may throw an exception" is strong enough. Also, on these classes (not subclasses) end() is idemopotent, isn't it? If so, this should be specified. The end() specs need to say something like, closes and releases resources, etc., henceforth operations will throw an exception (which? -- see below) but that subsequent calls to end() do nothing.

3) Which exceptions on closed Deflater/Inflater?

Oddly, it doesn't seem to be specified anywhere what exceptions are thrown if operations are attempted on a closed object. And the implementation actually throws NPE??!? Ideally we should specify what exception is thrown in this circumstance, but NPE seems wrong. Maybe we want to change the behavior to throw a different exception type. IllegalStateException seems like a reasonable candidate.

4) close() specification

The 2019 discussion kind of assumed that we want close() to be idempotent. I'm not sure this is necessary. Alan said the implementation might need to be "heroic" but Peter Levart's arrangement (carried through here, apparently) isn't terribly bad. And @liach suggests more comments on this code, quite reasonably... but the comment begs the question, why do we need to avoid calling end() more than once? I'm rethinking the need for close() to be idempotent. Maybe close() should simply call end(). It would simplify the implementation and the specs -- the implSpec would simply say that it calls the end() method.

This would only be a problem if a) some arrangement of TWR ends up calling close() twice, which apparently it doesn't; b) there is a subclass; and c) the subclass's end() method is not idempotent. As far as I can tell we haven't found any example of any of these. It thus seems to me that having extra logic in close() to avoid calling end() more than once is solving a non-problem. It also fits more closely to the model of "close() is simply a synonym for end()".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19675#issuecomment-2172433871

From epeter at openjdk.org  Mon Jun 17 07:54:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Jun 2024 07:54:15 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks
In-Reply-To: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
Message-ID: <nTueRcNtsyjwrIqO7k7rsDU6JT-0020BZGwhYbGhWk4=.f5b32b5f-bde3-40fd-a7d4-19cdb1b8e848@github.com>

On Sun, 16 Jun 2024 07:17:16 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> [8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.

A few extra comments:
There is already a `MergeStore` benchmark. I would prefer if you put yours next to it, unless if you have a good reason.

About your list:

getIntB    
getIntBU   
getIntL    
getIntLU   
getIntRB   
getIntRBU  
getIntRL   
getIntRLU  
getLongB   
getLongBU  
getLongL   
getLongLU  
getLongRB  
getLongRBU 
getLongRL  
getLongRLU
-> Obviously a "MergeStore" optimization does not work for loads. But if it is important, then maybe we could generalize the optimizations from stores to loads.

putChars4UC
-> Does the putChars4UC get inlined? Because here you are storing 4 variables, this pattern is not handled by MergeStore.

setIntB
-> You say that here MergeStore does not work. That is because the indices are increasing, but the shifts decreasing. So that does not work on little-endian machines (most architectures), but I would expect it to work on big-endian machines with https://github.com/openjdk/jdk/pull/19218.
   
setIntBU
-> order seems messed up

setIntRB    
setIntRBU   
setLongB
setLongBU  
setLongRB  
setLongRBU
-> I leave the rest for you to investigate.

test/micro/org/openjdk/bench/java/lang/MergeStoreBench.java line 2:

> 1: /*
> 2:  * Copyright (c) 2014, 2024, Oracle and/or its affiliates. All rights reserved.

I think for a new file, you don't want to backdate the copyright to `2014` ;)

test/micro/org/openjdk/bench/java/lang/MergeStoreBench.java line 57:

> 55:             HI_BYTE_SHIFT = 0;
> 56:             LO_BYTE_SHIFT = 8;
> 57:         }

I wonder if it would just be better to duplicate the tests. Because we may extend the `MergeStore` optimization such that it allows either order, and just adds a `Reverse` operations on the bytes/chars/ints. Then it would be nice to benchmark both orders on both little and big endian architectures. What do you think?

test/micro/org/openjdk/bench/java/lang/MergeStoreBench.java line 656:

> 654:         array[offset + 2] = (byte) (value >>  8);
> 655:         array[offset + 3] = (byte) (value      );
> 656:     }

You say that here `MergeStore` does not work. That is because the indices are increasing, but the shifts decreasing. So that does not work on little-endian machines (most architectures), but I would expect it to work on big-endian machines with https://github.com/openjdk/jdk/pull/19218.

test/micro/org/openjdk/bench/java/lang/MergeStoreBench.java line 664:

> 662:         UNSAFE.putByte(array, address + 2, (byte) (value >> 16));
> 663:         UNSAFE.putByte(array, address + 3, (byte) (value      ));
> 664:     }

Order messed up?

test/micro/org/openjdk/bench/java/lang/MergeStoreBench.java line 850:

> 848:         UNSAFE.putChar(array, address + 4, c2);
> 849:         UNSAFE.putChar(array, address + 6, c3);
> 850:     }

Does the `putChars4UC` get inlined? Because here you are storing 4 variables, this pattern is not handled by `MergeStore`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2172548153
PR Review Comment: https://git.openjdk.org/jdk/pull/19734#discussion_r1642327120
PR Review Comment: https://git.openjdk.org/jdk/pull/19734#discussion_r1642329554
PR Review Comment: https://git.openjdk.org/jdk/pull/19734#discussion_r1642341934
PR Review Comment: https://git.openjdk.org/jdk/pull/19734#discussion_r1642350184
PR Review Comment: https://git.openjdk.org/jdk/pull/19734#discussion_r1642343781

From asotona at openjdk.org  Mon Jun 17 08:09:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 08:09:19 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v10]
In-Reply-To: <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
 <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>
 <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
Message-ID: <1HKiSsY8pP4bLykPMG5pD63UNXaN8AmsscIJqJQBJwo=.107797e8-9d46-4805-8f77-3fd2c3e73751@github.com>

On Fri, 24 May 2024 17:12:24 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/indify/Indify.java line 578:
>> 
>>> 576:                         classTransform = ClassTransform.transformingMethodBodies(filter, codeTransform);
>>> 577:                         classModel = of().parse(
>>> 578:                              of().transform(classModel, classTransform));
>> 
>> What this transform (in the middle of instructions iteration) does?
>
> It updates the current classfile so when moving to a next action we avoid this runtime error:
> 
>> STATUS:Failed.`main' threw exception: java.lang.VerifyError: Bad type on operand stack

Injected transform to avoid verify error, that seems to me conceptually wrong.
What is the root cause of the verify error and how the transform suppose to fix it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1642372748

From duke at openjdk.org  Mon Jun 17 08:10:12 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 08:10:12 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks
In-Reply-To: <nTueRcNtsyjwrIqO7k7rsDU6JT-0020BZGwhYbGhWk4=.f5b32b5f-bde3-40fd-a7d4-19cdb1b8e848@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
 <nTueRcNtsyjwrIqO7k7rsDU6JT-0020BZGwhYbGhWk4=.f5b32b5f-bde3-40fd-a7d4-19cdb1b8e848@github.com>
Message-ID: <Q6pKA8f2Id2Rioqkcb-EneeL7-giwc3r3iL68BzNZcs=.ac8e4ff1-462d-4cf4-8bbf-0385c5b33eed@github.com>

On Mon, 17 Jun 2024 07:44:33 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> [8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.
>
> test/micro/org/openjdk/bench/java/lang/MergeStoreBench.java line 656:
> 
>> 654:         array[offset + 2] = (byte) (value >>  8);
>> 655:         array[offset + 3] = (byte) (value      );
>> 656:     }
> 
> You say that here `MergeStore` does not work. That is because the indices are increasing, but the shifts decreasing. So that does not work on little-endian machines (most architectures), but I would expect it to work on big-endian machines with https://github.com/openjdk/jdk/pull/19218.

Big endian is often used in network data transmission scenarios, and it is common to process big endian data on a little endian machine. In this case, can it be optimized to Integer.reverseBytes & putInt on a LittleEndian machine? `setIntB -> setIntRL`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19734#discussion_r1642373495

From asotona at openjdk.org  Mon Jun 17 08:15:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 08:15:23 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v10]
In-Reply-To: <UfxoKDo2autP7ThykBrrk7_uf9LCPahZQp0kKYRzzeM=.9f921b0f-2ac6-4110-ace9-41b84913653a@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <UfxoKDo2autP7ThykBrrk7_uf9LCPahZQp0kKYRzzeM=.9f921b0f-2ac6-4110-ace9-41b84913653a@github.com>
Message-ID: <j68Z-s1-uEJKk6UfmR1rJUg5JfR--cgcG7Zt_sY0hzA=.a6d1d0d7-8c5d-4f7e-837b-55c34a98e523@github.com>

On Tue, 28 May 2024 11:03:18 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
> 
>   chore: changed pool marking initialization to be done in one pass

test/jdk/java/lang/invoke/indify/Indify.java line 197:

> 195:                     break;
> 196:                 case "-v": case "--verbose": case "--verbose=":
> 197:                     verbose = booleanOption(a2);  // more output

Why the comments have been removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1642379144

From clanger at openjdk.org  Mon Jun 17 08:34:35 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Jun 2024 08:34:35 GMT
Subject: [jdk23] RFR: 8211847: [aix] java/lang/ProcessHandle/InfoTest.java
 fails: "reported cputime less than expected"
Message-ID: <g-8JKYvzx0LcjuuHEwVouO7RqG0h7YIz9KQQ0Cg1l4c=.57dcb930-46ce-46f8-93fe-7d7dd95c6de4@github.com>

Hi all,

This pull request contains a backport of [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847), commit [f5213671](https://github.com/openjdk/jdk/commit/f5213671f7b636b32bb93c78e43696a61cd69bae) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Christoph Langer on 13 Jun 2024 and was reviewed by Thomas Stuefe.

Thanks!

-------------

Commit messages:
 - Backport f5213671f7b636b32bb93c78e43696a61cd69bae

Changes: https://git.openjdk.org/jdk/pull/19742/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19742&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8211847
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19742/head:pull/19742

PR: https://git.openjdk.org/jdk/pull/19742

From asotona at openjdk.org  Mon Jun 17 08:36:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 08:36:22 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v10]
In-Reply-To: <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
 <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>
 <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
Message-ID: <9l-tSZGQ3LgJm95ZcSQyUwHIS6ptgQ6WzRixg39L3xc=.c8658387-c3e3-4f6b-8cf5-e110e0a62cf4@github.com>

On Fri, 24 May 2024 17:12:34 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/indify/Indify.java line 503:
>> 
>>> 501: 
>>> 502:                 Iterator<Instruction> instructionIterator =getInstructions(m).iterator();
>>> 503:                 final Stack<Boolean> shouldProceedAfterIndyAdded = new Stack<>();
>> 
>> What this stack of booleans suppose to do?
>
> We need a boolean value to determine if we should proceed after replacing the appropriate "pop" instruction with an "invokedynamic" instruction. However, instead of using just a boolean field, we use a stack. The reason for this is that within the lambda expression, we can only use final variables. By using a stack, we can update its value as needed, which is why this approach is chosen.

I see here an iteration over instructions of a method, where the whole class is retransformed in certain situations and some status is passed back in a stack of booleans.
The whole conversion should be implemented in a single transformation.
Original code repeatedly replaced instructions inline (that is BTW reason why added nops below), however architecture of ClassFile API is different, you are transforming one class into completely new class (free to remove and add as many elements as you need). You can compose transformations into complex trees and you can also collect information before the transformation, however the class transformation should be executed only once.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1642418788

From asotona at openjdk.org  Mon Jun 17 09:22:14 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 09:22:14 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v2]
In-Reply-To: <bBEJNOFm1d8dtYtNMorLWhE5NVt2XSY5orJodx0FCno=.d1babf90-203c-4f1a-b0e3-745eafddee7a@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
 <bBEJNOFm1d8dtYtNMorLWhE5NVt2XSY5orJodx0FCno=.d1babf90-203c-4f1a-b0e3-745eafddee7a@github.com>
Message-ID: <ILeRtyM6QUPtivKcT01XS2yX3J_Rzz8r85NP9HjpEHk=.ff611ba8-7886-4d79-b2b3-275193bb6ad4@github.com>

On Fri, 14 Jun 2024 17:02:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
>> 
>> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - I am a dumbass
>  - Retain strict flag for Method, even though it's obsolete

`javap` should never silently ignore erroneous class file content.
If the flag value violates JVMS - it should be reported as an error and `javap` should reflect that in the return value.
On the other hand `javap` should handle such situations, provide relevant error message and continue with the report.
It is similar case as `javap` detection of inappropriate CP entry types.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19708#issuecomment-2172842079

From kevinw at openjdk.org  Mon Jun 17 09:36:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 09:36:33 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v14]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <IbwKY7mW_FmbcAV0MjN5n2WYramr_kbyeui7ouypVJw=.e3e04af8-b6e5-47ca-9961-839a5252d4c9@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls 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 19 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8333344_JMX_Subject
 - Monitor: do not call doAs with an explicityly null Subject
 - Unnecessary catches to remove
 - Monitor update
 - ServerNotifForwarder simplification
 - Separate SM allowed and not allowed cases
 - ServerNotifForwarder getSubject update
 - Exception handling per Daniel comment
 - Annotation in checkAccess
 -  Undo test policy updates
 - ... and 9 more: https://git.openjdk.org/jdk/compare/c0b2e87b...ee2dd12e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/13d9202f..ee2dd12e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=12-13

  Stats: 15038 lines in 603 files changed: 6231 ins; 7274 del; 1533 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Mon Jun 17 09:36:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 09:36:33 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v13]
In-Reply-To: <sRb3ETsM2lP1ZBPr7zlspeHqYQMjA07Wb6YbcJhCyLQ=.5534d0b1-08dc-45f0-83a1-8ef097838878@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
 <sRb3ETsM2lP1ZBPr7zlspeHqYQMjA07Wb6YbcJhCyLQ=.5534d0b1-08dc-45f0-83a1-8ef097838878@github.com>
Message-ID: <24tYAB_NAd2xlS1OcTcyqphpFnl17RqS-lCv6avPX04=.fdea8971-3e2b-4ba9-9e14-78e1381823da@github.com>

On Sun, 16 Jun 2024 01:54:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unnecessary catches to remove
>
> src/java.management/share/classes/javax/management/monitor/Monitor.java line 1542:
> 
>> 1540:             if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>> 1541:                 // No SecurityManager permitted:
>> 1542:                 Subject.doAs(s, action); // s is permitted to be null
> 
> While `s` is permitted to be null, calling `Subject.doAs(null, action)` actually sets the current subject to null while calling `action`. This is not same as directly calling `action` where the current subject (could be non null) is used.

Yes, good point, got it. 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642504749

From kevinw at openjdk.org  Mon Jun 17 10:03:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 10:03:27 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v15]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - leave noPermissionsACC in place for now
 - leave noPermissionsACC in place for now

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/ee2dd12e..2f2179e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=13-14

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Mon Jun 17 10:06:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 10:06:14 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v10]
In-Reply-To: <ALogI3wbbzp9cQ-2KJKwXjcPLsWa5wkqUdX8N5qgCyc=.ff71b0c6-ba82-4231-867f-3b88b9497db8@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <-r3ZugqL4OdjUb6V1Z25NsUVPqKr4qn3SdSs-cojhTY=.d90a7230-fef3-484e-9d1d-177339233f24@github.com>
 <JeArKhrTjTXNpfjTqLmr9rYln2ZXOznbML2azNrZWCc=.8881d03f-8f06-4593-966f-9223e8732a7a@github.com>
 <cp-kNjl5sDRtOtdqgru1Vvs7zS3cQ4yq1lAnzQlrBXw=.e09c9e03-46b5-4fca-856d-cc064f09e495@github.com>
 <ALogI3wbbzp9cQ-2KJKwXjcPLsWa5wkqUdX8N5qgCyc=.ff71b0c6-ba82-4231-867f-3b88b9497db8@github.com>
Message-ID: <Fkj4mnp6LY4WRxS3JwZesaLFb0qM8Qk5qHSJPygP34s=.7d6af1c9-9135-43aa-ba8b-41af3df8661e@github.com>

On Fri, 14 Jun 2024 14:48:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > Does noPermissionsACC add anything?
> 
> I don't know. My principal for this code change is that nothing is changed for the SM-is-allowed case.

I've put back the noPermissionsACC for this change, it does not have to be removed in this change.  It was introduced in jdk6, and we will remove it next time we are here when we drop ACC usage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2172948152

From mbaesken at openjdk.org  Mon Jun 17 10:25:17 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Jun 2024 10:25:17 GMT
Subject: [jdk23] RFR: 8211847: [aix] java/lang/ProcessHandle/InfoTest.java
 fails: "reported cputime less than expected"
In-Reply-To: <g-8JKYvzx0LcjuuHEwVouO7RqG0h7YIz9KQQ0Cg1l4c=.57dcb930-46ce-46f8-93fe-7d7dd95c6de4@github.com>
References: <g-8JKYvzx0LcjuuHEwVouO7RqG0h7YIz9KQQ0Cg1l4c=.57dcb930-46ce-46f8-93fe-7d7dd95c6de4@github.com>
Message-ID: <QyeE7I4xobDvF1JZSv238Rl-0QXJJTxAZ9klJQ330Yw=.697c77d0-1886-44aa-98f1-f57653202e0e@github.com>

On Mon, 17 Jun 2024 08:19:18 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847), commit [f5213671](https://github.com/openjdk/jdk/commit/f5213671f7b636b32bb93c78e43696a61cd69bae) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Christoph Langer on 13 Jun 2024 and was reviewed by Thomas Stuefe.
> 
> Thanks!

Looks okay, but please reconsider the description text of the bug, is it still what you do?

-------------

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19742#pullrequestreview-2122517377

From adinn at redhat.com  Mon Jun 17 10:43:29 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 17 Jun 2024 11:43:29 +0100
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <2569c451-b686-427e-8a29-80c3239d9831@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
 <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
 <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
 <2569c451-b686-427e-8a29-80c3239d9831@oracle.com>
Message-ID: <004ab900-3ff5-4af9-87df-9316640e31a6@redhat.com>

On 13/06/2024 14:39, Alan Bateman wrote:
> Good to hear you've got a prototype to discuss. I don't think I can look 
> at what you have in your own repo but I do have a question. Do the 
> defaultXXX methods return a method handle or do they fail/null when 
> there are read/writeObject methods? Asking if they will bypass these 
> methods.
Why can you not look at David's repo? He is a JDK author (dmlloyd) and 
this work is being done as part of his employment by Red Hat.

regards,


Andrew Dinn
-----------


From asotona at openjdk.org  Mon Jun 17 11:24:31 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 11:24:31 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <r5Tiy1ujWNM3o6svQyBjU2-7SwMCwy16s3xCKZ6z0iA=.0c3cc3d8-c2c3-478d-b27c-8d6c7ea01e99@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
 <r5Tiy1ujWNM3o6svQyBjU2-7SwMCwy16s3xCKZ6z0iA=.0c3cc3d8-c2c3-478d-b27c-8d6c7ea01e99@github.com>
Message-ID: <sNXfVS28_c4DVAvHtEY3PJ-oALdxY8zHXIPjYBjvkjA=.d88e3567-df9e-4f71-ae5c-2ac37dc7b416@github.com>

On Thu, 13 Jun 2024 09:27:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 616:
>> 
>>> 614:             final ClassDesc classDesc = ClassDesc.of(className0);
>>> 615:             final ClassDesc superClassDesc = classDesc(speciesData.deriveSuperClass());
>>> 616:             return ClassFile.of().build(classDesc, clb -> {
>> 
>> We need a confirmation here that these BMH species are only initialized after LMF is ready. @cl4es Is a dependency on LMF from BMH safe?
>
> LMF will BMH and `ClassSpecializer`, but does not call into this code normally as the simple bound method handle needed by LMF is statically defined (`BoundMethodHandle.Species_L`). To be perfectly safe - and to keep lambda/indy/condy bootstrap overheads to a minumum - I'll continue recommending the desugaring of lambdas in java.lang.invoke

It results in not very nice code, but makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1642653369

From duke at openjdk.org  Mon Jun 17 11:30:27 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 11:30:27 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v2]
In-Reply-To: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
Message-ID: <JesSWXFOX9Nat3Nq96vgofgQiY5WGYj5Xk5p7I2Zst4=.df8bf398-ef8e-4cac-8c6c-a09e1b271dc8@github.com>

> [8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - use VarHandler CHAR_L & CHAR_B
 - copyright
 - bug fix for putIntBU
 - add cases for `getChar` & `putChar`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19734/files
  - new: https://git.openjdk.org/jdk/pull/19734/files/72a6256a..65bb597d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=00-01

  Stats: 322 lines in 1 file changed: 276 ins; 14 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/19734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19734/head:pull/19734

PR: https://git.openjdk.org/jdk/pull/19734

From clanger at openjdk.org  Mon Jun 17 12:23:16 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Jun 2024 12:23:16 GMT
Subject: [jdk23] Integrated: 8211847: [aix]
 java/lang/ProcessHandle/InfoTest.java fails:
 "reported cputime less than expected"
In-Reply-To: <g-8JKYvzx0LcjuuHEwVouO7RqG0h7YIz9KQQ0Cg1l4c=.57dcb930-46ce-46f8-93fe-7d7dd95c6de4@github.com>
References: <g-8JKYvzx0LcjuuHEwVouO7RqG0h7YIz9KQQ0Cg1l4c=.57dcb930-46ce-46f8-93fe-7d7dd95c6de4@github.com>
Message-ID: <WAIj33zeQW3BjM4-mbL2fFNiUCqKWhx7wB1r-k0_2lY=.0029870d-dc87-4989-8baf-8053665644aa@github.com>

On Mon, 17 Jun 2024 08:19:18 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847), commit [f5213671](https://github.com/openjdk/jdk/commit/f5213671f7b636b32bb93c78e43696a61cd69bae) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Christoph Langer on 13 Jun 2024 and was reviewed by Thomas Stuefe.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 4e3bfc92
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e3bfc926ebdf512c7b9dbddc8caa7b66e2777f7
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported cputime less than expected"

Reviewed-by: mbaesken
Backport-of: f5213671f7b636b32bb93c78e43696a61cd69bae

-------------

PR: https://git.openjdk.org/jdk/pull/19742

From weijun at openjdk.org  Mon Jun 17 12:41:15 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 17 Jun 2024 12:41:15 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v15]
In-Reply-To: <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>
Message-ID: <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>

On Mon, 17 Jun 2024 10:03:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - leave noPermissionsACC in place for now
>  - leave noPermissionsACC in place for now

Looks good to me. Just 2 tiny coding style issues.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:

> 1434:                         return op.run();
> 1435:                     } catch (Exception e) {
> 1436:                         if (e instanceof RuntimeException)

Enclose the next line in braces.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:

> 347:     @SuppressWarnings("removal")
> 348:     private Subject getSubject() {
> 349:        return Subject.current();

Add a leading whitespace.

-------------

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2122787201
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642742989
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642743676

From kevinw at openjdk.org  Mon Jun 17 12:41:15 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 12:41:15 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v15]
In-Reply-To: <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>
 <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>
Message-ID: <KR6r7-9EAauXGoWWFrHo9PfpXoskKHuiuh76plEPffM=.d18a8e8c-acee-4d4a-892f-cdef77609fea@github.com>

On Mon, 17 Jun 2024 12:33:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - leave noPermissionsACC in place for now
>>  - leave noPermissionsACC in place for now
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
> 
>> 347:     @SuppressWarnings("removal")
>> 348:     private Subject getSubject() {
>> 349:        return Subject.current();
> 
> Add a leading whitespace.

got it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642749038

From asotona at openjdk.org  Mon Jun 17 12:46:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 12:46:17 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
Message-ID: <D9UjnLE6txyedzyB76XOIjlFpfv_zDe4DKUA3N6X2N4=.983803b9-61da-49ef-a56f-923a09d98bf9@github.com>

On Thu, 6 Jun 2024 12:13:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - reverted static initialization of ConstantPoolBuilder and CP entries
>>  - fixed naming conventions
>
> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 784:
> 
>> 782:                             // mix them up and load them for the transform helper:
>> 783:                             List<Var> helperArgs = speciesData.deriveTransformHelperArguments(transformMethods.get(whichtm), whichtm, targs, tfields);
>> 784:                             List<Class<?>> helperTypes = new ArrayList<>(helperArgs.size());
> 
> Can we convert helperTypes here to List<ClassDesc> so we construct invokeBasicType as MethodTypeDesc below?

This part can be simplified to a directly used validated array of ClassDesc and many conversions can be skipped.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1642756354

From kevinw at openjdk.org  Mon Jun 17 12:54:44 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 12:54:44 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v16]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - style update
 - whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/2f2179e7..597264b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=14-15

  Stats: 11 lines in 2 files changed: 4 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Mon Jun 17 12:54:44 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 12:54:44 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v15]
In-Reply-To: <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <049IkM0XAZH--nI3kzEx5sr9bTZEmKAEthTpraZ0vQc=.a8195e52-7c69-458a-abf9-26e91702e8b3@github.com>
 <5qJoLdiqlmc02xfIUc-MSU4nr5LKzHI-ZLXhqoSZOIc=.851faac0-72bc-4ec6-bf66-2740231aad2e@github.com>
Message-ID: <uLCqOZEpYx1RI2_D-Cfj9AS-uzCGZpR03ZXfjYlCPqA=.d6220bf5-e3b2-48f8-9354-4b3accbd130c@github.com>

On Mon, 17 Jun 2024 12:33:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - leave noPermissionsACC in place for now
>>  - leave noPermissionsACC in place for now
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1436:
> 
>> 1434:                         return op.run();
>> 1435:                     } catch (Exception e) {
>> 1436:                         if (e instanceof RuntimeException)
> 
> Enclose the next line in braces.

Yes this file is full of pre-existing style problems like that.  I can update this and its friend at 1451.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642763028

From duke at openjdk.org  Mon Jun 17 12:56:49 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 12:56:49 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v3]
In-Reply-To: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
Message-ID: <sPwkJnsOreYD2EBvaHX-JIJwAHtFAV6hRjVCIb85Uek=.cc69ec8a-377a-4612-af06-12720c5125d9@github.com>

> [8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix for `putChars4C` and `putChars4S`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19734/files
  - new: https://git.openjdk.org/jdk/pull/19734/files/65bb597d..1ed9b22e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=01-02

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19734/head:pull/19734

PR: https://git.openjdk.org/jdk/pull/19734

From asotona at openjdk.org  Mon Jun 17 13:11:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 13:11:17 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
Message-ID: <fuKbZ1p078QkorEDMrLWQ4rlsFqb1_ktMI9FZvOaaKM=.7affebbb-60cb-411a-a8f2-7edf98acf247@github.com>

On Thu, 6 Jun 2024 12:17:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - reverted static initialization of ConstantPoolBuilder and CP entries
>>  - fixed naming conventions
>
> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 564:
> 
>> 562:             clb.withFlags(ACC_PRIVATE | ACC_FINAL | ACC_SUPER)
>> 563:                .withSuperclass(InvokerBytecodeGenerator.INVOKER_SUPER_DESC)
>> 564:                .with(SourceFileAttribute.of(className.substring(className.lastIndexOf('/') + 1)));
> 
> Maybe we can keep the classDesc from ofInternalName and use its displayName.

I don't see any benefits, both ways are sub-stringing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1642789436

From asotona at openjdk.org  Mon Jun 17 13:14:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 13:14:17 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
Message-ID: <4VNO-R9an10uGJn6E81-0XLDrwa_l1FVXHtCbw5GfkQ=.4fd2ce75-9489-4df0-8374-f7676673c89c@github.com>

On Thu, 6 Jun 2024 12:22:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - reverted static initialization of ConstantPoolBuilder and CP entries
>>  - fixed naming conventions
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 96:
> 
>> 94:         }
>> 95:     };
>> 96:     record MethodBody(Consumer<CodeBuilder> code) implements Consumer<MethodBuilder> {
> 
> Why do we have these 2 instead of a noop record field builder consumer (flags is already set in withField, and MethodBody should just be direct usage of withMethodBody)
> 
> Seems the problem is in CF implemetnation side. Then these should be part of CF implementation details.

There is no problem if you can rely on lambdas ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1642793485

From asotona at openjdk.org  Mon Jun 17 13:19:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 13:19:18 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
Message-ID: <oH3F4jkGlpCJVwa0QENdRm0rtFS7mxEjdhJQg2C9-Us=.00354cc6-20ae-4689-8d53-1a43f0e02ce6@github.com>

On Thu, 6 Jun 2024 13:17:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - reverted static initialization of ConstantPoolBuilder and CP entries
>>  - fixed naming conventions
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 470:
> 
>> 468:         MethodVisitor mv = cw.visitMethod(ACC_PRIVATE + ACC_FINAL,
>> 469:                                           NAME_METHOD_WRITE_OBJECT, DESCR_METHOD_WRITE_OBJECT,
>> 470:                                           null, SER_HOSTILE_EXCEPTIONS);
> 
> The exceptions attribute is now lost on the migrated methods. Is that ok? It's private and only accessed by reflection so I think there's no real impact.

Good catch, they were lost in translation.
I think we should keep them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1642800017

From zgu at openjdk.org  Mon Jun 17 13:27:14 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 17 Jun 2024 13:27:14 GMT
Subject: RFR: 8333962: Obsolete OldSize [v2]
In-Reply-To: <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
 <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
Message-ID: <qf1gkO5O2KSSxAjYSJmq_WPhQylmdcHUTEVD6sDeT6I=.9648e432-c43a-4eec-a1d9-801c55616d62@github.com>

On Fri, 14 Jun 2024 10:19:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   obsolete-old-size

src/hotspot/share/gc/shared/genArguments.hpp line 36:

> 34: extern size_t MaxOldSize;
> 35: 
> 36: extern size_t OldSize;

Any reason we still want to keep `OldSize` variable? becase GCs really care about are `init`, `min` and `max` values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19647#discussion_r1642814306

From Alan.Bateman at oracle.com  Mon Jun 17 13:28:34 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Jun 2024 14:28:34 +0100
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <004ab900-3ff5-4af9-87df-9316640e31a6@redhat.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
 <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>
 <CANghgrREJA1qAFGnXxPQ-5o=wD17X5RoMiUGp578Hd=J0fon1Q@mail.gmail.com>
 <355c3479-5734-4c43-af4d-a60223b0187e@oracle.com>
 <CANghgrRSaAj+WFhY=_nc2e-Y=x6s=Zgzi5-fyAG78BCF=J2UEg@mail.gmail.com>
 <4F5E0276-44AC-4C45-A9CC-DA8EAB7F6307@oracle.com>
 <CANghgrQayByesoeLXsAqVUFjtaOeuohCJKQ7w5YrOz=H73qzrw@mail.gmail.com>
 <2c60105e-2247-4e68-93a0-6e21e0f14e81@oracle.com>
 <CANghgrTvXdM+hpDGbjGjr2SnRi_WjOT9TneDvW0rkwR9s8bV9A@mail.gmail.com>
 <CANghgrR4jkvzsisfnKH9DvuyB9RtUe4KgXx5KeMtpCLXvLkE8w@mail.gmail.com>
 <2569c451-b686-427e-8a29-80c3239d9831@oracle.com>
 <004ab900-3ff5-4af9-87df-9316640e31a6@redhat.com>
Message-ID: <3e1e34ba-759b-485c-b16e-920b7e1bdc87@oracle.com>

On 17/06/2024 11:43, Andrew Dinn wrote:
> On 13/06/2024 14:39, Alan Bateman wrote:
>> Good to hear you've got a prototype to discuss. I don't think I can 
>> look at what you have in your own repo but I do have a question. Do 
>> the defaultXXX methods return a method handle or do they fail/null 
>> when there are read/writeObject methods? Asking if they will bypass 
>> these methods.
> Why can you not look at David's repo? He is a JDK author (dmlloyd) and 
> this work is being done as part of his employment by Red Hat.

He has created a draft PR against openjdk/jdk so that removes any 
question as to whether there is an issue looking at the change in 
another github repo.
-Alan



From liach at openjdk.org  Mon Jun 17 13:55:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 13:55:41 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v3]
In-Reply-To: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
Message-ID: <9JZ8XXWlauTkDg2OQqV5dnhSXbKzotJNpe0aaGPuZII=.899a1f8f-1d33-42a7-97ec-a4b3701d462f@github.com>

> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
> 
> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - Improve tests to check unmatched bit position and failure for non-inner-classes
 - Report error for flag problems

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19708/files
  - new: https://git.openjdk.org/jdk/pull/19708/files/84506788..0f3e1a97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19708&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19708&range=01-02

  Stats: 124 lines in 4 files changed: 55 ins; 34 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/19708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19708/head:pull/19708

PR: https://git.openjdk.org/jdk/pull/19708

From liach at openjdk.org  Mon Jun 17 13:58:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 13:58:13 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v2]
In-Reply-To: <ILeRtyM6QUPtivKcT01XS2yX3J_Rzz8r85NP9HjpEHk=.ff611ba8-7886-4d79-b2b3-275193bb6ad4@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
 <bBEJNOFm1d8dtYtNMorLWhE5NVt2XSY5orJodx0FCno=.d1babf90-203c-4f1a-b0e3-745eafddee7a@github.com>
 <ILeRtyM6QUPtivKcT01XS2yX3J_Rzz8r85NP9HjpEHk=.ff611ba8-7886-4d79-b2b3-275193bb6ad4@github.com>
Message-ID: <x54LrzmsJVT7vFr7QIr7-WS5AjSWQjw9VJUFQjEd3zY=.220208bb-ec78-425b-a45c-a1807b4bb5a1@github.com>

On Mon, 17 Jun 2024 09:19:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - I am a dumbass
>>  - Retain strict flag for Method, even though it's obsolete
>
> `javap` should never silently ignore erroneous class file content.
> If the flag value violates JVMS - it should be reported as an error and `javap` should reflect that in the return value.
> On the other hand `javap` should handle such situations, provide relevant error message and continue with the report.
> It is similar case as `javap` detection of inappropriate CP entry types.

@asotona Thanks for the note, I have updated the code so javap now behaves like your suggestion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19708#issuecomment-2173462470

From asotona at openjdk.org  Mon Jun 17 14:05:29 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 14:05:29 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v19]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <5q6ZiHnDOLrZq1qFKGcCGE0UZJFnKGgX6fuhpcE156E=.c9d2e24f-e81c-45c8-9947-a233924d9d8d@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/f870a8df..9d105694

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From asotona at openjdk.org  Mon Jun 17 14:05:29 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 14:05:29 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
Message-ID: <mFNiEA4pIT9ZmoxQupm9mqd3da2jWJJRqR05Y4tgiqA=.f486cc85-8465-4575-b5e0-350e06e86a01@github.com>

On Wed, 12 Jun 2024 20:27:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - reverted static initialization of ConstantPoolBuilder and CP entries
>>  - fixed naming conventions
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1148:
> 
>> 1146:     }
>> 1147: 
>> 1148:     private void emitPopInsn(CodeBuilder cob, BasicType type) {
> 
> We need a TypeKind-aware pop in CodeBuilder too :(

Yes, it would be helpful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1642870775

From dfuchs at openjdk.org  Mon Jun 17 14:12:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Jun 2024 14:12:18 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v16]
In-Reply-To: <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
Message-ID: <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>

On Mon, 17 Jun 2024 12:54:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - style update
>  - whitespace

The new version looks much better to me. I wonder if we can abstract away some of the repeated logic though.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1314:

> 1312:                     return AccessController.doPrivileged(action, acc);
> 1313:                 }
> 1314:             }

This piece of code is repeated at several places in similar but different forms - sometime we check for `SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime for `! SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime we check for `acc == null`, sometime for `acc != null` etc.. 
I wonder if we could abstract that to some utility method somewhere. Would that make sense? Maybe that's not possible due to using sometime `PrivelegedAction` and sometimes `PrivilegedExceptionAction` - but maybe we could use `PrivilegedExceptionAction` everywhere at the cost of handling `PrivilegedActionException`? 
If that doesn't prove useful (if handling `PrivilegedExceptionAction` adds again an equivalent amount of clutter) then maybe we could at least make sure we do the same checks in the same way (typically `acc == null` vs `acc != null`)?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2118725434
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1642864523

From dfuchs at openjdk.org  Mon Jun 17 14:12:20 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Jun 2024 14:12:20 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v13]
In-Reply-To: <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <5sBWV98TLsHljS8CO8bCqyvhfArlIVERR1PjwUXpqwc=.2b1df2ea-4679-4644-856b-9f9dbb0bba37@github.com>
Message-ID: <2mtwqvJmQWckd_gItk_ZImn-DoSfqLfYqKNn5LfsEZc=.5d214dee-d325-4530-806a-ad6e7e739d5f@github.com>

On Fri, 14 Jun 2024 15:26:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unnecessary catches to remove

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1437:

> 1435:                     } catch (Exception e) {
> 1436:                         if (e instanceof RuntimeException)
> 1437:                            throw (RuntimeException) e;

Suggestion:

                        if (e instanceof RuntimeException rte)
                           throw rte;

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1450:

> 1448:                     } catch (Exception e) {
> 1449:                         if (e instanceof RuntimeException)
> 1450:                            throw (RuntimeException) e;

Suggestion:

                        if (e instanceof RuntimeException rte)
                           throw rte;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1640033632
PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1640034429

From ayang at openjdk.org  Mon Jun 17 14:14:13 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Jun 2024 14:14:13 GMT
Subject: RFR: 8333962: Obsolete OldSize [v2]
In-Reply-To: <qf1gkO5O2KSSxAjYSJmq_WPhQylmdcHUTEVD6sDeT6I=.9648e432-c43a-4eec-a1d9-801c55616d62@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
 <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
 <qf1gkO5O2KSSxAjYSJmq_WPhQylmdcHUTEVD6sDeT6I=.9648e432-c43a-4eec-a1d9-801c55616d62@github.com>
Message-ID: <Ul1nqHnt6njMCx4s3G4lvXIEIXO58_xH3pWp38JpUkw=.ce1a3be2-459c-4413-a9c9-1d69f420a7ad@github.com>

On Mon, 17 Jun 2024 13:25:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   obsolete-old-size
>
> src/hotspot/share/gc/shared/genArguments.hpp line 36:
> 
>> 34: extern size_t MaxOldSize;
>> 35: 
>> 36: extern size_t OldSize;
> 
> Any reason we still want to keep `OldSize` variable? becase GCs really care about are `init`, `min` and `max` values.

The concept of "initial old-gen size" will always be there. If `OldSize` is removed, all readers need to be updated to `InitialHeapSize - NewSize`. It's not obvious that is definitely better/more readable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19647#discussion_r1642885640

From fguallini at openjdk.org  Mon Jun 17 14:14:35 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Mon, 17 Jun 2024 14:14:35 GMT
Subject: RFR: 8329335: HttpsURLConnectionTest fails due to network firewall
 rules
Message-ID: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>

Since HttpsURLConnectionTest attempts to reach external servers, it can fail if run on hosts without outbound traffic allowed. Therefore, it should not be executed in CI pipelines but rather manually on a host with no firewall rules preventing egress traffic.

-------------

Commit messages:
 - test should be run manually to avoid proxy problems

Changes: https://git.openjdk.org/jdk/pull/19745/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19745&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329335
  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19745/head:pull/19745

PR: https://git.openjdk.org/jdk/pull/19745

From zgu at openjdk.org  Mon Jun 17 14:24:14 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 17 Jun 2024 14:24:14 GMT
Subject: RFR: 8333962: Obsolete OldSize [v2]
In-Reply-To: <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
 <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
Message-ID: <9wcGUx1Tyv7uL_qE19qUb-65JJglpKpmxxsoZhqTuMo=.90e1be90-0f90-4d43-8bb7-87aa3d6a59cc@github.com>

On Fri, 14 Jun 2024 10:19:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   obsolete-old-size

LGTM

-------------

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19647#pullrequestreview-2123055719

From duke at openjdk.org  Mon Jun 17 14:26:49 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 14:26:49 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v4]
In-Reply-To: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
Message-ID: <DXI_H0s15RtGQf1DBiiXnQn5V5ec55x1BedosJbThI4=.7e12fe77-6041-4db2-8574-58c18cfba262@github.com>

> [8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix for `putChars4C`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19734/files
  - new: https://git.openjdk.org/jdk/pull/19734/files/1ed9b22e..1140bd81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=02-03

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19734/head:pull/19734

PR: https://git.openjdk.org/jdk/pull/19734

From ayang at openjdk.org  Mon Jun 17 14:30:30 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Jun 2024 14:30:30 GMT
Subject: RFR: 8333962: Obsolete OldSize [v3]
In-Reply-To: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
Message-ID: <2teqQqHjCobhvE7McOCbECpQ1z4kxnFg74KoqFHZiFg=.93fae87f-eeef-4010-a458-7a5aebbae869@github.com>

> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:

  obsolete-old-size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19647/files
  - new: https://git.openjdk.org/jdk/pull/19647/files/3e820b6f..a27f5172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19647&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19647&range=01-02

  Stats: 1483 lines in 67 files changed: 966 ins; 310 del; 207 mod
  Patch: https://git.openjdk.org/jdk/pull/19647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19647/head:pull/19647

PR: https://git.openjdk.org/jdk/pull/19647

From ayang at openjdk.org  Mon Jun 17 14:30:30 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Jun 2024 14:30:30 GMT
Subject: RFR: 8333962: Obsolete OldSize [v2]
In-Reply-To: <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
 <gEO_TdpGgGl-rZmXHWuoTuav6x4NxWi8tULj-xI07n4=.4af3e6e2-3440-4322-87cc-9479f16e11c2@github.com>
Message-ID: <gVf9cPGpdf56fP_KngDNJ73KAlfXnjaAcWQoP4AMw98=.7c113ec6-8095-48a1-aaf4-570411aa8191@github.com>

On Fri, 14 Jun 2024 10:19:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   obsolete-old-size

Synced with master. Running some tests before merging.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19647#issuecomment-2173573858

From mchhipa at openjdk.org  Mon Jun 17 14:50:11 2024
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Mon, 17 Jun 2024 14:50:11 GMT
Subject: RFR: 8329335: HttpsURLConnectionTest fails due to network firewall
 rules
In-Reply-To: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>
References: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>
Message-ID: <kcqBf8v4slJY6Ue0JSfkNYeUTZKGnWQzOz7gZSdTPGA=.20816b7c-0fbe-42a4-a434-27fd25ac9831@github.com>

On Mon, 17 Jun 2024 09:16:45 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Since HttpsURLConnectionTest attempts to reach external servers, it can fail if run on hosts without outbound traffic allowed. Therefore, it should not be executed in CI pipelines but rather manually on a host with no firewall rules preventing egress traffic.

Hi @fguallini , what if NAT Gateway of CI machines VCN is configured to allow one way initiation traffic to specific external server. Then this change is not required.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19745#issuecomment-2173618927

From asotona at openjdk.org  Mon Jun 17 14:57:45 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 14:57:45 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v20]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <Y1cq5H1CCKlLSl8d6ogrt782e7zBvRwcpHJm8x6nHCI=.d91ff41a-6120-434d-81e8-9060ed4f599e@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - applied suggested changes
 - Update src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - reverted static initialization of ConstantPoolBuilder and CP entries
 - fixed naming conventions
 - use of jdk.internal.constant to improve performance
 - fixed imports
 - Apply suggestions from code review
   
   There are new possibilities with decoupled constants implementation, thank you for the reminder.
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Attributes.java
 - ... and 22 more: https://git.openjdk.org/jdk/compare/cdf22b13...3aaf246e

-------------

Changes: https://git.openjdk.org/jdk/pull/17108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=19
  Stats: 2166 lines in 10 files changed: 462 ins; 881 del; 823 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From weijun at openjdk.org  Mon Jun 17 14:59:41 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 17 Jun 2024 14:59:41 GMT
Subject: RFR: 8334394: Race condition in Class::protectionDomain
Message-ID: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>

Make sure `pd` is always the same object when `getProtectionDomain0` is null.

-------------

Commit messages:
 - chmod
 - the fix

Changes: https://git.openjdk.org/jdk/pull/19752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19752&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334394
  Stats: 84 lines in 2 files changed: 67 ins; 10 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19752/head:pull/19752

PR: https://git.openjdk.org/jdk/pull/19752

From liach at openjdk.org  Mon Jun 17 15:06:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 15:06:12 GMT
Subject: RFR: 8334394: Race condition in Class::protectionDomain
In-Reply-To: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
Message-ID: <FECgB8VUIxBGeJWrmu5w_72mjAa508MTBhsRnwchNgs=.36876917-ad8c-4e2a-9df5-0224932b4224@github.com>

On Mon, 17 Jun 2024 14:51:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Make sure `pd` is always the same object when `getProtectionDomain0` is null.

Looks great! I just wonder about how we usually write tests for such races, as these races may be platform-dependent and the test might not be able to always reproduce the race (such as with number of threads).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19752#issuecomment-2173658541

From liach at openjdk.org  Mon Jun 17 15:11:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 15:11:13 GMT
Subject: RFR: 8334394: Race condition in Class::protectionDomain
In-Reply-To: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
Message-ID: <tuGN_pcg9yKwPKqZgSE0VAYsKJZpq2DHuVXNDPSyW_g=.79c34859-1296-48db-bbbb-6d06c422101e@github.com>

On Mon, 17 Jun 2024 14:51:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Make sure `pd` is always the same object when `getProtectionDomain0` is null.

test/jdk/java/lang/Class/ProtectionDomainRace.java line 42:

> 40:                 try {
> 41:                     Subject.doAs(null, ac);
> 42:                 } catch (Throwable t) {

This can test for the racy NPE, but it cannot detect if there's distinct allPermDomain objects written by races. Should we add another check to defend against that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19752#discussion_r1642969479

From asotona at openjdk.org  Mon Jun 17 15:13:12 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 15:13:12 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v3]
In-Reply-To: <9JZ8XXWlauTkDg2OQqV5dnhSXbKzotJNpe0aaGPuZII=.899a1f8f-1d33-42a7-97ec-a4b3701d462f@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
 <9JZ8XXWlauTkDg2OQqV5dnhSXbKzotJNpe0aaGPuZII=.899a1f8f-1d33-42a7-97ec-a4b3701d462f@github.com>
Message-ID: <R1N81BZYUWC_DwVz7vYQvD13ZA-iQMWv9pxjA0ONHqc=.6d7fabbc-eb05-47a1-b565-9ed389e0101c@github.com>

On Mon, 17 Jun 2024 13:55:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
>> 
>> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve tests to check unmatched bit position and failure for non-inner-classes
>  - Report error for flag problems

test/langtools/tools/javap/UndefinedAccessFlagTest.java line 105:

> 103:             .writeAll()
> 104:             .getOutputLines(Task.OutputKind.DIRECT);
> 105:         assertTrue(lines.stream().anyMatch(l -> l.contains("Unmatched bit position")), () -> String.join("\n", lines));

I would add a check the "fatal" error does not occur or any other way to confirm correct recovery.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19708#discussion_r1642972527

From weijun at openjdk.org  Mon Jun 17 15:14:14 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 17 Jun 2024 15:14:14 GMT
Subject: RFR: 8334394: Race condition in Class::protectionDomain
In-Reply-To: <tuGN_pcg9yKwPKqZgSE0VAYsKJZpq2DHuVXNDPSyW_g=.79c34859-1296-48db-bbbb-6d06c422101e@github.com>
References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
 <tuGN_pcg9yKwPKqZgSE0VAYsKJZpq2DHuVXNDPSyW_g=.79c34859-1296-48db-bbbb-6d06c422101e@github.com>
Message-ID: <haJwKcxkBBIFssVSaMEVCGcgbDpn2UIu9Gz_X6BTrOg=.06a2b5e3-2d47-4b63-bbbb-c45c66b77a7f@github.com>

On Mon, 17 Jun 2024 15:08:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Make sure `pd` is always the same object when `getProtectionDomain0` is null.
>
> test/jdk/java/lang/Class/ProtectionDomainRace.java line 42:
> 
>> 40:                 try {
>> 41:                     Subject.doAs(null, ac);
>> 42:                 } catch (Throwable t) {
> 
> This can test for the racy NPE, but it cannot detect if there's distinct allPermDomain objects written by races. Should we add another check to defend against that?

Actually it can. This bug originally breaks the `assert` statement at https://github.com/openjdk/jdk/blob/5cea53d372744ddf1bedaae4667415e6525ef82f/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#L1209.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19752#discussion_r1642973826

From weijun at openjdk.org  Mon Jun 17 15:17:11 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 17 Jun 2024 15:17:11 GMT
Subject: RFR: 8334394: Race condition in Class::protectionDomain
In-Reply-To: <haJwKcxkBBIFssVSaMEVCGcgbDpn2UIu9Gz_X6BTrOg=.06a2b5e3-2d47-4b63-bbbb-c45c66b77a7f@github.com>
References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
 <tuGN_pcg9yKwPKqZgSE0VAYsKJZpq2DHuVXNDPSyW_g=.79c34859-1296-48db-bbbb-6d06c422101e@github.com>
 <haJwKcxkBBIFssVSaMEVCGcgbDpn2UIu9Gz_X6BTrOg=.06a2b5e3-2d47-4b63-bbbb-c45c66b77a7f@github.com>
Message-ID: <3nhagpDHfNRRx-NEpHZKbJoOPkFbSjBZ2KFvV-BNlvQ=.d39a1d3b-2d1e-4841-93eb-55d5008bf359@github.com>

On Mon, 17 Jun 2024 15:11:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/java/lang/Class/ProtectionDomainRace.java line 42:
>> 
>>> 40:                 try {
>>> 41:                     Subject.doAs(null, ac);
>>> 42:                 } catch (Throwable t) {
>> 
>> This can test for the racy NPE, but it cannot detect if there's distinct allPermDomain objects written by races. Should we add another check to defend against that?
>
> Actually it can. This bug originally breaks the `assert` statement at https://github.com/openjdk/jdk/blob/5cea53d372744ddf1bedaae4667415e6525ef82f/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#L1209.

So this test might look like unrelated to the fix at first sight, but somewhere deep inside the call stack it does. I should add a comment. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19752#discussion_r1642978163

From weijun at openjdk.org  Mon Jun 17 15:24:27 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 17 Jun 2024 15:24:27 GMT
Subject: RFR: 8334394: Race condition in Class::protectionDomain [v2]
In-Reply-To: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
Message-ID: <Y_-dtrQSFf-aMn7biqRH7Sn2wmgkyjJDlKTkqk0QG08=.24828899-992c-4e1f-a0cc-7279be51dc86@github.com>

> Make sure `pd` is always the same object when `getProtectionDomain0` is null.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  explain why the test is related to the fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19752/files
  - new: https://git.openjdk.org/jdk/pull/19752/files/637cf0df..4ce5bc24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19752&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19752&range=00-01

  Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19752/head:pull/19752

PR: https://git.openjdk.org/jdk/pull/19752

From ayang at openjdk.org  Mon Jun 17 15:54:22 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Jun 2024 15:54:22 GMT
Subject: RFR: 8333962: Obsolete OldSize [v3]
In-Reply-To: <2teqQqHjCobhvE7McOCbECpQ1z4kxnFg74KoqFHZiFg=.93fae87f-eeef-4010-a458-7a5aebbae869@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
 <2teqQqHjCobhvE7McOCbECpQ1z4kxnFg74KoqFHZiFg=.93fae87f-eeef-4010-a458-7a5aebbae869@github.com>
Message-ID: <fEm5O703W9eHxMf1h6Xg9qqba_gx-6VlFH9ylPxY8PA=.cae1514c-81f6-4a33-ad01-76ce47609ea0@github.com>

On Mon, 17 Jun 2024 14:30:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   obsolete-old-size

Tests pass.

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19647#issuecomment-2173767317

From ayang at openjdk.org  Mon Jun 17 15:54:23 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Jun 2024 15:54:23 GMT
Subject: Integrated: 8333962: Obsolete OldSize
In-Reply-To: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
References: <Mz0TACM1hs81U3vMy_s5EMjmlrSWWbbNHBwS5tgj7pw=.7c7707f3-c140-4f0e-97f7-53850c51999a@github.com>
Message-ID: <h5rjaQxF5IwGrWwd-vtqtm3fhIE2v9L65dkHJyo6v2k=.ccd93956-def6-4abe-986c-ac2b3088714a@github.com>

On Tue, 11 Jun 2024 08:17:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Obsolete OldSize and related code. An internal variable `OldSize` is kept to capture the capacity of old-gen size.

This pull request has now been integrated.

Changeset: c94af6f9
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c94af6f943c179553d1827550847b93491d47506
Stats:     192 lines in 15 files changed: 7 ins; 168 del; 17 mod

8333962: Obsolete OldSize

Reviewed-by: dholmes, zgu

-------------

PR: https://git.openjdk.org/jdk/pull/19647

From asotona at openjdk.org  Mon Jun 17 15:59:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 15:59:22 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v3]
In-Reply-To: <9JZ8XXWlauTkDg2OQqV5dnhSXbKzotJNpe0aaGPuZII=.899a1f8f-1d33-42a7-97ec-a4b3701d462f@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
 <9JZ8XXWlauTkDg2OQqV5dnhSXbKzotJNpe0aaGPuZII=.899a1f8f-1d33-42a7-97ec-a4b3701d462f@github.com>
Message-ID: <5j_OsopEGYzJDxoirPKyIDc0qYJGcjxfR-RfcJd4f7o=.2ea32f8c-5d5b-4402-8231-9d22a85ec202@github.com>

On Mon, 17 Jun 2024 13:55:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
>> 
>> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve tests to check unmatched bit position and failure for non-inner-classes
>  - Report error for flag problems

src/jdk.jdeps/share/classes/com/sun/tools/javap/BasicWriter.java line 84:

> 82:         } catch (IllegalArgumentException ex) {
> 83:             mask &= LOCATION_MASKS.get(location);
> 84:             report(ex);

Unfortunately the original exception message is missing any info that it is related to access flags and it is not very clear what "Error: Unmatched bit position 0x2 for location CLASS" means.
I would add at least a message prefix, for example "Error: Access Flags: Unmatched bit position 0x2 for location CLASS".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19708#discussion_r1643041633

From kevinw at openjdk.org  Mon Jun 17 15:59:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 15:59:37 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v17]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Remove import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/597264b9..67aca736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=15-16

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Mon Jun 17 15:59:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 15:59:37 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v16]
In-Reply-To: <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
 <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
Message-ID: <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>

On Mon, 17 Jun 2024 13:58:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - style update
>>  - whitespace
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1314:
> 
>> 1312:                     return AccessController.doPrivileged(action, acc);
>> 1313:                 }
>> 1314:             }
> 
> This piece of code is repeated at several places in similar but different forms - sometime we check for `SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime for `! SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime we check for `acc == null`, sometime for `acc != null` etc.. 
> I wonder if we could abstract that to some utility method somewhere. Would that make sense? Maybe that's not possible due to using sometime `PrivelegedAction` and sometimes `PrivilegedExceptionAction` - but maybe we could use `PrivilegedExceptionAction` everywhere at the cost of handling `PrivilegedActionException`? 
> If that doesn't prove useful (if handling `PrivilegedExceptionAction` adds again an equivalent amount of clutter) then maybe we could at least make sure we do the same checks in the same way (typically `acc == null` vs `acc != null`)?

Hi,
We almost always check !SharedSecrets.getJavaLangAccess().allowSecurityManager() (except in the RMIConnectionImpl contstructor)

This keeps the "modern" case first (except in that constructor, where it is only one line for each side of the if...).

This extra checking of SharedSecrets.getJavaLangAccess().allowSecurityManager() is to keep the modern and old style cases distinct, based on other comments here.  It keeps it simple to read I hope, but yes it is a little more verbose than it could be.

I'm hoping you'll agree that as these checks will be removed anyway, probably with a release, we should delay more extensive cleanup until then.  (I've also  rolled back my noPermissionsACC removal to keep this change away from being a general cleanup.)

I had a bunch of additional Exception handling for e.g. PrivilegedActionException I think in here, and it wasn't very pretty.  But, it might look better when there are fewer nested ifs in these methods, and when we are properly in the post-SecurityManager world... 8-)

Whether it checks acc != null or acc == null is based on the existing code.  I think that makes this diff easier to read, but also could be reworked and be made more consistent after SM removal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1643036701

From liach at openjdk.org  Mon Jun 17 16:19:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 16:19:18 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v3]
In-Reply-To: <5j_OsopEGYzJDxoirPKyIDc0qYJGcjxfR-RfcJd4f7o=.2ea32f8c-5d5b-4402-8231-9d22a85ec202@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
 <9JZ8XXWlauTkDg2OQqV5dnhSXbKzotJNpe0aaGPuZII=.899a1f8f-1d33-42a7-97ec-a4b3701d462f@github.com>
 <5j_OsopEGYzJDxoirPKyIDc0qYJGcjxfR-RfcJd4f7o=.2ea32f8c-5d5b-4402-8231-9d22a85ec202@github.com>
Message-ID: <SBC1id6EeViRgceW_2kdSWjo1e1ZSVgNFkGjc8Dmupw=.5c691733-c749-4c46-8118-1530f35e845a@github.com>

On Mon, 17 Jun 2024 15:56:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Improve tests to check unmatched bit position and failure for non-inner-classes
>>  - Report error for flag problems
>
> src/jdk.jdeps/share/classes/com/sun/tools/javap/BasicWriter.java line 84:
> 
>> 82:         } catch (IllegalArgumentException ex) {
>> 83:             mask &= LOCATION_MASKS.get(location);
>> 84:             report(ex);
> 
> Unfortunately the original exception message is missing any info that it is related to access flags and it is not very clear what "Error: Unmatched bit position 0x2 for location CLASS" means.
> I would add at least a message prefix, for example "Error: Access Flags: Unmatched bit position 0x2 for location CLASS".

Agreed, even though this message is already printed right by the access modifiers.

> test/langtools/tools/javap/UndefinedAccessFlagTest.java line 105:
> 
>> 103:             .writeAll()
>> 104:             .getOutputLines(Task.OutputKind.DIRECT);
>> 105:         assertTrue(lines.stream().anyMatch(l -> l.contains("Unmatched bit position")), () -> String.join("\n", lines));
> 
> I would add a check the "fatal" error does not occur or any other way to confirm correct recovery.

Great suggestion! I will filter the lines starting with `Error:` and assert they `allMatch(st -> st.contains("Access Flags:"))`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19708#discussion_r1643072918
PR Review Comment: https://git.openjdk.org/jdk/pull/19708#discussion_r1643073763

From epeter at openjdk.org  Mon Jun 17 16:32:23 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Jun 2024 16:32:23 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v4]
In-Reply-To: <Q6pKA8f2Id2Rioqkcb-EneeL7-giwc3r3iL68BzNZcs=.ac8e4ff1-462d-4cf4-8bbf-0385c5b33eed@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
 <nTueRcNtsyjwrIqO7k7rsDU6JT-0020BZGwhYbGhWk4=.f5b32b5f-bde3-40fd-a7d4-19cdb1b8e848@github.com>
 <Q6pKA8f2Id2Rioqkcb-EneeL7-giwc3r3iL68BzNZcs=.ac8e4ff1-462d-4cf4-8bbf-0385c5b33eed@github.com>
Message-ID: <YQJFVbNrCHpaX3NX-0hAxgbUhh6lGwZ7ZZzuRSeqowI=.935caf89-1e76-4839-bd4e-6f0b103cd75f@github.com>

On Mon, 17 Jun 2024 08:07:40 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/MergeStoreBench.java line 656:
>> 
>>> 654:         array[offset + 2] = (byte) (value >>  8);
>>> 655:         array[offset + 3] = (byte) (value      );
>>> 656:     }
>> 
>> You say that here `MergeStore` does not work. That is because the indices are increasing, but the shifts decreasing. So that does not work on little-endian machines (most architectures), but I would expect it to work on big-endian machines with https://github.com/openjdk/jdk/pull/19218.
>
> Big endian is often used in network data transmission scenarios, and it is common to process big endian data on a little endian machine. In this case, can it be optimized to Integer.reverseBytes & putIntLittleEndian on a LittleEndian machine? `setIntB -> setIntRL`

I had already suggested that here:
https://github.com/openjdk/jdk/pull/19218#pullrequestreview-2076196539
Feel free to file an RFE. Maybe someone wants to work on it. I think it would not be that hard to make it work given all the code that is already there now. And it would be helpful in for both big/little endian to be able to do both orders.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19734#discussion_r1643088147

From darcy at openjdk.org  Mon Jun 17 17:09:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Jun 2024 17:09:26 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v2]
In-Reply-To: <x54LrzmsJVT7vFr7QIr7-WS5AjSWQjw9VJUFQjEd3zY=.220208bb-ec78-425b-a45c-a1807b4bb5a1@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
 <bBEJNOFm1d8dtYtNMorLWhE5NVt2XSY5orJodx0FCno=.d1babf90-203c-4f1a-b0e3-745eafddee7a@github.com>
 <ILeRtyM6QUPtivKcT01XS2yX3J_Rzz8r85NP9HjpEHk=.ff611ba8-7886-4d79-b2b3-275193bb6ad4@github.com>
 <x54LrzmsJVT7vFr7QIr7-WS5AjSWQjw9VJUFQjEd3zY=.220208bb-ec78-425b-a45c-a1807b4bb5a1@github.com>
Message-ID: <cOMkie82GVTX7a_RyxQENA5WmXwdVfFQRpybwxllMAA=.d2dc79f5-1b86-41d2-a620-b78f10bc7d55@github.com>

On Mon, 17 Jun 2024 13:55:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `javap` should never silently ignore erroneous class file content.
>> If the flag value violates JVMS - it should be reported as an error and `javap` should reflect that in the return value.
>> On the other hand `javap` should handle such situations, provide relevant error message and continue with the report.
>> It is similar case as `javap` detection of inappropriate CP entry types.
>
> @asotona Thanks for the note, I have updated the code so javap now behaves like your suggestion.

@liach , please file a CSR for this issue to discuss the behavioral changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19708#issuecomment-2173914440

From liach at openjdk.org  Mon Jun 17 17:38:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 17:38:56 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v4]
In-Reply-To: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
Message-ID: <_MkCPEDwMK8enNd80KQ8x-zJ7qkslor8Jok20NOtYeE=.93482adf-7dc0-4530-8aad-4440cbf2d162@github.com>

> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
> 
> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Improved error message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19708/files
  - new: https://git.openjdk.org/jdk/pull/19708/files/0f3e1a97..c8eee028

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19708&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19708&range=02-03

  Stats: 20 lines in 2 files changed: 16 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19708/head:pull/19708

PR: https://git.openjdk.org/jdk/pull/19708

From asotona at openjdk.org  Mon Jun 17 17:46:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 17 Jun 2024 17:46:13 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v4]
In-Reply-To: <_MkCPEDwMK8enNd80KQ8x-zJ7qkslor8Jok20NOtYeE=.93482adf-7dc0-4530-8aad-4440cbf2d162@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
 <_MkCPEDwMK8enNd80KQ8x-zJ7qkslor8Jok20NOtYeE=.93482adf-7dc0-4530-8aad-4440cbf2d162@github.com>
Message-ID: <eZ2TgFI_zyKjelDt1SjCDIwB-HNf_6bh7_iHHWYJO-M=.cef0d08a-279f-4063-b96f-96c10b24553b@github.com>

On Mon, 17 Jun 2024 17:38:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
>> 
>> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved error message

Now it looks good to me, thanks.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19708#pullrequestreview-2123504238

From alanb at openjdk.org  Mon Jun 17 17:46:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Jun 2024 17:46:13 GMT
Subject: RFR: 8334394: Race condition in Class::protectionDomain [v2]
In-Reply-To: <Y_-dtrQSFf-aMn7biqRH7Sn2wmgkyjJDlKTkqk0QG08=.24828899-992c-4e1f-a0cc-7279be51dc86@github.com>
References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
 <Y_-dtrQSFf-aMn7biqRH7Sn2wmgkyjJDlKTkqk0QG08=.24828899-992c-4e1f-a0cc-7279be51dc86@github.com>
Message-ID: <gEIcERDZfX2UXUkIjYLKE_2rYwCa8x59PcHpOLpRW3I=.bacdfb66-2361-4617-91ff-d6508709c496@github.com>

On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Make sure `pd` is always the same object when `getProtectionDomain0` is null.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   explain why the test is related to the fix

The update to Class looks okay. At some point I think we see if the protection domain field can be changed to be an explicit field (not injected) so that the native method and JVM_GetProtectionDomain can be removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19752#issuecomment-2173980108

From jlu at openjdk.org  Mon Jun 17 18:20:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jun 2024 18:20:18 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <acPv0AiTqob7XLTogkIj8Jgtk5yW1axTP56-3HY_fPI=.ef730fad-2590-40aa-81a7-5fc00d3c3205@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
 <6kmKgt5QX3KBTmpN4R5D9-XWbiUkP7ieQF00DZc48Es=.5f0e517a-06e2-4392-984d-754d287b0ac5@github.com>
 <acPv0AiTqob7XLTogkIj8Jgtk5yW1axTP56-3HY_fPI=.ef730fad-2590-40aa-81a7-5fc00d3c3205@github.com>
Message-ID: <p4r7JEmT1In094nPcamyJkJRQD00dzB3MvIlHtRg8Dg=.068d9c8c-a46c-41de-a074-149a09cc0ec1@github.com>

On Fri, 14 Jun 2024 03:28:58 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> I second Justin's suggestion here. The change should benefit every implementation in the JDK, not only NumberFormat. Also, I might suggest renaming the new class, as it is kind of long/redundant. How about using something as simple as "StringBuf"?
>
>> I second Justin's suggestion here. The change should benefit every implementation in the JDK, not only NumberFormat. Also, I might suggest renaming the new class, as it is kind of long/redundant. How about using something as simple as "StringBuf"?
> 
> Thanks for your comment. The long name bother me for a while. I have changed it to ""StringBuf".

Hi @lingjun-cg 

Thanks for your work here.

While this would benefit the performance of NumberFormat subclasses, we are hoping that if we are going to make the internal switch to StringBuilder, we can also make similar changes to other Format subclasses as well where applicable. So, we would want `isInternalSubclass()` to be defined at the Format level. Some methods that I can immediately think of would be `String DateFormat.format(Date date)`, `String ListFormat.format(List<String> input)` and, `String MessageFormat.format(Object obj)`.

I believe @naotoj shares the same sentiment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2174040047

From liach at openjdk.org  Mon Jun 17 18:35:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 18:35:47 GMT
Subject: RFR: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS [v4]
In-Reply-To: <_MkCPEDwMK8enNd80KQ8x-zJ7qkslor8Jok20NOtYeE=.93482adf-7dc0-4530-8aad-4440cbf2d162@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
 <_MkCPEDwMK8enNd80KQ8x-zJ7qkslor8Jok20NOtYeE=.93482adf-7dc0-4530-8aad-4440cbf2d162@github.com>
Message-ID: <9rLZjs66hzcTrqIK0axwvENh3H_bEBpKsxd6IPDQKEY=.01101ef7-4def-4dfe-8587-0a318822dc89@github.com>

On Mon, 17 Jun 2024 17:38:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
>> 
>> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved error message

I have created a CSR for this patch at https://bugs.openjdk.org/browse/JDK-8334406; please review. Also I am not sure about the correct interface kind and scope for this CSR: is "other" and "implementation" correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19708#issuecomment-2174128620

From naoto at openjdk.org  Mon Jun 17 18:55:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jun 2024 18:55:22 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <acPv0AiTqob7XLTogkIj8Jgtk5yW1axTP56-3HY_fPI=.ef730fad-2590-40aa-81a7-5fc00d3c3205@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
 <6kmKgt5QX3KBTmpN4R5D9-XWbiUkP7ieQF00DZc48Es=.5f0e517a-06e2-4392-984d-754d287b0ac5@github.com>
 <acPv0AiTqob7XLTogkIj8Jgtk5yW1axTP56-3HY_fPI=.ef730fad-2590-40aa-81a7-5fc00d3c3205@github.com>
Message-ID: <3NpdReLWFTVOEF_2W0pc-dP8tnr2f88zr1twaCu_CZw=.7a365feb-fdb4-4288-9ebe-10f1a62bb68d@github.com>

On Fri, 14 Jun 2024 03:28:58 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> I second Justin's suggestion here. The change should benefit every implementation in the JDK, not only NumberFormat. Also, I might suggest renaming the new class, as it is kind of long/redundant. How about using something as simple as "StringBuf"?
>
>> I second Justin's suggestion here. The change should benefit every implementation in the JDK, not only NumberFormat. Also, I might suggest renaming the new class, as it is kind of long/redundant. How about using something as simple as "StringBuf"?
> 
> Thanks for your comment. The long name bother me for a while. I have changed it to ""StringBuf".

> Hi @lingjun-cg
> 
> Thanks for your work here.
> 
> While this would benefit the performance of NumberFormat subclasses, we are hoping that if we are going to make the internal switch to StringBuilder, we can also make similar changes to other Format subclasses as well where applicable. So, we would want `isInternalSubclass()` to be defined at the Format level. Some methods that I can immediately think of would be `String DateFormat.format(Date date)`, `String ListFormat.format(List<String> input)` and, `String MessageFormat.format(Object obj)`.
> 
> I believe @naotoj shares the same sentiment.

Yes, that is what I would expect in this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2174184666

From naoto at openjdk.org  Mon Jun 17 18:55:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jun 2024 18:55:44 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root
In-Reply-To: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
Message-ID: <aeU5Ozr-eUvgCZ0Ga0f845XajhOmyJ6DVUughLwPLKU=.3130eeef-c7cb-446d-ab91-0cdd50b6a552@github.com>

On Sat, 15 Jun 2024 09:56:53 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
> The change has been verified, only change the testcase, no risk.

test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java line 60:

> 58:     public static void main(String[] args) throws Throwable {
> 59:         if(Platform.isRoot() && !Platform.isWindows()) {
> 60:             throw new SkippedException("root user has privileged will make this test fail.");

The exception message can be improved. How about "Unable to create an unreadable properties file"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19732#discussion_r1643295899

From liach at openjdk.org  Mon Jun 17 18:55:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 18:55:36 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v6]
In-Reply-To: <nFfGXQutLZFBZyY3wXFWfhOyxI6owEY7yWYinIQm09s=.a88ff8ac-2a73-4262-a02f-656bcea468fc@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <nFfGXQutLZFBZyY3wXFWfhOyxI6owEY7yWYinIQm09s=.a88ff8ac-2a73-4262-a02f-656bcea468fc@github.com>
Message-ID: <NQxsNg_uL4Hq6BgVh5abycIim4-sGAAkh82GOHn5F5E=.b47232a4-11ce-411c-a99d-ba36f7442a48@github.com>

On Fri, 14 Jun 2024 03:19:48 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

For StringBuf proxy, is it acceptible for us to introduce a new jdk.internal public interface (accessible only within java.base module) to expose common public methods in AbstractStringBuilder? We have public types extending or implementing non-public-types in the JDK (AbstractStringBuilder, NamedPackage) so I guess having a new module-specific superinterface would be fine? Need verification from API experts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2174193760

From naoto at openjdk.org  Mon Jun 17 19:43:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jun 2024 19:43:12 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v6]
In-Reply-To: <NQxsNg_uL4Hq6BgVh5abycIim4-sGAAkh82GOHn5F5E=.b47232a4-11ce-411c-a99d-ba36f7442a48@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <nFfGXQutLZFBZyY3wXFWfhOyxI6owEY7yWYinIQm09s=.a88ff8ac-2a73-4262-a02f-656bcea468fc@github.com>
 <NQxsNg_uL4Hq6BgVh5abycIim4-sGAAkh82GOHn5F5E=.b47232a4-11ce-411c-a99d-ba36f7442a48@github.com>
Message-ID: <eDL41J_X4lVBYxEEJzWlgFb23cfUQzgRsi4MuN9uTgk=.c46ba0c2-ac2d-4199-9c4b-93192d9d6a16@github.com>

On Mon, 17 Jun 2024 18:47:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> For StringBuf proxy, is it acceptible for us to introduce a new jdk.internal public interface (accessible only within java.base module) to expose common public methods in AbstractStringBuilder? We have public types extending or implementing non-public-types in the JDK (AbstractStringBuilder, NamedPackage) so I guess having a new module-specific superinterface would be fine? Need verification from API experts.

Hi @liach 
Do you know any other places within java.base where we would need the same proxy for StringBuffer?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2174283589

From mullan at openjdk.org  Mon Jun 17 19:59:15 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 17 Jun 2024 19:59:15 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v17]
In-Reply-To: <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
Message-ID: <N6SYKYLB33IV-G1rjfWa4pFzsR-kim0lFCHyh3rM_44=.b5514229-4330-4f14-8ef8-9ea97ae6efbc@github.com>

On Mon, 17 Jun 2024 15:59:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove import

AFAICT, the only test modified in this PR that actually enables a Security Manager is test/jdk/javax/management/security/AuthorizationTest.java. Is that test sufficient to exercise the code changes in this PR when an SM is enabled?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2174313063

From liach at openjdk.org  Mon Jun 17 20:13:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Jun 2024 20:13:25 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v6]
In-Reply-To: <NQxsNg_uL4Hq6BgVh5abycIim4-sGAAkh82GOHn5F5E=.b47232a4-11ce-411c-a99d-ba36f7442a48@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <nFfGXQutLZFBZyY3wXFWfhOyxI6owEY7yWYinIQm09s=.a88ff8ac-2a73-4262-a02f-656bcea468fc@github.com>
 <NQxsNg_uL4Hq6BgVh5abycIim4-sGAAkh82GOHn5F5E=.b47232a4-11ce-411c-a99d-ba36f7442a48@github.com>
Message-ID: <-rmT0nyhqVBvobYSzlRz6U8z0flKg_EXZ_CiLPQUSy4=.f41c7940-534d-401a-867c-4ef3246b288f@github.com>

On Mon, 17 Jun 2024 18:47:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> For StringBuf proxy, is it acceptible for us to introduce a new jdk.internal public interface (accessible only within java.base module) to expose common public methods in AbstractStringBuilder? We have public types extending or implementing non-public-types in the JDK (AbstractStringBuilder, NamedPackage) so I guess having a new module-specific superinterface would be fine? Need verification from API experts.

> Hi @liach Do you know any other places within java.base where we would need the same proxy for StringBuffer?

Good question! I looked at https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/class-use/StringBuffer.html. I think such a new interface indeed is of limited usefulness, as we don't really have that many non-java.lang APIs closely tied to StringBuffer. Matcher is like one, but it lives mostly fine without the shadowing because it is using `Appendable`. And this has enlightened me.

In fact, we can use `Appendable` too, as we just need 2 `append` from `Appendable` and `subSequence` (replacing `substring`) and `length` from `CharSequence`. We can declare method like:

<T extends Appendable & CharSequence> T format(double number, T toAppendTo,
                         FieldPosition status) {

This signature accepts both `StringBuilder` and `StringBuffer`; all use sites can be according updated. The only thing need to change is that `substring` should now become `subSequence`, but it's just used in `CharacterIteratorFieldDelegate` so the impact is small.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2174336411

From mullan at openjdk.org  Mon Jun 17 20:30:16 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 17 Jun 2024 20:30:16 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v17]
In-Reply-To: <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
Message-ID: <UwkvEflj9aYgHkIybhTE2-GWkKnmhx95KG8c8MKeuM4=.c57bfacb-40d1-4670-a7e0-2408a00d3525@github.com>

On Mon, 17 Jun 2024 15:59:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove import

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1306:

> 1304:                     return action.run();
> 1305:                 else
> 1306:                     return Subject.doAs(subject, action);

Code style comment: put braces around the if/else to be consistent with lines below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1643390138

From mullan at openjdk.org  Mon Jun 17 20:30:18 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 17 Jun 2024 20:30:18 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v16]
In-Reply-To: <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
 <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
 <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>
Message-ID: <bNZqEmj_nYQ55lQvaubYBsEPjCnCHHbi0VdBtexVtb4=.52a73eb6-6d91-46f5-8a8b-623cef3d5530@github.com>

On Mon, 17 Jun 2024 15:53:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1314:
>> 
>>> 1312:                     return AccessController.doPrivileged(action, acc);
>>> 1313:                 }
>>> 1314:             }
>> 
>> This piece of code is repeated at several places in similar but different forms - sometime we check for `SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime for `! SharedSecrets.getJavaLangAccess().allowSecurityManager()`, sometime we check for `acc == null`, sometime for `acc != null` etc.. 
>> I wonder if we could abstract that to some utility method somewhere. Would that make sense? Maybe that's not possible due to using sometime `PrivelegedAction` and sometimes `PrivilegedExceptionAction` - but maybe we could use `PrivilegedExceptionAction` everywhere at the cost of handling `PrivilegedActionException`? 
>> If that doesn't prove useful (if handling `PrivilegedExceptionAction` adds again an equivalent amount of clutter) then maybe we could at least make sure we do the same checks in the same way (typically `acc == null` vs `acc != null`)?
>
> Hi,
> We almost always check !SharedSecrets.getJavaLangAccess().allowSecurityManager() (except in the RMIConnectionImpl contstructor)
> 
> This keeps the "modern" case first (except in that constructor, where it is only one line for each side of the if...).
> 
> This extra checking of SharedSecrets.getJavaLangAccess().allowSecurityManager() is to keep the modern and old style cases distinct, based on other comments here.  It keeps it simple to read I hope, but yes it is a little more verbose than it could be.
> 
> I'm hoping you'll agree that as these checks will be removed anyway, probably with a release, we should delay more extensive cleanup until then.  (I've also  rolled back my noPermissionsACC removal to keep this change away from being a general cleanup.)
> 
> I had a bunch of additional Exception handling for e.g. PrivilegedActionException I think in here, and it wasn't very pretty.  But, it might look better when there are fewer nested ifs in these methods, and when we are properly in the post-SecurityManager world... 8-)
> 
> Whether it checks acc != null or acc == null is based on the existing code.  I think that makes this diff easier to read, but also could be reworked and be made more consistent after SM removal.

Agree with Kevin. To minimize risk, especially since this is to fix a significant regression and we are in RDP1, we are really trying to preserve the existing code as much as possible, even though it could be improved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1643395182

From kevinw at openjdk.org  Mon Jun 17 20:51:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Jun 2024 20:51:34 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v18]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  braces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/67aca736..384a3a19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=16-17

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From jlu at openjdk.org  Mon Jun 17 21:10:27 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jun 2024 21:10:27 GMT
Subject: RFR: 8334418: Update IANA Language Subtag Registry to Version
 2024-06-14
Message-ID: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>

Please review this PR, which is a trivial update of the IANA subtag registry to version 2024-06-14. 
Announcement: https://mm.icann.org/pipermail/ietf-languages-announcements/2024-June/000092.html

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/19757/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334418
  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19757/head:pull/19757

PR: https://git.openjdk.org/jdk/pull/19757

From naoto at openjdk.org  Mon Jun 17 22:06:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jun 2024 22:06:12 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v6]
In-Reply-To: <-rmT0nyhqVBvobYSzlRz6U8z0flKg_EXZ_CiLPQUSy4=.f41c7940-534d-401a-867c-4ef3246b288f@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <nFfGXQutLZFBZyY3wXFWfhOyxI6owEY7yWYinIQm09s=.a88ff8ac-2a73-4262-a02f-656bcea468fc@github.com>
 <NQxsNg_uL4Hq6BgVh5abycIim4-sGAAkh82GOHn5F5E=.b47232a4-11ce-411c-a99d-ba36f7442a48@github.com>
 <-rmT0nyhqVBvobYSzlRz6U8z0flKg_EXZ_CiLPQUSy4=.f41c7940-534d-401a-867c-4ef3246b288f@github.com>
Message-ID: <Z137ZI5UZDnznBxHQlbUfKgY3n8c78bLvSsSelk_LSo=.1ab04e61-cf43-413d-9075-7314d801d301@github.com>

On Mon, 17 Jun 2024 20:10:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For StringBuf proxy, is it acceptible for us to introduce a new jdk.internal public interface (accessible only within java.base module) to expose common public methods in AbstractStringBuilder? We have public types extending or implementing non-public-types in the JDK (AbstractStringBuilder, NamedPackage) so I guess having a new module-specific superinterface would be fine? Need verification from API experts.
>
>> Hi @liach Do you know any other places within java.base where we would need the same proxy for StringBuffer?
> 
> Good question! I looked at https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/class-use/StringBuffer.html. I think such a new interface indeed is of limited usefulness, as we don't really have that many non-java.lang APIs closely tied to StringBuffer. Matcher is like one, but it lives mostly fine without the shadowing because it is using `Appendable`. And this has enlightened me.
> 
> In fact, we can use `Appendable` too, as we just need 2 `append` from `Appendable` and `subSequence` (replacing `substring`) and `length` from `CharSequence`. We can declare method like:
> 
> <T extends Appendable & CharSequence> T format(double number, T toAppendTo,
>                          FieldPosition status) {
> 
> This signature accepts both `StringBuilder` and `StringBuffer`; all use sites can be according updated. The only thing need to change is that `substring` should now become `subSequence`, but it's just used in `CharacterIteratorFieldDelegate` so the impact is small.

> > Hi @liach Do you know any other places within java.base where we would need the same proxy for StringBuffer?
> 
> Good question! I looked at https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/class-use/StringBuffer.html. I think such a new interface indeed is of limited usefulness, as we don't really have that many non-java.lang APIs closely tied to StringBuffer. Matcher is like one, but it lives mostly fine without the shadowing because it is using `Appendable`. And this has enlightened me.
> 
> In fact, we can use `Appendable` too, as we just need 2 `append` from `Appendable` and `subSequence` (replacing `substring`) and `length` from `CharSequence`. We can declare method like:
> 
> ```java
> <T extends Appendable & CharSequence> T format(double number, T toAppendTo,
>                          FieldPosition status) {
> ```
> 
> This signature accepts both `StringBuilder` and `StringBuffer`; all use sites can be according updated. The only thing need to change is that `substring` should now become `subSequence`, but it's just used in `CharacterIteratorFieldDelegate` so the impact is small.

That looks promising! Much cleaner than having dual methods

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2174509435

From weijun at openjdk.org  Mon Jun 17 22:52:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 17 Jun 2024 22:52:12 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v17]
In-Reply-To: <N6SYKYLB33IV-G1rjfWa4pFzsR-kim0lFCHyh3rM_44=.b5514229-4330-4f14-8ef8-9ea97ae6efbc@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <69swlhYoC9BhYV6HhT3YoSi9uwi2QM33g3HkUDz1xN4=.d8aac5c8-2d99-47ca-b9c4-d93afd1d703a@github.com>
 <N6SYKYLB33IV-G1rjfWa4pFzsR-kim0lFCHyh3rM_44=.b5514229-4330-4f14-8ef8-9ea97ae6efbc@github.com>
Message-ID: <DuhLCm3oqnYEXcFHOwF1XYXS9zGyxC7rXvd4H_dZSHo=.08b67185-8a5b-41d5-a4a4-1defe579c189@github.com>

On Mon, 17 Jun 2024 19:56:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> AFAICT, the only test modified in this PR that actually enables a Security Manager is test/jdk/javax/management/security/AuthorizationTest.java. Is that test sufficient to exercise the code changes in this PR when an SM is enabled?

While this code change has done its best to avoid any behavior change when SM is allowed, I agree with Sean to run tests in both modes. When these tests were originally introduced they were meant to test the old implementation. Keep testing eith both implementations help us to avoid any future (might not be long) regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2174568617

From duke at openjdk.org  Mon Jun 17 23:02:47 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 17 Jun 2024 23:02:47 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v5]
In-Reply-To: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
Message-ID: <saHVkMz-74tIwX6Bxv83YXAz6QMEEDL-RgS9Ugtukeo=.a537a106-f6c2-48ad-9397-f5a23fa769ac@github.com>

> [8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into merge_store_bench
 - bug fix for `putChars4C`
 - bug fix for `putChars4C` and `putChars4S`
 - use VarHandler CHAR_L & CHAR_B
 - copyright
 - bug fix for putIntBU
 - add cases for `getChar` & `putChar`
 - code format
 - add `setIntRL` & `setIntRLU`
 - add comments
 - ... and 3 more: https://git.openjdk.org/jdk/compare/fc9315ff...4c9b9418

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19734/files
  - new: https://git.openjdk.org/jdk/pull/19734/files/1140bd81..4c9b9418

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=03-04

  Stats: 1440 lines in 77 files changed: 795 ins; 459 del; 186 mod
  Patch: https://git.openjdk.org/jdk/pull/19734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19734/head:pull/19734

PR: https://git.openjdk.org/jdk/pull/19734

From duke at openjdk.org  Tue Jun 18 01:12:15 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 18 Jun 2024 01:12:15 GMT
Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v5]
In-Reply-To: <saHVkMz-74tIwX6Bxv83YXAz6QMEEDL-RgS9Ugtukeo=.a537a106-f6c2-48ad-9397-f5a23fa769ac@github.com>
References: <l-C1qx89SSMtFXImh24hizsUyih-yCBzTDW9wpqvRYg=.3f37c64b-33ee-4f84-a37f-06563d05ccb0@github.com>
 <saHVkMz-74tIwX6Bxv83YXAz6QMEEDL-RgS9Ugtukeo=.a537a106-f6c2-48ad-9397-f5a23fa769ac@github.com>
Message-ID: <DCtwmexd8LwCvjqMGCP-dP02frsPno8_tzhX4bb3PCw=.a1099a8b-3481-4e88-b7d1-a096dc8197a8@github.com>

On Mon, 17 Jun 2024 23:02:47 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> [8318446](https://github.com/openjdk/jdk/pull/16245)  brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into merge_store_bench
>  - bug fix for `putChars4C`
>  - bug fix for `putChars4C` and `putChars4S`
>  - use VarHandler CHAR_L & CHAR_B
>  - copyright
>  - bug fix for putIntBU
>  - add cases for `getChar` & `putChar`
>  - code format
>  - add `setIntRL` & `setIntRLU`
>  - add comments
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d4942ac0...4c9b9418

I re-ran the performance test based on WebRevs 04: [Full](https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=04) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=03-04) ([4c9b9418](https://git.openjdk.org/jdk/pull/19734/files/4c9b9418fc4a95504867b6019b3e94605917f747)) .

# 1. Cases MergeStore does not work
@eme64 
I found `putChars4BV` and `putChars4LV` to be two cases where MergeStore didn't work, if support can be enhanced, it would be useful for people using VarHandle.


putChars4BV
putChars4LV


I also found that the performance of the case using VarHandle is particularly good. Why? For example:

setIntBV
setIntLV
setLongBV
setLongLV


# 2. Performance numbers
The names of these cases have the following B/L/V/U suffixes, which are:

B BigEndian
L LittleEndian
V VarHandle
U Unsafe
R reverseBytes
C Unsafe.getChar & putChar
S Unsafe.getShort & putShort


## 2.1 MacBook M1 Pro (aarch64)

Benchmark                    Mode  Cnt      Score    Error  Units
MergeStoreBench.getCharB     avgt   15   5340.200 ?  7.038  ns/op
MergeStoreBench.getCharBU    avgt   15   5482.163 ?  7.922  ns/op
MergeStoreBench.getCharBV    avgt   15   5074.165 ?  6.759  ns/op
MergeStoreBench.getCharC     avgt   15   5051.763 ?  6.552  ns/op
MergeStoreBench.getCharL     avgt   15   5374.464 ?  9.783  ns/op
MergeStoreBench.getCharLU    avgt   15   5487.532 ?  6.368  ns/op
MergeStoreBench.getCharLV    avgt   15   5071.263 ?  9.717  ns/op
MergeStoreBench.getIntB      avgt   15   6277.984 ?  6.284  ns/op
MergeStoreBench.getIntBU     avgt   15   5232.984 ? 10.384  ns/op
MergeStoreBench.getIntBV     avgt   15   1206.264 ?  1.193  ns/op
MergeStoreBench.getIntL      avgt   15   6172.779 ?  1.962  ns/op
MergeStoreBench.getIntLU     avgt   15   5157.317 ? 16.077  ns/op
MergeStoreBench.getIntLV     avgt   15   2558.110 ?  3.402  ns/op
MergeStoreBench.getIntRB     avgt   15   6889.916 ? 36.955  ns/op
MergeStoreBench.getIntRBU    avgt   15   5769.950 ? 11.499  ns/op
MergeStoreBench.getIntRL     avgt   15   6625.605 ? 10.662  ns/op
MergeStoreBench.getIntRLU    avgt   15   5746.742 ? 11.945  ns/op
MergeStoreBench.getIntRU     avgt   15   2544.586 ?  2.769  ns/op
MergeStoreBench.getIntU      avgt   15   2541.119 ?  3.252  ns/op
MergeStoreBench.getLongB     avgt   15  12098.129 ? 31.451  ns/op
MergeStoreBench.getLongBU    avgt   15   9760.621 ? 16.427  ns/op
MergeStoreBench.getLongBV    avgt   15   2593.635 ?  4.698  ns/op
MergeStoreBench.getLongL     avgt   15  12031.065 ? 19.820  ns/op
MergeStoreBench.getLongLU    avgt   15   9653.938 ? 18.372  ns/op
MergeStoreBench.getLongLV    avgt   15   2557.521 ?  3.338  ns/op
MergeStoreBench.getLongRB    avgt   15  12092.061 ? 18.026  ns/op
MergeStoreBench.getLongRBU   avgt   15   9763.489 ? 17.347  ns/op
MergeStoreBench.getLongRL    avgt   15  12027.686 ? 17.472  ns/op
MergeStoreBench.getLongRLU   avgt   15   9649.433 ?  8.384  ns/op
MergeStoreBench.getLongRU    avgt   15   2546.239 ?  2.088  ns/op
MergeStoreBench.getLongU     avgt   15   2539.762 ?  1.439  ns/op
MergeStoreBench.putChars4B   avgt   15   8487.381 ? 23.170  ns/op
MergeStoreBench.putChars4BU  avgt   15   3830.198 ?  7.083  ns/op
MergeStoreBench.putChars4BV  avgt   15   5154.819 ? 10.348  ns/op
MergeStoreBench.putChars4C   avgt   15   5162.766 ? 15.041  ns/op
MergeStoreBench.putChars4L   avgt   15   8381.231 ? 20.135  ns/op
MergeStoreBench.putChars4LU  avgt   15   3827.784 ?  3.163  ns/op
MergeStoreBench.putChars4LV  avgt   15   5151.508 ?  4.907  ns/op
MergeStoreBench.putChars4S   avgt   15   5152.123 ?  7.407  ns/op
MergeStoreBench.setCharBS    avgt   15   5317.319 ? 28.445  ns/op
MergeStoreBench.setCharBV    avgt   15   5175.400 ?  7.110  ns/op
MergeStoreBench.setCharC     avgt   15   5085.752 ?  6.222  ns/op
MergeStoreBench.setCharLS    avgt   15   5294.766 ?  9.742  ns/op
MergeStoreBench.setCharLV    avgt   15   5108.269 ?  6.692  ns/op
MergeStoreBench.setIntB      avgt   15   5095.236 ?  2.838  ns/op
MergeStoreBench.setIntBU     avgt   15   5097.007 ?  4.249  ns/op
MergeStoreBench.setIntBV     avgt   15   1224.506 ?  0.976  ns/op
MergeStoreBench.setIntL      avgt   15   2764.388 ?  2.400  ns/op
MergeStoreBench.setIntLU     avgt   15   2573.624 ?  6.677  ns/op
MergeStoreBench.setIntLV     avgt   15   5105.804 ? 11.551  ns/op
MergeStoreBench.setIntRB     avgt   15   5348.785 ?  4.974  ns/op
MergeStoreBench.setIntRBU    avgt   15   5422.049 ? 31.009  ns/op
MergeStoreBench.setIntRL     avgt   15   5293.414 ?  8.204  ns/op
MergeStoreBench.setIntRLU    avgt   15   5126.889 ?  7.435  ns/op
MergeStoreBench.setIntRU     avgt   15   5097.927 ?  3.588  ns/op
MergeStoreBench.setIntU      avgt   15   5087.192 ? 11.806  ns/op
MergeStoreBench.setLongB     avgt   15  10249.037 ? 19.538  ns/op
MergeStoreBench.setLongBU    avgt   15  10238.910 ? 11.998  ns/op
MergeStoreBench.setLongBV    avgt   15   2663.647 ?  4.147  ns/op
MergeStoreBench.setLongL     avgt   15   6304.458 ?  4.588  ns/op
MergeStoreBench.setLongLU    avgt   15   2921.575 ? 10.649  ns/op
MergeStoreBench.setLongLV    avgt   15   2663.323 ?  1.188  ns/op
MergeStoreBench.setLongRB    avgt   15  10255.875 ? 19.754  ns/op
MergeStoreBench.setLongRBU   avgt   15  10227.856 ?  9.970  ns/op
MergeStoreBench.setLongRL    avgt   15   6641.173 ?  3.836  ns/op
MergeStoreBench.setLongRLU   avgt   15   3241.057 ? 22.250  ns/op
MergeStoreBench.setLongRU    avgt   15   2608.399 ?  2.243  ns/op
MergeStoreBench.setLongU     avgt   15   2594.970 ?  3.490  ns/op


## 2.2 Aliyun ecs.c8a.xlarge (x64)
* CPU AMD EPYCTM Genoa

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getCharB     avgt   15   5969.667 ?  75.660  ns/op
MergeStoreBench.getCharBU    avgt   15   4576.650 ?  27.489  ns/op
MergeStoreBench.getCharBV    avgt   15   3085.061 ?   3.206  ns/op
MergeStoreBench.getCharC     avgt   15   2237.624 ?   1.383  ns/op
MergeStoreBench.getCharL     avgt   15   6044.112 ?   8.960  ns/op
MergeStoreBench.getCharLU    avgt   15   4538.252 ?   3.747  ns/op
MergeStoreBench.getCharLV    avgt   15   2221.833 ?   0.727  ns/op
MergeStoreBench.getIntB      avgt   15  11983.238 ?  74.190  ns/op
MergeStoreBench.getIntBU     avgt   15   9039.309 ?   6.332  ns/op
MergeStoreBench.getIntBV     avgt   15    303.874 ?   0.305  ns/op
MergeStoreBench.getIntL      avgt   15  10521.992 ?  15.238  ns/op
MergeStoreBench.getIntLU     avgt   15   8867.106 ?   7.014  ns/op
MergeStoreBench.getIntLV     avgt   15   2226.223 ?   0.887  ns/op
MergeStoreBench.getIntRB     avgt   15  12332.136 ?  19.948  ns/op
MergeStoreBench.getIntRBU    avgt   15  11114.256 ?   8.652  ns/op
MergeStoreBench.getIntRL     avgt   15  11206.728 ?  15.291  ns/op
MergeStoreBench.getIntRLU    avgt   15   9349.279 ?   7.379  ns/op
MergeStoreBench.getIntRU     avgt   15   2507.213 ?   1.222  ns/op
MergeStoreBench.getIntU      avgt   15   2495.432 ?   1.278  ns/op
MergeStoreBench.getLongB     avgt   15  26832.797 ?  19.316  ns/op
MergeStoreBench.getLongBU    avgt   15  13996.454 ?  17.628  ns/op
MergeStoreBench.getLongBV    avgt   15    605.548 ?   0.538  ns/op
MergeStoreBench.getLongL     avgt   15  26859.909 ?  31.234  ns/op
MergeStoreBench.getLongLU    avgt   15  14519.709 ?  23.482  ns/op
MergeStoreBench.getLongLV    avgt   15   2227.782 ?   0.535  ns/op
MergeStoreBench.getLongRB    avgt   15  26846.549 ?  17.321  ns/op
MergeStoreBench.getLongRBU   avgt   15  13994.948 ?  14.752  ns/op
MergeStoreBench.getLongRL    avgt   15  26838.819 ?  14.425  ns/op
MergeStoreBench.getLongRLU   avgt   15  14547.807 ?  73.859  ns/op
MergeStoreBench.getLongRU    avgt   15   3061.373 ?   1.690  ns/op
MergeStoreBench.getLongU     avgt   15   3049.441 ?   1.162  ns/op
MergeStoreBench.putChars4B   avgt   15  13411.014 ?   4.491  ns/op
MergeStoreBench.putChars4BU  avgt   15   4206.040 ?   4.317  ns/op
MergeStoreBench.putChars4BV  avgt   15   7948.154 ? 904.918  ns/op
MergeStoreBench.putChars4C   avgt   15   5316.859 ?   3.066  ns/op
MergeStoreBench.putChars4L   avgt   15  13419.757 ?  11.175  ns/op
MergeStoreBench.putChars4LU  avgt   15   4205.094 ?   5.079  ns/op
MergeStoreBench.putChars4LV  avgt   15   6734.543 ?   6.452  ns/op
MergeStoreBench.putChars4S   avgt   15   5323.487 ?  10.605  ns/op
MergeStoreBench.setCharBS    avgt   15   9225.082 ?  11.461  ns/op
MergeStoreBench.setCharBV    avgt   15   5242.360 ?  12.546  ns/op
MergeStoreBench.setCharC     avgt   15   4497.345 ?   7.426  ns/op
MergeStoreBench.setCharLS    avgt   15   8991.865 ?   7.281  ns/op
MergeStoreBench.setCharLV    avgt   15   2535.475 ?   4.230  ns/op
MergeStoreBench.setIntB      avgt   15   8036.698 ?   6.763  ns/op
MergeStoreBench.setIntBU     avgt   15  10332.333 ?  10.071  ns/op
MergeStoreBench.setIntBV     avgt   15    586.392 ?   1.024  ns/op
MergeStoreBench.setIntL      avgt   15   2541.327 ?   4.538  ns/op
MergeStoreBench.setIntLU     avgt   15   6122.574 ?  46.593  ns/op
MergeStoreBench.setIntLV     avgt   15    597.930 ?   0.672  ns/op
MergeStoreBench.setIntRB     avgt   15   9740.301 ?   3.367  ns/op
MergeStoreBench.setIntRBU    avgt   15  10648.285 ?  29.338  ns/op
MergeStoreBench.setIntRL     avgt   15   6227.445 ?  15.378  ns/op
MergeStoreBench.setIntRLU    avgt   15   8409.781 ?  61.847  ns/op
MergeStoreBench.setIntRU     avgt   15    631.337 ?   6.930  ns/op
MergeStoreBench.setIntU      avgt   15    604.432 ?   0.682  ns/op
MergeStoreBench.setLongB     avgt   15  17184.183 ?  11.490  ns/op
MergeStoreBench.setLongBU    avgt   15  21377.695 ?  51.384  ns/op
MergeStoreBench.setLongBV    avgt   15   1191.037 ?  10.983  ns/op
MergeStoreBench.setLongL     avgt   15   3342.476 ?   4.704  ns/op
MergeStoreBench.setLongLU    avgt   15   6194.791 ?  13.241  ns/op
MergeStoreBench.setLongLV    avgt   15   1194.042 ?   2.943  ns/op
MergeStoreBench.setLongRB    avgt   15  17946.742 ?  26.888  ns/op
MergeStoreBench.setLongRBU   avgt   15  21342.899 ?  22.937  ns/op
MergeStoreBench.setLongRL    avgt   15   4034.050 ?   3.792  ns/op
MergeStoreBench.setLongRLU   avgt   15   4825.627 ?  11.409  ns/op
MergeStoreBench.setLongRU    avgt   15   1170.252 ?   1.582  ns/op
MergeStoreBench.setLongU     avgt   15   1192.220 ?   1.060  ns/op


## 2.3 Aliyun ecs.c8i.xlarge (x64)
* CPU CPU Intel? Xeon? Emerald

Benchmark                    Mode  Cnt      Score     Error  Units
MergeStoreBench.getCharB     avgt   15   5374.604 ?  11.001  ns/op
MergeStoreBench.getCharBU    avgt   15   4760.386 ?  20.612  ns/op
MergeStoreBench.getCharBV    avgt   15   3068.661 ?   2.712  ns/op
MergeStoreBench.getCharC     avgt   15   2591.548 ?   0.428  ns/op
MergeStoreBench.getCharL     avgt   15   5224.986 ?   3.388  ns/op
MergeStoreBench.getCharLU    avgt   15   4781.157 ?  19.001  ns/op
MergeStoreBench.getCharLV    avgt   15   2577.009 ?   1.374  ns/op
MergeStoreBench.getIntB      avgt   15  10512.241 ?  17.214  ns/op
MergeStoreBench.getIntBU     avgt   15   9271.460 ?  17.628  ns/op
MergeStoreBench.getIntBV     avgt   15    255.186 ?   0.731  ns/op
MergeStoreBench.getIntL      avgt   15   9728.629 ?   2.364  ns/op
MergeStoreBench.getIntLU     avgt   15   8983.810 ?   2.463  ns/op
MergeStoreBench.getIntLV     avgt   15   2569.886 ?   1.389  ns/op
MergeStoreBench.getIntRB     avgt   15  11285.198 ?  15.566  ns/op
MergeStoreBench.getIntRBU    avgt   15  10321.709 ?   4.604  ns/op
MergeStoreBench.getIntRL     avgt   15  10567.777 ?   3.931  ns/op
MergeStoreBench.getIntRLU    avgt   15   9436.647 ?  16.046  ns/op
MergeStoreBench.getIntRU     avgt   15   2327.805 ?   0.495  ns/op
MergeStoreBench.getIntU      avgt   15   2310.299 ?   2.477  ns/op
MergeStoreBench.getLongB     avgt   15  21698.862 ?  58.286  ns/op
MergeStoreBench.getLongBU    avgt   15  14682.074 ?  22.913  ns/op
MergeStoreBench.getLongBV    avgt   15    649.422 ?   2.738  ns/op
MergeStoreBench.getLongL     avgt   15  21584.034 ?  29.685  ns/op
MergeStoreBench.getLongLU    avgt   15  14346.370 ?   5.548  ns/op
MergeStoreBench.getLongLV    avgt   15   2574.877 ?   0.748  ns/op
MergeStoreBench.getLongRB    avgt   15  21689.446 ?  31.897  ns/op
MergeStoreBench.getLongRBU   avgt   15  14678.181 ?   3.447  ns/op
MergeStoreBench.getLongRL    avgt   15  21578.598 ?   4.353  ns/op
MergeStoreBench.getLongRLU   avgt   15  14350.201 ?  37.668  ns/op
MergeStoreBench.getLongRU    avgt   15   2988.364 ?   3.983  ns/op
MergeStoreBench.getLongU     avgt   15   2941.190 ?   0.582  ns/op
MergeStoreBench.putChars4B   avgt   15  10434.718 ?   3.309  ns/op
MergeStoreBench.putChars4BU  avgt   15   3008.607 ?   1.378  ns/op
MergeStoreBench.putChars4BV  avgt   15   7151.913 ? 483.572  ns/op
MergeStoreBench.putChars4C   avgt   15   6489.426 ?   1.369  ns/op
MergeStoreBench.putChars4L   avgt   15  10436.577 ?   5.568  ns/op
MergeStoreBench.putChars4LU  avgt   15   2837.432 ?   0.697  ns/op
MergeStoreBench.putChars4LV  avgt   15   7024.161 ?   9.887  ns/op
MergeStoreBench.putChars4S   avgt   15   6495.194 ?  12.316  ns/op
MergeStoreBench.setCharBS    avgt   15   8865.676 ?   6.476  ns/op
MergeStoreBench.setCharBV    avgt   15   5002.613 ?  20.300  ns/op
MergeStoreBench.setCharC     avgt   15   3936.314 ?   7.415  ns/op
MergeStoreBench.setCharLS    avgt   15   6989.120 ?  23.404  ns/op
MergeStoreBench.setCharLV    avgt   15   2589.797 ?   2.805  ns/op
MergeStoreBench.setIntB      avgt   15   6891.353 ?  13.239  ns/op
MergeStoreBench.setIntBU     avgt   15  10188.827 ?  21.409  ns/op
MergeStoreBench.setIntBV     avgt   15    899.335 ?   2.777  ns/op
MergeStoreBench.setIntL      avgt   15   2889.929 ?   6.582  ns/op
MergeStoreBench.setIntLU     avgt   15   5314.714 ?   5.170  ns/op
MergeStoreBench.setIntLV     avgt   15    945.432 ?   1.255  ns/op
MergeStoreBench.setIntRB     avgt   15   8159.294 ?  16.214  ns/op
MergeStoreBench.setIntRBU    avgt   15  10625.120 ?  12.809  ns/op
MergeStoreBench.setIntRL     avgt   15   6035.911 ?  47.780  ns/op
MergeStoreBench.setIntRLU    avgt   15   7148.487 ?  73.927  ns/op
MergeStoreBench.setIntRU     avgt   15    969.966 ?   6.127  ns/op
MergeStoreBench.setIntU      avgt   15    988.272 ?   2.214  ns/op
MergeStoreBench.setLongB     avgt   15  15857.394 ?   9.621  ns/op
MergeStoreBench.setLongBU    avgt   15  22955.799 ?   6.266  ns/op
MergeStoreBench.setLongBV    avgt   15   1831.898 ?   5.519  ns/op
MergeStoreBench.setLongL     avgt   15   4344.954 ?   4.273  ns/op
MergeStoreBench.setLongLU    avgt   15   5452.006 ?   9.333  ns/op
MergeStoreBench.setLongLV    avgt   15   1910.294 ?  22.688  ns/op
MergeStoreBench.setLongRB    avgt   15  16990.616 ?  59.974  ns/op
MergeStoreBench.setLongRBU   avgt   15  24951.367 ?  47.760  ns/op
MergeStoreBench.setLongRL    avgt   15   4484.135 ?   5.756  ns/op
MergeStoreBench.setLongRLU   avgt   15   4891.413 ?  26.743  ns/op
MergeStoreBench.setLongRU    avgt   15   1820.416 ?  11.285  ns/op
MergeStoreBench.setLongU     avgt   15   1932.694 ?  28.488  ns/op


[MergeStoreBench.txt](https://github.com/user-attachments/files/15878863/MergeStoreBench.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2174717821

From syan at openjdk.org  Tue Jun 18 02:00:41 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Jun 2024 02:00:41 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v2]
In-Reply-To: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
Message-ID: <9LxKMCFv_T7GMNglZ8DcQMb9DhdtY_Z0GVTFH7KvCPM=.45d71466-ca41-4071-8e02-50198d339a5b@github.com>

> Hi all,
> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
> The change has been verified, only change the testcase, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  change the excption meassges to: Unable to create an unreadable properties file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19732/files
  - new: https://git.openjdk.org/jdk/pull/19732/files/5cf26a11..9b8a0bcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19732&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19732&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19732/head:pull/19732

PR: https://git.openjdk.org/jdk/pull/19732

From syan at openjdk.org  Tue Jun 18 02:00:41 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Jun 2024 02:00:41 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v2]
In-Reply-To: <aeU5Ozr-eUvgCZ0Ga0f845XajhOmyJ6DVUughLwPLKU=.3130eeef-c7cb-446d-ab91-0cdd50b6a552@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <aeU5Ozr-eUvgCZ0Ga0f845XajhOmyJ6DVUughLwPLKU=.3130eeef-c7cb-446d-ab91-0cdd50b6a552@github.com>
Message-ID: <4pZ-5JOzaLU_eEFrIfwjYCtJHmsCk-zEInqBBCLREtc=.86f91858-6b9d-42e6-91f7-6ca42f5dba2e@github.com>

On Mon, 17 Jun 2024 18:46:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change the excption meassges to: Unable to create an unreadable properties file
>
> test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java line 60:
> 
>> 58:     public static void main(String[] args) throws Throwable {
>> 59:         if(Platform.isRoot() && !Platform.isWindows()) {
>> 60:             throw new SkippedException("root user has privileged will make this test fail.");
> 
> The exception message can be improved. How about "Unable to create an unreadable properties file"?

Thanks for the suggestion. The exception message has been change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19732#discussion_r1643627352

From duke at openjdk.org  Tue Jun 18 06:11:38 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 18 Jun 2024 06:11:38 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v7]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <D7Iwv_NTxjJeI8IE7ang9WWkN7sijK6ledst116idhI=.09bfe353-0492-42e5-8444-3ba0adcd50c4@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request with a new target base due to a merge or a rebase.

-------------

Changes: https://git.openjdk.org/jdk/pull/19513/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=06
  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From duke at openjdk.org  Tue Jun 18 06:11:38 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 18 Jun 2024 06:11:38 GMT
Subject: Withdrawn: 8333396: Performance regression of DecimalFormat.format
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <AxYQVxknT_Dl4YkmKtQe5MLxZj4saYCmtSLro9_Vj7Q=.7d805ba6-cf1a-4be9-ba37-f24aa8ffac68@github.com>

On Mon, 3 Jun 2024 04:18:20 GMT, lingjun-cg <duke at openjdk.org> wrote:

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19513

From aturbanov at openjdk.org  Tue Jun 18 06:21:11 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 18 Jun 2024 06:21:11 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v2]
In-Reply-To: <9LxKMCFv_T7GMNglZ8DcQMb9DhdtY_Z0GVTFH7KvCPM=.45d71466-ca41-4071-8e02-50198d339a5b@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <9LxKMCFv_T7GMNglZ8DcQMb9DhdtY_Z0GVTFH7KvCPM=.45d71466-ca41-4071-8e02-50198d339a5b@github.com>
Message-ID: <V84FSRaSILWiF8fUBQxmyk8sFSvvt4yZzWffYrKZiJU=.aaee48f8-5228-4c7c-8dae-b42ad4b1f400@github.com>

On Tue, 18 Jun 2024 02:00:41 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
>> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
>> The change has been verified, only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change the excption meassges to: Unable to create an unreadable properties file

test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java line 59:

> 57: public class MissingResourceCauseTestRun {
> 58:     public static void main(String[] args) throws Throwable {
> 59:         if(Platform.isRoot() && !Platform.isWindows()) {

Suggestion:

        if (Platform.isRoot() && !Platform.isWindows()) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19732#discussion_r1643875207

From syan at openjdk.org  Tue Jun 18 06:31:37 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Jun 2024 06:31:37 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v3]
In-Reply-To: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
Message-ID: <IaZqDqmfsr4Kvz76v2F_40vkZez329B4By7dKOLwhuc=.6c161659-3f8d-4913-9f94-225fd148ce67@github.com>

> Hi all,
> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
> The change has been verified, only change the testcase, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  add a whitespace before if

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19732/files
  - new: https://git.openjdk.org/jdk/pull/19732/files/9b8a0bcb..90d3b335

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19732&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19732&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19732/head:pull/19732

PR: https://git.openjdk.org/jdk/pull/19732

From syan at openjdk.org  Tue Jun 18 06:31:38 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Jun 2024 06:31:38 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v2]
In-Reply-To: <V84FSRaSILWiF8fUBQxmyk8sFSvvt4yZzWffYrKZiJU=.aaee48f8-5228-4c7c-8dae-b42ad4b1f400@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <9LxKMCFv_T7GMNglZ8DcQMb9DhdtY_Z0GVTFH7KvCPM=.45d71466-ca41-4071-8e02-50198d339a5b@github.com>
 <V84FSRaSILWiF8fUBQxmyk8sFSvvt4yZzWffYrKZiJU=.aaee48f8-5228-4c7c-8dae-b42ad4b1f400@github.com>
Message-ID: <VRnqaCu-hcjTYo73_2FRE0Xn1NKIO3ZvPbk0crj7nCQ=.c2c7e885-5e65-498b-bb8e-76664846da67@github.com>

On Tue, 18 Jun 2024 06:18:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change the excption meassges to: Unable to create an unreadable properties file
>
> test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java line 59:
> 
>> 57: public class MissingResourceCauseTestRun {
>> 58:     public static void main(String[] args) throws Throwable {
>> 59:         if(Platform.isRoot() && !Platform.isWindows()) {
> 
> Suggestion:
> 
>         if (Platform.isRoot() && !Platform.isWindows()) {

Thanks for  the review. A white space before `if` has been added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19732#discussion_r1643892712

From duke at openjdk.org  Tue Jun 18 07:03:38 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 18 Jun 2024 07:03:38 GMT
Subject: RFR: 8333867: SHA3 performance can be improved [v4]
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <1sYLyt2IjOt4mKaUOTiAp11jfLloVwkAoGsNmSzbKVw=.30096712-0701-4349-a51d-cd833b56d813@github.com>

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Copyright year update.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19632/files
  - new: https://git.openjdk.org/jdk/pull/19632/files/4fcdd09f..2bcd3000

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19632&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19632&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19632/head:pull/19632

PR: https://git.openjdk.org/jdk/pull/19632

From cstein at openjdk.org  Tue Jun 18 07:14:11 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 18 Jun 2024 07:14:11 GMT
Subject: RFR: 8331431: Update to use jtreg 7.4
In-Reply-To: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
References: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
Message-ID: <W7q7oAMxTX4twDdm8W2H6-Goe06hADcSwVpiRo2awN8=.fedd879f-ceb6-4293-b373-4054c6e7b9fc@github.com>

On Thu, 2 May 2024 09:48:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using `jtreg` **7.4**.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> Tested: tier 1 ? tier 8

Tests in tier 6-8 also look good. About to make `jtreg 7.4` the default now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19052#issuecomment-2175335129

From cstein at openjdk.org  Tue Jun 18 07:30:18 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 18 Jun 2024 07:30:18 GMT
Subject: Integrated: 8331431: Update to use jtreg 7.4
In-Reply-To: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
References: <_Q1eZAC0M9Q3B8idE8tfSg0TZ7Lh-tXoLdcbV4LZsa4=.392cc442-74ce-47c0-aea5-eaee500da7c1@github.com>
Message-ID: <LXI3ux42IW9D4te_KD8zEMI1qtoVkxKaDyY3wESYu5I=.27e9de55-2b87-4c52-b541-810528b17f55@github.com>

On Thu, 2 May 2024 09:48:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using `jtreg` **7.4**.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> Tested: tier 1 ? tier 8

This pull request has now been integrated.

Changeset: 99fefec0
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99fefec092f49cd759f93aa75e008cfa06d2a183
Stats:     12 lines in 8 files changed: 0 ins; 0 del; 12 mod

8331431: Update to use jtreg 7.4

Reviewed-by: ihse, erikj, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/19052

From asotona at openjdk.org  Tue Jun 18 07:32:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 18 Jun 2024 07:32:13 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v5]
In-Reply-To: <9AW2LHJmnkUALw9OaT2lLPDri-hR6qw61_8bx_zdGlo=.672dc82f-8bb4-4105-9361-13b81f5ff545@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <9AW2LHJmnkUALw9OaT2lLPDri-hR6qw61_8bx_zdGlo=.672dc82f-8bb4-4105-9361-13b81f5ff545@github.com>
Message-ID: <qkVifV9tTU2SQ389qvK3x42Z-t8em6WCp7OV32MoxdI=.8873bf0d-568f-4ff3-b5c2-346a4a173e80@github.com>

On Thu, 13 Jun 2024 14:11:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> Since the problematic patch from before cannot be backed out, this patch aims to emulate the old behavior before. A diff between before the problematic patch and this patch is available at https://gist.github.com/7565b2091008f561eb0ada019bc5e517, generated by running `git diff 326dbb1b139dd1ec1b8605339b91697cdf49da9a -- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   methodField can be initialized eagerly

It is unfortunate that LDC of a CP entry cannot substitute the original complex approach (and the critical cases were not covered by any tests).

@liach great work on the restoration of the original approach, while keeping the other improvements
Thanks!

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19615#pullrequestreview-2124720977

From jlu at openjdk.org  Tue Jun 18 07:34:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Jun 2024 07:34:11 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v3]
In-Reply-To: <IaZqDqmfsr4Kvz76v2F_40vkZez329B4By7dKOLwhuc=.6c161659-3f8d-4913-9f94-225fd148ce67@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <IaZqDqmfsr4Kvz76v2F_40vkZez329B4By7dKOLwhuc=.6c161659-3f8d-4913-9f94-225fd148ce67@github.com>
Message-ID: <TwWlLMDArIBPeGJz5lKj4CLddZ8eVfGPE9eye5fmgPY=.a55c7fdb-9fc4-4751-9237-d3a697dbf678@github.com>

On Tue, 18 Jun 2024 06:31:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
>> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
>> The change has been verified, only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a whitespace before if

test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java line 54:

> 52: import jdk.test.lib.Utils;
> 53: import jdk.test.lib.process.ProcessTools;
> 54: import jdk.test.lib.Platform;

It would be beneficial to add this issue's bug ID to the Jtreg `@bug` tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19732#discussion_r1643972916

From syan at openjdk.org  Tue Jun 18 07:41:35 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Jun 2024 07:41:35 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v4]
In-Reply-To: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
Message-ID: <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>

> Hi all,
> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
> The change has been verified, only change the testcase, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  add bug id 8334333 to jtreg tag @bug

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19732/files
  - new: https://git.openjdk.org/jdk/pull/19732/files/90d3b335..23f99429

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19732&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19732&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19732/head:pull/19732

PR: https://git.openjdk.org/jdk/pull/19732

From syan at openjdk.org  Tue Jun 18 07:41:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Jun 2024 07:41:36 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v3]
In-Reply-To: <TwWlLMDArIBPeGJz5lKj4CLddZ8eVfGPE9eye5fmgPY=.a55c7fdb-9fc4-4751-9237-d3a697dbf678@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <IaZqDqmfsr4Kvz76v2F_40vkZez329B4By7dKOLwhuc=.6c161659-3f8d-4913-9f94-225fd148ce67@github.com>
 <TwWlLMDArIBPeGJz5lKj4CLddZ8eVfGPE9eye5fmgPY=.a55c7fdb-9fc4-4751-9237-d3a697dbf678@github.com>
Message-ID: <ncnPrg4SlghB79Y3iTfmLGL9SojhgxhzdefFgaholl4=.90398f37-8ddc-405c-94bf-ff7818ce7cd7@github.com>

On Tue, 18 Jun 2024 07:31:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add a whitespace before if
>
> test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java line 54:
> 
>> 52: import jdk.test.lib.Utils;
>> 53: import jdk.test.lib.process.ProcessTools;
>> 54: import jdk.test.lib.Platform;
> 
> It would be beneficial to add this issue's bug ID to the Jtreg `@bug` tag.

Thanks for the suggestion. The bug id `8334333` has been added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19732#discussion_r1643982602

From redestad at openjdk.org  Tue Jun 18 07:45:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 18 Jun 2024 07:45:19 GMT
Subject: RFR: 8334437: De-duplicate ProxyMethod list creation
Message-ID: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>

Simple refactoring to extract identical, simple lambda expressions. Improve code clarity and reduce classes generated.

-------------

Commit messages:
 - Simplify
 - Refactor ProxyMethod list creation

Changes: https://git.openjdk.org/jdk/pull/19760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19760&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334437
  Stats: 10 lines in 1 file changed: 4 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19760/head:pull/19760

PR: https://git.openjdk.org/jdk/pull/19760

From redestad at openjdk.org  Tue Jun 18 07:55:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 18 Jun 2024 07:55:22 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps [v2]
In-Reply-To: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
Message-ID: <dZASJpGCp6U9Toyzh8FqlpOOux4AERfHsNILTqfG1hM=.481b642c-0538-4d4b-8109-3822d9708da5@github.com>

> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  @ExE-Boss review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19477/files
  - new: https://git.openjdk.org/jdk/pull/19477/files/cff6d034..a223e608

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19477&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19477&range=00-01

  Stats: 40 lines in 1 file changed: 11 ins; 0 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/19477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19477/head:pull/19477

PR: https://git.openjdk.org/jdk/pull/19477

From duke at openjdk.org  Tue Jun 18 10:00:33 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 18 Jun 2024 10:00:33 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/e95f0928..1fde6a60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=06-07

  Stats: 186 lines in 8 files changed: 130 ins; 0 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From redestad at openjdk.org  Tue Jun 18 10:00:46 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 18 Jun 2024 10:00:46 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps [v3]
In-Reply-To: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
Message-ID: <OVmK9shSdckDHbxyLjdQADmRADEXp5eR-B_r9L-zZic=.ed696fcb-f490-466c-85a1-295d4e55376f@github.com>

> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19477/files
  - new: https://git.openjdk.org/jdk/pull/19477/files/a223e608..d83a1c96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19477&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19477&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19477/head:pull/19477

PR: https://git.openjdk.org/jdk/pull/19477

From redestad at openjdk.org  Tue Jun 18 10:14:18 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 18 Jun 2024 10:14:18 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v18]
In-Reply-To: <sNXfVS28_c4DVAvHtEY3PJ-oALdxY8zHXIPjYBjvkjA=.d88e3567-df9e-4f71-ae5c-2ac37dc7b416@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Wx-kwCkkjAKLD7rQb4iIilYVo3ut-6Hku7AeKoWM5F4=.5beecc37-96e8-41b8-8e9f-5dfebb7e4abc@github.com>
 <CX-T1Tu1natwbyv9Kxuce5hHwuOQP1Us6O9n4BQRgck=.26750fd9-298b-4d70-a71a-c8e4d0749762@github.com>
 <r5Tiy1ujWNM3o6svQyBjU2-7SwMCwy16s3xCKZ6z0iA=.0c3cc3d8-c2c3-478d-b27c-8d6c7ea01e99@github.com>
 <sNXfVS28_c4DVAvHtEY3PJ-oALdxY8zHXIPjYBjvkjA=.d88e3567-df9e-4f71-ae5c-2ac37dc7b416@github.com>
Message-ID: <MOYvc-ddZx4zV-AKKsvquP88iJmyOMQ_e-OlwEJBx4Q=.b5079cc2-ed81-4c86-8214-fa47343b1c7b@github.com>

On Mon, 17 Jun 2024 11:21:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LMF will BMH and `ClassSpecializer`, but does not call into this code normally as the simple bound method handle needed by LMF is statically defined (`BoundMethodHandle.Species_L`). To be perfectly safe - and to keep lambda/indy/condy bootstrap overheads to a minumum - I'll continue recommending the desugaring of lambdas in java.lang.invoke
>
> It results in not very nice code, but makes sense.

I'll note that replacing a lambda with an anonymous class has a very marginal effect on startup when amortizing the cost of setting up the infrastructure for spinning classes. What can have a decent effect is if we can replace a few lambdas/anon classes with more imperative code that spins up/loads fewer classes, e.g., desugaring streams to for loops.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1644202229

From duke at openjdk.org  Tue Jun 18 10:40:12 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 18 Jun 2024 10:40:12 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v5]
In-Reply-To: <p4r7JEmT1In094nPcamyJkJRQD00dzB3MvIlHtRg8Dg=.068d9c8c-a46c-41de-a074-149a09cc0ec1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <b8L-9rNtxMFcO7iJ14ZXt8S3rt-HRrF28EAVciYxaa0=.4b035cca-43b9-4db9-a628-7353e5769e2e@github.com>
 <6kmKgt5QX3KBTmpN4R5D9-XWbiUkP7ieQF00DZc48Es=.5f0e517a-06e2-4392-984d-754d287b0ac5@github.com>
 <acPv0AiTqob7XLTogkIj8Jgtk5yW1axTP56-3HY_fPI=.ef730fad-2590-40aa-81a7-5fc00d3c3205@github.com>
 <p4r7JEmT1In094nPcamyJkJRQD00dzB3MvIlHtRg8Dg=.068d9c8c-a46c-41de-a074-149a09cc0ec1@github.com>
Message-ID: <zFWEX67FOXTWoUsXUUjNHL7kt_cjaG0KMVYc4zFKFLo=.cdec0542-5b1c-4ba5-9dad-3a745537cb14@github.com>

On Mon, 17 Jun 2024 18:17:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>>> I second Justin's suggestion here. The change should benefit every implementation in the JDK, not only NumberFormat. Also, I might suggest renaming the new class, as it is kind of long/redundant. How about using something as simple as "StringBuf"?
>> 
>> Thanks for your comment. The long name bother me for a while. I have changed it to ""StringBuf".
>
> Hi @lingjun-cg 
> 
> Thanks for your work here.
> 
> While this would benefit the performance of NumberFormat subclasses, we are hoping that if we are going to make the internal switch to StringBuilder, we can also make similar changes to other Format subclasses as well where applicable. So, we would want `isInternalSubclass()` to be defined at the Format level. Some methods that I can immediately think of would be `String DateFormat.format(Date date)`, `String ListFormat.format(List<String> input)` and, `String MessageFormat.format(Object obj)`.
> 
> I believe @naotoj shares the same sentiment.

@justin-curtis-lu The method `isInternalSubclass` in `DecimalFormat` already pulls up to `Format`.
@liach @naotoj Using `Appendable & CharSequence` instead of an interface with a limited method is a great idea. Following this idea, I have updated the PR. But there are some notes when implementing the idea.

1. Rename `format` to `formatWithGeneric` in DecimalFormat that accepts StringBuilder. If not that, throw a  StackOverflowException when run with `DecimalFormat.format(double)`. If not rename the format, there are 2 methods in DecimalFormat: 
```    
   @Override
    public StringBuffer format(double number, StringBuffer result,
                               FieldPosition fieldPosition) {
        return format(number, result, fieldPosition);
    }
    @Override
    <T extends Appendable & CharSequence> T format(double number, T result,
                                                   FieldPosition fieldPosition) {
   }

Because the second parameter type `StringBuffer` of the 1st method is more concrete than type `T` of the 2nd method, so the 1st method will call itself recursively. 

2. The `Appendable#append(java.lang.CharSequence)` method can throws IOException, so there is some messy code handling IOException.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2175778275

From kevinw at openjdk.org  Tue Jun 18 10:52:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Jun 2024 10:52:13 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v18]
In-Reply-To: <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
Message-ID: <yguKr43BeWYo7Cv84-OpDs7w_Dri2cDApOaDzZUk1Yg=.f17fe80d-62b6-44f8-a68a-2fa9ed2bf34d@github.com>

On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   braces

Yes, maybe we are light on testing with an SM actually enabled.  AuthorizationTest is the key test here, and tests authenticated connections with user/role names.  That is passing with no SM, SM allowed, and SM enabled with policy.

I am testing ThreadPoolAccTest.java with SM enabled with an allPermission policy, as well as just SM allowed or not allowed.  This is a good test as it exercises the Monitor class.  This still works, will add it.

Also, manual testing looks good to me:

In problem builds of jdk 23, attaching with JMX using authentication results in:
org.openjdk.kjdb.MyDebuggerException: getSubject is supported only if a security manager is allowed

With this change, JMX attach using authentication works.  A monitor role can correctly get refusals like:

Caused by: java.lang.SecurityException: Access denied! Invalid access level for requested MBeanServer operation.
        at com.sun.jmx.remote.security.MBeanServerFileAccessController.checkAccess(MBeanServerFileAccessController.java:348)
        at com.sun.jmx.remote.security.MBeanServerFileAccessController.checkWrite(MBeanServerFileAccessController.java:240)
        at com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:469)
        at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1520)

...and a control role is accepted (that's JMX simple security at work).

Running the target with a SecurityManager, and attaching, I see e.g.:
org.openjdk.kjdb.MyDebuggerException: access denied ("javax.management.MBeanPermission" "com.sun.management.internal.HotSpotThreadImpl#-[java.lang:type=Threading]" "isInstanceOf")

...which looks correct.

Add a -Djava.security.policy=/my/all.policy 
which has allPermission, and connections work OK.  Removing AllPermission from that policy, we get Exceptions again.
This looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2175801724

From lancea at openjdk.org  Tue Jun 18 10:58:18 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Jun 2024 10:58:18 GMT
Subject: RFR: 8334418: Update IANA Language Subtag Registry to Version
 2024-06-14
In-Reply-To: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
References: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
Message-ID: <hY3VXJwrPTQODK1gi-hHMkuRF-L1270FxR2lprwnCLw=.d884bb3a-c6f7-4e58-bb72-690102e237b8@github.com>

On Mon, 17 Jun 2024 21:05:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a trivial update of the IANA subtag registry to version 2024-06-14. 
> Announcement: https://mm.icann.org/pipermail/ietf-languages-announcements/2024-June/000092.html

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19757#pullrequestreview-2125182766

From alanb at openjdk.org  Tue Jun 18 11:08:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Jun 2024 11:08:11 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v18]
In-Reply-To: <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
Message-ID: <StONdJj3hnPMIhPy8s60aHy_O0hbYRis9SfdPuy92kI=.a83b0472-ed75-4201-95ef-90ec3727ba94@github.com>

On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   braces

I skimmed through the changes, much more readable now compared to some of the initial revisions. I kinda agree with one of the comments from a few days ago that if (allow) { .. } else { ..} is easier to read than putting the disallow case first. It's not a big deal as this code will be changed very soon to remove the SM path.

As regards testing then I think the highest priority should be to default/no-SM case. We need to be confident that there are no regressions in JMX for this execution mode. We don't have of course want to regression for the SM case but that is a niche execution mode and not long for this world.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2175831168

From dfuchs at openjdk.org  Tue Jun 18 11:36:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Jun 2024 11:36:12 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v16]
In-Reply-To: <bNZqEmj_nYQ55lQvaubYBsEPjCnCHHbi0VdBtexVtb4=.52a73eb6-6d91-46f5-8a8b-623cef3d5530@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
 <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
 <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>
 <bNZqEmj_nYQ55lQvaubYBsEPjCnCHHbi0VdBtexVtb4=.52a73eb6-6d91-46f5-8a8b-623cef3d5530@github.com>
Message-ID: <wL_WtVjqrsFxG0Hw3Mtckp6P46RGEjjw1swBwg0noYk=.5a506c00-9e83-4260-8305-9aaf10723bbf@github.com>

On Mon, 17 Jun 2024 20:27:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hi,
>> We almost always check !SharedSecrets.getJavaLangAccess().allowSecurityManager() (except in the RMIConnectionImpl contstructor)
>> 
>> This keeps the "modern" case first (except in that constructor, where it is only one line for each side of the if...).
>> 
>> This extra checking of SharedSecrets.getJavaLangAccess().allowSecurityManager() is to keep the modern and old style cases distinct, based on other comments here.  It keeps it simple to read I hope, but yes it is a little more verbose than it could be.
>> 
>> I'm hoping you'll agree that as these checks will be removed anyway, probably with a release, we should delay more extensive cleanup until then.  (I've also  rolled back my noPermissionsACC removal to keep this change away from being a general cleanup.)
>> 
>> I had a bunch of additional Exception handling for e.g. PrivilegedActionException I think in here, and it wasn't very pretty.  But, it might look better when there are fewer nested ifs in these methods, and when we are properly in the post-SecurityManager world... 8-)
>> 
>> Whether it checks acc != null or acc == null is based on the existing code.  I think that makes this diff easier to read, but also could be reworked and be made more consistent after SM removal.
>
> Agree with Kevin. To minimize risk, especially since this is to fix a significant regression and we are in RDP1, we are really trying to preserve the existing code as much as possible, even though it could be improved.

It is also more error prone (which is why I suggested using a single well tested utility method to implement the temporary hackery rather than spreading it at different places in different forms). But I'm OK with the code in this form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1644303322

From kevinw at openjdk.org  Tue Jun 18 12:17:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Jun 2024 12:17:46 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v18]
In-Reply-To: <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <rLnZacIFSDlp58TaQ5hyNTHX5dKKo2WRz7kGqAi_feo=.59606716-c45d-4251-9742-937bbf01a10d@github.com>
Message-ID: <ALvHHVyxYdAe54QrghKh5Y0sUv17FTCKzNVfNO9o-Ww=.6a8b71c8-1713-4ee3-b6fe-95255fc635ee@github.com>

On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   braces

Agreed that this is niche and will be short-lived, but I have added some SM-enabled runs with all permission policy for ThreadPoolAccTest.java and StartStopTest.java.  These look trivial to add, and will be trivial to remove...

Looking forward to more cleanup when we remove the SM-enabled paths.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2175956243

From kevinw at openjdk.org  Tue Jun 18 12:17:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Jun 2024 12:17:46 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v19]
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Additional test runs with SM enabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19624/files
  - new: https://git.openjdk.org/jdk/pull/19624/files/384a3a19..697fc0d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=17-18

  Stats: 7 lines in 3 files changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624

PR: https://git.openjdk.org/jdk/pull/19624

From kevinw at openjdk.org  Tue Jun 18 12:25:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Jun 2024 12:25:18 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v16]
In-Reply-To: <wL_WtVjqrsFxG0Hw3Mtckp6P46RGEjjw1swBwg0noYk=.5a506c00-9e83-4260-8305-9aaf10723bbf@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <FilB9DuhlMS0s4XFrVy9Lnz5JaOhwxbM4MQa1FjBWMk=.9224573d-f1ef-4e92-b776-21b89a8e70b3@github.com>
 <wtbwu9-cMtS6JUlisEqSrbOe-NssF6IoT49uY907CmE=.3ce37902-fd79-46e8-83f8-d549db85ac7e@github.com>
 <k2_DFVlnyLAAu_R2I6l8bGeula1PiDaKx8oPYlfn0nA=.1c7d5aa1-ea23-4086-a6f8-374eec84ddaa@github.com>
 <bNZqEmj_nYQ55lQvaubYBsEPjCnCHHbi0VdBtexVtb4=.52a73eb6-6d91-46f5-8a8b-623cef3d5530@github.com>
 <wL_WtVjqrsFxG0Hw3Mtckp6P46RGEjjw1swBwg0noYk=.5a506c00-9e83-4260-8305-9aaf10723bbf@github.com>
Message-ID: <qDRAxV6PniMw15KX3rUlFKbruMOZwuUYk4dSnjk55YY=.4a58ed30-e605-4bd2-9f50-f5d53737559a@github.com>

On Tue, 18 Jun 2024 11:33:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Agree with Kevin. To minimize risk, especially since this is to fix a significant regression and we are in RDP1, we are really trying to preserve the existing code as much as possible, even though it could be improved.
>
> It is also more error prone (which is why I suggested using a single well tested utility method to implement the temporary hackery rather than spreading it at different places in different forms). But I'm OK with the code in this form.

Thanks Daniel!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1644374757

From asotona at openjdk.org  Tue Jun 18 13:22:45 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 18 Jun 2024 13:22:45 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v21]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <Vp581Xvz71oxlmFsj44bHskbM1gsXjKh1J9ZZc9GyMc=.d506c229-90c0-417a-b79e-f2b2f58ddd9c@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with four additional commits since the last revision:

 - Merge pull request #8 from cl4es/serialization_hostile
   
   SerializationHostileMethod
 - Reduce gratuitous code movement
 - Inline Consumer<MethodBuilder> into generateSer.. method, move seldom-used serialization support constants to new holder
 - SerializationHostileMethod

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/3aaf246e..d3367487

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=19-20

  Stats: 86 lines in 1 file changed: 43 ins; 38 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From redestad at openjdk.org  Tue Jun 18 13:33:18 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 18 Jun 2024 13:33:18 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v21]
In-Reply-To: <Vp581Xvz71oxlmFsj44bHskbM1gsXjKh1J9ZZc9GyMc=.d506c229-90c0-417a-b79e-f2b2f58ddd9c@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Vp581Xvz71oxlmFsj44bHskbM1gsXjKh1J9ZZc9GyMc=.d506c229-90c0-417a-b79e-f2b2f58ddd9c@github.com>
Message-ID: <_yrejoZsB5xpL6Id4R2lDpgILaumoXMk6-zs4n6QQHU=.6d75bd22-443e-4d05-98be-1448daf8006c@github.com>

On Tue, 18 Jun 2024 13:22:45 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Merge pull request #8 from cl4es/serialization_hostile
>    
>    SerializationHostileMethod
>  - Reduce gratuitous code movement
>  - Inline Consumer<MethodBuilder> into generateSer.. method, move seldom-used serialization support constants to new holder
>  - SerializationHostileMethod

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 108:

> 106: 
> 107:         // condy to load implMethod from class data
> 108:         implMethodCondy = DynamicConstantDesc.ofNamed(BSM_CLASS_DATA, DEFAULT_NAME, CD_MethodHandle);

Pre-existing tiny wart, but this one seem to be used only exceptionally (see the comment/code around line 183) so it's probably better to inline the code at the usage site rather than have a constant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1644473614

From redestad at openjdk.org  Tue Jun 18 13:47:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 18 Jun 2024 13:47:20 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v21]
In-Reply-To: <Vp581Xvz71oxlmFsj44bHskbM1gsXjKh1J9ZZc9GyMc=.d506c229-90c0-417a-b79e-f2b2f58ddd9c@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Vp581Xvz71oxlmFsj44bHskbM1gsXjKh1J9ZZc9GyMc=.d506c229-90c0-417a-b79e-f2b2f58ddd9c@github.com>
Message-ID: <p92sR4tHQLgYKogEyn-IkkHjgwAFG_kx1LinxUwJDXc=.088f50b4-d142-4445-a168-f0b8b0e70714@github.com>

On Tue, 18 Jun 2024 13:22:45 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Merge pull request #8 from cl4es/serialization_hostile
>    
>    SerializationHostileMethod
>  - Reduce gratuitous code movement
>  - Inline Consumer<MethodBuilder> into generateSer.. method, move seldom-used serialization support constants to new holder
>  - SerializationHostileMethod

I've done a final pass over this. Code changes overall look good - great even - and the only caveat is that there's going to be some added startup overhead in some apps from integrating this. A minimal app with a lambda expression might see a 2-3ms hit, for example.

While there are ideas on how to trim down such overheads further I think this is a good time to draw a line in the sand and get this change integrated and exposed to a larger set of testing.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17108#pullrequestreview-2125569570

From redestad at openjdk.org  Tue Jun 18 13:49:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 18 Jun 2024 13:49:15 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v5]
In-Reply-To: <9AW2LHJmnkUALw9OaT2lLPDri-hR6qw61_8bx_zdGlo=.672dc82f-8bb4-4105-9361-13b81f5ff545@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <9AW2LHJmnkUALw9OaT2lLPDri-hR6qw61_8bx_zdGlo=.672dc82f-8bb4-4105-9361-13b81f5ff545@github.com>
Message-ID: <WXAPr0J_-U0qd2P5SxgfLg8Mo4tVXOWYEDfOF73wIN4=.dca85944-df05-454d-9965-15821c80e2a6@github.com>

On Thu, 13 Jun 2024 14:11:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> Since the problematic patch from before cannot be backed out, this patch aims to emulate the old behavior before. A diff between before the problematic patch and this patch is available at https://gist.github.com/7565b2091008f561eb0ada019bc5e517, generated by running `git diff 326dbb1b139dd1ec1b8605339b91697cdf49da9a -- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   methodField can be initialized eagerly

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19615#pullrequestreview-2125576655

From liach at openjdk.org  Tue Jun 18 13:50:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jun 2024 13:50:17 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v21]
In-Reply-To: <_yrejoZsB5xpL6Id4R2lDpgILaumoXMk6-zs4n6QQHU=.6d75bd22-443e-4d05-98be-1448daf8006c@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Vp581Xvz71oxlmFsj44bHskbM1gsXjKh1J9ZZc9GyMc=.d506c229-90c0-417a-b79e-f2b2f58ddd9c@github.com>
 <_yrejoZsB5xpL6Id4R2lDpgILaumoXMk6-zs4n6QQHU=.6d75bd22-443e-4d05-98be-1448daf8006c@github.com>
Message-ID: <1xbUNMsqURxzZBRPDt9nQ2qfzfjXhPUTsi5p1Y6hX64=.c717c482-df83-4570-8e01-d5cb551154ca@github.com>

On Tue, 18 Jun 2024 13:30:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Merge pull request #8 from cl4es/serialization_hostile
>>    
>>    SerializationHostileMethod
>>  - Reduce gratuitous code movement
>>  - Inline Consumer<MethodBuilder> into generateSer.. method, move seldom-used serialization support constants to new holder
>>  - SerializationHostileMethod
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 108:
> 
>> 106: 
>> 107:         // condy to load implMethod from class data
>> 108:         implMethodCondy = DynamicConstantDesc.ofNamed(BSM_CLASS_DATA, DEFAULT_NAME, CD_MethodHandle);
> 
> Pre-existing tiny wart, but this one seem to be used only exceptionally (see the comment/code around line 183) so it's probably better to inline the code at the usage site rather than have a constant.

If we aren't caching this descriptor, maybe it's even more simple for us to just construct the ConstantDynamicEntry from the pool builder at the use site; we can extract a method to keep this condy visible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1644501219

From liach at openjdk.org  Tue Jun 18 13:54:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jun 2024 13:54:19 GMT
Subject: RFR: 8333854: IllegalAccessError with proxies after JDK-8332457
 [v5]
In-Reply-To: <9AW2LHJmnkUALw9OaT2lLPDri-hR6qw61_8bx_zdGlo=.672dc82f-8bb4-4105-9361-13b81f5ff545@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
 <9AW2LHJmnkUALw9OaT2lLPDri-hR6qw61_8bx_zdGlo=.672dc82f-8bb4-4105-9361-13b81f5ff545@github.com>
Message-ID: <N4mzdXNGhAEe7Nnx5YW6seOZQfp2OxnjZR3zt54YY1I=.bfb3d78b-0dfd-4744-8003-3fe1c6ceab65@github.com>

On Thu, 13 Jun 2024 14:11:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that fixes a critical issue that breaks some Proxy usages.
>> 
>> Since the problematic patch from before cannot be backed out, this patch aims to emulate the old behavior before. A diff between before the problematic patch and this patch is available at https://gist.github.com/7565b2091008f561eb0ada019bc5e517, generated by running `git diff 326dbb1b139dd1ec1b8605339b91697cdf49da9a -- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   methodField can be initialized eagerly

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19615#issuecomment-2176158264

From liach at openjdk.org  Tue Jun 18 13:54:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jun 2024 13:54:21 GMT
Subject: Integrated: 8333854: IllegalAccessError with proxies after JDK-8332457
In-Reply-To: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
References: <DzzSVeIVgmY6Pd5S1IVa6sWL9WCwyFTvTQjgHOBcpgw=.bca8a4a4-9210-4637-9835-fb013db6c8e1@github.com>
Message-ID: <Rm2YBbS9QNFj-0__JhHrwIt82ySItFKEnmtgDo_AIv4=.51e0086f-62da-42d6-9a11-8e9fd28266ae@github.com>

On Mon, 10 Jun 2024 01:32:09 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch that fixes a critical issue that breaks some Proxy usages.
> 
> Since the problematic patch from before cannot be backed out, this patch aims to emulate the old behavior before. A diff between before the problematic patch and this patch is available at https://gist.github.com/7565b2091008f561eb0ada019bc5e517, generated by running `git diff 326dbb1b139dd1ec1b8605339b91697cdf49da9a -- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java`.

This pull request has now been integrated.

Changeset: 91bd85d6
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91bd85d65dff9cea91b88da7ef241be5c7b85f94
Stats:     238 lines in 2 files changed: 161 ins; 8 del; 69 mod

8333854: IllegalAccessError with proxies after JDK-8332457

Reviewed-by: redestad, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/19615

From asotona at openjdk.org  Tue Jun 18 14:39:27 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 18 Jun 2024 14:39:27 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v22]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <W78ecwlfAmo7yQ4nn-L7oIWNbm5XrmF7LA1-AtHAPlo=.8747a56e-02a8-49a2-a1b8-e50b86a7da3c@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Inlined condy construction directly into CP entries

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/d3367487..857b8821

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=20-21

  Stats: 9 lines in 1 file changed: 2 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From iris at openjdk.org  Tue Jun 18 16:01:10 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 18 Jun 2024 16:01:10 GMT
Subject: RFR: 8334418: Update IANA Language Subtag Registry to Version
 2024-06-14
In-Reply-To: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
References: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
Message-ID: <9ccQsYPPse0YtThdo9cB-UOTICdLaNORMUzB2aBhMuw=.74aadde3-36ac-46d2-beec-80a844d24506@github.com>

On Mon, 17 Jun 2024 21:05:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a trivial update of the IANA subtag registry to version 2024-06-14. 
> Announcement: https://mm.icann.org/pipermail/ietf-languages-announcements/2024-June/000092.html

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19757#pullrequestreview-2125932353

From srl at openjdk.org  Tue Jun 18 16:13:19 2024
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 18 Jun 2024 16:13:19 GMT
Subject: RFR: 8334418: Update IANA Language Subtag Registry to Version
 2024-06-14
In-Reply-To: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
References: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
Message-ID: <GTA0eABOGJPlHH-bQdwSQos8-9_LNn6-BXJcHS5Cqds=.ee0f3477-f046-47be-900c-eb64a2ad699f@github.com>

On Mon, 17 Jun 2024 21:05:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a trivial update of the IANA subtag registry to version 2024-06-14. 
> Announcement: https://mm.icann.org/pipermail/ietf-languages-announcements/2024-June/000092.html

Marked as reviewed by srl (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19757#pullrequestreview-2125966725

From ihse at openjdk.org  Tue Jun 18 16:19:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Jun 2024 16:19:39 GMT
Subject: RFR: 8333268: Fixes for static build [v2]
In-Reply-To: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
Message-ID: <hGVURwSbHviIo4QVpM6u_RNZysJwpEemBkCVI8N9bp0=.e99aa609-66e7-47da-864b-98221064ad63@github.com>

> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
> 
> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
> 
> 2) Remove the work-arounds to exclude duplicated symbols.
> 
> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
> 
> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into static-linking-progress
 - Merge branch 'master' into static-linking-progress
 - Move the exported JVM_IsStaticallyLinked to a better location
 - Use runtime lookup of static vs dynamic instead of #ifdef STATIC_BUILD
 - Copy fix for init_system_properties_values on linux
 - Make sure we do not try to build static libraries on Windows
 - 8333268: Fixes for static build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19478/files
  - new: https://git.openjdk.org/jdk/pull/19478/files/6b24a789..e1c46562

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19478&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19478&range=00-01

  Stats: 2608 lines in 114 files changed: 1321 ins; 955 del; 332 mod
  Patch: https://git.openjdk.org/jdk/pull/19478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19478/head:pull/19478

PR: https://git.openjdk.org/jdk/pull/19478

From naoto at openjdk.org  Tue Jun 18 16:25:19 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jun 2024 16:25:19 GMT
Subject: RFR: 8334418: Update IANA Language Subtag Registry to Version
 2024-06-14
In-Reply-To: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
References: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
Message-ID: <adqLt_92O16-EgN5vXwO2ntxKmJdXu7U4zO60rHSnGk=.1002962a-7f28-4a46-974c-4a6127db26e4@github.com>

On Mon, 17 Jun 2024 21:05:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a trivial update of the IANA subtag registry to version 2024-06-14. 
> Announcement: https://mm.icann.org/pipermail/ietf-languages-announcements/2024-June/000092.html

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19757#pullrequestreview-2125989013

From ihse at openjdk.org  Tue Jun 18 17:55:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Jun 2024 17:55:20 GMT
Subject: RFR: 8333268: Fixes for static build
In-Reply-To: <P32-FWD7brdEivGnFEvOsk5z2BajBIAseIVn_EM7Hw0=.bce78cf4-a2d0-4b4a-b287-6953350e90c5@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <P32-FWD7brdEivGnFEvOsk5z2BajBIAseIVn_EM7Hw0=.bce78cf4-a2d0-4b4a-b287-6953350e90c5@github.com>
Message-ID: <tn0FzmnVtOikBuuZjOA06dXjOcQ-8q7jdnjIl_9TcrA=.97f711e0-9606-431a-83c0-4a3685ea930d@github.com>

On Thu, 30 May 2024 19:35:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Do os::lookup_function need to be implemented on Windows too, for symmetry, even if it is only used on Unix platforms?

@AlanBateman suggested to add `lookup_function` to os_windows.cpp as well, but just let it contain ShouldNotReachHere. That sounds like a good solution to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19478#issuecomment-2176657975

From ihse at openjdk.org  Tue Jun 18 18:00:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Jun 2024 18:00:13 GMT
Subject: RFR: 8333268: Fixes for static build [v2]
In-Reply-To: <hGVURwSbHviIo4QVpM6u_RNZysJwpEemBkCVI8N9bp0=.e99aa609-66e7-47da-864b-98221064ad63@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <hGVURwSbHviIo4QVpM6u_RNZysJwpEemBkCVI8N9bp0=.e99aa609-66e7-47da-864b-98221064ad63@github.com>
Message-ID: <0dEUfxGGkUTfm3TPCNbBxREmGZScyLCXwKv9-7AFf3M=.b69446a9-0828-4a99-a677-8f948ea612b6@github.com>

On Tue, 18 Jun 2024 16:19:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into static-linking-progress
>  - Merge branch 'master' into static-linking-progress
>  - Move the exported JVM_IsStaticallyLinked to a better location
>  - Use runtime lookup of static vs dynamic instead of #ifdef STATIC_BUILD
>  - Copy fix for init_system_properties_values on linux
>  - Make sure we do not try to build static libraries on Windows
>  - 8333268: Fixes for static build

src/hotspot/os/linux/os_linux.cpp line 605:

> 603: 
> 604:       // Get rid of /{client|server|hotspot}, if binary is libjvm.so.
> 605:       // Or, cut off /<binary_name>.

@jianglizhou This code is based on changes in the Hermetic Java repo, but I do not fully understand neither the comment nor what the purpose is. If you could explain this a bit I'd be grateful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1644855137

From duke at openjdk.org  Tue Jun 18 18:06:16 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 18 Jun 2024 18:06:16 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v21]
In-Reply-To: <Vp581Xvz71oxlmFsj44bHskbM1gsXjKh1J9ZZc9GyMc=.d506c229-90c0-417a-b79e-f2b2f58ddd9c@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <Vp581Xvz71oxlmFsj44bHskbM1gsXjKh1J9ZZc9GyMc=.d506c229-90c0-417a-b79e-f2b2f58ddd9c@github.com>
Message-ID: <n6p0IBEAqaDB-cHtkGkIe7VyyGMRY_dwurvcAG7PSvE=.313f0005-29c2-43c7-a0a7-70c09626d450@github.com>

On Tue, 18 Jun 2024 13:22:45 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Merge pull request #8 from cl4es/serialization_hostile
>    
>    SerializationHostileMethod
>  - Reduce gratuitous code movement
>  - Inline Consumer<MethodBuilder> into generateSer.. method, move seldom-used serialization support constants to new holder
>  - SerializationHostileMethod

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 509:

> 507:     }
> 508: 
> 509: 

Suggestion:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17108#discussion_r1644860876

From naoto at openjdk.org  Tue Jun 18 18:19:11 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jun 2024 18:19:11 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v4]
In-Reply-To: <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>
Message-ID: <tVtvyenjVrzIJnNDdKwG7vV9UBRwtjHsRfOWbk6tMd8=.bc9c56bb-261c-44e2-aa75-d45356b92a41@github.com>

On Tue, 18 Jun 2024 07:41:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
>> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
>> The change has been verified, only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id 8334333 to jtreg tag @bug

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19732#pullrequestreview-2126195112

From naoto at openjdk.org  Tue Jun 18 18:27:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jun 2024 18:27:31 GMT
Subject: RFR: 8334490: Normalize string with locale invariant `toLowerCase()`
Message-ID: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>

The test library `jdk.test.lib.Platform` uses no-arg `toLowerCase()` for string comparison, which should be avoided.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/19775/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19775&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334490
  Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19775/head:pull/19775

PR: https://git.openjdk.org/jdk/pull/19775

From jlu at openjdk.org  Tue Jun 18 18:47:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Jun 2024 18:47:14 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v4]
In-Reply-To: <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>
Message-ID: <bf7KEBiutvDwHBj0JFsVyKZ1TllWMB8oS-ScqENJIl8=.6003f97e-1b47-46b1-90a4-ed90632e90d4@github.com>

On Tue, 18 Jun 2024 07:41:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
>> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
>> The change has been verified, only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id 8334333 to jtreg tag @bug

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19732#pullrequestreview-2126241928

From jlu at openjdk.org  Tue Jun 18 18:49:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Jun 2024 18:49:11 GMT
Subject: RFR: 8334490: Normalize string with locale invariant
 `toLowerCase()`
In-Reply-To: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
References: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
Message-ID: <J_7SYVL0pQQakzM9bNqTsPVxySBVDCGxMhTCUrqVrpQ=.75abba65-c05f-4b14-b494-d9fb4d5456df@github.com>

On Tue, 18 Jun 2024 18:23:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The test library `jdk.test.lib.Platform` uses no-arg `toLowerCase()` for string comparison, which should be avoided.

LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19775#pullrequestreview-2126244306

From dfuchs at openjdk.org  Tue Jun 18 18:53:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Jun 2024 18:53:10 GMT
Subject: RFR: 8334490: Normalize string with locale invariant
 `toLowerCase()`
In-Reply-To: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
References: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
Message-ID: <e5WUrDdjUgViTwkiIzwwguBeFQP-N6ih67adV3a-r74=.e3579568-76ff-479f-845a-73a1832432a4@github.com>

On Tue, 18 Jun 2024 18:23:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The test library `jdk.test.lib.Platform` uses no-arg `toLowerCase()` for string comparison, which should be avoided.

+1

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19775#pullrequestreview-2126251008

From lancea at openjdk.org  Tue Jun 18 19:17:16 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Jun 2024 19:17:16 GMT
Subject: RFR: 8334490: Normalize string with locale invariant
 `toLowerCase()`
In-Reply-To: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
References: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
Message-ID: <_wz-tEEfEJNiZl8ydeRsjPV1D9oiIu4N7QrQoV30Ung=.9f87305f-8497-45c9-b81b-6b1d752995b7@github.com>

On Tue, 18 Jun 2024 18:23:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The test library `jdk.test.lib.Platform` uses no-arg `toLowerCase()` for string comparison, which should be avoided.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19775#pullrequestreview-2126291246

From darcy at openjdk.org  Tue Jun 18 20:43:25 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Jun 2024 20:43:25 GMT
Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v3]
In-Reply-To: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
References: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
Message-ID: <xYcNdFnU4QqrScLmlU4QUF-2RE1xEvu2IvmWWi9A43Y=.31cc3f41-8b0c-45f2-a364-5d2925fcbf07@github.com>

> Misc small doc updates and addition of `@Overrides` annotations.

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 three additional commits since the last revision:

 - Merge branch 'master' into JDK-8333768
 - Merge branch 'master' into JDK-8333768
 - JDK-8333768: Minor doc updates to java.lang.{Float, Double}

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19590/files
  - new: https://git.openjdk.org/jdk/pull/19590/files/cfe77e62..9df534a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19590&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19590&range=01-02

  Stats: 15989 lines in 652 files changed: 6385 ins; 7852 del; 1752 mod
  Patch: https://git.openjdk.org/jdk/pull/19590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19590/head:pull/19590

PR: https://git.openjdk.org/jdk/pull/19590

From jlu at openjdk.org  Tue Jun 18 20:51:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Jun 2024 20:51:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
Message-ID: <0_blXbzNSt_2oGoSQST54wV46XrmWSCsgJWzzEMxNzc=.bba3bde8-6e1d-41cd-997c-dafcbb6248df@github.com>

On Tue, 18 Jun 2024 10:00:33 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

> If not that, throw a StackOverflowException when run with DecimalFormat.format(double)

I'm not sure I understand this point.

I think this is on the right track and looks much better with the generic implementation.

src/java.base/share/classes/java/text/ChoiceFormat.java line 561:

> 559:             toAppendTo.append(choiceFormats[i]);
> 560:         } catch (IOException ioe) {
> 561:             throw new UncheckedIOException(ioe.getMessage(), ioe);

Perhaps `AssertionError` instead of `UncheckedIOException` is better suited here and in the other ocurrences.

src/java.base/share/classes/java/text/Format.java line 278:

> 276:      *         {@code false} otherwise
> 277:      */
> 278:     boolean isInternalSubclass() {

Since this is defined in Format, can we apply similar changes of StringBuilder formatting to the other Format subclasses beyond just NumberFormat.

For example, in DateFormat, something such as,


<T extends Appendable & CharSequence> T formatWithGeneric(Date date,
                                                   T toAppendTo,
                                                   FieldPosition pos) {
        throw new UnsupportedOperationException("Subclasses should override this method");
}

-------------

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2126447188
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1645029030
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1645026453

From syan at openjdk.org  Wed Jun 19 00:56:40 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Jun 2024 00:56:40 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v4]
In-Reply-To: <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>
Message-ID: <1Refqv1j61qaVBk3Y9oGmkskyJpqfOGcwshzZuLKMNg=.7508e81f-4430-4abc-94cb-f01bdb4db037@github.com>

On Tue, 18 Jun 2024 07:41:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
>> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
>> The change has been verified, only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id 8334333 to jtreg tag @bug

Thanks all for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19732#issuecomment-2177319690

From darcy at openjdk.org  Wed Jun 19 01:43:27 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Jun 2024 01:43:27 GMT
Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v4]
In-Reply-To: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
References: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
Message-ID: <BDNLvk20P24Am4KTlR8IZMtDQVASq2_Mdc4s3Kld2fs=.ae156591-9ad9-4649-b30e-4a40e93c086c@github.com>

> Misc small doc updates and addition of `@Overrides` annotations.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19590/files
  - new: https://git.openjdk.org/jdk/pull/19590/files/9df534a3..4277c32b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19590&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19590&range=02-03

  Stats: 30 lines in 2 files changed: 26 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19590/head:pull/19590

PR: https://git.openjdk.org/jdk/pull/19590

From darcy at openjdk.org  Wed Jun 19 01:52:10 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Jun 2024 01:52:10 GMT
Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v4]
In-Reply-To: <MXM5kghdAA5XLbPx-IooCLAqWE2tMhB-D7ay8OHlPaA=.70d72aa8-a1dc-4cff-ba6d-a4e4209be124@github.com>
References: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
 <MXM5kghdAA5XLbPx-IooCLAqWE2tMhB-D7ay8OHlPaA=.70d72aa8-a1dc-4cff-ba6d-a4e4209be124@github.com>
Message-ID: <nH5BfL710C5aJfpi-NAcnUCDLc1xLwjmxer43Dlb2a0=.11a62d87-3459-4310-92d6-0441315dbd41@github.com>

On Fri, 7 Jun 2024 12:48:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/java/lang/Double.java line 595:
> 
>> 593:      * This method corresponds to the convertToDecimalCharacter
>> 594:      * operation defined in IEEE 754.
>> 595:      *
> 
> Does it?
> 
> IEEE 754 `convertToDecimalCharacter` takes a 2nd argument, the `conversionSpecification` which "specifies the precision and formatting of the _decimalCharacterSequence_ result". There's no such flexibility here.
> 
> Moreover, there seems to be no way to have a `conversionSpecification` that ensures the "shortest decimal" semantics of this method.
> 
> Finally, IEEE 754 requires to signal inexact exceptions.
> 
> Suggestion:
> 
>      * This method vaguely corresponds to the convertToDecimalCharacter
> 
> 
> The same holds for the other additional `@apiNote`s.

> Does it?
> 
> IEEE 754 `convertToDecimalCharacter` takes a 2nd argument, the `conversionSpecification` which "specifies the precision and formatting of the _decimalCharacterSequence_ result". There's no such flexibility here.
> 
> Moreover, there seems to be no way to have a `conversionSpecification` that ensures the "shortest decimal" semantics of this method.
> 
> Finally, IEEE 754 requires to signal inexact exceptions.
> 
> The same holds for the other additional `@apiNote`s.

Thanks for the comments @rgiulietti .

I've weakened the language for this method and added a javadoc to Formatter, which more closely aligns with the IEEE model of binary -> decimal conversion. For toHexString, the IEEE standard does state:

"When converting to hexadecimal-significand character sequences in the absence of an explicit precision
specification, enough hexadecimal characters shall be used to represent the binary floating-point number
exactly."

so the there isn't an exactly corresponding concern there.

With the frame condition that the Java platform ignores the sticky flags, I think making the linkage to IEEE operations is still informative. Basically, (in many case) if you project down to the subset of IEEE 754 the Java platform supports, this Java method computes the same floating-point value as this IEEE operation, etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19590#discussion_r1645286967

From duke at openjdk.org  Wed Jun 19 02:08:16 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 19 Jun 2024 02:08:16 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
Message-ID: <bwzVGsQPnmZgto9MjL8VC3TJK6ulyn_itq-RYBkEngw=.f79d0520-2b38-4e6f-8c5f-458fccba2e7c@github.com>

On Tue, 18 Jun 2024 10:00:33 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Using `<T extends Appendable & CharSequence> ` instead of  `StringBuf` seems a good idea, but it has a disadvantage. The `Appendable` defines only 3 `append` methods which cannot cover some cases.  For example, this method `SimpleDateFormat#format(Date, StringBuffer, FieldDelegate)` contains the following code:


            case TAG_QUOTE_CHARS:
                toAppendTo.append(compiledPattern, i, count);
                i += count;
                break;


It requires `append(char[], int, int)`, but the `Appendable` has no such method.
So it's difficult to use  `<T extends Appendable & CharSequence> ` in methods `String DateFormat.format(Date date), String ListFormat.format(List<String> input) and, String MessageFormat.format(Object obj)`.

The method in `java.text.MessageFormat#subformat` contains the following code:

            int argumentNumber = argumentNumbers[i];
            if (arguments == null || argumentNumber >= arguments.length) {
                result.append('{').append(argumentNumber).append('}');
                continue;
            }

It requires `append(int)`, but the `Appendable` has no such method.

To sum up
1. `<T extends Appendable & CharSequence> ` is clear, but lack of extensibility
2. StringBuf is not so clear, but it's more extensibility. We can add `append(char[], int, int)` to `StringBuf` to support `SimpleDateFormat`.
3.  New interface StringBuf no need to handle IOException, but use `<T extends Appendable & CharSequence> ` need to add a lot of try...catch statements around the append method.
4. 
So it seems `StringBuf` is better if we want to fix the problem in `DateFormat,ListFormat,MessageFormat` in unique way. 
I look forward to your reply. @naotoj @liach @justin-curtis-lu

Using `<T extends Appendable & CharSequence> ` instead of  `StringBuf` seems a good idea, but it has a disadvantage. The `Appendable` defines only 3 `append` methods which cannot cover some cases.  For example, this method `SimpleDateFormat#format(Date, StringBuffer, FieldDelegate)` contains the following code:


            case TAG_QUOTE_CHARS:
                toAppendTo.append(compiledPattern, i, count);
                i += count;
                break;


It requires `append(char[], int, int)`, but the `Appendable` has no such method.
So it's difficult to use  `<T extends Appendable & CharSequence> ` in methods `String DateFormat.format(Date date), String ListFormat.format(List<String> input) and, String MessageFormat.format(Object obj)`.

The method in `java.text.MessageFormat#subformat` contains the following code:

            int argumentNumber = argumentNumbers[i];
            if (arguments == null || argumentNumber >= arguments.length) {
                result.append('{').append(argumentNumber).append('}');
                continue;
            }

It requires `append(int)`, but the `Appendable` has no such method.

To sum up
1. `<T extends Appendable & CharSequence> ` is clear, but lack of extensibility
2. StringBuf is not so clear, but it's more extensibility. We can add `append(char[], int, int)` to `StringBuf` to support `SimpleDateFormat`.
3.  New interface StringBuf no need to handle IOException, but use `<T extends Appendable & CharSequence> ` need to add a lot of try...catch statements around the append method.


So it seems `StringBuf` is better if we want to fix the problem in `DateFormat,ListFormat,MessageFormat` in unique way. 
I look forward to your reply. @naotoj @liach @justin-curtis-lu

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2177382329
PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2177383927

From duke at openjdk.org  Wed Jun 19 02:14:13 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 19 Jun 2024 02:14:13 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <0_blXbzNSt_2oGoSQST54wV46XrmWSCsgJWzzEMxNzc=.bba3bde8-6e1d-41cd-997c-dafcbb6248df@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <0_blXbzNSt_2oGoSQST54wV46XrmWSCsgJWzzEMxNzc=.bba3bde8-6e1d-41cd-997c-dafcbb6248df@github.com>
Message-ID: <aHDjxn4Er_qUu6Vuql4tqi_j2AeNBVquB1YJOevHans=.0656a5dc-0357-47b6-a3b2-04c2c3409745@github.com>

On Tue, 18 Jun 2024 20:36:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/Format.java line 278:
> 
>> 276:      *         {@code false} otherwise
>> 277:      */
>> 278:     boolean isInternalSubclass() {
> 
> Since this is defined in Format, can we apply similar changes of StringBuilder formatting to the other Format subclasses beyond just NumberFormat.
> 
> For example, in DateFormat, something such as,
> 
> 
> <T extends Appendable & CharSequence> T formatWithGeneric(Date date,
>                                                    T toAppendTo,
>                                                    FieldPosition pos) {
>         throw new UnsupportedOperationException("Subclasses should override this method");
> }

ok. I will update it if we have a conclusion about using  `StringBuf` or using `<T extends Appendable & CharSequence>`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1645300958

From duke at openjdk.org  Wed Jun 19 02:17:11 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 19 Jun 2024 02:17:11 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <0_blXbzNSt_2oGoSQST54wV46XrmWSCsgJWzzEMxNzc=.bba3bde8-6e1d-41cd-997c-dafcbb6248df@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <0_blXbzNSt_2oGoSQST54wV46XrmWSCsgJWzzEMxNzc=.bba3bde8-6e1d-41cd-997c-dafcbb6248df@github.com>
Message-ID: <AnWm2w_wtHvOr-Z3DF8-5QSulERlnPNG7rvgX0Md_uQ=.c0f88702-f2f9-4952-a41a-01e6554118a0@github.com>

On Tue, 18 Jun 2024 20:39:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 561:
> 
>> 559:             toAppendTo.append(choiceFormats[i]);
>> 560:         } catch (IOException ioe) {
>> 561:             throw new UncheckedIOException(ioe.getMessage(), ioe);
> 
> Perhaps `AssertionError` instead of `UncheckedIOException` is better suited here and in the other ocurrences.

This can be removed if using `StringBuf`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1645304136

From duke at openjdk.org  Wed Jun 19 02:24:15 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 19 Jun 2024 02:24:15 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <aHDjxn4Er_qUu6Vuql4tqi_j2AeNBVquB1YJOevHans=.0656a5dc-0357-47b6-a3b2-04c2c3409745@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <0_blXbzNSt_2oGoSQST54wV46XrmWSCsgJWzzEMxNzc=.bba3bde8-6e1d-41cd-997c-dafcbb6248df@github.com>
 <aHDjxn4Er_qUu6Vuql4tqi_j2AeNBVquB1YJOevHans=.0656a5dc-0357-47b6-a3b2-04c2c3409745@github.com>
Message-ID: <EePQfWOv5y-v5JOFWX20sPDLEBnmj8DHkoykYZNBLvk=.67cc112f-f682-45ce-b0f8-ce916ff127ee@github.com>

On Wed, 19 Jun 2024 02:12:01 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/Format.java line 278:
>> 
>>> 276:      *         {@code false} otherwise
>>> 277:      */
>>> 278:     boolean isInternalSubclass() {
>> 
>> Since this is defined in Format, can we apply similar changes of StringBuilder formatting to the other Format subclasses beyond just NumberFormat.
>> 
>> For example, in DateFormat, something such as,
>> 
>> 
>> <T extends Appendable & CharSequence> T formatWithGeneric(Date date,
>>                                                    T toAppendTo,
>>                                                    FieldPosition pos) {
>>         throw new UnsupportedOperationException("Subclasses should override this method");
>> }
>
> ok. I will update it if we have a conclusion about using  `StringBuf` or using `<T extends Appendable & CharSequence>`.

This  comment inspire me that  use '<T extends Appendable & CharSequence>' in `SimpleDateFormat` is impossible, because the 'Appendable' lack of necessary `append` method which SimpleDateFormat requires.
So we need discuss whether `StringBuf` is a better solution?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1645309140

From darcy at openjdk.org  Wed Jun 19 02:25:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Jun 2024 02:25:16 GMT
Subject: RFR: 8309821: Link to hidden classes section in Class specification
 for Class::isHidden
Message-ID: <8JgEAcTlHALr5L95oTy7qLu7PygLVCslSYrSHI0NFFE=.c114ffe4-3074-498c-af23-6a9f715c83f0@github.com>

Simple doc improvement.

-------------

Commit messages:
 - JDK-8309821: Link to hidden classes section in Class specification for Class::isHidden

Changes: https://git.openjdk.org/jdk/pull/19781/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19781&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309821
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19781.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19781/head:pull/19781

PR: https://git.openjdk.org/jdk/pull/19781

From iris at openjdk.org  Wed Jun 19 03:13:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 19 Jun 2024 03:13:08 GMT
Subject: RFR: 8309821: Link to hidden classes section in Class
 specification for Class::isHidden
In-Reply-To: <8JgEAcTlHALr5L95oTy7qLu7PygLVCslSYrSHI0NFFE=.c114ffe4-3074-498c-af23-6a9f715c83f0@github.com>
References: <8JgEAcTlHALr5L95oTy7qLu7PygLVCslSYrSHI0NFFE=.c114ffe4-3074-498c-af23-6a9f715c83f0@github.com>
Message-ID: <ou3GSXryV7OYHsZoZcM0zamjEJ5USOAGHTTXz11XBAg=.cef25c9b-712d-48d8-8598-131454f013a5@github.com>

On Wed, 19 Jun 2024 02:21:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple doc improvement.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19781#pullrequestreview-2126919618

From asotona at openjdk.org  Wed Jun 19 07:44:26 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Jun 2024 07:44:26 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v23]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <ppB58tFcsUni52b_NG_vb2VwIcWd0Yi2lBTIZLzRx3k=.1912a1c6-b09b-4ccc-93ed-a135f81a33a0@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/857b8821..ac20f1f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=21-22

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From asotona at openjdk.org  Wed Jun 19 08:15:28 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Jun 2024 08:15:28 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v24]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <SHQrRMUOpcY3SVno4e1nPttSqVZF2-yIq02XHT7zDSs=.937142b6-8b30-4382-a4b0-8be489152c11@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed sneaky completion typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/ac20f1f8..257d66ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=22-23

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From fguallini at openjdk.org  Wed Jun 19 09:06:17 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 19 Jun 2024 09:06:17 GMT
Subject: Withdrawn: 8329335: HttpsURLConnectionTest fails due to network
 firewall rules
In-Reply-To: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>
References: <-PszXiahJE5B4j0_RGK1kqJZL6yzUDV5lkTOf8vmLbc=.7027d8d5-888a-4029-b15f-d3f4bd757cb6@github.com>
Message-ID: <tY6GHUCOsAM4-2IvXFnZ2QKoP6_3lite_OLMVKXXnJw=.20b7c52b-6966-4301-9e39-01222a776d83@github.com>

On Mon, 17 Jun 2024 09:16:45 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Since HttpsURLConnectionTest attempts to reach external servers, it can fail if run on hosts without outbound traffic allowed. Therefore, it should not be executed in CI pipelines but rather manually on a host with no firewall rules preventing egress traffic.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19745

From asotona at openjdk.org  Wed Jun 19 09:08:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Jun 2024 09:08:35 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v25]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - removed empty line
 - problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17108/files
  - new: https://git.openjdk.org/jdk/pull/17108/files/257d66ee..6e851a50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=23-24

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From asotona at openjdk.org  Wed Jun 19 09:19:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Jun 2024 09:19:15 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v25]
In-Reply-To: <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
Message-ID: <ho0sFjjfvd5_u9c8-llVcheqU5eulPj72L8DRDd1iWo=.d4698f1f-18a0-4e48-9cfc-87c4795e4067@github.com>

On Wed, 19 Jun 2024 09:08:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed empty line
>  - problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java

`runtime/ClassInitErrors/TestStackOverflowDuringInit.java` seems to be fragile and affected by this PR, so I created [JDK-8334545](https://bugs.openjdk.org/browse/JDK-8334545) and listed the test in `test/hotspot/jtreg/ProblemList.txt`

@mlchung @cl4es @liach @ExE-Boss  many thanks for significant contribution to this complex conversion!

Any final thoughts or objections to the integration?

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17108#issuecomment-2178180439

From redestad at openjdk.org  Wed Jun 19 10:13:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 19 Jun 2024 10:13:15 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v25]
In-Reply-To: <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
Message-ID: <KG4ShHoHTvr4l-JvOO_tvtEssgCFCqNdqPam1yHoqoU=.0c02a49e-5b31-4491-b90c-f7ddc088f657@github.com>

On Wed, 19 Jun 2024 09:08:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed empty line
>  - problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java

No objections as long as there's an understanding that we'll need to work on some of the startup/warmup regressions this will cause.

We have preliminary data on a subset of benchmarks which suggests it's a combination of loading more classes and spreading the work across a larger set of methods, which means we need to warm and JIT more methods to reach peak performance. ASM is a smaller library with a more minimalist approach, so it loads faster and gets up and running a bit faster. We'll probably need to file regressions as they are detected for tracking purposes, but I expect we'll continue chipping away at and improving the classfile API in the months to come.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17108#pullrequestreview-2127764187

From dfuchs at openjdk.org  Wed Jun 19 11:24:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Jun 2024 11:24:16 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v19]
In-Reply-To: <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
Message-ID: <XtBoIoECiDQjmCNTi-7fpxctvLaTnbZz2G2n6RBS_GQ=.9a6e67ba-7c13-4724-8606-dec36377501a@github.com>

On Tue, 18 Jun 2024 12:17:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test runs with SM enabled

The code changes look good to me (if a bit verbose) and the test changes look reasonable. It could be beneficial to add some more tests in the future involving monitoring and getting the subject from within a monitored MBean.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19624#pullrequestreview-2127943873

From kevinw at openjdk.org  Wed Jun 19 11:33:12 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Jun 2024 11:33:12 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v19]
In-Reply-To: <XtBoIoECiDQjmCNTi-7fpxctvLaTnbZz2G2n6RBS_GQ=.9a6e67ba-7c13-4724-8606-dec36377501a@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
 <XtBoIoECiDQjmCNTi-7fpxctvLaTnbZz2G2n6RBS_GQ=.9a6e67ba-7c13-4724-8606-dec36377501a@github.com>
Message-ID: <AxULD2W738W2iOTPona5XLppy5WY_2v-QmpP-WucsFM=.6dce5000-48a0-4f60-9033-9457801b2146@github.com>

On Wed, 19 Jun 2024 11:21:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The code changes look good to me (if a bit verbose) and the test changes look reasonable. It could be beneficial to add some more tests in the future involving monitoring and getting the subject from within a monitored MBean.

Yes, agreed. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2178461246

From duke at openjdk.org  Wed Jun 19 11:58:24 2024
From: duke at openjdk.org (duke)
Date: Wed, 19 Jun 2024 11:58:24 GMT
Subject: Withdrawn: 8315487: Security Providers Filter
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <5PNi_dgjCITWqq16SbW9qhJEBj0NJLI5DcpKQVS8-jw=.62d23893-1ba1-4474-a784-5c339b7e9d94@github.com>

On Fri, 1 Sep 2023 15:13:46 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15539

From shade at openjdk.org  Wed Jun 19 12:01:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Jun 2024 12:01:12 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
Message-ID: <C-adDF0cUN-nv1gz7gkrrNptRwWJ7-aJTa96KYmDX-c=.913b5b4a-f277-4b88-99fb-adf96c40ecd3@github.com>

On Thu, 6 Jun 2024 12:46:36 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2625.125 ? 71.802  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2607.447 ? 46.400  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2615.500 ? 30.771  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2583.892 ? 62.086  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding benchmarks for readObject

@AlanBateman -- could you please take a look? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2178515650

From duke at openjdk.org  Wed Jun 19 12:04:27 2024
From: duke at openjdk.org (Oussama Louati)
Date: Wed, 19 Jun 2024 12:04:27 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v11]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <rDMLLPxeeoJPZ-H2RfLOIvtIC-zAAyOO_IEL8sST-2c=.1bfddcef-51b9-402f-a7be-ca90587782e5@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  fix: fix comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/0cac912d..f869cce8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=09-10

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From duke at openjdk.org  Wed Jun 19 12:20:16 2024
From: duke at openjdk.org (Oussama Louati)
Date: Wed, 19 Jun 2024 12:20:16 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v9]
In-Reply-To: <j68Z-s1-uEJKk6UfmR1rJUg5JfR--cgcG7Zt_sY0hzA=.a6d1d0d7-8c5d-4f7e-837b-55c34a98e523@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <UfxoKDo2autP7ThykBrrk7_uf9LCPahZQp0kKYRzzeM=.9f921b0f-2ac6-4110-ace9-41b84913653a@github.com>
 <j68Z-s1-uEJKk6UfmR1rJUg5JfR--cgcG7Zt_sY0hzA=.a6d1d0d7-8c5d-4f7e-837b-55c34a98e523@github.com>
Message-ID: <Oex1oRS6vc6UX7dbjCr6DbToAXf1wrc9exALeL-Bxo8=.fa212500-ed2b-489a-9909-19bb5e88e7c3@github.com>

On Mon, 17 Jun 2024 08:12:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Oussama Louati has updated the pull request incrementally with 19 additional commits since the last revision:
>> 
>>  - fix: fixed whitespaces
>>  - fix: fixed whitespaces
>>  - chore: used Class::descriptorString
>>  - remove: added removed test comments
>>  - remove: added removed test comments
>>  - remove: removed changes in tests
>>  - update: optimize imports and remove unnecessary utils
>>  - update: optimize imports
>>  - update: 5th patch of code review
>>  - update: 5th patch of code review
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/781c951d...2b8c94a7
>
> test/jdk/java/lang/invoke/indify/Indify.java line 197:
> 
>> 195:             try {
>> 196:                 runApplication(avl.toArray(new String[0]));
>> 197:             } catch (Exception ex) {
> 
> Why the comments have been removed?

Detailed explanations are above in those options variables declaration.
Comments returned

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1646069101

From alanb at openjdk.org  Wed Jun 19 12:55:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Jun 2024 12:55:14 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <C-adDF0cUN-nv1gz7gkrrNptRwWJ7-aJTa96KYmDX-c=.913b5b4a-f277-4b88-99fb-adf96c40ecd3@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
 <C-adDF0cUN-nv1gz7gkrrNptRwWJ7-aJTa96KYmDX-c=.913b5b4a-f277-4b88-99fb-adf96c40ecd3@github.com>
Message-ID: <PaAlrwQm_PJNGZOt_3DPmVUOiil94nfHw8KZ0r80-a4=.bb6780d6-0e6a-4feb-aaf1-e24bb575a1fc@github.com>

On Wed, 19 Jun 2024 11:58:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> @AlanBateman -- could you please take a look? Thanks.

There was a lot of heap analysis done a few years ago that shined a light on the number of empty collections in a typical heap. I don't recall seeing COWAL in any of the data but it seems plausible that there are cases where there are a lot of empty COWAL instances in the heap.

Main thing for a change like this to make sure it doesn't hurt other cases and check if there are overridable methods used in the existing + updated implementations that might get reported as a behavior change by something that extends and overrides some methods. I don't see anything so I think it's okay.

One thing that surprises me is the change to remove(Object) to handle the case where the last remaining element is removed. Does that help the application that prompted this changed? Part of wonders if remove(int) needs to do the same as someone will show up sometime to ask.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2178649021

From jvernee at openjdk.org  Wed Jun 19 13:41:23 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 13:41:23 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted
 methods
Message-ID: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>

This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.

The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.

The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:


app.jar (ALL-UNNAMED):
  main.Main:
    main.Main::main(String[])void references restricted methods:
      java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
    main.Main::m()void is a native method declaration


The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.

Testing: 
- `langtools_jnativescan` tests.
- Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
- tier 1-3

-------------

Commit messages:
 - Merge branch 'master' into jnativescan
 - use URI-based constructor of Path
 - add jnativescan to help flag test
 - add --print-native-access test
 - correct one more comment
 - correct comment
 - add missing newlinw
 - add more testing + cleanup code
 - add test for references through subclasses
 - add test for array method refs
 - ... and 5 more: https://git.openjdk.org/jdk/compare/50bed6c6...9e8dad03

Changes: https://git.openjdk.org/jdk/pull/19774/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317611
  Stats: 1769 lines in 34 files changed: 1760 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From jvernee at openjdk.org  Wed Jun 19 13:41:23 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 13:41:23 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <aC-o0l0yU3ZZne9YyCzUfj8xl98T3EkZV9QDXViz2Y4=.c474e914-0ecf-48a6-9979-a716b323d4a3@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 93:

> 91:     }
> 92: 
> 93:     public PlatformDescription getPlatformTrusted(String platformName) {

I noticed that `getPlatform` was not throwing an exception if the release was not valid, which then later results in an NPE. I've added an explicit check here instead. The caller can then catch the exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1644763290

From liach at openjdk.org  Wed Jun 19 14:22:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Jun 2024 14:22:18 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v25]
In-Reply-To: <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
 <JyUc5SImg9QKVkHLM--Ot6izXoJC9G1KSLIXrMTHhzw=.f9178ce3-baa7-4abd-83d0-43af63ac02d8@github.com>
Message-ID: <ZoPv07YtIVpXVk_W6prmIcvzolje6J7HZYRekbuFUGk=.18337c5b-5a2e-443e-afd5-b39713fbffb3@github.com>

On Wed, 19 Jun 2024 09:08:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
>> 
>> This patch converts ASM calls to Classfile API.
>> 
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>> 
>> Any comments and suggestions are welcome.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed empty line
>  - problem-listed runtime/ClassInitErrors/TestStackOverflowDuringInit.java

The new changes since the last round of review is great. Also much thanks for fixing that sneaky condy typo in LMF.

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17108#pullrequestreview-2128433285

From rgiulietti at openjdk.org  Wed Jun 19 14:29:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 19 Jun 2024 14:29:11 GMT
Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v4]
In-Reply-To: <nH5BfL710C5aJfpi-NAcnUCDLc1xLwjmxer43Dlb2a0=.11a62d87-3459-4310-92d6-0441315dbd41@github.com>
References: <N3hDhuQGxQX09DFODpTzWZXK6DjhMUZ9INEphoQY9Vw=.5e3426a0-0583-4770-8a83-ca94a8016cf2@github.com>
 <MXM5kghdAA5XLbPx-IooCLAqWE2tMhB-D7ay8OHlPaA=.70d72aa8-a1dc-4cff-ba6d-a4e4209be124@github.com>
 <nH5BfL710C5aJfpi-NAcnUCDLc1xLwjmxer43Dlb2a0=.11a62d87-3459-4310-92d6-0441315dbd41@github.com>
Message-ID: <eqKb55CcubAhlkFBSjpzKsCKloSDWwVIHZwraKHFcDk=.02a71923-22fd-4ba5-b518-968f48496ba6@github.com>

On Wed, 19 Jun 2024 01:49:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Double.java line 595:
>> 
>>> 593:      * This method corresponds to the convertToDecimalCharacter
>>> 594:      * operation defined in IEEE 754.
>>> 595:      *
>> 
>> Does it?
>> 
>> IEEE 754 `convertToDecimalCharacter` takes a 2nd argument, the `conversionSpecification` which "specifies the precision and formatting of the _decimalCharacterSequence_ result". There's no such flexibility here.
>> 
>> Moreover, there seems to be no way to have a `conversionSpecification` that ensures the "shortest decimal" semantics of this method.
>> 
>> Finally, IEEE 754 requires to signal inexact exceptions.
>> 
>> Suggestion:
>> 
>>      * This method vaguely corresponds to the convertToDecimalCharacter
>> 
>> 
>> The same holds for the other additional `@apiNote`s.
>
>> Does it?
>> 
>> IEEE 754 `convertToDecimalCharacter` takes a 2nd argument, the `conversionSpecification` which "specifies the precision and formatting of the _decimalCharacterSequence_ result". There's no such flexibility here.
>> 
>> Moreover, there seems to be no way to have a `conversionSpecification` that ensures the "shortest decimal" semantics of this method.
>> 
>> Finally, IEEE 754 requires to signal inexact exceptions.
>> 
>> The same holds for the other additional `@apiNote`s.
> 
> Thanks for the comments @rgiulietti .
> 
> I've weakened the language for this method and added a javadoc to Formatter, which more closely aligns with the IEEE model of binary -> decimal conversion. For toHexString, the IEEE standard does state:
> 
> "When converting to hexadecimal-significand character sequences in the absence of an explicit precision
> specification, enough hexadecimal characters shall be used to represent the binary floating-point number
> exactly."
> 
> so the there isn't an exactly corresponding concern there.
> 
> With the frame condition that the Java platform ignores the sticky flags, I think making the linkage to IEEE operations is still informative. Basically, (in many case) if you project down to the subset of IEEE 754 the Java platform supports, this Java method computes the same floating-point value as this IEEE operation, etc.

Take the `double` closest to the exact decimal 0.1.

My understanding is that IEEE with a precision of 17 would convert it to the decimal 0.10000000000000001.

However, `Formatter` with a specifier `"%.17f"` will render this as 0.10000000000000000. That's because `Formatter`'s spec is based on this method (which produces 0.1), so cannot generate the trailing 1.

Similarly, the `double` closest to 1.2 is converted to 1.19999999999999996 by IEEE and to 1.20000000000000000 by `Formatter`, because this method produces 1.2.

In other words, neither this method nor the functionality offered by `Formatter` and friends correspond to IEEE, at least not in full.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19590#discussion_r1646298859

From rriggs at openjdk.org  Wed Jun 19 14:33:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Jun 2024 14:33:12 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <KKh_-XYeoNt6yqnKsMtf-ZHP07C2M83GzCNFjAqgPwI=.43e5ed09-de68-4a6f-9dd7-a546f2ff799f@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

One more tool. or...
Could this be coalesced into a tool that does deprscan and restricted methods, and other "lint" type checks?
I might go so far as to suggest it be extensible and accept patterns or regular expressions for matching classes, methods, fields, etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2178860810

From ihse at openjdk.org  Wed Jun 19 14:37:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 19 Jun 2024 14:37:10 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <xa1dzvMddNo_NOWB6UjLxbJUALnwLjYi3GS4l1qA2cI=.c0843358-bd3b-4261-a226-f17e88c08154@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Build changes are trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2128470410

From rriggs at openjdk.org  Wed Jun 19 14:41:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Jun 2024 14:41:13 GMT
Subject: RFR: 8309821: Link to hidden classes section in Class
 specification for Class::isHidden
In-Reply-To: <8JgEAcTlHALr5L95oTy7qLu7PygLVCslSYrSHI0NFFE=.c114ffe4-3074-498c-af23-6a9f715c83f0@github.com>
References: <8JgEAcTlHALr5L95oTy7qLu7PygLVCslSYrSHI0NFFE=.c114ffe4-3074-498c-af23-6a9f715c83f0@github.com>
Message-ID: <_7AmXG7NgG_zlFIX4aCb2967PtU8KEoyUYOZUybI8L4=.40e3a5ef-2781-439e-ad28-75fb8f3abd3a@github.com>

On Wed, 19 Jun 2024 02:21:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple doc improvement.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19781#pullrequestreview-2128478464

From rriggs at openjdk.org  Wed Jun 19 14:42:14 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Jun 2024 14:42:14 GMT
Subject: RFR: 8334490: Normalize string with locale invariant
 `toLowerCase()`
In-Reply-To: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
References: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
Message-ID: <MZSeDPXa35J5y2EOD6iU3MSg8yQU2zmfszz8bSFwmck=.d9f4f3b4-4c80-48c2-9de8-c8bc8e0be691@github.com>

On Tue, 18 Jun 2024 18:23:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The test library `jdk.test.lib.Platform` uses no-arg `toLowerCase()` for string comparison, which should be avoided.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19775#pullrequestreview-2128480919

From ihse at openjdk.org  Wed Jun 19 15:11:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 19 Jun 2024 15:11:24 GMT
Subject: RFR: 8333268: Fixes for static build [v3]
In-Reply-To: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
Message-ID: <Vo-QT7xUnoABC0mROKRIOdnO7GFNn9UveIrcXjq1YlQ=.ab73a667-b562-44c6-b756-d76486928d53@github.com>

> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
> 
> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
> 
> 2) Remove the work-arounds to exclude duplicated symbols.
> 
> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
> 
> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Do not use partial linking when building static libraries for internal consumption

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19478/files
  - new: https://git.openjdk.org/jdk/pull/19478/files/e1c46562..4ab70df3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19478&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19478&range=01-02

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19478/head:pull/19478

PR: https://git.openjdk.org/jdk/pull/19478

From ihse at openjdk.org  Wed Jun 19 15:15:43 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 19 Jun 2024 15:15:43 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
Message-ID: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>

> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
> 
> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
> 
> 2) Remove the work-arounds to exclude duplicated symbols.
> 
> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
> 
> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add dummy implementation of os::lookup_function for Windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19478/files
  - new: https://git.openjdk.org/jdk/pull/19478/files/4ab70df3..b88d813e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19478&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19478&range=02-03

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19478/head:pull/19478

PR: https://git.openjdk.org/jdk/pull/19478

From asotona at openjdk.org  Wed Jun 19 15:18:21 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 19 Jun 2024 15:18:21 GMT
Subject: Integrated: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <jaht5IXsbmYw0yZi2o1yv-K7r2JCorjD6wx_JGsc0ec=.39bb1baf-d012-40dd-a1ab-286b74e4826a@github.com>

On Thu, 14 Dec 2023 12:39:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 01ee4241
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01ee4241b76e78ca67803c4b083fcedecef1c96c
Stats:     2175 lines in 11 files changed: 459 ins; 877 del; 839 mod

8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles

Co-authored-by: Claes Redestad <redestad at openjdk.org>
Reviewed-by: redestad, liach

-------------

PR: https://git.openjdk.org/jdk/pull/17108

From ihse at openjdk.org  Wed Jun 19 15:21:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 19 Jun 2024 15:21:10 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <PAHS2P3FEGqTR7FQdmkoiT_xVDHGDyTRhQtRwMv9oc4=.53547b23-d0a9-4cea-b731-b0f4d3d123b5@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

The reason the gtest failed was that we build a static library libgtest.a, which is linked with the gtest libjvm.so. With the changes in this PR, libgtest.a was being built using the `ld -r` + `objcopy --localize-hidden` method. This caused some weird issues with gcc, related to C++ code and the `COMDAT` object info. 

I failed to track down any proper solution, so instead I added a patch where the libraries that we explicitly declare as `STATIC_LIBRARIES` are linked as before, without the partial linking step. These libraries are only intended for internal consumption (that is, they are linked to and used by another, "external" library), and so the extra protection added by the partial linking is not really needed.

It's a bit sad that this did not work, but it is no big deal. It won't affect files released in the image, and it will not be a regression as compared to now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19478#issuecomment-2178961562

From fguallini at openjdk.org  Wed Jun 19 15:46:33 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 19 Jun 2024 15:46:33 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
Message-ID: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>

The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.

In addition, this patch is removing the test from the problemList as it passes, and from manual test list.

-------------

Commit messages:
 - test TextCallbackHandler/Default.java is automated

Changes: https://git.openjdk.org/jdk/pull/19790/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19790&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334562
  Stats: 50 lines in 3 files changed: 29 ins; 2 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/19790.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19790/head:pull/19790

PR: https://git.openjdk.org/jdk/pull/19790

From jvernee at openjdk.org  Wed Jun 19 16:25:09 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 16:25:09 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <KKh_-XYeoNt6yqnKsMtf-ZHP07C2M83GzCNFjAqgPwI=.43e5ed09-de68-4a6f-9dd7-a546f2ff799f@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <KKh_-XYeoNt6yqnKsMtf-ZHP07C2M83GzCNFjAqgPwI=.43e5ed09-de68-4a6f-9dd7-a546f2ff799f@github.com>
Message-ID: <pa_spv5tLf23U-JtA0fsRxKnoqrl9LkikNa7ySWgJEk=.9683a7b2-7a88-4eb6-bdf3-55c4477cfbbd@github.com>

On Wed, 19 Jun 2024 14:30:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> One more tool. or... Could this be coalesced into a tool that does deprscan and restricted methods, and other "lint" type checks? I might go so far as to suggest it be extensible and accept patterns or regular expressions for matching classes, methods, fields, etc.

Discussed this with several people ahead of this PR. That is something we might want to do in the future, but we want this scanning feature to be ready for the JNI restriction, which is proposed to target Java 24.

Other work might include unifying the code bases of `jdeprscan`, `jdeps`, and exposing a general purpose static-analysis API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2179078565

From kevinw at openjdk.org  Wed Jun 19 16:38:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Jun 2024 16:38:18 GMT
Subject: RFR: 8333344: JMX attaching of Subject does not work when security
 manager not allowed [v19]
In-Reply-To: <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
 <0Yy3aRUY8VFFryY4gwCt9UWBVnto_0mJHa6ick1Womw=.25249932-2c92-4033-b8f1-5064839229e3@github.com>
Message-ID: <6DZAICD7aTF44fKtMTT1061FHQYv9d3JpLLqo_uGewU=.8c5d4ea9-218b-480f-bff1-ef050d3cd3ae@github.com>

On Tue, 18 Jun 2024 12:17:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
>> 
>> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional test runs with SM enabled

Integrating, thanks for all the comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2179099175

From kevinw at openjdk.org  Wed Jun 19 16:38:19 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Jun 2024 16:38:19 GMT
Subject: Integrated: 8333344: JMX attaching of Subject does not work when
 security manager not allowed
In-Reply-To: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
References: <Tmf3mBMn_xjrwy1kLtuB-VJuzdVoLQt7e9TMUKaPjME=.f9fbae47-ef27-4dd5-a16d-3babb26d40c2@github.com>
Message-ID: <IxGiF8r8a1ENredV58PPDLB6uBqFcP5AHVi6UKmdRI0=.4b8d874e-1445-44fa-b225-e7e197528e25@github.com>

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  -Djava.security.manager=allow to use JMX authentication.

This pull request has now been integrated.

Changeset: bcf4bb48
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f
Stats:     162 lines in 17 files changed: 113 ins; 3 del; 46 mod

8333344: JMX attaching of Subject does not work when security manager not allowed

Reviewed-by: weijun, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/19624

From mcimadamore at openjdk.org  Wed Jun 19 17:19:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 17:19:11 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <ChzChQyVpNczA8ZU8BJ2EvTJNwzCM18eqDsVFlLeIH4=.2de03818-e44c-4b53-8726-1ef13694570b@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java line 125:

> 123:         if (optionSet.has(helpOpt)) {
> 124:             out.println("""
> 125:                 The jnativescan tool can be used to find methods that may access native functionality when

Suggestion:

                The jnativescan tool can be used to find methods that may access native functionalities when

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java line 126:

> 124:             out.println("""
> 125:                 The jnativescan tool can be used to find methods that may access native functionality when
> 126:                 run. This includes methods that call restricted methods, and 'native' method declarations.

I think it would be more readable if we said "This includes restricted method calls and `native` method declarations`. The way it is now it seems (for some weird subjective reason) that the sentence is saying "methods ... that call ... native method declarations" :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646530805
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646531845

From jvernee at openjdk.org  Wed Jun 19 17:28:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 17:28:11 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <ChzChQyVpNczA8ZU8BJ2EvTJNwzCM18eqDsVFlLeIH4=.2de03818-e44c-4b53-8726-1ef13694570b@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <ChzChQyVpNczA8ZU8BJ2EvTJNwzCM18eqDsVFlLeIH4=.2de03818-e44c-4b53-8726-1ef13694570b@github.com>
Message-ID: <F9P-dfpEZodN5n_9jXNTEJMETPoM9p5EFikZq3JPVrU=.3896807b-54bd-4069-8199-b815cfac430a@github.com>

On Wed, 19 Jun 2024 17:16:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java line 126:
> 
>> 124:             out.println("""
>> 125:                 The jnativescan tool can be used to find methods that may access native functionality when
>> 126:                 run. This includes methods that call restricted methods, and 'native' method declarations.
> 
> I think it would be more readable if we said "This includes restricted method calls and `native` method declarations`. The way it is now it seems (for some weird subjective reason) that the sentence is saying "methods ... that call ... native method declarations" :-)

Oh, the oxford comma has failed me :D

> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 43:
> 
>> 41: import java.util.*;
>> 42: 
>> 43: class RestrictedMethodFinder {
> 
> The name of this is a bit confusing as this class looks for both restricted methods and JNI decls

True. How about `NativeAccessFinder`?

> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 48:
> 
>> 46:     // see make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java
>> 47:     private static final String RESTRICTED_NAME = "Ljdk/internal/javac/Restricted+Annotation;";
>> 48:     private static final List<String> RESTRICTED_MODULES = List.of("java.base");
> 
> unused?

Yes

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646535247
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646538303
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646535411

From mcimadamore at openjdk.org  Wed Jun 19 17:28:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 17:28:11 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <6j-_WLlk0VhImc1HHeOskaoc91fGsF0BbwMToF9ub2E=.457c4678-fe74-493a-ae74-fb7ec9d2d24a@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 43:

> 41: import java.util.*;
> 42: 
> 43: class RestrictedMethodFinder {

The name of this is a bit confusing as this class looks for both restricted methods and JNI decls

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 48:

> 46:     // see make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java
> 47:     private static final String RESTRICTED_NAME = "Ljdk/internal/javac/Restricted+Annotation;";
> 48:     private static final List<String> RESTRICTED_MODULES = List.of("java.base");

unused?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646536647
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646535286

From mcimadamore at openjdk.org  Wed Jun 19 17:33:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 17:33:10 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <b-uhV47r6YU4IekjBDkHgNbOn2piv7Gp1XVA13HPc48=.548adfe8-b62b-4935-a39c-4d9dc13ad23e@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 105:

> 103:         return switch (method) {
> 104:             case MethodRefEntry mre ->
> 105:                     isRestrictedMethod(mre.owner().asSymbol(), mre.name().stringValue(), mre.typeSymbol());

Do we really need these two identical calls to `isRestrictedMethod` ? Note that both `MethodRefEntry` and `InterfaceMethodEntry` are subclasses of `MemberRefEntry`, so perhaps the other `isRestrictedMethod` can just take `MemberRefEntry`?

Or maybe we can have different factories in `MethodRef` one that takes `InterfaceMethodEntry` and another that takes `MemberRefEntry`.

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 120:

> 118:             Optional<ClassResolver.Info> info = systemClassResolver.lookup(methodRef.owner());
> 119:             if (!info.isPresent()) {
> 120:                 return false;

Is this just `false` or maybe a warning that a certain owner could not be resolved (maybe if running with enough debug options) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646540627
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646541992

From mcimadamore at openjdk.org  Wed Jun 19 17:37:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 17:37:10 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <cIM05ppuR10y4VvCCuHE_pPvMzvXhN3jWsuju9iztik=.3211d3b0-b440-41fd-9283-52b23482c3f3@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 98:

> 96:     // in this.classPaths, and recursively following all Class-Path manifest
> 97:     // attributes
> 98:     private Stream<ScannedModule> findAllClassPathJars() throws JNativeScanFatalError {

nice!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646545209

From mcimadamore at openjdk.org  Wed Jun 19 17:44:09 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 17:44:09 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <wN7MphwgpmzUS7Iu2EByjTzJ3YfNpLKJEUqE9c1LBgo=.3c9180e1-a791-47bf-a1d9-006a45c9cf29@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 76:

> 74:             URI location = m.reference().location().orElseThrow();
> 75:             Path path = Path.of(location);
> 76:             checkRegularJar(path);

if exploded modules aren't supported (as discussed offline), maybe the error message generated here should be more specific?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646550176

From mcimadamore at openjdk.org  Wed Jun 19 17:49:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 17:49:10 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <BKjkHvbykNTROJyHcjiFnfz0uBAD41v-18h92fl3dRA=.28383472-0bcd-4373-9a93-08fcc895c0fe@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 81:

> 79: 
> 80:         Map<ScannedModule, Map<ClassDesc, List<RestrictedUse>>> allRestrictedMethods;
> 81:         try(ClassResolver classesToScan = ClassResolver.forScannedModules(modulesToScan, version);

Could it make sense here to "chain" the two resolvers into one, and just pass the chained one to the restricted finder?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646553850

From jvernee at openjdk.org  Wed Jun 19 17:49:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 17:49:11 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <b-uhV47r6YU4IekjBDkHgNbOn2piv7Gp1XVA13HPc48=.548adfe8-b62b-4935-a39c-4d9dc13ad23e@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <b-uhV47r6YU4IekjBDkHgNbOn2piv7Gp1XVA13HPc48=.548adfe8-b62b-4935-a39c-4d9dc13ad23e@github.com>
Message-ID: <KNsQIZsg6ziCB3ZS9SUpUOOi7-tAkfjdTcPJ6Jok3cM=.7aa7b1c4-1ff5-4c34-a4ee-0cf9599f357e@github.com>

On Wed, 19 Jun 2024 17:30:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 120:
> 
>> 118:             Optional<ClassResolver.Info> info = systemClassResolver.lookup(methodRef.owner());
>> 119:             if (!info.isPresent()) {
>> 120:                 return false;
> 
> Is this just `false` or maybe a warning that a certain owner could not be resolved (maybe if running with enough debug options) ?

Yes, thought about that yesterday as well. Good catch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646552669

From mcimadamore at openjdk.org  Wed Jun 19 18:00:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 18:00:13 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <twTRFGvpiWyQwkJHrt2VJFltjJ1FpgKtIUnC9htiKcc=.e2355e07-566a-414e-9168-fe1f9a82f956@github.com>

On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Looks very good! I left a bunch of comments and question.

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java line 126:

> 124: 
> 125:         private static Map<String, String> packageToSystemModule() {
> 126:             List<ModuleDescriptor> descriptors = ModuleFinder.ofSystem()

Is it a problem that we compute the package -> module map using the runtime info (so latest version) but then all the other info is taken from a release-specific symbol file? E.g. say that package "foo" was moved from module "A" to module "B" in version N, and that user passes N - 1 as release to the scan tool - would that work?

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 165:

> 163:                     restrictedUses.forEach(use -> {
> 164:                         switch (use) {
> 165:                             case RestrictedUse.NativeMethodDecl(MethodRef nmd) ->

should user be able to filter output using an option? E.g. say if they are only interested in restricted methods but not JNI (seems remote, but adding it here for completeness)

-------------

PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2128837697
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646558424
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646560383

From mcimadamore at openjdk.org  Wed Jun 19 18:00:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 18:00:14 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <F9P-dfpEZodN5n_9jXNTEJMETPoM9p5EFikZq3JPVrU=.3896807b-54bd-4069-8199-b815cfac430a@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <ChzChQyVpNczA8ZU8BJ2EvTJNwzCM18eqDsVFlLeIH4=.2de03818-e44c-4b53-8726-1ef13694570b@github.com>
 <F9P-dfpEZodN5n_9jXNTEJMETPoM9p5EFikZq3JPVrU=.3896807b-54bd-4069-8199-b815cfac430a@github.com>
Message-ID: <LYg_Cc-lIPCkcv9XLqbppd_vlYBKv-9hjLGbEpZtf40=.b732f28c-6902-4c50-ac2b-128e3f899937@github.com>

On Wed, 19 Jun 2024 17:25:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 43:
>> 
>>> 41: import java.util.*;
>>> 42: 
>>> 43: class RestrictedMethodFinder {
>> 
>> The name of this is a bit confusing as this class looks for both restricted methods and JNI decls
>
> True. How about `NativeAccessFinder`?

Good name

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646561469

From jvernee at openjdk.org  Wed Jun 19 18:07:16 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 18:07:16 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <twTRFGvpiWyQwkJHrt2VJFltjJ1FpgKtIUnC9htiKcc=.e2355e07-566a-414e-9168-fe1f9a82f956@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <twTRFGvpiWyQwkJHrt2VJFltjJ1FpgKtIUnC9htiKcc=.e2355e07-566a-414e-9168-fe1f9a82f956@github.com>
Message-ID: <AcXkU10irmAgiCBqCyQgiY9FICqDjl6avUEig4ddx8k=.f45f9895-719e-4787-b04a-3d2f5e2b0263@github.com>

On Wed, 19 Jun 2024 17:53:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java line 126:
> 
>> 124: 
>> 125:         private static Map<String, String> packageToSystemModule() {
>> 126:             List<ModuleDescriptor> descriptors = ModuleFinder.ofSystem()
> 
> Is it a problem that we compute the package -> module map using the runtime info (so latest version) but then all the other info is taken from a release-specific symbol file? E.g. say that package "foo" was moved from module "A" to module "B" in version N, and that user passes N - 1 as release to the scan tool - would that work?

That's a good point, I don't think that scenario will work. We should really use the release specific info if we can. I think that's relatively easy to do, will take a look.

> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 81:
> 
>> 79: 
>> 80:         Map<ScannedModule, Map<ClassDesc, List<RestrictedUse>>> allRestrictedMethods;
>> 81:         try(ClassResolver classesToScan = ClassResolver.forScannedModules(modulesToScan, version);
> 
> Could it make sense here to "chain" the two resolvers into one, and just pass the chained one to the restricted finder?

We need to scan all the classes in the `classesToScan` resolver, but only look for restricted methods in the system resolver. So, they need to stay separate.

> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 165:
> 
>> 163:                     restrictedUses.forEach(use -> {
>> 164:                         switch (use) {
>> 165:                             case RestrictedUse.NativeMethodDecl(MethodRef nmd) ->
> 
> should user be able to filter output using an option? E.g. say if they are only interested in restricted methods but not JNI (seems remote, but adding it here for completeness)

That's a good suggestion, but to pull on that string some more, there's also the possibility of filtering based on class/package/method names. Maybe for a followup?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646564392
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646563349
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646566299

From jvernee at openjdk.org  Wed Jun 19 18:12:10 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 18:12:10 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <b-uhV47r6YU4IekjBDkHgNbOn2piv7Gp1XVA13HPc48=.548adfe8-b62b-4935-a39c-4d9dc13ad23e@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <b-uhV47r6YU4IekjBDkHgNbOn2piv7Gp1XVA13HPc48=.548adfe8-b62b-4935-a39c-4d9dc13ad23e@github.com>
Message-ID: <VAT7EGTOmNBcK9UChr_307pBNIZXOY6tETilDzyEma0=.a837fa43-df6f-48dc-bd36-762f9c9041a5@github.com>

On Wed, 19 Jun 2024 17:28:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 105:
> 
>> 103:         return switch (method) {
>> 104:             case MethodRefEntry mre ->
>> 105:                     isRestrictedMethod(mre.owner().asSymbol(), mre.name().stringValue(), mre.typeSymbol());
> 
> Do we really need these two identical calls to `isRestrictedMethod` ? Note that both `MethodRefEntry` and `InterfaceMethodEntry` are subclasses of `MemberRefEntry`, so perhaps the other `isRestrictedMethod` can just take `MemberRefEntry`?
> 
> Or maybe we can have different factories in `MethodRef` one that takes `InterfaceMethodEntry` and another that takes `MemberRefEntry`.

I can do that, but I think this will always be a bit awkward since these types don't have a common super type that exposes the needed information.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646571620

From mcimadamore at openjdk.org  Wed Jun 19 18:30:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 18:30:10 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods
In-Reply-To: <AcXkU10irmAgiCBqCyQgiY9FICqDjl6avUEig4ddx8k=.f45f9895-719e-4787-b04a-3d2f5e2b0263@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <twTRFGvpiWyQwkJHrt2VJFltjJ1FpgKtIUnC9htiKcc=.e2355e07-566a-414e-9168-fe1f9a82f956@github.com>
 <AcXkU10irmAgiCBqCyQgiY9FICqDjl6avUEig4ddx8k=.f45f9895-719e-4787-b04a-3d2f5e2b0263@github.com>
Message-ID: <kH3ayVsG7hOhgk3AlrYUTZyCFwHDQb-0OxgeyslX29A=.0fe73dd2-9e2c-43ee-bc6d-f2d6ed12115a@github.com>

On Wed, 19 Jun 2024 18:00:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 81:
>> 
>>> 79: 
>>> 80:         Map<ScannedModule, Map<ClassDesc, List<RestrictedUse>>> allRestrictedMethods;
>>> 81:         try(ClassResolver classesToScan = ClassResolver.forScannedModules(modulesToScan, version);
>> 
>> Could it make sense here to "chain" the two resolvers into one, and just pass the chained one to the restricted finder?
>
> We need to scan all the classes in the `classesToScan` resolver, but only look for restricted methods in the system resolver. So, they need to stay separate.

Ah, ok!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646584528

From duke at openjdk.org  Wed Jun 19 18:48:19 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Wed, 19 Jun 2024 18:48:19 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <IiA39tOcrS-pay9AhFx6jpowc6GKB8Xng6nfF9Da_js=.c7e8aea4-70b6-46cc-8e26-8bd2c33f7a2a@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 <NC3E6wpsavqRXUqdgNHh3y26lFSIPXoA0yi
 KcV_2CyI=.391c9553-458a-417f-b86d-2c88dacf7df1@github.com>
 <Kc8tP6_hlFmF_NqcwSHEX6NF9atmoeglRsRFTrLaA5A=.bacb4a7d-26cb-4fdc-8f7b-f883587cd58c@github.com>
 <xrA2rqmjQ-gHGaZ23SQIYZCgda6sHslW2oHIqQxyM2Y=.f4ae4438-78b0-4eb1-b4aa-ed461c31ef1f@github.com>
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
 <hSP68W3vGCfGCOlUCf84DDw0qzt9Z7d-56LKLALocYo=.6c507f84-037d-449f-b4f6-f8c9771e6409@github.com>
 <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@github.com>
 <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>
 <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
 <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>
 <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>
 <z094CbYeWxVsMZ8s2_54mVC8fD_p67gSGyJxeiTZuVE=.78b39116-a5ad-4f03-ac15-7e3a09dc180e@
 github.com>
 <jd32y3QbyVdNJ3WX995GiSj6RbrVjiK9mpk9SruJDfY=.40eb6b15-8b11-4387-8fab-d95c70fed1da@github.com>
 <Gyn-uB7iXtaX4BK8wuLqzafphTfNbJLy2n5a41RShsI=.7f279eb8-fb29-4003-9f49-84061def1e3a@github.com>
 <IiA39tOcrS-pay9AhFx6jpowc6GKB8Xng6nfF9Da_js=.c7e8aea4-70b6-46cc-8e26-8bd2c33f7a2a@github.com>
Message-ID: <QIuNxdP5Q_MYmKZOYiHvLJYfEphkPn43FCOUvP4Mx9c=.a7b81f58-f14d-468e-93e3-9aff017cc67b@github.com>

On Fri, 10 May 2024 22:08:47 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Could you please run the new benchmarking to finalize the best version?
>> What you need is to compile and run JavaBenchmarkHarness:
>> 
>> javac --patch-module java.base=. -d classes *.java
>> java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness
>> 
>> Find the sources there:
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_11.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_11a.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_12.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_12a.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java
>> 
>> Thank you,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> Please see the data below.
> 
> Thanks,
> Vamsi
> 
> 
> name | builder | size | mode | count | score
> -- | -- | -- | -- | -- | --
> b01 | RANDOM | 600 | avg | 325677 | 6.861
> b01 | RANDOM | 3000 | avg | 52041 | 77.313
> b01 | RANDOM | 90000 | avg | 1217 | 4315.41
> b01 | RANDOM | 400000 | avg | 242 | 22110.95
> b01 | RANDOM | 1000000 | avg | 90 | 58613.45
> b01 | REPEATED | 600 | avg | 651354 | 1.993
> b01 | REPEATED | 3000 | avg | 104083 | 13.026
> b01 | REPEATED | 90000 | avg | 2435 | 741.97
> b01 | REPEATED | 400000 | avg | 484 | 3161.073
> b01 | REPEATED | 1000000 | avg | 180 | 8363.671
> b01 | STAGGER | 600 | avg | 1954062 | 9.124
> b01 | STAGGER | 3000 | avg | 312251 | 10.026
> b01 | STAGGER | 90000 | avg | 7305 | 286.313
> b01 | STAGGER | 400000 | avg | 1453 | 1278.758
> b01 | STAGGER | 1000000 | avg | 542 | 3242.849
> b01 | SHUFFLE | 600 | avg | 325677 | 5.113
> b01 | SHUFFLE | 3000 | avg | 52041 | 28.85
> b01 | SHUFFLE | 90000 | avg | 1217 | 1368.91
> b01 | SHUFFLE | 400000 | avg | 242 | 5718.052
> b01 | SHUFFLE | 1000000 | avg | 90 | 15376.1
> r31_11 | RANDOM | 600 | avg | 325677 | 4.305
> r31_11 | RANDOM | 3000 | avg | 52041 | 73.399
> r31_11 | RANDOM | 90000 | avg | 1217 | 3963.515
> r31_11 | RANDOM | 400000 | avg | 242 | 19841.07
> r31_11 | RANDOM | 1000000 | avg | 90 | 53372.63
> r31_11 | REPEATED | 600 | avg | 651354 | 1.208
> r31_11 | REPEATED | 3000 | avg | 104083 | 6.206
> r31_11 | REPEATED | 90000 | avg | 2435 | 614.159
> r31_11 | REPEATED | 400000 | avg | 484 | 2615.923
> r31_11 | REPEATED | 1000000 | avg | 180 | 6553.801
> r31_11 | STAGGER | 600 | avg | 1954062 | 1.023
> r31_11 | STAGGER | 3000 | avg | 312251 | 4.406
> r31_11 | STAGGER | 90000 | avg | 7305 | 129.76
> r31_11 | STAGGER | 400000 | avg | 1453 | 600.581
> r31_11 | STAGGER | 1000000 | avg | 542 | 1588.827
> r31_11 | SHUFFLE | 600 | avg | 325677 | 2.887
> r31_11 | SHUFFLE | 3000 | avg | 52041 | 17.901
> r31_11 | SHUFFLE | 90000 | avg | 1217 | 1033.808
> r31_11 | SHUFFLE | 400000 | avg | 242 | 4686.188
> r31_11 | SHUFFLE | 1000000 | avg | 90 | 11589.67
> r31_11a | RANDOM | 600 | avg | 325677 | 4.277
> r31_11a | RANDOM | 3000 | avg | 52041 | 70.578
> r31_11a | RANDOM | 90000 | avg | 1217 | 3963.836
> r31_11a | RANDOM | 400000 | avg | 242 | 19771.67
> r31_11a | RANDOM | 1000000 | avg | 90 | 53417.95
> r31_11a | REPEATED | 600 | avg | 651354 | 1.112
> r31_11a | REPEATED | 3000 | avg | 104083 | 5.662
> r31_11a | REPEATED | 90000 | avg | 2435 | 596.963
> r31_11a | REPEATED | 400000 | avg | 484 | 2618.076
> r31_11a | REPEATED | 1000000 | avg | 180 | 6597.833
> r31_1...

Hello Vamsi (@vamsi-parasa),

Could you please run the new benchmarking to check sorting of all data types?
What you need is to compile and run JavaBenchmarkHarness:

javac --patch-module java.base=. -d classes *.java
java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness

Find the sources there:

https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r32.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java

Thank you,
Vladimir

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2179307223

From jvernee at openjdk.org  Wed Jun 19 19:00:22 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 19:00:22 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v2]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <ugZemJ32HxiQLQRjB5rhQVJ7fnKmzrmAJc_TCzU_SG0=.07546402-0265-4aa2-b06c-3b649756f9b1@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/9e8dad03..861965b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From jvernee at openjdk.org  Wed Jun 19 19:00:23 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 19:00:23 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v2]
In-Reply-To: <VAT7EGTOmNBcK9UChr_307pBNIZXOY6tETilDzyEma0=.a837fa43-df6f-48dc-bd36-762f9c9041a5@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <b-uhV47r6YU4IekjBDkHgNbOn2piv7Gp1XVA13HPc48=.548adfe8-b62b-4935-a39c-4d9dc13ad23e@github.com>
 <VAT7EGTOmNBcK9UChr_307pBNIZXOY6tETilDzyEma0=.a837fa43-df6f-48dc-bd36-762f9c9041a5@github.com>
Message-ID: <D14r1J_wbnoqUrpz4CrRY-RRj_SxmJDbm5Nf3Q2TyLY=.2c84988f-28bd-45eb-afa1-f7bde285f18a@github.com>

On Wed, 19 Jun 2024 18:09:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> these types don't have a common super type that exposes the needed information

No wait, they actually do :) That's just `MemberRefEntry`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646604479

From jvernee at openjdk.org  Wed Jun 19 19:04:12 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 19:04:12 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v2]
In-Reply-To: <KNsQIZsg6ziCB3ZS9SUpUOOi7-tAkfjdTcPJ6Jok3cM=.7aa7b1c4-1ff5-4c34-a4ee-0cf9599f357e@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <b-uhV47r6YU4IekjBDkHgNbOn2piv7Gp1XVA13HPc48=.548adfe8-b62b-4935-a39c-4d9dc13ad23e@github.com>
 <KNsQIZsg6ziCB3ZS9SUpUOOi7-tAkfjdTcPJ6Jok3cM=.7aa7b1c4-1ff5-4c34-a4ee-0cf9599f357e@github.com>
Message-ID: <qpqxjHGcNGA0ph0u6ohXpeoI0ZPu5Qe235pFerQpOdY=.a2d2cf8c-4840-4490-aea7-24ae4018b455@github.com>

On Wed, 19 Jun 2024 17:45:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 120:
>> 
>>> 118:             Optional<ClassResolver.Info> info = systemClassResolver.lookup(methodRef.owner());
>>> 119:             if (!info.isPresent()) {
>>> 120:                 return false;
>> 
>> Is this just `false` or maybe a warning that a certain owner could not be resolved (maybe if running with enough debug options) ?
>
> Yes, thought about that yesterday as well. Good catch

Thinking a bit more: we also use the optional being empty to know if the owner is not a system class, so I think this code here is what we want. We can however throw an exception if a class is not found in `SystemClassResolver::lookup`. Since, if a class is inside a system module package, it should be found as well (unless the user sets the release to the wrong version).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646606901

From sgehwolf at openjdk.org  Wed Jun 19 19:09:17 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 19 Jun 2024 19:09:17 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v11]
In-Reply-To: <ulK8y4gzGQO2lQ48R44-Z6mNu94p5LOx6Y0NLEnCfa8=.5f8693c8-e29b-410a-94d8-38d55e88e4a8@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <ulK8y4gzGQO2lQ48R44-Z6mNu94p5LOx6Y0NLEnCfa8=.5f8693c8-e29b-410a-94d8-38d55e88e4a8@github.com>
Message-ID: <0XLnf6PMwHUMBeEKQilahZovLPC3bbTnDCWo8sJ-bhU=.c9ef8ef6-e7b9-4231-8a9a-bb8c03065c77@github.com>

On Wed, 22 May 2024 15:02:18 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 74 commits:
> 
>  - .
>  - .
>  - Merge branch 'jdk-8331560-cgroup-controller-delegation-merge-diamond' into jdk-8331560-cgroup-controller-delegation-merge-cgroup
>  - diamond
>  - Merge branch 'jerboaarefactor-merge-cgroup' into jdk-8331560-cgroup-controller-delegation-merge-cgroup
>  - Merge branch 'jerboaarefactor-merge' into jerboaarefactor-merge-cgroup
>  - Merge branch 'master' into jerboaarefactor-merge
>  - whitespace fix
>  - centos7 compat
>  - 64a5feb6: <no commit message found>
>  - ... and 64 more: https://git.openjdk.org/jdk/compare/3d511ff6...25c0287d

Keep open.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2179330671

From rotanolexandr842 at gmail.com  Wed Jun 19 19:43:17 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Wed, 19 Jun 2024 22:43:17 +0300
Subject: java.time lacks start and end aware period data types
Message-ID: <CAL5bRt8N4NfQLqDvKUWPmV3_gCDggaWt6PD+=fK-mqJ3KZea4A@mail.gmail.com>

Greetings to the Java community. I have a question regarding the design of
java,time package.

Commercial Java developers deal with time periods all the time with
different validations regarding intersection of periods, big data
processing, entity auditing etc etc. And it is surprising for everyone to
look into java.time for the first time and find out that there is no start
and end aware span data types at all!

There is no rocket science in implementing such data types yourself, that's
for sure. However, as always, there are hidden spikes in these waters.To
use these types in JPA entities, you would have to write a custom converter
to familiar for database type, which ties project tightly to
database, which is contrary to what JPA was intended for . To use it in
auditing. one would have to write a custom auditor as no framework or
library knows about our custom data type. Same goes for big data
processing: no library or framework would support processing series of your
custom data type, at least unless you provide some adapter using library
mechanisms, if those exist at all. This rant could go on and on, but the
points are:

1) Lack of standardization for such data types leads to obstacles on each
step of development: constant writing of adapters, converters and blah blah
blah. Each of those serves as a space to make mistakes. One-two easy
implementations are not likely to be the source of errors, but the more a
project grows, the more dependencies it acquires, the more it is likely to
fall for some subtle specific feature of some library and spend hours or
even days debugging.
2) One could rightfully argue that for small projects or microservice
projects with no shared codebase and different team for each service, this
whole mess I described above is overengineering. Seriously, not everyone
would want to go through all of that for one-two usages of class in the
domain layer of the project, and, moreover, not everyone should. However,
leaving it be "as is" is a screaming source of data inconsistencies, as it
is now responsibility of developer (or even worse, user) to keep in mind
the requirement to update all fields, that combined form that start- and
end-aware period (like start date/datetime and Period/Duration as common
way to emulate such thing)

So, the question is: was it a conscious decision to omit such types back in
the day when java.time was designed, or is it a blindspot created by
deadlines/lack of resources/something else?

Would appreciate anything some of you have to share on this topic.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240619/678fd7ed/attachment.htm>

From jvernee at openjdk.org  Wed Jun 19 20:02:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 20:02:11 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v2]
In-Reply-To: <wN7MphwgpmzUS7Iu2EByjTzJ3YfNpLKJEUqE9c1LBgo=.3c9180e1-a791-47bf-a1d9-006a45c9cf29@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <wN7MphwgpmzUS7Iu2EByjTzJ3YfNpLKJEUqE9c1LBgo=.3c9180e1-a791-47bf-a1d9-006a45c9cf29@github.com>
Message-ID: <D_MQ4c6s7n1qldn9CHeYZKfHaUgGclpU6murkDtsjuY=.dff9a39b-9db8-4ebb-b10f-4c0e36cea555@github.com>

On Wed, 19 Jun 2024 17:41:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
>>   
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 76:
> 
>> 74:             URI location = m.reference().location().orElseThrow();
>> 75:             Path path = Path.of(location);
>> 76:             checkRegularJar(path);
> 
> if exploded modules aren't supported (as discussed offline), maybe the error message generated here should be more specific?

What do you suggest? Just a note in the error message that exploded modules/class paths are not supported?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646643125

From scolebourne at joda.org  Wed Jun 19 20:29:21 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 19 Jun 2024 21:29:21 +0100
Subject: java.time lacks start and end aware period data types
In-Reply-To: <CAL5bRt8N4NfQLqDvKUWPmV3_gCDggaWt6PD+=fK-mqJ3KZea4A@mail.gmail.com>
References: <CAL5bRt8N4NfQLqDvKUWPmV3_gCDggaWt6PD+=fK-mqJ3KZea4A@mail.gmail.com>
Message-ID: <CACzrW9CDta2PWHvNL9iJZd6DPcLOtZri5P1tBbH+xtoUdjXvPw@mail.gmail.com>

There are a variety of ways that a range of the timeline can be defined.
And some would argue that Java should have a general purpose Range class to
cover all Comparable classes rather than a few specific ones for Java time.

Ultimately, Java time chose to avoid the issues by not addressing the
design space. There were plenty of other things to tackle at the time.

BTW, see ThreeTen-Extra for some range and interval classes.

Stephen



On Wed, 19 Jun 2024, 20:44 Olexandr Rotan, <rotanolexandr842 at gmail.com>
wrote:

> Greetings to the Java community. I have a question regarding the design of
> java,time package.
>
> Commercial Java developers deal with time periods all the time with
> different validations regarding intersection of periods, big data
> processing, entity auditing etc etc. And it is surprising for everyone to
> look into java.time for the first time and find out that there is no start
> and end aware span data types at all!
>
> There is no rocket science in implementing such data types yourself,
> that's for sure. However, as always, there are hidden spikes in these
> waters.To use these types in JPA entities, you would have to write a custom
> converter to familiar for database type, which ties project tightly to
> database, which is contrary to what JPA was intended for . To use it in
> auditing. one would have to write a custom auditor as no framework or
> library knows about our custom data type. Same goes for big data
> processing: no library or framework would support processing series of your
> custom data type, at least unless you provide some adapter using library
> mechanisms, if those exist at all. This rant could go on and on, but the
> points are:
>
> 1) Lack of standardization for such data types leads to obstacles on each
> step of development: constant writing of adapters, converters and blah blah
> blah. Each of those serves as a space to make mistakes. One-two easy
> implementations are not likely to be the source of errors, but the more a
> project grows, the more dependencies it acquires, the more it is likely to
> fall for some subtle specific feature of some library and spend hours or
> even days debugging.
> 2) One could rightfully argue that for small projects or microservice
> projects with no shared codebase and different team for each service, this
> whole mess I described above is overengineering. Seriously, not everyone
> would want to go through all of that for one-two usages of class in the
> domain layer of the project, and, moreover, not everyone should. However,
> leaving it be "as is" is a screaming source of data inconsistencies, as it
> is now responsibility of developer (or even worse, user) to keep in mind
> the requirement to update all fields, that combined form that start- and
> end-aware period (like start date/datetime and Period/Duration as common
> way to emulate such thing)
>
> So, the question is: was it a conscious decision to omit such types back
> in the day when java.time was designed, or is it a blindspot created by
> deadlines/lack of resources/something else?
>
> Would appreciate anything some of you have to share on this topic.
>
> Best regards
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240619/24f1ac29/attachment.htm>

From rotanolexandr842 at gmail.com  Wed Jun 19 21:12:43 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 20 Jun 2024 00:12:43 +0300
Subject: java.time lacks start and end aware period data types
In-Reply-To: <CACzrW9CDta2PWHvNL9iJZd6DPcLOtZri5P1tBbH+xtoUdjXvPw@mail.gmail.com>
References: <CAL5bRt8N4NfQLqDvKUWPmV3_gCDggaWt6PD+=fK-mqJ3KZea4A@mail.gmail.com>
 <CACzrW9CDta2PWHvNL9iJZd6DPcLOtZri5P1tBbH+xtoUdjXvPw@mail.gmail.com>
Message-ID: <CAL5bRt_3Mh6ztifK+NBxi2YtsUzvUowdXLVrp=_95ts-s+V5_A@mail.gmail.com>

I am aware of  ThreeTen-Extra. The issue with this library is that it lacks
native transition to java.time types, java.time hierarchy is closed and
therefore there is no in-all-ways complete way to integrate it in a project
without seams all over the place.

The issue with ranges and comparables is the fact that it is impossible to
implement multiple interfaces with different type parameters. This leads to
an issue, that, for example, Range<BigDecimal> cant be used against
BigInteger, Float, Long etc etc. This is why, I think, this idea in current
Java is inherently bad.

So, to summarize, the main reason why there is no such types in java.time
is the fact that there just were tasks with higher priorities at the
moment. If so, I might do some research and draft some APIs myself and
present it to the Java team to determine whether it is ok or not to
continue development in this direction or not.



On Wed, Jun 19, 2024 at 11:29?PM Stephen Colebourne <scolebourne at joda.org>
wrote:

> There are a variety of ways that a range of the timeline can be defined.
> And some would argue that Java should have a general purpose Range class to
> cover all Comparable classes rather than a few specific ones for Java time.
>
> Ultimately, Java time chose to avoid the issues by not addressing the
> design space. There were plenty of other things to tackle at the time.
>
> BTW, see ThreeTen-Extra for some range and interval classes.
>
> Stephen
>
>
>
> On Wed, 19 Jun 2024, 20:44 Olexandr Rotan, <rotanolexandr842 at gmail.com>
> wrote:
>
>> Greetings to the Java community. I have a question regarding the design
>> of java,time package.
>>
>> Commercial Java developers deal with time periods all the time with
>> different validations regarding intersection of periods, big data
>> processing, entity auditing etc etc. And it is surprising for everyone to
>> look into java.time for the first time and find out that there is no start
>> and end aware span data types at all!
>>
>> There is no rocket science in implementing such data types yourself,
>> that's for sure. However, as always, there are hidden spikes in these
>> waters.To use these types in JPA entities, you would have to write a custom
>> converter to familiar for database type, which ties project tightly to
>> database, which is contrary to what JPA was intended for . To use it in
>> auditing. one would have to write a custom auditor as no framework or
>> library knows about our custom data type. Same goes for big data
>> processing: no library or framework would support processing series of your
>> custom data type, at least unless you provide some adapter using library
>> mechanisms, if those exist at all. This rant could go on and on, but the
>> points are:
>>
>> 1) Lack of standardization for such data types leads to obstacles on each
>> step of development: constant writing of adapters, converters and blah blah
>> blah. Each of those serves as a space to make mistakes. One-two easy
>> implementations are not likely to be the source of errors, but the more a
>> project grows, the more dependencies it acquires, the more it is likely to
>> fall for some subtle specific feature of some library and spend hours or
>> even days debugging.
>> 2) One could rightfully argue that for small projects or microservice
>> projects with no shared codebase and different team for each service, this
>> whole mess I described above is overengineering. Seriously, not everyone
>> would want to go through all of that for one-two usages of class in the
>> domain layer of the project, and, moreover, not everyone should. However,
>> leaving it be "as is" is a screaming source of data inconsistencies, as it
>> is now responsibility of developer (or even worse, user) to keep in mind
>> the requirement to update all fields, that combined form that start- and
>> end-aware period (like start date/datetime and Period/Duration as common
>> way to emulate such thing)
>>
>> So, the question is: was it a conscious decision to omit such types back
>> in the day when java.time was designed, or is it a blindspot created by
>> deadlines/lack of resources/something else?
>>
>> Would appreciate anything some of you have to share on this topic.
>>
>> Best regards
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240620/05ce20a3/attachment.htm>

From jvernee at openjdk.org  Wed Jun 19 21:16:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 21:16:46 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - review comments
 - add man page

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/861965b7..b5468440

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=01-02

  Stats: 645 lines in 10 files changed: 467 ins; 155 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From jvernee at openjdk.org  Wed Jun 19 21:16:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 21:16:46 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v2]
In-Reply-To: <ugZemJ32HxiQLQRjB5rhQVJ7fnKmzrmAJc_TCzU_SG0=.07546402-0265-4aa2-b06c-3b649756f9b1@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <ugZemJ32HxiQLQRjB5rhQVJ7fnKmzrmAJc_TCzU_SG0=.07546402-0265-4aa2-b06c-3b649756f9b1@github.com>
Message-ID: <Bq3Po3jZcLeT5aYmDL4zBetXItqnZJkdUK7Q8K8w83s=.b70ce7d1-7c92-4813-8c40-a655ba40dc5f@github.com>

On Wed, 19 Jun 2024 19:00:22 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

I've also added a first version of the man page for the tool. I'm not every familiar with the JDK man pages, as I rarely use them myself, so there's probably things missing. Please let me know.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2179460047

From jvernee at openjdk.org  Wed Jun 19 21:16:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 21:16:46 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <AcXkU10irmAgiCBqCyQgiY9FICqDjl6avUEig4ddx8k=.f45f9895-719e-4787-b04a-3d2f5e2b0263@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <twTRFGvpiWyQwkJHrt2VJFltjJ1FpgKtIUnC9htiKcc=.e2355e07-566a-414e-9168-fe1f9a82f956@github.com>
 <AcXkU10irmAgiCBqCyQgiY9FICqDjl6avUEig4ddx8k=.f45f9895-719e-4787-b04a-3d2f5e2b0263@github.com>
Message-ID: <6FezoYQtEi_zkMimW3LvyNOoeL05xC7GucK_eyu9w8s=.1136bc45-f143-40b8-97e3-7080f168256a@github.com>

On Wed, 19 Jun 2024 18:02:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java line 126:
>> 
>>> 124: 
>>> 125:         private static Map<String, String> packageToSystemModule() {
>>> 126:             List<ModuleDescriptor> descriptors = ModuleFinder.ofSystem()
>> 
>> Is it a problem that we compute the package -> module map using the runtime info (so latest version) but then all the other info is taken from a release-specific symbol file? E.g. say that package "foo" was moved from module "A" to module "B" in version N, and that user passes N - 1 as release to the scan tool - would that work?
>
> That's a good point, I don't think that scenario will work. We should really use the release specific info if we can. I think that's relatively easy to do, will take a look.

Ok, I managed to implement this, but I don't think we can actually test this use case, since (AFAIK) there's never been a case of a package being moved to a different module under the same name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646688656

From mcimadamore at openjdk.org  Wed Jun 19 21:16:46 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 21:16:46 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <D_MQ4c6s7n1qldn9CHeYZKfHaUgGclpU6murkDtsjuY=.dff9a39b-9db8-4ebb-b10f-4c0e36cea555@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <wN7MphwgpmzUS7Iu2EByjTzJ3YfNpLKJEUqE9c1LBgo=.3c9180e1-a791-47bf-a1d9-006a45c9cf29@github.com>
 <D_MQ4c6s7n1qldn9CHeYZKfHaUgGclpU6murkDtsjuY=.dff9a39b-9db8-4ebb-b10f-4c0e36cea555@github.com>
Message-ID: <2r8s2SU2XAXtfb8KUesb8VMMc80KPrvhWSCxJQmFXQY=.a2fad386-3ace-4ef0-badf-23f8ef2f88b2@github.com>

On Wed, 19 Jun 2024 19:59:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 76:
>> 
>>> 74:             URI location = m.reference().location().orElseThrow();
>>> 75:             Path path = Path.of(location);
>>> 76:             checkRegularJar(path);
>> 
>> if exploded modules aren't supported (as discussed offline), maybe the error message generated here should be more specific?
>
> What do you suggest? Just a note in the error message that exploded modules/class paths are not supported?

Something like that yes

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646692395

From jvernee at openjdk.org  Wed Jun 19 21:16:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 21:16:46 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
Message-ID: <6W3bKkLC6Y1m8fLZunLX-dD-ZWyKBOY-O5F6QPq3rTI=.93d48385-70a5-4115-9ecf-3fabaf7e84e3@github.com>

On Wed, 19 Jun 2024 21:13:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review comments
>  - add man page

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 89:

> 87:                              throw new JNativeScanFatalError("Error while processing method: " +
> 88:                                      MethodRef.ofModel(methodModel), e);
> 89:                          }

I'm re-wrapping the exception here, thrown from `SystemClassResolver::lookup`, in order to include the method that called the missing system class in the error message as well. (See also the code added in `Main` to print out an exception cause if it is a `JNativeScanFatalError`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646689741

From jvernee at openjdk.org  Wed Jun 19 21:16:47 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Jun 2024 21:16:47 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <D14r1J_wbnoqUrpz4CrRY-RRj_SxmJDbm5Nf3Q2TyLY=.2c84988f-28bd-45eb-afa1-f7bde285f18a@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <b-uhV47r6YU4IekjBDkHgNbOn2piv7Gp1XVA13HPc48=.548adfe8-b62b-4935-a39c-4d9dc13ad23e@github.com>
 <VAT7EGTOmNBcK9UChr_307pBNIZXOY6tETilDzyEma0=.a837fa43-df6f-48dc-bd36-762f9c9041a5@github.com>
 <D14r1J_wbnoqUrpz4CrRY-RRj_SxmJDbm5Nf3Q2TyLY=.2c84988f-28bd-45eb-afa1-f7bde285f18a@github.com>
Message-ID: <xN1B1cJfAORjIveXerz5ufcIpY7pOTNA9p0hCskYMRo=.abc6ed86-3611-4129-bc0d-993a71061a99@github.com>

On Wed, 19 Jun 2024 18:57:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I can do that, but I think this will always be a bit awkward since these types don't have a common super type that exposes the needed information.
>
>> these types don't have a common super type that exposes the needed information
> 
> No wait, they actually do :) That's just `MemberRefEntry`.

I was able to eliminate this method entirely, now the caller just creates a `MethodRef` and passes that to the other `isRestrictedMethod` overload.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646691228

From duke at openjdk.org  Wed Jun 19 21:28:18 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 19 Jun 2024 21:28:18 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v11]
In-Reply-To: <rDMLLPxeeoJPZ-H2RfLOIvtIC-zAAyOO_IEL8sST-2c=.1bfddcef-51b9-402f-a7be-ca90587782e5@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <rDMLLPxeeoJPZ-H2RfLOIvtIC-zAAyOO_IEL8sST-2c=.1bfddcef-51b9-402f-a7be-ca90587782e5@github.com>
Message-ID: <OuujJDFPrBy0qne269EzN352pu-QM2Sj8bjFqRvW53o=.f6f09bdc-974e-4255-bb2f-beb136db44c5@github.com>

On Wed, 19 Jun 2024 12:04:27 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix: fix comments

Formatting?nits:

More?formatting?nits:

test/jdk/java/lang/invoke/indify/Indify.java line 656:

> 654:             for(PoolEntry entry : classModel.constantPool()){
> 655:                 char mark = 0;
> 656:                 if(poolMarks[entry.index()] != 0) continue;

Suggestion:

        boolean initializeMarks() {
            boolean anyMarkChanged = false;
            for (PoolEntry entry : classModel.constantPool()) {
                char mark = 0;
                if (poolMarks[entry.index()] != 0) continue;

test/jdk/java/lang/invoke/indify/Indify.java line 674:

> 672:                     if(poolMarks[memberRefEntry.owner().index()] != 0){
> 673:                         mark = poolMarks[memberRefEntry.owner().index()];
> 674:                     }

Suggestion:

                if (entry instanceof Utf8Entry utf8Entry) {
                    mark = nameMark(utf8Entry.stringValue());
                }
                if (entry instanceof ClassEntry classEntry) {
                    mark = nameMark(classEntry.asInternalName());
                }
                if (entry instanceof StringEntry stringEntry) {
                    mark = nameMark(stringEntry.stringValue());
                }
                if (entry instanceof NameAndTypeEntry nameAndTypeEntry) {
                    mark = nameAndTypeMark(nameAndTypeEntry.name(), nameAndTypeEntry.type());
                }
                if (entry instanceof MemberRefEntry memberRefEntry) {
                    poolMarks[memberRefEntry.owner().index()] = nameMark(memberRefEntry.owner().asInternalName());
                    if(poolMarks[memberRefEntry.owner().index()] != 0){
                        mark = poolMarks[memberRefEntry.owner().index()];
                    }

test/jdk/java/lang/invoke/indify/Indify.java line 678:

> 676:                         if(memberRefEntry.owner().equals(classModel.thisClass())){
> 677:                             mark = nameMark(memberRefEntry.name().stringValue());
> 678:                         }

Suggestion:

                    else {
                        if (memberRefEntry.owner().equals(classModel.thisClass())) {
                            mark = nameMark(memberRefEntry.name().stringValue());
                        }

test/jdk/java/lang/invoke/indify/Indify.java line 686:

> 684:             return anyMarkChanged;
> 685:         }
> 686:         char nameAndTypeMark(Utf8Entry name, Utf8Entry type){

Suggestion:

        }

        char nameAndTypeMark(Utf8Entry name, Utf8Entry type){

test/jdk/java/lang/invoke/indify/Indify.java line 691:

> 689:             String descriptor = type.stringValue();
> 690:             String requiredType;
> 691:             switch (mark){

Suggestion:

            switch (mark) {

test/jdk/java/lang/invoke/indify/Indify.java line 696:

> 694:                 default:  return 0;
> 695:             }
> 696:             if(matchType(descriptor, requiredType)) return mark;

Suggestion:

            if (matchType(descriptor, requiredType)) return mark;

-------------

PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2129054394
PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2129056939
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1646696601
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1646697107
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1646697252
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1646698327
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1646698374
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1646698432

From mcimadamore at openjdk.org  Wed Jun 19 21:38:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 21:38:14 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
Message-ID: <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>

On Wed, 19 Jun 2024 21:16:46 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review comments
>  - add man page

Nice changes!

src/jdk.jdeps/share/man/jnativescan.1 line 43:

> 41: .PP
> 42: jnativescan - static analysis tool that scans one or more jar files for
> 43: uses of native functionality, such as restricted methods or

I think using `functionalities` would be better. Also "restricted method **calls** works better too (so it's restricted method **calls** and native method **declarations.

src/jdk.jdeps/share/man/jnativescan.1 line 55:

> 53: The \f[V]jnative\f[R] tool is a static analysis tool provided by the JDK
> 54: that scans a JAR file for uses of native functionality, such as
> 55: restricted methods or \f[V]native\f[R] method declarations.

Same comments as above

src/jdk.jdeps/share/man/jnativescan.1 line 60:

> 58: configuration, as well as a set of root modules, and a target release.
> 59: It scans the jars on the class and module paths, and reports uses of
> 60: native functionality either in a tree like structure, which also

functionalities

src/jdk.jdeps/share/man/jnativescan.1 line 68:

> 66: .TP
> 67: \f[V]--class-path\f[R] \f[I]path\f[R]
> 68: Used to specify a path list of class path jar files to be scanned.

I can't parse "path list of class path jar files". What is the argument here? I think it has to be a list of jars? If so, one way could be  `a list of paths pointing to the jar files to be scanned`

src/jdk.jdeps/share/man/jnativescan.1 line 76:

> 74: .TP
> 75: \f[V]--module-path\f[R] \f[I]path\f[R]
> 76: Used to specify a path list of jar files or directories containing

This is also hard to read. Perhaps `a list of paths pointing to the jar files to be scanned, or the directories containing said jar files.`

src/jdk.jdeps/share/man/jnativescan.1 line 112:

> 110: Used to specifiy a comma-separated list of module names that indicate
> 111: the root modules to scan.
> 112: All the modules in the root set will be scanned, as well as any modules

Suggestion:

All the root modules will be scanned, as well as any modules

src/jdk.jdeps/share/man/jnativescan.1 line 121:

> 119: .TP
> 120: \f[V]--release\f[R] \f[I]version\f[R]
> 121: Used to specify the Java SE release that specifies the set of restricted

In principle, the release could also affect which methods are native or not?

src/jdk.jdeps/share/man/jnativescan.1 line 127:

> 125: This option should be set to the version of the runtime under which the
> 126: application is eventually intended to be run.
> 127: If this flag is omitted, the version of \f[V]jnativescan\f[R] is used as

Maybe we should point to `Runtime.version()` instead?

src/jdk.jdeps/share/man/jnativescan.1 line 146:

> 144: For the class path, the tool will scan all jar files, including those
> 145: found recursively through the \f[V]Class-Path\f[R] manifest attribute.
> 146: For the module path, the tool scans all modules in the root module set

Note: sometimes you say root modules, sometimes root module set. I'd suggest to pick one and remain consistent.

src/jdk.jdeps/share/man/jnativescan.1 line 166:

> 164: .fi
> 165: .PP
> 166: \f[V]app.jar (ALL-UNNAMED)\f[R] is the path to the jar file, with the

This is a good explanation, I'm not sure whether it's necessary, as the output seems quite self-explanatory. But I'm ok either way.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2129052320
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646696108
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646696214
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646696446
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646696855
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646697366
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646702494
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646703008
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646703573
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646704113
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646704937

From mcimadamore at openjdk.org  Wed Jun 19 21:38:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jun 2024 21:38:15 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
 <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>
Message-ID: <EKffGkzcF04XTY1oTH3QYgntDAvQiDZNvJ8hY3GrM6E=.c80bb89a-6b91-46ae-82d4-b9bf5a01a48f@github.com>

On Wed, 19 Jun 2024 21:22:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comments
>>  - add man page
>
> src/jdk.jdeps/share/man/jnativescan.1 line 68:
> 
>> 66: .TP
>> 67: \f[V]--class-path\f[R] \f[I]path\f[R]
>> 68: Used to specify a path list of class path jar files to be scanned.
> 
> I can't parse "path list of class path jar files". What is the argument here? I think it has to be a list of jars? If so, one way could be  `a list of paths pointing to the jar files to be scanned`

My suggestion is to separate up the "what is this argument?" (is a list of paths, to jar files), from the "semantics" (e.g. the classes in the jarfiles are assumed to belong to the unnamed module). The you can mirror this structure in the module option.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646700042

From darcy at openjdk.org  Wed Jun 19 23:26:12 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 19 Jun 2024 23:26:12 GMT
Subject: Integrated: 8309821: Link to hidden classes section in Class
 specification for Class::isHidden
In-Reply-To: <8JgEAcTlHALr5L95oTy7qLu7PygLVCslSYrSHI0NFFE=.c114ffe4-3074-498c-af23-6a9f715c83f0@github.com>
References: <8JgEAcTlHALr5L95oTy7qLu7PygLVCslSYrSHI0NFFE=.c114ffe4-3074-498c-af23-6a9f715c83f0@github.com>
Message-ID: <q9G4N8Y6ZzRx9x3Zphva7cNrQ04W8MZ7hTUw085-EnE=.5e6aaff8-6578-4c76-8b09-fc1fd52107ed@github.com>

On Wed, 19 Jun 2024 02:21:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple doc improvement.

This pull request has now been integrated.

Changeset: 4e58d8c8
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e58d8c897d845cfa73780264481da174d46acb4
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8309821: Link to hidden classes section in Class specification for Class::isHidden

Reviewed-by: iris, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/19781

From rotanolexandr842 at gmail.com  Thu Jun 20 00:36:16 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 20 Jun 2024 03:36:16 +0300
Subject: java.time lacks start and end aware period data types
In-Reply-To: <CAL5bRt_3Mh6ztifK+NBxi2YtsUzvUowdXLVrp=_95ts-s+V5_A@mail.gmail.com>
References: <CAL5bRt8N4NfQLqDvKUWPmV3_gCDggaWt6PD+=fK-mqJ3KZea4A@mail.gmail.com>
 <CACzrW9CDta2PWHvNL9iJZd6DPcLOtZri5P1tBbH+xtoUdjXvPw@mail.gmail.com>
 <CAL5bRt_3Mh6ztifK+NBxi2YtsUzvUowdXLVrp=_95ts-s+V5_A@mail.gmail.com>
Message-ID: <CAL5bRt9gPB+zYt4ViLd+Ur8RiiQSJ0uX2RPDSqi_ENVSHY0Yxw@mail.gmail.com>

Sorry to send as follow up, those "to summarize" sentence is a question,
not a statement. Sorry for possible confusion

On Thu, Jun 20, 2024, 00:12 Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> I am aware of  ThreeTen-Extra. The issue with this library is that it
> lacks native transition to java.time types, java.time hierarchy is closed
> and therefore there is no in-all-ways complete way to integrate it in a
> project without seams all over the place.
>
> The issue with ranges and comparables is the fact that it is impossible to
> implement multiple interfaces with different type parameters. This leads to
> an issue, that, for example, Range<BigDecimal> cant be used against
> BigInteger, Float, Long etc etc. This is why, I think, this idea in current
> Java is inherently bad.
>
> So, to summarize, the main reason why there is no such types in java.time
> is the fact that there just were tasks with higher priorities at the
> moment. If so, I might do some research and draft some APIs myself and
> present it to the Java team to determine whether it is ok or not to
> continue development in this direction or not.
>
>
>
> On Wed, Jun 19, 2024 at 11:29?PM Stephen Colebourne <scolebourne at joda.org>
> wrote:
>
>> There are a variety of ways that a range of the timeline can be defined.
>> And some would argue that Java should have a general purpose Range class to
>> cover all Comparable classes rather than a few specific ones for Java time.
>>
>> Ultimately, Java time chose to avoid the issues by not addressing the
>> design space. There were plenty of other things to tackle at the time.
>>
>> BTW, see ThreeTen-Extra for some range and interval classes.
>>
>> Stephen
>>
>>
>>
>> On Wed, 19 Jun 2024, 20:44 Olexandr Rotan, <rotanolexandr842 at gmail.com>
>> wrote:
>>
>>> Greetings to the Java community. I have a question regarding the design
>>> of java,time package.
>>>
>>> Commercial Java developers deal with time periods all the time with
>>> different validations regarding intersection of periods, big data
>>> processing, entity auditing etc etc. And it is surprising for everyone to
>>> look into java.time for the first time and find out that there is no start
>>> and end aware span data types at all!
>>>
>>> There is no rocket science in implementing such data types yourself,
>>> that's for sure. However, as always, there are hidden spikes in these
>>> waters.To use these types in JPA entities, you would have to write a custom
>>> converter to familiar for database type, which ties project tightly to
>>> database, which is contrary to what JPA was intended for . To use it in
>>> auditing. one would have to write a custom auditor as no framework or
>>> library knows about our custom data type. Same goes for big data
>>> processing: no library or framework would support processing series of your
>>> custom data type, at least unless you provide some adapter using library
>>> mechanisms, if those exist at all. This rant could go on and on, but the
>>> points are:
>>>
>>> 1) Lack of standardization for such data types leads to obstacles on
>>> each step of development: constant writing of adapters, converters and blah
>>> blah blah. Each of those serves as a space to make mistakes. One-two easy
>>> implementations are not likely to be the source of errors, but the more a
>>> project grows, the more dependencies it acquires, the more it is likely to
>>> fall for some subtle specific feature of some library and spend hours or
>>> even days debugging.
>>> 2) One could rightfully argue that for small projects or microservice
>>> projects with no shared codebase and different team for each service, this
>>> whole mess I described above is overengineering. Seriously, not everyone
>>> would want to go through all of that for one-two usages of class in the
>>> domain layer of the project, and, moreover, not everyone should. However,
>>> leaving it be "as is" is a screaming source of data inconsistencies, as it
>>> is now responsibility of developer (or even worse, user) to keep in mind
>>> the requirement to update all fields, that combined form that start- and
>>> end-aware period (like start date/datetime and Period/Duration as common
>>> way to emulate such thing)
>>>
>>> So, the question is: was it a conscious decision to omit such types back
>>> in the day when java.time was designed, or is it a blindspot created by
>>> deadlines/lack of resources/something else?
>>>
>>> Would appreciate anything some of you have to share on this topic.
>>>
>>> Best regards
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240620/90e8e587/attachment-0001.htm>

From duke at openjdk.org  Thu Jun 20 00:42:22 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 20 Jun 2024 00:42:22 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v8]
In-Reply-To: <Vjuj_jb6e10neab80hXDoCtked0g1Iedre45s7-p9A8=.acf15ea1-211b-43df-a3cf-629b099c1888@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <JiQEOXo6zrzVGIhJBbrYVJY4Kl5OOo2T-E2LUYVkUBU=.607a0258-52de-4f9f-9b2f-41d1542c7c26@github.com>
 <Vjuj_jb6e10neab80hXDoCtked0g1Iedre45s7-p9A8=.acf15ea1-211b-43df-a3cf-629b099c1888@github.com>
Message-ID: <W6G6Y1ocZ9tUxCWau-Wf8Y9U96QPPrJGVnqMSPrXkiw=.c65af17e-d3a4-4933-a00b-8d4af284b193@github.com>

On Thu, 13 Jun 2024 09:51:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - rename benchmark
>>  - code format & use long address
>
> Replacing `StringUTF16.putChar` with an `Unsafe.putByte` construct seems safe since the former already depends on bounds checks having been done elsewhere. Replacing `byte[]` stores with `Unsafe.putByte` requires a thorough examination as that would drop implicit bounds checks.  
> 
> On my M1 laptop I get similar numbers:
> 
> Name                                 Cnt  Base   Error   Test   Error  Unit  Change
> StringBuilders.appendWithBool8Latin1  15 7,500 ? 0,072  6,112 ? 0,049 ns/op   1,23x (p = 0,000*)
> StringBuilders.appendWithBool8Utf16   15 9,650 ? 0,021  7,304 ? 0,047 ns/op   1,32x (p = 0,000*)
> StringBuilders.appendWithNull8Latin1  15 7,118 ? 0,033  5,158 ? 0,062 ns/op   1,38x (p = 0,000*)
> StringBuilders.appendWithNull8Utf16   15 9,336 ? 0,083  6,870 ? 0,069 ns/op   1,36x (p = 0,000*)
>   * = significant
> 
> 
> On a linux-x64 workstation some of the micros regress, though:
> 
> Name                                 Cnt   Base    Error    Test   Error  Unit  Change
> StringBuilders.appendWithBool8Latin1  15 10.781 ?  0.236  16.279 ? 1.087 ns/op   0.66x (p = 0.000*)
> StringBuilders.appendWithBool8Utf16   15 22.942 ?  0.405  23.733 ? 0.792 ns/op   0.97x (p = 0.001*)
> StringBuilders.appendWithNull8Latin1  15 24.313 ? 10.479  24.397 ? 7.483 ns/op   1.00x (p = 0.979 )
> StringBuilders.appendWithNull8Utf16   15 38.704 ?  5.972  27.542 ? 5.620 ns/op   1.41x (p = 0.000*)
>   * = significant
> 
> 
> `-XX:+TraceMergeStores` seem to indicate the merging happens as it should in each case:
> 
> 
> [TraceMergeStores]: Replace
>  2493  StoreB  === 1387 5370 2980 2939  [[ 1962 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=13; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact[2] *, idx=13; !jvms: StringLatin1::putCharsAt @ bci:50 (line 834) AbstractStringBuilder::appendNull @ bci:34 (line 642) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append @ bci:2 (line 179) StringBuilders::appendWithNull8Latin1 @ bci:38 (line 267) StringBuilders_appendWithNull8Latin1_jmhTest::appendWithNull8Latin1_avgt_jmhStub @ bci:17 (line 190)
>  1962  StoreB  === 1387 2493 2494 2442  [[ 1388 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=13; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact[2] *, idx=13; !jvms: StringLatin1::putCharsAt @ bci:62 (line 835) AbstractStringBuilder::appendNull @ bci:34 (line 642) AbstractStringBuilder::append @ bci:5 (line 587) StringBuilder::append...

The performance regression issue on x64 platform has been fixed. Please continue to review @cl4es @liach

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2179620100

From duke at openjdk.org  Thu Jun 20 01:32:20 2024
From: duke at openjdk.org (lingjun-cg)
Date: Thu, 20 Jun 2024 01:32:20 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
Message-ID: <-ZTnRHRNgJgpZAfm3UIyFieXwje3GUxqVoj74CVrUBs=.af3f0a26-36e3-4eeb-a3bf-82d34cf6ad73@github.com>

On Tue, 18 Jun 2024 10:00:33 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

If change the visibility of `java.lang.AbstractStringBuilder` from package-private to public, it seems more simple.
The `AbstractStringBuilder` is a sealed class, user code cannot extend it, and it also used by other class like `String`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2179655141

From sgehwolf at openjdk.org  Thu Jun 20 08:34:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Jun 2024 08:34:45 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v2]
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <7NnRX5w4y2cPb9q5BDEH8UgwWnMS5u1nUYYOrS0YIaI=.2f8ee7b9-51d9-4493-89b6-b733026a6614@github.com>

> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
> 
> I'm adding those tests in order to not regress another time.
> 
> Testing:
> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
> - [x] GHA

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Fix comments
 - 8333446: Add tests for hierarchical container support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19530/files
  - new: https://git.openjdk.org/jdk/pull/19530/files/98d780ac..00b528ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=00-01

  Stats: 45352 lines in 1129 files changed: 26950 ins; 13694 del; 4708 mod
  Patch: https://git.openjdk.org/jdk/pull/19530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19530/head:pull/19530

PR: https://git.openjdk.org/jdk/pull/19530

From erikj at openjdk.org  Thu Jun 20 08:39:13 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Jun 2024 08:39:13 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <a6z4rQC2WJmKiInIPhs31pYd6UpOpxiMZhAQgkFgbAs=.dea0067e-e622-4d7d-9581-66e4a833bc3e@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

Build changes look ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19478#pullrequestreview-2129807207

From prappo at openjdk.org  Thu Jun 20 09:56:45 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 20 Jun 2024 09:56:45 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v5]
In-Reply-To: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
Message-ID: <jtvFBEmGok6gtwpgcl_oZeUzGBDC65fLQRQmAC-T8oM=.491abcab-678a-4a56-aa59-f6bbd52301f8@github.com>

> Please review this fix for an intermittent test failure.
> 
> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
> 
> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
> 
> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.

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 six additional commits since the last revision:

 - Merge branch 'master' into 8333358
 - Merge branch 'master' into 8333358
 - Add a comment for future maintainers
 - Disable timeout in expect scripts
 - Change url as suggested in review
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19627/files
  - new: https://git.openjdk.org/jdk/pull/19627/files/aad8b491..ae111829

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19627&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19627&range=03-04

  Stats: 17482 lines in 318 files changed: 13721 ins; 2088 del; 1673 mod
  Patch: https://git.openjdk.org/jdk/pull/19627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19627/head:pull/19627

PR: https://git.openjdk.org/jdk/pull/19627

From redestad at openjdk.org  Thu Jun 20 09:57:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 20 Jun 2024 09:57:19 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v12]
In-Reply-To: <d7kEmw8X84iZgGkLLa7XYSVipLSkiLZUz2p83dL_TEw=.941a9357-530b-4ec7-b815-7079302a990f@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <d7kEmw8X84iZgGkLLa7XYSVipLSkiLZUz2p83dL_TEw=.941a9357-530b-4ec7-b815-7079302a990f@github.com>
Message-ID: <rYEbV8xlwLh3Cf7YgmBIZqzGlImRrnYX9rdugdgLCUE=.37968711-d1dc-4ef7-895c-7e1c961b3434@github.com>

On Mon, 17 Jun 2024 05:53:45 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Utf16 case remove `append first utf16 char`

src/java.base/share/classes/java/lang/StringLatin1.java line 832:

> 830:         // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
> 831:         long address  = Unsafe.ARRAY_BYTE_BASE_OFFSET + index;
> 832:         Unsafe UNSAFE = Unsafe.getUnsafe();

Perhaps better to put in a `private static final` field

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1647313459

From redestad at openjdk.org  Thu Jun 20 10:12:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 20 Jun 2024 10:12:22 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
 <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
 <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>
Message-ID: <nIWEJwBl6I1MnZtAftoVz7Nt4_u2p66CvnJghrU2KF4=.bc7f4242-5106-4a17-bd46-9fa500f9d269@github.com>

On Thu, 13 Jun 2024 07:36:34 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Thanks to @eme64 's patience and help, I found a way to use MergeStore without doing boundary checking.
>> 
>> It would be even better if Unsafe.putChar could be used for MergeStore in the future.
>> 
>> ## 1. JavaCode
>> 
>> class StringUTF16 {
>>     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
>>         // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
>>         putChar1(value, i    , c1);
>>         putChar1(value, i + 1, c2);
>>         putChar1(value, i + 2, c3);
>>         putChar1(value, i + 3, c4);
>>     }
>> 
>>     public static void putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4, char c5) {
>>         // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
>>         putChar1(value, i    , c1);
>>         putChar1(value, i + 1, c2);
>>         putChar1(value, i + 2, c3);
>>         putChar1(value, i + 3, c4);
>>         putChar1(value, i + 4, c5);
>>     }
>> 
>>     static void putChar1(byte[] value, int i, char c) {
>>         int address = Unsafe.ARRAY_BYTE_BASE_OFFSET + (i << 1);
>>         Unsafe.getUnsafe().putByte(value, address    , (byte)(c >> HI_BYTE_SHIFT));
>>         Unsafe.getUnsafe().putByte(value, address + 1, (byte)(c >> LO_BYTE_SHIFT));
>>     }
>> }
>> 
>> 
>> ## 2. Benchmark Numbers
>> The performance numbers under MacBookPro M1 Max are as follows:
>> 
>> -Benchmark                                   Mode  Cnt  Score   Error  Units
>> -StringBuilders.toStringCharWithNull8Latin1  avgt   15  7.073 ? 0.010  ns/op
>> -StringBuilders.toStringCharWithNull8Utf16   avgt   15  9.298 ? 0.015  ns/op
>> -StringBuilders.toStringCharWithBool8Latin1  avgt   15  7.387 ? 0.021  ns/op
>> -StringBuilders.toStringCharWithBool8Utf16   avgt   15  9.615 ? 0.011  ns/op
>> 
>> +Benchmark                                   Mode  Cnt  Score   Error  Units
>> +StringBuilders.toStringCharWithNull8Latin1  avgt   15  5.628 ? 0.017  ns/op +25.67%
>> +StringBuilders.toStringCharWithNull8Utf16   avgt   15  6.873 ? 0.026  ns/op +35.28%
>> +StringBuilders.toStringCharWithBool8Latin1  avgt   15  6.480 ? 0.077  ns/op +13.99%
>> +StringBuilders.toStringCharWithBool8Utf16   avgt   15  7.456 ? 0.059  ns/op +28.95%
>> 
>> 
>> ## 3.  TraceMergeStores
>> 
>> [TraceMergeStores]: Replace
>>  65  StoreB  === 54 7 64 12  [[ 87 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; unsafe  Memory: @byte[int:>=0] (java/la...
>
> @wenshao I'm glad we figured it out a bit, and I hope you learned a thing or two :)
> 
>> It would be even better if Unsafe.putChar could be used for MergeStore in the future.
> 
> The `_putCharStringU` intrinsic uses `LibraryCallKit::inline_string_char_access`. It seems to generate IR nodes, I speculate it could be `StoreC`. We'd have to do more digging to see why that pattern is not accepted by `MergeStore`.
> 
> @wenshao I'm not sure if everything is right with the bounds checking, but I leave this to the library folks to review. What you will definately need is benchmarking not just on `M1`, but also `x86-64` and other `aarch64` architectures.

I'm not opposed to accepting this patch as-is, but I think we should do so with an eye towards reverting if we figure out a way to improve the `putChar` intrinsic so that it doesn't block merge store optimization. What do you think @eme64?

As the need for the changes in [b5ad8e7](https://github.com/openjdk/jdk/pull/19626/commits/b5ad8e70928c547d134d0e4a532441cad9a7e4a2) showed added code complexity (like here) can be detrimental to performance, and if the `putChar` can be improved we might see benefits in more places.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2180308686

From epeter at openjdk.org  Thu Jun 20 10:57:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 20 Jun 2024 10:57:15 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <nIWEJwBl6I1MnZtAftoVz7Nt4_u2p66CvnJghrU2KF4=.bc7f4242-5106-4a17-bd46-9fa500f9d269@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
 <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
 <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>
 <nIWEJwBl6I1MnZtAftoVz7Nt4_u2p66CvnJghrU2KF4=.bc7f4242-5106-4a17-bd46-9fa500f9d269@github.com>
Message-ID: <Vc4OgDPfVE7ZtFrp7fWW8QL6ZKpWsaR9EpnPETShlns=.719b479f-611f-4d31-8331-53c53e42089b@github.com>

On Thu, 20 Jun 2024 10:09:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @wenshao I'm glad we figured it out a bit, and I hope you learned a thing or two :)
>> 
>>> It would be even better if Unsafe.putChar could be used for MergeStore in the future.
>> 
>> The `_putCharStringU` intrinsic uses `LibraryCallKit::inline_string_char_access`. It seems to generate IR nodes, I speculate it could be `StoreC`. We'd have to do more digging to see why that pattern is not accepted by `MergeStore`.
>> 
>> @wenshao I'm not sure if everything is right with the bounds checking, but I leave this to the library folks to review. What you will definately need is benchmarking not just on `M1`, but also `x86-64` and other `aarch64` architectures.
>
> I'm not opposed to accepting this patch as-is, but I think we should do so with an eye towards reverting if we figure out a way to improve the `putChar` intrinsic so that it doesn't block merge store optimization. What do you think @eme64?
> 
> As the need for the changes in [b5ad8e7](https://github.com/openjdk/jdk/pull/19626/commits/b5ad8e70928c547d134d0e4a532441cad9a7e4a2) showed added code complexity (like here) can be detrimental to performance, and if the `putChar` can be improved we might see benefits in more places.

@cl4es  @wenshao I think we should probably work on `putChar`, or at least figure out what blocks `MergeStore` for `putChar`. Can someone produce a simple stand-alone `.java` file that uses `putChar`, so that I can investigate why `MergeStore` does not work for it?

Otherwise, I agree with @cl4es : the code here may be ok for now, but we would have to revert it again later, should `MergeStore` eventually do the trick.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2180388366

From jvernee at openjdk.org  Thu Jun 20 11:47:16 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 11:47:16 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
 <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>
Message-ID: <NSSe8cQ3IuDSEJWMApUnESikaFM6OtYOzalm4Z7Q3_U=.956e5c2a-8988-4037-b794-926b21354c39@github.com>

On Wed, 19 Jun 2024 21:30:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comments
>>  - add man page
>
> src/jdk.jdeps/share/man/jnativescan.1 line 121:
> 
>> 119: .TP
>> 120: \f[V]--release\f[R] \f[I]version\f[R]
>> 121: Used to specify the Java SE release that specifies the set of restricted
> 
> In principle, the release could also affect which methods are native or not?

Yes, but we don't warn on `native` method references, only on declarations. So, it would only affect which methods might be `native` in the user code. But I think that is already implied by the note on multi-release jars?

> src/jdk.jdeps/share/man/jnativescan.1 line 127:
> 
>> 125: This option should be set to the version of the runtime under which the
>> 126: application is eventually intended to be run.
>> 127: If this flag is omitted, the version of \f[V]jnativescan\f[R] is used as
> 
> Maybe we should point to `Runtime.version()` instead?

Not sure. If a client is just using the tool, how would they know what `Runtime.version()` returns? I mean, it's the version of the JDK, but to find that out they'd have to use another JDK tool (e.g. jshell)  to print it out, or look at the release file. The `jnativescan` version on the other hand is readily accessible through the `--version` flag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647436934
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647441115

From jvernee at openjdk.org  Thu Jun 20 11:47:17 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 11:47:17 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <NSSe8cQ3IuDSEJWMApUnESikaFM6OtYOzalm4Z7Q3_U=.956e5c2a-8988-4037-b794-926b21354c39@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
 <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>
 <NSSe8cQ3IuDSEJWMApUnESikaFM6OtYOzalm4Z7Q3_U=.956e5c2a-8988-4037-b794-926b21354c39@github.com>
Message-ID: <49g4OeyOWnbGw1IZAMrwELrL9IEesIPgVIeTkLuy3vI=.9a1f6aa9-d80a-4b23-ba9b-30f329519f62@github.com>

On Thu, 20 Jun 2024 11:42:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/jdk.jdeps/share/man/jnativescan.1 line 127:
>> 
>>> 125: This option should be set to the version of the runtime under which the
>>> 126: application is eventually intended to be run.
>>> 127: If this flag is omitted, the version of \f[V]jnativescan\f[R] is used as
>> 
>> Maybe we should point to `Runtime.version()` instead?
>
> Not sure. If a client is just using the tool, how would they know what `Runtime.version()` returns? I mean, it's the version of the JDK, but to find that out they'd have to use another JDK tool (e.g. jshell)  to print it out, or look at the release file. The `jnativescan` version on the other hand is readily accessible through the `--version` flag.

I'll add a note like: `, which is the same as the version of
the JDK that the tool belongs to.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647442344

From sgehwolf at openjdk.org  Thu Jun 20 11:50:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Jun 2024 11:50:11 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v2]
In-Reply-To: <7NnRX5w4y2cPb9q5BDEH8UgwWnMS5u1nUYYOrS0YIaI=.2f8ee7b9-51d9-4493-89b6-b733026a6614@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <7NnRX5w4y2cPb9q5BDEH8UgwWnMS5u1nUYYOrS0YIaI=.2f8ee7b9-51d9-4493-89b6-b733026a6614@github.com>
Message-ID: <yPm4Cu-W9Q3gw-FAz_Tx8T74xEjbTtggqLuxp4otQCA=.b44c6bf7-2b99-495b-84ff-7e34313863df@github.com>

On Thu, 20 Jun 2024 08:34:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges.
>> 
>> I'm adding those tests in order to not regress another time.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1.
>> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to  JDK-8322420)
>> - [x] GHA
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

Anyone willing to review this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2180477503

From sgehwolf at openjdk.org  Thu Jun 20 11:57:42 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Jun 2024 11:57:42 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v5]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <zZm_itYVKZezfpdMfA6bwS3Aab1w25vSBoZTeVMcs6I=.c8b73533-4ee7-45c8-a12d-bc25a71285d5@github.com>

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Add doc for mountinfo scanning.
 - Unify naming of variables
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - jcheck fixes
 - Fix tests
 - Implement Metrics.isContainerized()
 - Some clean-up
 - ... and 4 more: https://git.openjdk.org/jdk/compare/01ee4241...7c163cb2

-------------

Changes: https://git.openjdk.org/jdk/pull/18201/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=04
  Stats: 406 lines in 19 files changed: 301 ins; 78 del; 27 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 jvernee at openjdk.org  Thu Jun 20 11:59:14 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 11:59:14 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
 <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>
Message-ID: <I8OShnFurSxTNPGmbfpb-V-acUdTlZV4Ajs3pFVRBm4=.885bf021-2027-495f-acff-fc0ab6cd211d@github.com>

On Wed, 19 Jun 2024 21:35:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comments
>>  - add man page
>
> src/jdk.jdeps/share/man/jnativescan.1 line 166:
> 
>> 164: .fi
>> 165: .PP
>> 166: \f[V]app.jar (ALL-UNNAMED)\f[R] is the path to the jar file, with the
> 
> This is a good explanation, I'm not sure whether it's necessary, as the output seems quite self-explanatory. But I'm ok either way.

I think that people that get to this section of the man page are the people who either don't understand the output, or (probably more likely) have an idea but want to be sure of what things mean. In both those cases, I think walking through the output is useful. The description of the command line options is probably enough for more people?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647458338

From jvernee at openjdk.org  Thu Jun 20 12:05:25 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 12:05:25 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v4]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <ZEEvi-RSlbYEQEtc17-PQWtbggxiLEmbMzT61LFgHwI=.fa28c6b4-7c62-41f1-883d-dec762833c08@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  man page review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/b5468440..4c6abddf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=02-03

  Stats: 26 lines in 1 file changed: 5 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From sgehwolf at openjdk.org  Thu Jun 20 12:06:43 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Jun 2024 12:06:43 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v6]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <ZBtopTZicUFg1h2ck9567ccbp4ReUXcMUWWuMypiyw4=.04c04d2d-5ba5-47f1-8d8f-126c060cf2cb@github.com>

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove problem listing of PlainRead which is reworked here

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18201/files
  - new: https://git.openjdk.org/jdk/pull/18201/files/7c163cb2..3d98cbc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 sgehwolf at openjdk.org  Thu Jun 20 12:06:48 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Jun 2024 12:06:48 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
Message-ID: <VGN76x6JcYBSxx_hpeHg6iWfKsUfaJTXpErVVtDCa4E=.f8108ea0-a894-48ee-9e08-739098979fc7@github.com>

On Tue, 16 Apr 2024 18:25:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - jcheck fixes
>>  - Fix tests
>>  - Implement Metrics.isContainerized()
>>  - Some clean-up
>>  - Drop cgroups testing on plain Linux
>>  - Implement fall-back logic for non-ro controller mounts
>>  - Make find_ro static and local to compilation unit
>>  - 8261242: [Linux] OSContainer::is_containerized() returns true
>
> I am not enough of a container expert to judge if the basic approach is right - I trust you on this. This is just a technical code review.

@tstuefe Do you mind to take another look? Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2180504024

From jvernee at openjdk.org  Thu Jun 20 12:11:25 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 12:11:25 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  update man page header to be consisten with the others

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/4c6abddf..06f53e31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From duke at openjdk.org  Thu Jun 20 12:54:12 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 20 Jun 2024 12:54:12 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
Message-ID: <gFWZmzXwClqNWJeWqqMN-w6luMd2cnniedH-iXapV9w=.42d6e4be-2139-4aab-9e54-e6c191d30450@github.com>

On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update man page header to be consisten with the others

Just as a guest here. Just theoretically, wouldn't it be better to create one uniform tool to detect all "undesired" APIs. This would be more flexible, and potentially could be adapted to use some kind of "meticulous" mode, that will also indicate usage of public APIs, that, while never will be removed, are recommended to remove in favor of new alternatives (like old Date API or old collections". Just a thought btw, not a proposal for now

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2180594098

From alanb at openjdk.org  Thu Jun 20 13:09:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 13:09:12 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <x2MH6xG7kX0O6i0LoaxAv-Vd8hLNXmZoqXhq-6MCw3g=.10857ad1-9428-4576-9c6b-011498fb472a@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

The changes to the launcher look okay. The move from `ifdef STATIC_BUILD` to `JLI_IsStaticallyLinked` is quite nice.

Having libjdwp link to libjvm was a surprise but I think okay.

I think it would be useful to provide a brief summary on the when/where the static builds are tested to ensure that the changes don't bit rot. I realise we already have static builds but it isn't obvious where this is tested.

src/hotspot/share/runtime/linkType.cpp line 36:

> 34:   return JNI_TRUE;
> 35: #else
> 36:   return JNI_FALSE;

bool != jboolean, I assume you don't want that.

The naming is a bit unusual, a function that returns a boolean is usually name is_XXX, but maybe there is reason for this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19478#issuecomment-2180635747
PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1647480992

From jvernee at openjdk.org  Thu Jun 20 13:15:15 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 13:15:15 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <gFWZmzXwClqNWJeWqqMN-w6luMd2cnniedH-iXapV9w=.42d6e4be-2139-4aab-9e54-e6c191d30450@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
 <gFWZmzXwClqNWJeWqqMN-w6luMd2cnniedH-iXapV9w=.42d6e4be-2139-4aab-9e54-e6c191d30450@github.com>
Message-ID: <_k4D6mk16P9uX8tcAfx-3MiE8OMK3MOi2t9NqCkOOdk=.1dce9b0c-1224-450f-99a7-73d47aa5b4a3@github.com>

On Thu, 20 Jun 2024 12:51:22 GMT, Evemose <duke at openjdk.org> wrote:

> wouldn't it be better to create one uniform tool

See my reply here: https://github.com/openjdk/jdk/pull/19774#issuecomment-2179078565

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2180653743

From duke at openjdk.org  Thu Jun 20 14:35:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 20 Jun 2024 14:35:14 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <Vc4OgDPfVE7ZtFrp7fWW8QL6ZKpWsaR9EpnPETShlns=.719b479f-611f-4d31-8331-53c53e42089b@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
 <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
 <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>
 <nIWEJwBl6I1MnZtAftoVz7Nt4_u2p66CvnJghrU2KF4=.bc7f4242-5106-4a17-bd46-9fa500f9d269@github.com>
 <Vc4OgDPfVE7ZtFrp7fWW8QL6ZKpWsaR9EpnPETShlns=.719b479f-611f-4d31-8331-53c53e42089b@github.com>
Message-ID: <dKtXgrAuwD5ZkbCJYZaCPKgCjgK5Gt_0CIqk0Dp4cBs=.cfb43f8b-fdc1-46b9-add8-1454964313d0@github.com>

On Thu, 20 Jun 2024 10:54:49 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> I'm not opposed to accepting this patch as-is, but I think we should do so with an eye towards reverting if we figure out a way to improve the `putChar` intrinsic so that it doesn't block merge store optimization. What do you think @eme64?
>> 
>> As the need for the changes in [b5ad8e7](https://github.com/openjdk/jdk/pull/19626/commits/b5ad8e70928c547d134d0e4a532441cad9a7e4a2) showed added code complexity (like here) can be detrimental to performance, and if the `putChar` can be improved we might see benefits in more places.
>
> @cl4es  @wenshao I think we should probably work on `putChar`, or at least figure out what blocks `MergeStore` for `putChar`. Can someone produce a simple stand-alone `.java` file that uses `putChar`, so that I can investigate why `MergeStore` does not work for it?
> 
> Otherwise, I agree with @cl4es : the code here may be ok for now, but we would have to revert it again later, should `MergeStore` eventually do the trick.

@eme64 

simple stand-alone java

import jdk.internal.misc.Unsafe;

public class PutCharTest {
    static final Unsafe UNSAFE = Unsafe.getUnsafe();

    static void putCharsAt(byte[] val, int index, int c1, int c2, int c3, int c4) {
        putChar(val, index    , (char)(c1));
        putChar(val, index + 1, (char)(c2));
        putChar(val, index + 2, (char)(c3));
        putChar(val, index + 3, (char)(c4));
    }
    
    static void putChar(byte[] bytes, int index, int c) {
        UNSAFE.putChar(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1), (char)(c));
    }

    static void putChar0(byte[] bytes, int index, int c) {
        UNSAFE.putByte(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1), (byte)(c));
        UNSAFE.putByte(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1) + 1, (byte)(c << 8));
    }

    static void putNull(byte[] bytes, int index) {
        putCharsAt(bytes, index, 'n', 'u', 'l', 'l');
    }

    public static void main(String[] args) {
        for (int i = 0; i < 5; i++) {
            testNull();
        }

        System.out.println("done");
    }

    private static void testNull() {
        byte[] bytes = new byte[8192];

        for (int i = 0; i < 1000; i++) {
            int index = 0;
            for (int j = 0; j < 1024; j++) {
                putNull(bytes, index);
                index += 4;
            }
        }
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2180862537

From asemenyuk at openjdk.org  Thu Jun 20 15:48:11 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 20 Jun 2024 15:48:11 GMT
Subject: RFR: 8325525: Create jtreg test case for JDK-8325203
In-Reply-To: <JIasinDL2M84-haLaLLxS9CpuyMHMAome0X3ZLUWARQ=.d01fdb93-d307-476d-81aa-00185088245a@github.com>
References: <JIasinDL2M84-haLaLLxS9CpuyMHMAome0X3ZLUWARQ=.d01fdb93-d307-476d-81aa-00185088245a@github.com>
Message-ID: <R0kqD8SnBEwdlesr7G57UUxl9n8cmkoVazatfxAoHEE=.8e89d987-25f9-4e05-880e-f80d91ba39e4@github.com>

On Tue, 4 Jun 2024 07:13:15 GMT, Vanitha B P <duke at openjdk.org> wrote:

> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue.
> 
> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated.

Changes requested by asemenyuk (Reviewer).

The test builds an installer that must be installed as a part of the test. This will not work in an environment where tests are executed under a user account without restricted permissions. Building app image instead of an installer is sufficient for this test,

There are helper classes for writing jpackage tests in https://github.com/openjdk/jdk/tree/master/test/jdk/tools/jpackage/helpers/jdk/jpackage/test folder.

I'd not use a file to communicate PID of the started process between the launcher and the test. I'd use stdout instead:

public class ThirdPartyAppLauncher {
    public static void main(String[] args) throws IOException {
        Process process = new ProcessBuilder("regedit").start();
        System.out.println("RegEdit PID=" + process.pid());
    }
}


Compiling, jarring, and running jpackage that will create app image from the jar with these helpers would be as follows:

JPackageCommand.helloAppImage(TKit.TEST_SRC_ROOT.resolve("apps/ThirdPartyAppLauncher.java") + "*Hello").executeAndAssertImageCreated();


Then you run "ThirdPartyAppLauncher" class using jpackage launcher and capture its stdout:

String pidStr = new Executor().saveOutput().dumpOutput().setExecutable(cmd.appLauncherPath().toAbsolutePath()).execute(0).getFirstLineOfOutput();

// parse regedit PID
long regeditPid = Long.parseLong(pidStr.split("=", 2)[1]);

// Run your checks
...

// Kill only a specific regedit instance
Runtime.getRuntime().exec("taskkill /F /PID " + regeditPid);


You may use one of the existing jpackage tests for the reference (https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jpackage/share/AppLauncherEnvTest.java is a good example)

test/jdk/tools/jpackage/windows/JpackageTest.java line 160:

> 158:      */
> 159:     private void closeThirdPartyApplication() throws Throwable {
> 160:         Runtime.getRuntime().exec("taskkill /F /IM regedit.exe");

I guess this will kill all regedit processes including those not started by the test. This doesn't seem right.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19536#pullrequestreview-2130771716
PR Comment: https://git.openjdk.org/jdk/pull/19536#issuecomment-2181016935
PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1647775863

From mcimadamore at openjdk.org  Thu Jun 20 16:10:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 20 Jun 2024 16:10:13 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v3]
In-Reply-To: <NSSe8cQ3IuDSEJWMApUnESikaFM6OtYOzalm4Z7Q3_U=.956e5c2a-8988-4037-b794-926b21354c39@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <tgnHRr-Pdxp_hXBW9CsPbsDwMfpC7gG32E7v9MLTEMo=.d991b8a7-744b-4e01-8d7f-1da7fc19feeb@github.com>
 <CUQ1g5yVt3s4Ia_OFyv6018YwMaTV_GmYsxpjjIXX7M=.ad2b3cbe-1b7e-431e-b797-4d8c508ae023@github.com>
 <NSSe8cQ3IuDSEJWMApUnESikaFM6OtYOzalm4Z7Q3_U=.956e5c2a-8988-4037-b794-926b21354c39@github.com>
Message-ID: <XuGTV8qp92BktgNeLFQVg2z3Vq0AYMA6go0-QXbKzUg=.8d39161d-86fb-41fa-9f05-785aa3ab728d@github.com>

On Thu, 20 Jun 2024 11:38:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/jdk.jdeps/share/man/jnativescan.1 line 121:
>> 
>>> 119: .TP
>>> 120: \f[V]--release\f[R] \f[I]version\f[R]
>>> 121: Used to specify the Java SE release that specifies the set of restricted
>> 
>> In principle, the release could also affect which methods are native or not?
>
> Yes, but we don't warn on `native` method references, only on declarations. So, it would only affect which methods might be `native` in the user code. But I think that is already implied by the note on multi-release jars?

You are right... declarations inside the JDK are... inside the JDK

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647820666

From alanb at openjdk.org  Thu Jun 20 16:15:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 16:15:14 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
Message-ID: <wqfGqnyP0-ReMQR0ijahzQXxy26doXTiFmkABdGm72U=.693b0dc3-0cc6-4b07-a0af-f0be2494ea9e@github.com>

On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update man page header to be consisten with the others

One thing to check is usages like `jnativescan foo`, should that fail as the tool doesn't take args.

Another thing is that using joptsimple gives up a bit of control, e.g. the help output shows the parameter for --class-path as `<String>` where the java launcher and other tools will show "path" or "class path".  Same thing with `--release` where it shows  `<String>` where jar, javac, and other tools will say "release".   Not important for now, just comments from trying out the tool.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2181070909

From alanb at openjdk.org  Thu Jun 20 16:18:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 16:18:13 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
Message-ID: <VfJ6RlvK04rvjekLkXSeEMaIJ52jONsvV6YAb96BEpQ=.d9d8121f-4eb7-481d-be11-7098a21b6751@github.com>

On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update man page header to be consisten with the others

`jnativescan --version` prints the value of Runtime.version where jdeprscan and some of the other tools print System.getProperty("java.version").  Just something to check as they might look inconsistent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2181075350

From naoto at openjdk.org  Thu Jun 20 16:31:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jun 2024 16:31:17 GMT
Subject: RFR: 8333358: java/io/IO/IO.java test fails intermittently [v5]
In-Reply-To: <jtvFBEmGok6gtwpgcl_oZeUzGBDC65fLQRQmAC-T8oM=.491abcab-678a-4a56-aa59-f6bbd52301f8@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
 <jtvFBEmGok6gtwpgcl_oZeUzGBDC65fLQRQmAC-T8oM=.491abcab-678a-4a56-aa59-f6bbd52301f8@github.com>
Message-ID: <pWPIBIftaYGGbw48Zo4auMr_6IKyPrzcNvd4edzvRy0=.90354562-c017-4580-a67b-7848fa3cc004@github.com>

On Thu, 20 Jun 2024 09:56:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this fix for an intermittent test failure.
>> 
>> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
>> 
>> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
>> 
>> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.
>
> 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into 8333358
>  - Merge branch 'master' into 8333358
>  - Add a comment for future maintainers
>  - Disable timeout in expect scripts
>  - Change url as suggested in review
>  - Initial commit

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19627#pullrequestreview-2130880264

From prappo at openjdk.org  Thu Jun 20 16:31:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 20 Jun 2024 16:31:18 GMT
Subject: Integrated: 8333358: java/io/IO/IO.java test fails intermittently
In-Reply-To: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
References: <BtA-aCe9id_BRvqlfQSrA1uQXeAapxZH8vzzza7zRj0=.80379352-02e2-4c0f-a78b-31c923975be5@github.com>
Message-ID: <J4IDiNmw7HcdUQVWMp7qjqHG5vXGV5WMDxsPElbDeKM=.c1ed920f-0ac9-4952-aee0-f07c7766cafb@github.com>

On Mon, 10 Jun 2024 12:29:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this fix for an intermittent test failure.
> 
> On some configurations, the default `expect` timeout of 10 seconds is insufficient. It is increased to 20; it's hard to imagine a configuration for which that new value would still be insufficient, but we'll see.
> 
> Aside from that, test-generated diagnostics are improved: the version of the `expect` command and the duration of each test method are recorded. `output.exp` is modified for robustness and clear indication of the timeout condition.
> 
> I was reminded, out-of-band, that test timeouts should be scaled with `test.timeout.factor`. I propose to integrate this PR first and then separately update all the affected tests to scale their `expect` timeouts.

This pull request has now been integrated.

Changeset: 1b1dba80
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43
Stats:     69 lines in 3 files changed: 63 ins; 2 del; 4 mod

8333358: java/io/IO/IO.java test fails intermittently

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/19627

From alanb at openjdk.org  Thu Jun 20 17:01:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 17:01:17 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <aC-o0l0yU3ZZne9YyCzUfj8xl98T3EkZV9QDXViz2Y4=.c474e914-0ecf-48a6-9979-a716b323d4a3@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <aC-o0l0yU3ZZne9YyCzUfj8xl98T3EkZV9QDXViz2Y4=.c474e914-0ecf-48a6-9979-a716b323d4a3@github.com>
Message-ID: <7WkZwa41PggNvizNuEeUAsUce2yIyqhO7uLcCkzorMc=.1b198bd6-414d-4cdc-aa17-3bb008d64275@github.com>

On Tue, 18 Jun 2024 16:35:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update man page header to be consisten with the others
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 93:
> 
>> 91:     }
>> 92: 
>> 93:     public PlatformDescription getPlatformTrusted(String platformName) {
> 
> I noticed that `getPlatform` was not throwing an exception if the release was not valid, which then later results in an NPE. I've added an explicit check here instead. The caller can then catch the exception.

I see the "options" arg is not used so maybe another approach here is a one-arg getPlatform that throws PlatformNotSupported and then migrate the other usages at another time. 

(This is just a passing comment, not important for the core of this feature).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647877795

From naoto at openjdk.org  Thu Jun 20 17:04:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jun 2024 17:04:14 GMT
Subject: RFR: 8334490: Normalize string with locale invariant
 `toLowerCase()`
In-Reply-To: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
References: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
Message-ID: <v9zcuJA_5t-mAIQV8NFV3FrVEiP9vKznqoz6IJ5BfRM=.1c925c39-a68d-451c-8f6e-918543ff9853@github.com>

On Tue, 18 Jun 2024 18:23:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The test library `jdk.test.lib.Platform` uses no-arg `toLowerCase()` for string comparison, which should be avoided.

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19775#issuecomment-2181150302

From naoto at openjdk.org  Thu Jun 20 17:04:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jun 2024 17:04:14 GMT
Subject: Integrated: 8334490: Normalize string with locale invariant
 `toLowerCase()`
In-Reply-To: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
References: <A4zDHOyDhANC6Fzkru25Ff4E7VCQ4fua1_NkJU2Mn1E=.28c56137-892a-4c9f-90c9-ddd4fc57b3ec@github.com>
Message-ID: <CCjhik4qnr4Z-ruMWD6m5lxZHfFMNFOAcCJ-5OF-N08=.d8bff510-9b81-49ad-8523-3a2547efecf3@github.com>

On Tue, 18 Jun 2024 18:23:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The test library `jdk.test.lib.Platform` uses no-arg `toLowerCase()` for string comparison, which should be avoided.

This pull request has now been integrated.

Changeset: 265a0f55
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/265a0f5547d0ddb220391aef679c122768f02a00
Stats:     7 lines in 1 file changed: 1 ins; 0 del; 6 mod

8334490: Normalize string with locale invariant `toLowerCase()`

Reviewed-by: jlu, dfuchs, lancea, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/19775

From alanb at openjdk.org  Thu Jun 20 17:28:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 17:28:14 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <2r8s2SU2XAXtfb8KUesb8VMMc80KPrvhWSCxJQmFXQY=.a2fad386-3ace-4ef0-badf-23f8ef2f88b2@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <wN7MphwgpmzUS7Iu2EByjTzJ3YfNpLKJEUqE9c1LBgo=.3c9180e1-a791-47bf-a1d9-006a45c9cf29@github.com>
 <D_MQ4c6s7n1qldn9CHeYZKfHaUgGclpU6murkDtsjuY=.dff9a39b-9db8-4ebb-b10f-4c0e36cea555@github.com>
 <2r8s2SU2XAXtfb8KUesb8VMMc80KPrvhWSCxJQmFXQY=.a2fad386-3ace-4ef0-badf-23f8ef2f88b2@github.com>
Message-ID: <WJfH2ULLY138ofx9uwWkK9-_eMzWTWsZ18ibeOQixSU=.47df4a28-5135-48cc-bf12-4424d9bc1be2@github.com>

On Wed, 19 Jun 2024 21:13:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> What do you suggest? Just a note in the error message that exploded modules/class paths are not supported?
>
> Something like that yes

An altermative is to use ResolvedModule::reference to get a ModuleReference, then use its open method to open the contents of the module to get a ModuleReader. That will give you a stream over the names of all resources in the module. It will work for all exploded and packaged modules.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647911987

From stuefe at openjdk.org  Thu Jun 20 17:41:16 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 20 Jun 2024 17:41:16 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v6]
In-Reply-To: <ZBtopTZicUFg1h2ck9567ccbp4ReUXcMUWWuMypiyw4=.04c04d2d-5ba5-47f1-8d8f-126c060cf2cb@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <ZBtopTZicUFg1h2ck9567ccbp4ReUXcMUWWuMypiyw4=.04c04d2d-5ba5-47f1-8d8f-126c060cf2cb@github.com>
Message-ID: <3garHvE8lhPovujClt422-1pcIcs7z7zpqpngEHDd6w=.8776bce8-2b79-44bd-8355-d753562a75cf@github.com>

On Thu, 20 Jun 2024 12:06:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove problem listing of PlainRead which is reworked here

Seems okay. I don't understand the depths of V1 vs V2 controller files as well as you do, @jerboaa , but I trust you there. The mechanics seem fine.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 373:

> 371:      * (11)   mount source:    matched with '%*s' and discarded
> 372:      * (12)   super options:   matched with '%*s' and discarded
> 373:      */

Thanks for the good comment. That scanf line is a brain teaser.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 422:

> 420:      * (12)   super options:   matched with '%s' and captured in 'tmpcgroups'
> 421:      */
> 422:     if (sscanf(p, "%*d %*d %*d:%*d %s %s %s%*[^-]- %s %*s %s", tmproot, tmpmount, mount_opts, tmp_fs_type, tmpcgroups) == 5) {

The only difference to v1 is that we parse the super options (12), right? Could we factor out the parsing into a helper function? Or, alternatively, at least `#define` the scanf format somewhere up top, including the nice comment, and reuse that format string?

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18201#pullrequestreview-2130943896
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1647881202
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1647925120

From alanb at openjdk.org  Thu Jun 20 17:43:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 17:43:13 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
Message-ID: <J7pSRoT9jBwnYtznnH46TZDaJaHStiogsf0_H5kGvHU=.59bfad41-e552-40c7-a874-1d0e954d411d@github.com>

On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update man page header to be consisten with the others

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 113:

> 111:                     // Class-Path attribute specifies that jars that
> 112:                     // are not found are simply ignored. Do the same here
> 113:                     classPathJars.offer(otherJar);

The expansion of the class path looks right but the Class-Path attribute is awkward to deal with as its relative URI rather than a file path. More on this this later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647929185

From alanb at openjdk.org  Thu Jun 20 17:47:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Jun 2024 17:47:11 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <J7pSRoT9jBwnYtznnH46TZDaJaHStiogsf0_H5kGvHU=.59bfad41-e552-40c7-a874-1d0e954d411d@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
 <J7pSRoT9jBwnYtznnH46TZDaJaHStiogsf0_H5kGvHU=.59bfad41-e552-40c7-a874-1d0e954d411d@github.com>
Message-ID: <QRYmX9kxA82Xkq6QKe-OMTyUiPnKBdufDrUgZNGBO4s=.a8fad8c3-74be-4f66-a5a2-ba43cae5e13d@github.com>

On Thu, 20 Jun 2024 17:40:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update man page header to be consisten with the others
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 113:
> 
>> 111:                     // Class-Path attribute specifies that jars that
>> 112:                     // are not found are simply ignored. Do the same here
>> 113:                     classPathJars.offer(otherJar);
> 
> The expansion of the class path looks right but the Class-Path attribute is awkward to deal with as its relative URI rather than a file path. More on this this later.

Not important for now but the expansion will probably need to a "visited" set to detect cycles (yes, it is possible).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1647934012

From duke at openjdk.org  Thu Jun 20 18:01:22 2024
From: duke at openjdk.org (duke)
Date: Thu, 20 Jun 2024 18:01:22 GMT
Subject: Withdrawn: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <iQ5vLF-epEZcsxwc5Pm8qkMMjDLJJxHW0aCldN7efZM=.b2eda6dd-1889-4737-a20e-4cf6c3bdea19@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18639

From jlu at openjdk.org  Thu Jun 20 18:06:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Jun 2024 18:06:35 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update
Message-ID: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>

Please review this PR which incorporates the ISO 4217 Amendment 177 Update.

Specifically, the introduction of the new currency, Zimbabwe Gold.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/19813/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19813&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334653
  Stats: 14 lines in 4 files changed: 2 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/19813.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19813/head:pull/19813

PR: https://git.openjdk.org/jdk/pull/19813

From syan at openjdk.org  Thu Jun 20 18:07:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 20 Jun 2024 18:07:15 GMT
Subject: Integrated: 8334333: MissingResourceCauseTestRun.java fails if run by
 root
In-Reply-To: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
Message-ID: <kE_KXHQc6XgfLWvR2oXOfv19lElavJ4S9pU5BN2PBTA=.68c21de7-d66a-4b53-bc66-8bab0edeaca9@github.com>

On Sat, 15 Jun 2024 09:56:53 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
> The change has been verified, only change the testcase, no risk.

This pull request has now been integrated.

Changeset: de8ee977
Author:    SendaoYan <syan at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8334333: MissingResourceCauseTestRun.java fails if run by root

Reviewed-by: naoto, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/19732

From naoto at openjdk.org  Thu Jun 20 18:24:15 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jun 2024 18:24:15 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
Message-ID: <KSDsUIl970pSl2VfYTNxdQsyKuJz1PwLF_6EzwBT0NU=.22532f56-6b92-469a-b1c3-223c35cd5192@github.com>

On Thu, 20 Jun 2024 18:01:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which incorporates the ISO 4217 Amendment 177 Update.
> 
> Specifically, the introduction of the new currency, Zimbabwe Gold.

src/java.base/share/classes/sun/util/resources/CurrencyNames.properties line 516:

> 514: zmk=Zambian Kwacha
> 515: zwd=Zimbabwean Dollar (1980-2008)
> 516: zwg=Zimbabwe Gold

It's interesting to see the difference `Zimbabwe` and `Zimbabwean` here. The latter is from CLDR and the name for ZWG is not yet available, so we may need to pull the name from CLDR later.

src/java.base/share/data/currency/CurrencyData.properties line 585:

> 583: ZM=ZMW
> 584: # ZIMBABWE
> 585: ZW=ZWL;2024-08-31-22-00-00;ZWG

JDK switches the currency at the beginning of the transition period. So in this case, it's 6/25. So we don't need to even specify the transition at all, as the next build drop is beyond that date.

test/jdk/java/util/Currency/tablea1.txt line 279:

> 277: YE	YER	886	2
> 278: ZM	ZMW	967	2
> 279: ZW	ZWL	932	2	2024-08-31-22-00-00	ZWG	924	2

Same as above

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1647972810
PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1647967701
PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1647967861

From naoto at openjdk.org  Thu Jun 20 18:39:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jun 2024 18:39:12 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
Message-ID: <QM_jeaCi81iSyHXasFVf_2yhJxbH0u7JvZ0pJ8uw4f4=.ae0e4c4a-caa8-468e-899e-485c51d7c408@github.com>

On Thu, 20 Jun 2024 18:01:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which incorporates the ISO 4217 Amendment 177 Update.
> 
> Specifically, the introduction of the new currency, Zimbabwe Gold.

It's not about this update, but it may be better to rename the `tablea1.txt` data file to `list-one.txt` or something along the line. The name `tablea1` is obsolete, and it is now called "List one: Currency, fund and precious metal codes"
https://www.six-group.com/en/products-services/financial-information/data-standards.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19813#issuecomment-2181303334

From rhalade at openjdk.org  Thu Jun 20 18:39:34 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 20 Jun 2024 18:39:34 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
Message-ID: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>

Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.

-------------

Commit messages:
 - Update comments
 - comment explaining why these are manual
 - update ProblemList
 - 8334441: Mark tests in jdk_security_infra group as manual

Changes: https://git.openjdk.org/jdk/pull/19814/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19814&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334441
  Stats: 160 lines in 10 files changed: 5 ins; 2 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/19814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19814/head:pull/19814

PR: https://git.openjdk.org/jdk/pull/19814

From jvernee at openjdk.org  Thu Jun 20 18:49:15 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 18:49:15 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <wqfGqnyP0-ReMQR0ijahzQXxy26doXTiFmkABdGm72U=.693b0dc3-0cc6-4b07-a0af-f0be2494ea9e@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
 <wqfGqnyP0-ReMQR0ijahzQXxy26doXTiFmkABdGm72U=.693b0dc3-0cc6-4b07-a0af-f0be2494ea9e@github.com>
Message-ID: <x-AoM9sUMee24PA6mAEU9Y60l9b_1d8QNB3VZ1RWuMs=.cb668c47-a667-4b7b-bd1c-032ffabb457d@github.com>

On Thu, 20 Jun 2024 16:13:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Another thing is that using joptsimple gives up a bit of control, e.g. the help output shows the parameter for --class-path as `<String>` where the java launcher and other tools will show "path" or "class path". Same thing with `--release` where it shows `<String>` where jar, javac, and other tools will say "release". Not important for now, just comments from trying out the tool.

It seems that it is possible in joptsimple to attach a description to the argument as well, and get something like:


--module-path <String: module path>   The class path as used at runtime


It looks like we could also customize the argument type and get something like:


--module-path <ModulePath>


(we'd just need to add a `ModulePath` class with a `valueOf(String)` method)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2181315973

From naoto at openjdk.org  Thu Jun 20 19:01:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jun 2024 19:01:12 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
Message-ID: <julUD8fYOzQKcVXJIvBs0XdHwkigMmCB2gNg_sWonjE=.ad9fddd3-91c7-4fbe-a578-7886ad46edb4@github.com>

On Tue, 18 Jun 2024 10:00:33 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

I did not mean to introduce a public API for this change (if we do, the fix cannot be backported). I thought we could define a package private one, but based on your observation, it may get messier... So I agree that falling back to `StringBuf` is the way to go, IMO.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2181339942

From jlu at openjdk.org  Thu Jun 20 19:04:29 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Jun 2024 19:04:29 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update [v2]
In-Reply-To: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
Message-ID: <7yQrJcH_ahIicPSFDiuRpHETGZVXa1xWcMU0q-Z5qG8=.b504e2c7-87d7-4035-806e-ad1d9f5ef6eb@github.com>

> Please review this PR which incorporates the ISO 4217 Amendment 177 Update.
> 
> Specifically, the introduction of the new currency, Zimbabwe Gold.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19813/files
  - new: https://git.openjdk.org/jdk/pull/19813/files/37d1bed4..761d8efc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19813&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19813&range=00-01

  Stats: 11 lines in 5 files changed: 1 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19813.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19813/head:pull/19813

PR: https://git.openjdk.org/jdk/pull/19813

From jlu at openjdk.org  Thu Jun 20 19:04:29 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Jun 2024 19:04:29 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <QM_jeaCi81iSyHXasFVf_2yhJxbH0u7JvZ0pJ8uw4f4=.ae0e4c4a-caa8-468e-899e-485c51d7c408@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <QM_jeaCi81iSyHXasFVf_2yhJxbH0u7JvZ0pJ8uw4f4=.ae0e4c4a-caa8-468e-899e-485c51d7c408@github.com>
Message-ID: <jbCYU6WrRqJGMf986_lLtWAHFWi7-O77aU9BOdjNXnQ=.1b4f5ab5-fd95-4a64-85c5-54985a0fa104@github.com>

On Thu, 20 Jun 2024 18:36:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> It's not about this update, but it may be better to rename the `tablea1.txt` data file to `list-one.txt` or something along the line. The name `tablea1` is obsolete, and it is now called "List one: Currency, fund and precious metal codes" https://www.six-group.com/en/products-services/financial-information/data-standards.html

Without further context, it is hard to infer meaning from `tablea1.txt` or `list-one.txt`. I have renamed it to `ISO4217-codes.txt`, which I think is much more straight forward and provides immediate info.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19813#issuecomment-2181344921

From jlu at openjdk.org  Thu Jun 20 19:04:29 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Jun 2024 19:04:29 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update [v2]
In-Reply-To: <KSDsUIl970pSl2VfYTNxdQsyKuJz1PwLF_6EzwBT0NU=.22532f56-6b92-469a-b1c3-223c35cd5192@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <KSDsUIl970pSl2VfYTNxdQsyKuJz1PwLF_6EzwBT0NU=.22532f56-6b92-469a-b1c3-223c35cd5192@github.com>
Message-ID: <ZYSL4fjcvG21tvK2quHfyF_WlLoR4I2OD5-w3J9ctkc=.d4e9fe38-da0f-4be7-a901-e4156dd41f19@github.com>

On Thu, 20 Jun 2024 18:21:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review comments
>
> src/java.base/share/classes/sun/util/resources/CurrencyNames.properties line 516:
> 
>> 514: zmk=Zambian Kwacha
>> 515: zwd=Zimbabwean Dollar (1980-2008)
>> 516: zwg=Zimbabwe Gold
> 
> It's interesting to see the difference `Zimbabwe` and `Zimbabwean` here. The latter is from CLDR and the name for ZWG is not yet available, so we may need to pull the name from CLDR later.

I see your point. CLDR takes precedence over ISO4217 regarding currencies here?

> src/java.base/share/data/currency/CurrencyData.properties line 585:
> 
>> 583: ZM=ZMW
>> 584: # ZIMBABWE
>> 585: ZW=ZWL;2024-08-31-22-00-00;ZWG
> 
> JDK switches the currency at the beginning of the transition period. So in this case, it's 6/25. So we don't need to even specify the transition at all, as the next build drop is beyond that date.

Good to know. Removed the cutover dates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1648013380
PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1648013361

From duke at openjdk.org  Thu Jun 20 19:17:25 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 20 Jun 2024 19:17:25 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v4]
In-Reply-To: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
Message-ID: <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>

> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2625.125 ? 71.802  ns/op
> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2607.447 ? 46.400  ns/op
> 
> 
> After:
> 
> Benchmark                                                    Mode  Cnt   Score   Error  Units
> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op
> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2615.500 ? 30.771  ns/op
> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2583.892 ? 62.086  ns/op

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Expanding coverage of remove()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19527/files
  - new: https://git.openjdk.org/jdk/pull/19527/files/b1920f7a..2ff93ab6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19527&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19527&range=02-03

  Stats: 35 lines in 2 files changed: 35 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19527/head:pull/19527

PR: https://git.openjdk.org/jdk/pull/19527

From duke at openjdk.org  Thu Jun 20 19:20:12 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 20 Jun 2024 19:20:12 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <DDhpzH5cdDxXuvCWA_5NFWRvtxgmW1gj6D3ceVF8Los=.003e5f3b-c04d-4196-8c8f-428fcbcacb39@github.com>
Message-ID: <kwlr662TpT3kSylSgRPMAY3mq8RG-Fb_mKlQXti1cHQ=.bbe2ff2e-0b00-400f-acc9-77b60cd5bee8@github.com>

On Thu, 6 Jun 2024 12:46:36 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  74.487 ? 1.793  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  27.918 ? 0.759  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.656 ? 0.375  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  15.415 ? 0.489  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.608 ? 0.363  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  15.374 ? 0.260  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  15.688 ? 0.350  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2625.125 ? 71.802  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2607.447 ? 46.400  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                                    Mode  Cnt   Score   Error  Units
>> CopyOnWriteArrayListBenchmark.clear                          avgt    5  75.365 ? 2.092  ns/op
>> CopyOnWriteArrayListBenchmark.clearEmpty                     avgt    5  20.803 ? 0.539  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArray            avgt    5  16.808 ? 0.582  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty       avgt    5  12.980 ? 0.418  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollection       avgt    5  21.627 ? 0.173  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty  avgt    5  12.864 ? 0.408  ns/op
>> CopyOnWriteArrayListBenchmark.createInstanceDefault          avgt    5  12.931 ? 0.255  ns/op
>> CopyOnWriteArrayListBenchmark.readInstance                   avgt   10  2615.500 ? 30.771  ns/op
>> CopyOnWriteArrayListBenchmark.readInstanceEmpty              avgt   10  2583.892 ? 62.086  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding benchmarks for readObject

Thank you!  I've expanded coverage to remove(int) as well.

> One thing that surprises me is the change to remove(Object) to handle the case where the last remaining element is removed. Does that help the application that prompted this change? Part of me wonders if remove(int) needs to do the same as someone will show up sometime to ask.

The application benefits most from the lower footprint of the empty constructors, but I tried to expand the optimization throughout the class.  Clearly I missed a spot, thank you for catching it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2181366938

From jvernee at openjdk.org  Thu Jun 20 19:40:42 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 19:40:42 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v6]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <qcBZF504c9zbrT07csse8TSZxOLnTAEF_6osJHdXcyo=.d4bb4f8f-bc7f-4074-b12f-8deeb08e2a5b@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  review comments Alan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/06f53e31..75c9a6af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=04-05

  Stats: 98 lines in 2 files changed: 59 ins; 26 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From jvernee at openjdk.org  Thu Jun 20 19:40:43 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 19:40:43 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
Message-ID: <JFxVnwSfHRPIBR9Tw9rkO2viNZusJ-8MDL1wH44xEaI=.60fe1572-8c1d-4e20-ad78-e44d549ba15e@github.com>

On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update man page header to be consisten with the others

I've massaged the parsing code to where the help message now looks like this:


...
Option                  Description
------                  -----------
-?, -h, --help          help
--add-modules <String>  List of root modules to scan
--class-path <Path>     The class path as used at runtime
--module-path <Path>    The module path as used at runtime
--print-native-access   print a comma separated list of modules that may
                          perform native access operations. ALL-UNNAMED is used
                          to indicate unnamed modules.
--release <Version>     The runtime version that will run the application
--version               Print version information and exit


I'm not sure if joptsimple has a way to display the option arguments like `<Path>[,<Path>]` to indicate multiple options (at least I couldn't find it immediately).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2181397654

From liach at openjdk.org  Thu Jun 20 19:43:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jun 2024 19:43:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
Message-ID: <cBs9ewHfdjRKMTbzFhd1Vw1_bWKANoaZAE7FjThrQf4=.8f41c9d4-b93a-4846-a050-4e5263765834@github.com>

On Tue, 18 Jun 2024 10:00:33 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

A `jdk.internal.access.StringBuf` that `AbstractStringBuilder` implements may work, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2181402131

From jvernee at openjdk.org  Thu Jun 20 19:45:29 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 20 Jun 2024 19:45:29 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v7]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <UKoCu-vjDZ4cNxaFCwS6tuzI_5sORE4Uol0p2y3bDZw=.de8b6657-ccd9-4bec-bf7e-4eb6fd6f3384@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  add extra test for missing root modules

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/75c9a6af..a4723494

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=05-06

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From naoto at openjdk.org  Thu Jun 20 19:50:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jun 2024 19:50:12 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update [v2]
In-Reply-To: <ZYSL4fjcvG21tvK2quHfyF_WlLoR4I2OD5-w3J9ctkc=.d4e9fe38-da0f-4be7-a901-e4156dd41f19@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <KSDsUIl970pSl2VfYTNxdQsyKuJz1PwLF_6EzwBT0NU=.22532f56-6b92-469a-b1c3-223c35cd5192@github.com>
 <ZYSL4fjcvG21tvK2quHfyF_WlLoR4I2OD5-w3J9ctkc=.d4e9fe38-da0f-4be7-a901-e4156dd41f19@github.com>
Message-ID: <-d44Rl_Lgf3-Jdn-BE5nu8eZ8oQujOD_GfbFaidWXos=.7b6511ac-29b4-4ddb-a489-a3b538c543f7@github.com>

On Thu, 20 Jun 2024 19:01:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/resources/CurrencyNames.properties line 516:
>> 
>>> 514: zmk=Zambian Kwacha
>>> 515: zwd=Zimbabwean Dollar (1980-2008)
>>> 516: zwg=Zimbabwe Gold
>> 
>> It's interesting to see the difference `Zimbabwe` and `Zimbabwean` here. The latter is from CLDR and the name for ZWG is not yet available, so we may need to pull the name from CLDR later.
>
> I see your point. CLDR takes precedence over ISO4217 regarding currencies here?

That is more consistent IMO

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1648054882

From naoto at openjdk.org  Thu Jun 20 19:54:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Jun 2024 19:54:08 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <jbCYU6WrRqJGMf986_lLtWAHFWi7-O77aU9BOdjNXnQ=.1b4f5ab5-fd95-4a64-85c5-54985a0fa104@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <QM_jeaCi81iSyHXasFVf_2yhJxbH0u7JvZ0pJ8uw4f4=.ae0e4c4a-caa8-468e-899e-485c51d7c408@github.com>
 <jbCYU6WrRqJGMf986_lLtWAHFWi7-O77aU9BOdjNXnQ=.1b4f5ab5-fd95-4a64-85c5-54985a0fa104@github.com>
Message-ID: <vu8gd2JFKSFcTgu489kvAlIkRT0xEk8EIFtePPH-BW8=.e2767633-2074-4073-8455-1e89153d2773@github.com>

On Thu, 20 Jun 2024 19:01:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> > It's not about this update, but it may be better to rename the `tablea1.txt` data file to `list-one.txt` or something along the line. The name `tablea1` is obsolete, and it is now called "List one: Currency, fund and precious metal codes" https://www.six-group.com/en/products-services/financial-information/data-standards.html
> 
> Without further context, it is hard to infer meaning from `tablea1.txt` or `list-one.txt`. I have renamed it to `ISO4217-codes.txt`, which I think is much more straight forward and provides immediate info.

The point I wanted to make is that the text file only contains the "list one" part of the ISO 4217. Looks like "list two" is a subset of list one (as they are funds codes), but "list three", which lists historic codes, is definitely not covered in that file.

I am ok with the suggested name, but then we should include some comments mentioning this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19813#issuecomment-2181418086

From kevinw at openjdk.org  Thu Jun 20 20:07:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 20 Jun 2024 20:07:20 GMT
Subject: [jdk23] RFR: 8333344: JMX attaching of Subject does not work when
 security manager not allowed
Message-ID: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>

8333344: JMX attaching of Subject does not work when security manager not allowed

-------------

Commit messages:
 - Backport bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f

Changes: https://git.openjdk.org/jdk/pull/19810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333344
  Stats: 162 lines in 17 files changed: 113 ins; 3 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/19810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19810/head:pull/19810

PR: https://git.openjdk.org/jdk/pull/19810

From jlu at openjdk.org  Thu Jun 20 20:12:39 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Jun 2024 20:12:39 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update [v3]
In-Reply-To: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
Message-ID: <7Kvrfh2yG5gpA80vhiiCVch-LymiU2RlsIS2rVx-0Xs=.43323ea3-4c0b-4057-83df-5a11c04264b0@github.com>

> Please review this PR which incorporates the ISO 4217 Amendment 177 Update.
> 
> Specifically, the introduction of the new currency, Zimbabwe Gold.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review: change txt name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19813/files
  - new: https://git.openjdk.org/jdk/pull/19813/files/761d8efc..58c09005

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19813&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19813&range=01-02

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19813.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19813/head:pull/19813

PR: https://git.openjdk.org/jdk/pull/19813

From jlu at openjdk.org  Thu Jun 20 20:12:39 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Jun 2024 20:12:39 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <vu8gd2JFKSFcTgu489kvAlIkRT0xEk8EIFtePPH-BW8=.e2767633-2074-4073-8455-1e89153d2773@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <QM_jeaCi81iSyHXasFVf_2yhJxbH0u7JvZ0pJ8uw4f4=.ae0e4c4a-caa8-468e-899e-485c51d7c408@github.com>
 <jbCYU6WrRqJGMf986_lLtWAHFWi7-O77aU9BOdjNXnQ=.1b4f5ab5-fd95-4a64-85c5-54985a0fa104@github.com>
 <vu8gd2JFKSFcTgu489kvAlIkRT0xEk8EIFtePPH-BW8=.e2767633-2074-4073-8455-1e89153d2773@github.com>
Message-ID: <9zQff4mFJPG1pPpEnyhnlKxLfvrCLNKceMkL_WdlPw8=.19fb85bd-b5c3-4937-9cce-ee1c29a892e9@github.com>

On Thu, 20 Jun 2024 19:51:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The point I wanted to make is that the text file only contains the "list one" part of the ISO 4217. 

Renamed the file name to "ISO4217-list-one.txt"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19813#issuecomment-2181478826

From liach at openjdk.org  Thu Jun 20 20:16:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jun 2024 20:16:21 GMT
Subject: [jdk23] RFR: 8333854: IllegalAccessError with proxies after
 JDK-8332457
Message-ID: <WGrnxZdxr_gKg43KmfVaEH-YRQdrxwU5-hdsgNGzFtc=.fb280ea0-b829-4d79-9c92-209ebfca8036@github.com>

Please review this patch, which is a backport of the fix in #19615 to JDK 23.

This is not a clean patch, because the old patch was done on JDK-8333479 (#19585) which was absent in JDK 23; however, the conflicts were small, and the only real changes were that `methodTypeDesc` and `classDesc` from `ConstantUtils` were not available, so the original approaches were retained. There is also import adjustments.

Testing: tier 1-3

-------------

Commit messages:
 - 8333854: IllegalAccessError with proxies after JDK-8332457

Changes: https://git.openjdk.org/jdk/pull/19815/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19815&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333854
  Stats: 238 lines in 2 files changed: 161 ins; 9 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/19815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19815/head:pull/19815

PR: https://git.openjdk.org/jdk/pull/19815

From srl at openjdk.org  Thu Jun 20 20:33:10 2024
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 20 Jun 2024 20:33:10 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update [v3]
In-Reply-To: <-d44Rl_Lgf3-Jdn-BE5nu8eZ8oQujOD_GfbFaidWXos=.7b6511ac-29b4-4ddb-a489-a3b538c543f7@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <KSDsUIl970pSl2VfYTNxdQsyKuJz1PwLF_6EzwBT0NU=.22532f56-6b92-469a-b1c3-223c35cd5192@github.com>
 <ZYSL4fjcvG21tvK2quHfyF_WlLoR4I2OD5-w3J9ctkc=.d4e9fe38-da0f-4be7-a901-e4156dd41f19@github.com>
 <-d44Rl_Lgf3-Jdn-BE5nu8eZ8oQujOD_GfbFaidWXos=.7b6511ac-29b4-4ddb-a489-a3b538c543f7@github.com>
Message-ID: <db3oNirMQ-ofzu5XPjWDQ7VuyZl56l9h-K-fHDdm0Ag=.6d6d0e8e-4603-4181-8672-9609142c5052@github.com>

On Thu, 20 Jun 2024 19:47:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I see your point. CLDR takes precedence over ISO4217 regarding currencies here?
>
> That is more consistent IMO

CLDR is aware of this change but hasn't added it yet. We're mid cycle so it won't be much more than metadata this round due to timing.  https://unicode-org.atlassian.net/issues/CLDR-17751 if you want to track.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1648094193

From jlu at openjdk.org  Thu Jun 20 21:56:13 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Jun 2024 21:56:13 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <bwzVGsQPnmZgto9MjL8VC3TJK6ulyn_itq-RYBkEngw=.f79d0520-2b38-4e6f-8c5f-458fccba2e7c@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <bwzVGsQPnmZgto9MjL8VC3TJK6ulyn_itq-RYBkEngw=.f79d0520-2b38-4e6f-8c5f-458fccba2e7c@github.com>
Message-ID: <chyUATkwMLuzNBY9RMVc76AENpjfZTk33Z9qi9lc1f8=.93b45ae7-a5ab-465d-9dbc-5992e62481d7@github.com>

On Wed, 19 Jun 2024 02:05:28 GMT, lingjun-cg <duke at openjdk.org> wrote:

> It requires append(int), but the Appendable has no such method.

If via `Appendable` we don't have access to `append(int)`, can we simply `append(String.valueOf(int))`.
And similarly for `append(char[], int, int)`, can we `append(String.valueOf(char[], int, int))`.

According to the method descriptions in `AbstractStringBuilder`, this should behaviorally be the same.
That way we don't have to add any new classes, and can continue with the generic implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2181620101

From jiangli at openjdk.org  Fri Jun 21 00:30:18 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 00:30:18 GMT
Subject: RFR: 8333268: Fixes for static build [v2]
In-Reply-To: <0dEUfxGGkUTfm3TPCNbBxREmGZScyLCXwKv9-7AFf3M=.b69446a9-0828-4a99-a677-8f948ea612b6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <hGVURwSbHviIo4QVpM6u_RNZysJwpEemBkCVI8N9bp0=.e99aa609-66e7-47da-864b-98221064ad63@github.com>
 <0dEUfxGGkUTfm3TPCNbBxREmGZScyLCXwKv9-7AFf3M=.b69446a9-0828-4a99-a677-8f948ea612b6@github.com>
Message-ID: <fqlIj7uRZR0hjJqk-ySGsjDP5XhM756sF2_8fC-10-w=.83a9a715-2adf-4305-af56-408521e2e33b@github.com>

On Tue, 18 Jun 2024 17:57:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into static-linking-progress
>>  - Merge branch 'master' into static-linking-progress
>>  - Move the exported JVM_IsStaticallyLinked to a better location
>>  - Use runtime lookup of static vs dynamic instead of #ifdef STATIC_BUILD
>>  - Copy fix for init_system_properties_values on linux
>>  - Make sure we do not try to build static libraries on Windows
>>  - 8333268: Fixes for static build
>
> src/hotspot/os/linux/os_linux.cpp line 605:
> 
>> 603: 
>> 604:       // Get rid of /{client|server|hotspot}, if binary is libjvm.so.
>> 605:       // Or, cut off /<binary_name>.
> 
> @jianglizhou This code is based on changes in the Hermetic Java repo, but I do not fully understand neither the comment nor what the purpose is. If you could explain this a bit I'd be grateful.

The specific related commit in the hermetic Java branch is https://github.com/openjdk/leyden/commit/53aa8f0cf418ab5f435a4b9996c7754fb8505d4b. 

The change in os_linux.cpp here is to make sure  that the libjvm.so related path manipulation is conditionally done only. The check at line 599 looks for "/libjvm.so" substring, so we only chop off (`*pslash = `\0` at line 601) that part when necessary. In the static JDK case, there is no `libjvm.so` and the path string is `<jdk_path>/bin/javastatic`, which should not be affected. Otherwise, it could fail.

I found the code was not very easy to follow when running into problems and fixing for static support. So I added a bit more comments in the code here. The comment above about `/{client|server|hotspot}` was there originally. I think we no longer have those directories. We can cleanup that later, since it needs some more testing.

@magicus, thanks a lot for extracting/reworking/cleaning-up the static Java changes from the hermetic Java branch. That's a substantial amount of work!

I have one quick comment about the removal of `STATIC_LIB_EXCLUDE_OBJS` changes. Will post it as separate comment for the related code. 

I'll also look closely of the vm & jdk changes and compare those with the changes in the hermetic Java branch this week.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1648283151

From syan at openjdk.org  Fri Jun 21 00:43:19 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 00:43:19 GMT
Subject: RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root [v4]
In-Reply-To: <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>
References: <TIwTPu1AMeq69IjfJ1ImijthOGZ99Bl1OdR9aPA3E38=.1142336f-70ce-45d5-8e0e-2b880b065206@github.com>
 <3l1cwZlz1VoyWNznQDG-FJoOQBBljQN2G3BOd1-FvI0=.302446c5-450f-4ce7-ac93-0115b4a4440c@github.com>
Message-ID: <yPEMMajHledCDBy_xLlaImXnXGYtSQBqxYBA2PcM2VQ=.89cab1f6-588f-4512-bb0e-56109ababe1f@github.com>

On Tue, 18 Jun 2024 07:41:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Testcase `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java` run fails with root user privileged. I think it's necessary to skip this testcase when user is root.
>> Why run the jtreg test by root user? It's because during rpmbuild process for linux distribution of JDK, root user is the default user to build the openjdk, also is the default user to run the `make test-tier1`, this PR make this testcase more robustness.
>> The change has been verified, only change the testcase, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id 8334333 to jtreg tag @bug

Thanks for the sponsor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19732#issuecomment-2181783165

From jiangli at openjdk.org  Fri Jun 21 00:48:12 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 00:48:12 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <shD8VZcEEUpy53MVuI83DzIpZsUlzeEYs4H-y3Jg0Zw=.fce27cca-3d9a-4d92-9cf5-4ff992b0cbb8@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

make/modules/java.base/lib/CoreLibraries.gmk line 148:

> 146:           $(LIBJLI_EXTRA_FILE_LIST))
> 147: 
> 148:   # Do not include these libz objects in the static libjli library.

Why this is no longer needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1648290693

From jiangli at openjdk.org  Fri Jun 21 00:51:17 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 00:51:17 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <r6KjeY8WrfQDRZxEP8F8uLINEfqUwlu__RItYg4N_Lw=.eb4b1de3-dfe3-4bed-b90c-feb3ebc10e11@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

make/modules/java.desktop/lib/AwtLibraries.gmk line 257:

> 255:       JDK_LIBS := libawt java.base:libjava, \
> 256:       LIBS_unix := $(LIBDL) $(LIBM) $(X_LIBS) -lX11 -lXext -lXi -lXrender \
> 257:           -lXtst, \

Same question as for the STATIC_LIB_EXCLUDE_OBJS change with `libjli`. Are the duplicate symbol issues resolved by symbol hiding?

I think it's still better to not include those .o files to avoid unnecessary footprint overhead in the binary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1648292220

From jiangli at openjdk.org  Fri Jun 21 00:54:12 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 00:54:12 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <1fgMACYXrz2wEFaJ22HNdkjUu5MGpVjUu7oG14oFvzc=.7f6bb2d8-4ad8-4e2c-a781-182e91908d07@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

make/common/native/Link.gmk line 72:

> 70: define CreateStaticLibrary
> 71:   # Include partial linking when building the static library with clang on linux
> 72:   ifeq ($(call isTargetOs, linux macosx), true)

Is this mainly for `clang` support for now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1648293391

From syan at openjdk.org  Fri Jun 21 00:57:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 00:57:39 GMT
Subject: [jdk23] RFR: 8334333: MissingResourceCauseTestRun.java fails if run by
 root
Message-ID: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>

Hi all,

This pull request contains a backport of commit [de8ee977](https://github.com/openjdk/jdk/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by SendaoYan on 20 Jun 2024 and was reviewed by Naoto Sato and Justin Lu.

Thanks!

-------------

Commit messages:
 - Backport de8ee97718d7e12b541b310cf5b67f3e10e91ad9

Changes: https://git.openjdk.org/jdk/pull/19817/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19817&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334333
  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19817.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19817/head:pull/19817

PR: https://git.openjdk.org/jdk/pull/19817

From naoto at openjdk.org  Fri Jun 21 02:01:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Jun 2024 02:01:14 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update [v3]
In-Reply-To: <db3oNirMQ-ofzu5XPjWDQ7VuyZl56l9h-K-fHDdm0Ag=.6d6d0e8e-4603-4181-8672-9609142c5052@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <KSDsUIl970pSl2VfYTNxdQsyKuJz1PwLF_6EzwBT0NU=.22532f56-6b92-469a-b1c3-223c35cd5192@github.com>
 <ZYSL4fjcvG21tvK2quHfyF_WlLoR4I2OD5-w3J9ctkc=.d4e9fe38-da0f-4be7-a901-e4156dd41f19@github.com>
 <-d44Rl_Lgf3-Jdn-BE5nu8eZ8oQujOD_GfbFaidWXos=.7b6511ac-29b4-4ddb-a489-a3b538c543f7@github.com>
 <db3oNirMQ-ofzu5XPjWDQ7VuyZl56l9h-K-fHDdm0Ag=.6d6d0e8e-4603-4181-8672-9609142c5052@github.com>
Message-ID: <PjfozyFSOSyW0-px2No9nWxI4rFLhwM8n3TT45m30yM=.880ca4bd-0fae-4d5d-a94f-358531805091@github.com>

On Thu, 20 Jun 2024 20:30:36 GMT, Steven Loomis <srl at openjdk.org> wrote:

> CLDR is aware of this change but hasn't added it yet. We're mid cycle so it won't be much more than metadata this round due to timing. https://unicode-org.atlassian.net/issues/CLDR-17751 if you want to track.

Out of curiosity, what's the rationale behind the currency name change from "Zimbabwe Dollar" (ISO 4217 definition) to "Zimbabwean Dollar"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1648324116

From duke at openjdk.org  Fri Jun 21 02:13:18 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 21 Jun 2024 02:13:18 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <chyUATkwMLuzNBY9RMVc76AENpjfZTk33Z9qi9lc1f8=.93b45ae7-a5ab-465d-9dbc-5992e62481d7@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <bwzVGsQPnmZgto9MjL8VC3TJK6ulyn_itq-RYBkEngw=.f79d0520-2b38-4e6f-8c5f-458fccba2e7c@github.com>
 <chyUATkwMLuzNBY9RMVc76AENpjfZTk33Z9qi9lc1f8=.93b45ae7-a5ab-465d-9dbc-5992e62481d7@github.com>
Message-ID: <El-GvNiBNotMNr7lkQogDGi4vCI-rOMYOAZNZEp-S6E=.c12af922-9f2d-4666-a4a1-d4c453b34e18@github.com>

On Thu, 20 Jun 2024 21:53:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> > It requires append(int), but the Appendable has no such method.
> 
> If via `Appendable` we don't have access to `append(int)`, can we simply `append(String.valueOf(int))`. And similarly for `append(char[], int, int)`, can we `append(String.valueOf(char[], int, int))`.
> 
> According to the method descriptions in `AbstractStringBuilder`, this should behaviorally be the same. That way we don't have to add any new classes, and can continue with the generic implementation.

If do that ,there is some performance degradation.

Benchmark                                                      Mode  Cnt   Score   Error  Units
AppendableTest.tesAppendableAppendCharAscii                    avgt   50  33.628 ? 0.263  ns/op
AppendableTest.tesAppendableAppendCharMixNoAsciiChars          avgt   50  33.522 ? 0.245  ns/op
AppendableTest.testAppendableAppendInt                         avgt   50  32.602 ? 0.186  ns/op
AppendableTest.testStringBufferAppendCharArrayAscii            avgt   50  31.028 ? 0.134  ns/op
AppendableTest.testStringBufferAppendCharArrayMixNoAsciiChars  avgt   50  31.075 ? 0.158  ns/op
AppendableTest.testStringBufferAppendInt                       avgt   50  25.706 ? 0.268  ns/op



@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class AppendableTest {

    private StringBuffer sb;
    private Appendable appendable;
    private char[] asciiChars;
    private char[] mixNoAsciiChars;

    @Setup(Level.Iteration)
    public void setup() {
        sb = new StringBuffer();
        appendable = sb;
        asciiChars = "Criticism appears to Anatole France the most recent and possibly the ultimate evolution".toCharArray();
        mixNoAsciiChars = "The ???? above mentioned two volumes of poetry were followed by many works in prose, which we shall notice. France?s critical writings".toCharArray();
    }

    @Benchmark
    public void testStringBufferAppendInt() throws InterruptedException {
        sb.append(12345890);
    }

    @Benchmark
    public void testAppendableAppendInt() throws InterruptedException, IOException {
        appendable.append(String.valueOf(12345890));
    }

    @Benchmark
    public void testStringBufferAppendCharArrayAscii() throws InterruptedException {
        sb.append(asciiChars, 40, 18);
    }

    @Benchmark
    public void tesAppendableAppendCharAscii() throws InterruptedException, IOException {
        appendable.append(new String(asciiChars, 40, 18));
    }

    @Benchmark
    public void testStringBufferAppendCharArrayMixNoAsciiChars() throws InterruptedException {
        sb.append(mixNoAsciiChars, 40, 18);
    }

    @Benchmark
    public void tesAppendableAppendCharMixNoAsciiChars() throws InterruptedException, IOException {
        appendable.append(new String(mixNoAsciiChars, 40, 18));
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2181851223

From duke at openjdk.org  Fri Jun 21 07:11:40 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 21 Jun 2024 07:11:40 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v9]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <9QS2E2FuOsCEoy8Iu_Fw4_IXZhi8dCy7nZdHrnWnKAk=.aa26f47c-ba42-4b62-a876-0bc3b398b2bf@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/1fde6a60..9a6f646f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=07-08

  Stats: 348 lines in 11 files changed: 198 ins; 65 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From duke at openjdk.org  Fri Jun 21 07:25:27 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 21 Jun 2024 07:25:27 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v10]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <zipIuEv-5EWDGQOywhB1igaVbC5dkuN8NHru0oljHBE=.8584e76c-fac0-4708-b2eb-68ed33c3a840@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/9a6f646f..67c724c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From duke at openjdk.org  Fri Jun 21 07:30:15 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 21 Jun 2024 07:30:15 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v10]
In-Reply-To: <zipIuEv-5EWDGQOywhB1igaVbC5dkuN8NHru0oljHBE=.8584e76c-fac0-4708-b2eb-68ed33c3a840@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <zipIuEv-5EWDGQOywhB1igaVbC5dkuN8NHru0oljHBE=.8584e76c-fac0-4708-b2eb-68ed33c3a840@github.com>
Message-ID: <uKYmJwlCak-oRaXQY7w3mVqDxyClQAXh8urJBXr8DBY=.9ec82757-9a02-4a5a-b1f3-7b6a06e5fcaf@github.com>

On Fri, 21 Jun 2024 07:25:27 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Updates:
1. Add package private interface `StringBuf` into `Format` as an inner class. Like `java.text.Format.FieldDelegate` that used by `Format` implemetations.
2. Add `boolean isInternalSubclass` into all `Format` implemetations that in package `java.text`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2182167568

From hgreule at openjdk.org  Fri Jun 21 07:45:34 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Fri, 21 Jun 2024 07:45:34 GMT
Subject: RFR: 8334708: FFM: two javadoc problems
Message-ID: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>

Addresses two simple problems regarding javadocs in the FFM API.

-------------

Commit messages:
 - fix two javadoc problems in FFM

Changes: https://git.openjdk.org/jdk/pull/19820/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19820&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334708
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19820/head:pull/19820

PR: https://git.openjdk.org/jdk/pull/19820

From mcimadamore at openjdk.org  Fri Jun 21 08:59:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Jun 2024 08:59:11 GMT
Subject: RFR: 8334708: FFM: two javadoc problems
In-Reply-To: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
References: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
Message-ID: <u_vJIoTRJY0vy1MteL_Mah4edIZE2a1BtgGxHQ-c5Q0=.5463ae2a-e83d-45ea-9cfc-2b4724cf6f57@github.com>

On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Addresses two simple problems regarding javadocs in the FFM API.

Thanks! Should we backport to 23?

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19820#pullrequestreview-2132155399

From dfuchs at openjdk.org  Fri Jun 21 09:39:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Jun 2024 09:39:10 GMT
Subject: [jdk23] RFR: 8333344: JMX attaching of Subject does not work when
 security manager not allowed
In-Reply-To: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
References: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
Message-ID: <CPqgovD--dzKQyoJwjoku3og1Ma4z1m8GonV0SSxIDc=.9f616f3a-1013-4ed1-a147-18d82178b84b@github.com>

On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8333344: JMX attaching of Subject does not work when security manager not allowed

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19810#pullrequestreview-2132226211

From kevinw at openjdk.org  Fri Jun 21 09:39:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 09:39:11 GMT
Subject: [jdk23] RFR: 8333344: JMX attaching of Subject does not work when
 security manager not allowed
In-Reply-To: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
References: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
Message-ID: <WvmoXagyDvZH_hI4oRJCMjOBLHls13YzOZodNWm0szE=.5e045404-6e7b-4964-b038-ab19294f5f27@github.com>

On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8333344: JMX attaching of Subject does not work when security manager not allowed

Thanks Daniel.  Testing automated and manual looks good in 24 and in this 23 backport, so I'll get this integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19810#issuecomment-2182392102

From kevinw at openjdk.org  Fri Jun 21 10:12:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 10:12:14 GMT
Subject: [jdk23] Integrated: 8333344: JMX attaching of Subject does not work
 when security manager not allowed
In-Reply-To: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
References: <TA_VD3j-QjSZKMP6iLDPQEWcApiiDR8JdVXfNHTQbWA=.24c445b1-ecfd-4c04-86e2-8c2f9850fae4@github.com>
Message-ID: <Vsnat6Klsc1cdKNeXujA3H1UtZpbMjya3d41SADlh9s=.2bde1226-6f6a-497f-943e-e354652db574@github.com>

On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 8333344: JMX attaching of Subject does not work when security manager not allowed

This pull request has now been integrated.

Changeset: 23f2c97f
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23f2c97f4ce42316fd51290175b01b41bcc24f6b
Stats:     162 lines in 17 files changed: 113 ins; 3 del; 46 mod

8333344: JMX attaching of Subject does not work when security manager not allowed

Reviewed-by: dfuchs
Backport-of: bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f

-------------

PR: https://git.openjdk.org/jdk/pull/19810

From duke at openjdk.org  Fri Jun 21 11:37:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 21 Jun 2024 11:37:10 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v8]
In-Reply-To: <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>
 <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
Message-ID: <W5kyS1qQSlXTEZEa4ovtCrh5t6jX50hshLOgExyPAiQ=.5dd405a2-830b-484b-b3e3-4eaca3cd8034@github.com>

On Sun, 16 Jun 2024 21:00:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code format
>
> src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 171:
> 
>> 169:     /* Using the deprecated constructor enhances performance */
>> 170:     @SuppressWarnings("deprecation")
>> 171:     static String charsToString(byte[] str, int index) {
> 
> This should be named something like `asciiBytesToString` now. Perhaps `ToDecimal.LATIN1` can be renamed `ASCII`, too.

In JDK internal string processing, LATIN1 and UTF16 appear in pairs, so I think LATIN1 is better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1648846026

From kevinw at openjdk.org  Fri Jun 21 11:42:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 11:42:24 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v5]
In-Reply-To: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
Message-ID: <POzv0bdm5swCUcSeVFOBDlu3sK4dvKTxXowSZHf5p64=.8b2dba8e-b455-496b-a455-7506290517fa@github.com>

> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
> 
> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

Kevin Walls 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 remote-tracking branch 'upstream/master' into 8327793_jstatd_deprecate
 - Remove annotations
 - Replace (C)
 - Remove annotations
 - No annotations for src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote
 - Remove tmp file
 - Annotations
 - Annotations
 - Merge remote-tracking branch 'upstream/master' into 8327793_jstatd_deprecate
 - Basic deprecation of module, jstatd prints warning.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19658/files
  - new: https://git.openjdk.org/jdk/pull/19658/files/ed386505..3c7e86a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=03-04

  Stats: 27075 lines in 733 files changed: 18445 ins; 5705 del; 2925 mod
  Patch: https://git.openjdk.org/jdk/pull/19658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19658/head:pull/19658

PR: https://git.openjdk.org/jdk/pull/19658

From kevinw at openjdk.org  Fri Jun 21 11:45:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 11:45:37 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v6]
In-Reply-To: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
Message-ID: <AMNCoiUmktLFigallYVrri5DMeGXN2WS4oiHMPsPM3Q=.8261f593-f7c0-4b1d-986f-3fb1524ad003@github.com>

> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
> 
> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  wording

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19658/files
  - new: https://git.openjdk.org/jdk/pull/19658/files/3c7e86a1..1a240155

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19658/head:pull/19658

PR: https://git.openjdk.org/jdk/pull/19658

From asotona at openjdk.org  Fri Jun 21 11:51:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 21 Jun 2024 11:51:11 GMT
Subject: [jdk23] RFR: 8333854: IllegalAccessError with proxies after
 JDK-8332457
In-Reply-To: <WGrnxZdxr_gKg43KmfVaEH-YRQdrxwU5-hdsgNGzFtc=.fb280ea0-b829-4d79-9c92-209ebfca8036@github.com>
References: <WGrnxZdxr_gKg43KmfVaEH-YRQdrxwU5-hdsgNGzFtc=.fb280ea0-b829-4d79-9c92-209ebfca8036@github.com>
Message-ID: <pxm6gM1GRjjyL95wK3CovL3MtzGUiH-yE-hc9KrzFVI=.44048da0-5808-4caa-9838-28b3877db9b8@github.com>

On Thu, 20 Jun 2024 20:11:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch, which is a backport of the fix in #19615 to JDK 23.
> 
> This is not a clean patch, because the old patch was done on JDK-8333479 (#19585) which was absent in JDK 23; however, the conflicts were small, and the only real changes were that `methodTypeDesc` and `classDesc` from `ConstantUtils` were not available, so the original approaches were retained. There is also import adjustments.
> 
> Testing: tier 1-3

It looks good to me, thanks.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19815#pullrequestreview-2132482150

From asotona at openjdk.org  Fri Jun 21 12:00:31 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 21 Jun 2024 12:00:31 GMT
Subject: RFR: 8334714: Class-File API leaves preview
Message-ID: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>

Class-File API is leaving preview.
This is a removal of all `@PreviewFeature` annotations from Class-File API.
It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - bumped @since tag
 - 8334714: Class-File API leaves preview

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334714
  Stats: 718 lines in 166 files changed: 0 ins; 479 del; 239 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

PR: https://git.openjdk.org/jdk/pull/19826

From liach at openjdk.org  Fri Jun 21 12:27:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Jun 2024 12:27:10 GMT
Subject: RFR: 8334714: Class-File API leaves preview
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <tjeQFDe_SHcRbXK4yPcoHSVDh-u-zUtOdB-rK6oHMPk=.ad2dd597-c461-4ff6-b907-8d04dc09f0a5@github.com>

On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Do we intend to do it after we finish our planned API changes or as soon as possible? Also we might need to look at the preview-enabled test treatments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2182652273

From alanb at openjdk.org  Fri Jun 21 12:31:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Jun 2024 12:31:12 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v4]
In-Reply-To: <LISaI-LJ9qv_-K2tcQi9-LTTf3QEehsNjswllnhl-40=.717b32eb-65bc-441c-8a63-0eb9e193627d@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>
 <d3aggiAGNe4LBHeFafvI3QEbwXBrc-Z9BE1yKAa9lYs=.6bbb0616-b7b5-477b-9deb-9776c654148f@github.com>
 <wIhpHcj6H6xPj3tHaw9xDvxiUuvFr1DvT2MnUVxHqBo=.c6a93b7f-8dda-4fc5-8206-f71bdcb7574a@github.com>
 <LISaI-LJ9qv_-K2tcQi9-LTTf3QEehsNjswllnhl-40=.717b32eb-65bc-441c-8a63-0eb9e193627d@github.com>
Message-ID: <OrA7zRnimXlAxG5AlOd690kFSoVrM3SbbYnD8_UT70o=.a13fa729-2c10-4e3a-a893-9f64b75591b5@github.com>

On Tue, 11 Jun 2024 21:09:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I also think a period at the end is not necessary.
>
> For the Security Manager, the warning was worded a little differently:
> 
> "WARNING: The Security Manager is deprecated and will be removed in a future release"
> 
> I think that wording is more clear. The current wording could be confusing because JDK 24 is when jstatd is deprecated for removal, and not a future release. The wording above is more definitive for those that may not understand what "deprecated for removal" means. Thus, I suggest:
> 
> "WARNING: jstatd is deprecated and will be removed in a future release"

@kevinjwalls Are you planning to move to "WARNING" as has been suggested in the previous comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19658#discussion_r1648897498

From alanb at openjdk.org  Fri Jun 21 12:36:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Jun 2024 12:36:08 GMT
Subject: RFR: 8334714: Class-File API leaves preview
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <rR6LOT5_HGEctIfpG-Iqy5dEAXCugPxXXPitJYP6kmU=.b8c70a9f-bbba-46c7-baaa-c2590e01ed12@github.com>

On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Looks like this has been accidentally created as a sub-task of the JEP issue, I assume you'll fix that. Will there be another issue to update the tests and drop `@enablePreview`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2182663458

From asotona at openjdk.org  Fri Jun 21 12:36:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 21 Jun 2024 12:36:09 GMT
Subject: RFR: 8334714: Class-File API leaves preview
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <IpKw9PdbQGx7-59LYepO5CF3jYCiVvk-79zLZ3pF8Vo=.c52a5c30-70a0-402b-9569-55dd28aacd17@github.com>

On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Any potential API changes should be merged first, to avoid impression of changing a non-preview API.
However any discussion and approval processes of API and documentation changes should not block the JEP process (and each other).

Cleaning up preview-enabled tests has a lower priority and should follow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2182666656

From asotona at openjdk.org  Fri Jun 21 12:40:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 21 Jun 2024 12:40:09 GMT
Subject: RFR: 8334714: Class-File API leaves preview
In-Reply-To: <rR6LOT5_HGEctIfpG-Iqy5dEAXCugPxXXPitJYP6kmU=.b8c70a9f-bbba-46c7-baaa-c2590e01ed12@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <rR6LOT5_HGEctIfpG-Iqy5dEAXCugPxXXPitJYP6kmU=.b8c70a9f-bbba-46c7-baaa-c2590e01ed12@github.com>
Message-ID: <Y2Okpnj_tjKvIKaNnbjGXO17mWCNAO9te_GBnvJJ_pg=.d0786ebb-e772-4777-a88a-7fb00f5a43c9@github.com>

On Fri, 21 Jun 2024 12:31:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks like this has been accidentally created as a sub-task of the JEP issue, I assume you'll fix that. Will there be another issue to update the tests and drop `@enablePreview`?

I thought the implementation is usually created as a subtask of JEP, however I can make it a standalone bug if neede.

Yes, there will be follow up task to clean all the `@enablePreview` mess, I'll create it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2182673557

From kevinw at openjdk.org  Fri Jun 21 12:55:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 12:55:11 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v4]
In-Reply-To: <OrA7zRnimXlAxG5AlOd690kFSoVrM3SbbYnD8_UT70o=.a13fa729-2c10-4e3a-a893-9f64b75591b5@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <FVwFYnqB1hkJ54yDNsH1oZWLaGLtVnCYk88u5oxx8hg=.a6e8d8f4-85e0-48e9-aca3-511b3ee03859@github.com>
 <d3aggiAGNe4LBHeFafvI3QEbwXBrc-Z9BE1yKAa9lYs=.6bbb0616-b7b5-477b-9deb-9776c654148f@github.com>
 <wIhpHcj6H6xPj3tHaw9xDvxiUuvFr1DvT2MnUVxHqBo=.c6a93b7f-8dda-4fc5-8206-f71bdcb7574a@github.com>
 <LISaI-LJ9qv_-K2tcQi9-LTTf3QEehsNjswllnhl-40=.717b32eb-65bc-441c-8a63-0eb9e193627d@github.com>
 <OrA7zRnimXlAxG5AlOd690kFSoVrM3SbbYnD8_UT70o=.a13fa729-2c10-4e3a-a893-9f64b75591b5@github.com>
Message-ID: <oBBJiQ-m3L8TgvASSVLTZXl6yOwvtNxN-GLkNttHI-g=.f61f1143-eb97-456c-ad7b-268d1d668304@github.com>

On Fri, 21 Jun 2024 12:28:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> For the Security Manager, the warning was worded a little differently:
>> 
>> "WARNING: The Security Manager is deprecated and will be removed in a future release"
>> 
>> I think that wording is more clear. The current wording could be confusing because JDK 24 is when jstatd is deprecated for removal, and not a future release. The wording above is more definitive for those that may not understand what "deprecated for removal" means. Thus, I suggest:
>> 
>> "WARNING: jstatd is deprecated and will be removed in a future release"
>
> @kevinjwalls Are you planning to move to "WARNING" as has been suggested in the previous comments.

No, I was just pausing while the pre-submit checks ran again.  I did investigate, the JDK seems fairly evenly split on WARNING vs Warning.  This message should not be around for many releases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19658#discussion_r1648922812

From alanb at openjdk.org  Fri Jun 21 13:02:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Jun 2024 13:02:12 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <JFxVnwSfHRPIBR9Tw9rkO2viNZusJ-8MDL1wH44xEaI=.60fe1572-8c1d-4e20-ad78-e44d549ba15e@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
 <JFxVnwSfHRPIBR9Tw9rkO2viNZusJ-8MDL1wH44xEaI=.60fe1572-8c1d-4e20-ad78-e44d549ba15e@github.com>
Message-ID: <teWZz-yzy3JwQzY_EX8dmZsFzeRURrUIRwYhYt3R5L8=.069e0228-8af4-4582-a2b5-fa91ce48c761@github.com>

On Thu, 20 Jun 2024 19:37:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I've massaged the parsing code to where the help message now looks like this:

It is better but it might mean looking at HelpFormatter as you mentioned,. Right now the usage message `--add-modules <String>` whereas the java --help will print `--add-modules <module name>[,<module name>...]` and javac --help will print `--add-modules <module>(,<module>)*`. 

Not super important for now, I think the main thing with this PR is getting agreement to add a tool with a short shelf life. It's clear there is a longer term story here to have one tool to do static analysis and replace (or front) `jdeps`, `jdeprscan` and this the new tool here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2182708610

From clanger at openjdk.org  Fri Jun 21 13:13:12 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 21 Jun 2024 13:13:12 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
In-Reply-To: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
Message-ID: <0duwUwX0rmRuucpAKb5i-kze6YtKOQhfSLIH6E_yfaQ=.dc24f3ad-448a-44c1-b425-a6e38c8f0365@github.com>

On Thu, 20 Jun 2024 18:35:00 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.

Looks good, although I don't see why sometimes the directive is @run main/othervm/manual/manual (double occurence of manual).

test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 30:

> 28:  * @library /test/lib
> 29:  * @build jtreg.SkippedException ValidatePathWithURL CAInterop
> 30:  * @run main/othervm/manual/manual -Djava.security.debug=certpath,ocsp

What is the reason why manual is written twice? (Here and in all other places in this file...)

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19814#pullrequestreview-2132623582
PR Review Comment: https://git.openjdk.org/jdk/pull/19814#discussion_r1648943324

From kevinw at openjdk.org  Fri Jun 21 13:13:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 13:13:38 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v7]
In-Reply-To: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
Message-ID: <3iV8RySrIBJY4Crih0t8eNhb7fq9KSNhTSVzO2hUQrc=.609afed0-4e84-4efa-824f-662e2ca4fff8@github.com>

> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
> 
> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  caps

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19658/files
  - new: https://git.openjdk.org/jdk/pull/19658/files/1a240155..db53d078

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19658&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19658/head:pull/19658

PR: https://git.openjdk.org/jdk/pull/19658

From kevinw at openjdk.org  Fri Jun 21 13:20:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 13:20:11 GMT
Subject: RFR: 8327793: Deprecate jstatd for removal [v7]
In-Reply-To: <3iV8RySrIBJY4Crih0t8eNhb7fq9KSNhTSVzO2hUQrc=.609afed0-4e84-4efa-824f-662e2ca4fff8@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
 <3iV8RySrIBJY4Crih0t8eNhb7fq9KSNhTSVzO2hUQrc=.609afed0-4e84-4efa-824f-662e2ca4fff8@github.com>
Message-ID: <0zrNXnpYSWY85w563eWY4OmOdF89a4n0QT-x7s9EQtU=.be6c9f66-8eda-4563-a1ef-7f939aed608a@github.com>

On Fri, 21 Jun 2024 13:13:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   caps

/INTEGRATE

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2182738142

From naoto at openjdk.org  Fri Jun 21 13:29:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Jun 2024 13:29:10 GMT
Subject: RFR: 8334653: ISO 4217 Amendment 177 Update [v3]
In-Reply-To: <7Kvrfh2yG5gpA80vhiiCVch-LymiU2RlsIS2rVx-0Xs=.43323ea3-4c0b-4057-83df-5a11c04264b0@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
 <7Kvrfh2yG5gpA80vhiiCVch-LymiU2RlsIS2rVx-0Xs=.43323ea3-4c0b-4057-83df-5a11c04264b0@github.com>
Message-ID: <-taQsr4ee8LUNL67RYzi1fKbXqdL0f7x41VFYw87_EY=.46c61edd-db67-45d5-a07f-bb74e4767b48@github.com>

On Thu, 20 Jun 2024 20:12:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which incorporates the ISO 4217 Amendment 177 Update.
>> 
>> Specifically, the introduction of the new currency, Zimbabwe Gold.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review: change txt name

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19813#pullrequestreview-2132659325

From kevinw at openjdk.org  Fri Jun 21 13:54:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 13:54:13 GMT
Subject: Integrated: 8327793: Deprecate jstatd for removal
In-Reply-To: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
References: <bH51qxZs6pVFTaZ7zJ2q3EsyF--SP6Tc1iPgsBXq9OU=.9891092d-aae0-4904-9837-e45cf713115c@github.com>
Message-ID: <KDH077Q6Tlrz0xmNs7vvPT66Z1_VUpEizxjO33A3hmI=.95c43c6e-dc07-404a-bd31-c8d89db6dcdf@github.com>

On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> jstatd is an RMI server application which monitors HotSpot VMs, and provides an interface to the monitoring tool jstat, for use across a remote RMI connection.
> 
> RMI is not how modern applications communicate. It is an old transport with long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not affect usage of jstat for monitoring local VMs using the Attach API.

This pull request has now been integrated.

Changeset: 9f8de221
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f8de221d7f0186718411ab3f5217e3883237e84
Stats:     6 lines in 3 files changed: 3 ins; 0 del; 3 mod

8327793: Deprecate jstatd for removal

Reviewed-by: alanb, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/19658

From hgreule at openjdk.org  Fri Jun 21 14:09:09 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Fri, 21 Jun 2024 14:09:09 GMT
Subject: RFR: 8334708: FFM: two javadoc problems
In-Reply-To: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
References: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
Message-ID: <pyeKx8b3l1yPlglCo74eR0WQOVau6Jp2JnJ8EyVLDaI=.e568d162-678b-48cc-91fb-80779d1d9e13@github.com>

On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Addresses two simple problems regarding javadocs in the FFM API.

Thank you for your review.

> Should we backport to 23?

I leave that up to you, I don't know how those things are handled normally. But a backport would be very simple in this case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19820#issuecomment-2182825539

From kevinw at openjdk.org  Fri Jun 21 14:12:17 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 14:12:17 GMT
Subject: RFR: 8334287: Man page update for jstatd deprecation
Message-ID: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>

Man page update for JDK-8327793 which marked jstatd as deprecated for removal in JDK 24.

-------------

Commit messages:
 - 8334287: Man page update for jstatd deprecation

Changes: https://git.openjdk.org/jdk/pull/19829/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19829&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334287
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19829/head:pull/19829

PR: https://git.openjdk.org/jdk/pull/19829

From liach at openjdk.org  Fri Jun 21 14:15:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Jun 2024 14:15:14 GMT
Subject: RFR: 8334708: FFM: two javadoc problems
In-Reply-To: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
References: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
Message-ID: <_rYhYVKmWKngHNIX4AotVyxkFptoyABROI2MAfaiNLI=.62828443-b71a-44c6-aba1-81f38b0239f8@github.com>

On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Addresses two simple problems regarding javadocs in the FFM API.

I think we can safely backport this to 23, as this is a doc-only fix (I've labeled the JBS issue noreg-doc as well) allowed by JEP-3 for RDP 1 and 2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19820#issuecomment-2182836082

From duke at openjdk.org  Fri Jun 21 14:19:17 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 21 Jun 2024 14:19:17 GMT
Subject: Integrated: 8333867: SHA3 performance can be improved
In-Reply-To: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
References: <koWANMo6uUDEWUU9OI55rZX2m33KHF1Dj-rUhrdVsu0=.6390aab0-42c8-4f1d-b5c0-5747a79dc756@github.com>
Message-ID: <yEVTNCIkUony-ap9tFiPkQxDH5rQf-Sh1bTl1O_OIiU=.6c3680be-f311-4052-96e0-96c9de492321@github.com>

On Mon, 10 Jun 2024 15:01:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> This PR removes some unnecessary conversions between byte arrays and long arrays during SHA3 digest computations.

This pull request has now been integrated.

Changeset: 75bea280
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75bea280b9adb6dac9fefafbb3f4b212f100fbb5
Stats:     86 lines in 3 files changed: 24 ins; 35 del; 27 mod

8333867: SHA3 performance can be improved

Reviewed-by: kvn, valeriep

-------------

PR: https://git.openjdk.org/jdk/pull/19632

From mli at openjdk.org  Fri Jun 21 14:29:40 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 21 Jun 2024 14:29:40 GMT
Subject: RFR: 8334397: RISC-V: verify perf of ReverseBytesS/US
Message-ID: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>

Hi,
Can you help to review this patch?
Thanks!

This is similar with previous JDK-8334396.
Added some tests.

###?Test
<google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
? | Tests | Scores | Errors | Unit
-- | -- | -- | -- | --
Intrinsic, +zbb, +rvv | Characters.reverseBytes | 1654.535 | 69.36 | ns/op
? | Shorts.reverseBytes | 1795.403 | 44.015 | ns/op
Intrinsic, +zbb, -rvv | Characters.reverseBytes | 1649.752 | 74.965 | ns/op
? | Shorts.reverseBytes | 1798.637 | 49.52 | ns/op
Intrinsic, -zbb, +rvv | Characters.reverseBytes | 2279.588 | 44.222 | ns/op
? | Shorts.reverseBytes | 2441.674 | 63.895 | ns/op
Intrinsic, -zbb, -rvv | Characters.reverseBytes | 2288.876 | 49.099 | ns/op
? | Shorts.reverseBytes | 2454.454 | 94.004 | ns/op
No intrinsic | Characters.reverseBytes | 1629.722 | 23.656 | ns/op
? | Shorts.reverseBytes | 2108.81 | 43.378 | ns/op

</google-sheets-html-origin>

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/19830/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19830&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334397
  Stats: 129 lines in 4 files changed: 98 ins; 31 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19830/head:pull/19830

PR: https://git.openjdk.org/jdk/pull/19830

From liach at openjdk.org  Fri Jun 21 14:45:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Jun 2024 14:45:18 GMT
Subject: RFR: 8334726: Remove accidentally exposed individual methods from
 Class-File API
Message-ID: <jzWivtE7S86Q5cJaPja-OMMTvyIrGFCnoq5Z-78iuls=.07abc099-76b0-4676-8df6-e3649e53dba0@github.com>

In preparation of Class-File API exiting review, we are housekeeping our API surface. These 3 method removals are the most obvious and simple ones.

This is separated from more throughout and (possibly controversial) changes for the future, to make reviews (both code and CSR) easier.

-------------

Commit messages:
 - 8334726: Remove accidentally exposed individual methods from Class-File API

Changes: https://git.openjdk.org/jdk/pull/19832/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19832&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334726
  Stats: 37 lines in 7 files changed: 0 ins; 30 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19832/head:pull/19832

PR: https://git.openjdk.org/jdk/pull/19832

From asotona at openjdk.org  Fri Jun 21 15:18:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 21 Jun 2024 15:18:09 GMT
Subject: RFR: 8334726: Remove accidentally exposed individual methods from
 Class-File API
In-Reply-To: <jzWivtE7S86Q5cJaPja-OMMTvyIrGFCnoq5Z-78iuls=.07abc099-76b0-4676-8df6-e3649e53dba0@github.com>
References: <jzWivtE7S86Q5cJaPja-OMMTvyIrGFCnoq5Z-78iuls=.07abc099-76b0-4676-8df6-e3649e53dba0@github.com>
Message-ID: <1gQMd9I0-5fzaVWjDt424CZ43IpRFl1MLJCYmWFOVq8=.e10dfe5e-dff0-408b-b5e4-0e1e6d6c4b72@github.com>

On Fri, 21 Jun 2024 14:38:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In preparation of Class-File API exiting review, we are housekeeping our API surface. These 3 method removals are the most obvious and simple ones.
> 
> This is separated from more throughout and (possibly controversial) changes for the future, to make reviews (both code and CSR) easier.

Looks good to me, thanks.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19832#pullrequestreview-2132887472

From kevinw at openjdk.org  Fri Jun 21 15:34:10 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 21 Jun 2024 15:34:10 GMT
Subject: RFR: 8334287: Man page update for jstatd deprecation
In-Reply-To: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
References: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
Message-ID: <KvEy8PBBkLxJMnxZfpXnsaUYOuNzWg8PcDc14OWNhKM=.5ed15022-efb8-46fa-9d9d-2b422252af4a@github.com>

On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Man page update for JDK-8327793 which marked jstatd as deprecated for removal in JDK 24.

The updated man page looks like:


JSTATD(1)                                                             JDK Commands                                                            JSTATD(1)

NAME
       jstatd - monitor the creation and termination of instrumented Java HotSpot VMs

SYNOPSIS
       WARNING: This command is deprecated and will be removed in a future release.

       Note: This command is experimental and unsupported.

       jstatd [options]
...etc...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19829#issuecomment-2182976031

From liach at openjdk.org  Fri Jun 21 15:57:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Jun 2024 15:57:37 GMT
Subject: RFR: 8334734: Remove specialized readXxxEntry methods from ClassReader
Message-ID: <7G5zGUXmAmiZUZ1g8K4ksYA73NmGnF2EZIIAO4cmf1I=.529a63f1-1592-450e-a9fb-f3679e670741@github.com>

`ClassReader.readXxxEntry` were added before we had generic, type-aware `readEntry` and `readEntryOrNull` APIs (#19330). We should remove these specialized versions in favor of the generic version to reduce API bloating.

-------------

Commit messages:
 - Copyright years
 - 8334734: Remove specialized readXxxEntry methods from ClassReader

Changes: https://git.openjdk.org/jdk/pull/19833/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19833&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334734
  Stats: 169 lines in 9 files changed: 1 ins; 111 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/19833.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19833/head:pull/19833

PR: https://git.openjdk.org/jdk/pull/19833

From rhalade at openjdk.org  Fri Jun 21 16:11:34 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Jun 2024 16:11:34 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
Message-ID: <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>

> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.

Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:

  fix typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19814/files
  - new: https://git.openjdk.org/jdk/pull/19814/files/5f1889af..2fdaa890

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19814&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19814&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19814/head:pull/19814

PR: https://git.openjdk.org/jdk/pull/19814

From rhalade at openjdk.org  Fri Jun 21 16:11:35 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Jun 2024 16:11:35 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <0duwUwX0rmRuucpAKb5i-kze6YtKOQhfSLIH6E_yfaQ=.dc24f3ad-448a-44c1-b425-a6e38c8f0365@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
 <0duwUwX0rmRuucpAKb5i-kze6YtKOQhfSLIH6E_yfaQ=.dc24f3ad-448a-44c1-b425-a6e38c8f0365@github.com>
Message-ID: <J_MbQDsAkVL4faYoch_tU7wbDsxopO_avgTAYNU_h7w=.1af8ef01-591b-43df-bb0a-c9ed23584e39@github.com>

On Fri, 21 Jun 2024 13:10:00 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typos
>
> test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java line 30:
> 
>> 28:  * @library /test/lib
>> 29:  * @build jtreg.SkippedException ValidatePathWithURL CAInterop
>> 30:  * @run main/othervm/manual/manual -Djava.security.debug=certpath,ocsp
> 
> What is the reason why manual is written twice? (Here and in all other places in this file...)

good catch! I have fixed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19814#discussion_r1649163406

From naoto at openjdk.org  Fri Jun 21 16:35:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Jun 2024 16:35:08 GMT
Subject: [jdk23] RFR: 8334333: MissingResourceCauseTestRun.java fails if
 run by root
In-Reply-To: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>
References: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>
Message-ID: <g5Va80Af_Bipe5WlDuKhTb6UkW0DHgcWiPS-txUXId8=.81cd2c09-9a44-49fc-a5c9-9df6891ef407@github.com>

On Fri, 21 Jun 2024 00:49:33 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [de8ee977](https://github.com/openjdk/jdk/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 20 Jun 2024 and was reviewed by Naoto Sato and Justin Lu.
> 
> Thanks!

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19817#pullrequestreview-2133028593

From mullan at openjdk.org  Fri Jun 21 16:36:11 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 21 Jun 2024 16:36:11 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
 <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
Message-ID: <H4K8GAjMQEiwgZeIWsFr-6-Jb_PO1qJlfKvZxSl8qcI=.4740263f-286c-4639-bbd0-a6703da2b70e@github.com>

On Fri, 21 Jun 2024 16:11:34 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typos

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19814#pullrequestreview-2133029865

From syan at openjdk.org  Fri Jun 21 16:39:10 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 16:39:10 GMT
Subject: [jdk23] RFR: 8334333: MissingResourceCauseTestRun.java fails if
 run by root
In-Reply-To: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>
References: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>
Message-ID: <zyYK1MThqVTz4Zdwf__vF2wkLjYY5YKZ7bpB0AJoqJU=.b555c331-0100-4a5f-b198-4db7b0ed73ae@github.com>

On Fri, 21 Jun 2024 00:49:33 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [de8ee977](https://github.com/openjdk/jdk/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 20 Jun 2024 and was reviewed by Naoto Sato and Justin Lu.
> 
> Thanks!

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19817#issuecomment-2183078007

From rhalade at openjdk.org  Fri Jun 21 16:40:16 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 21 Jun 2024 16:40:16 GMT
Subject: Integrated: 8334441: Mark tests in jdk_security_infra group as manual
In-Reply-To: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
Message-ID: <99xuXYSt1gT7lmTPPvSB1lBZljI71AEaPlb37Wv0gtM=.b0958bd5-7d23-470e-bfad-19ccdee4ac3e@github.com>

On Thu, 20 Jun 2024 18:35:00 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.

This pull request has now been integrated.

Changeset: 8e1d2b09
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a
Stats:     160 lines in 10 files changed: 5 ins; 2 del; 153 mod

8334441: Mark tests in jdk_security_infra group as manual

Reviewed-by: clanger, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/19814

From syan at openjdk.org  Fri Jun 21 16:44:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 16:44:14 GMT
Subject: [jdk23] RFR: 8334333: MissingResourceCauseTestRun.java fails if
 run by root
In-Reply-To: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>
References: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>
Message-ID: <MLTquavRQkXf7SaZZFwa3p41MTrPum_qnAJsaF0Cb4U=.6318e7cd-6763-4cb7-869a-2f45658317de@github.com>

On Fri, 21 Jun 2024 00:49:33 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [de8ee977](https://github.com/openjdk/jdk/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 20 Jun 2024 and was reviewed by Naoto Sato and Justin Lu.
> 
> Thanks!

Thanks for the sponsor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19817#issuecomment-2183087424

From syan at openjdk.org  Fri Jun 21 16:44:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Jun 2024 16:44:14 GMT
Subject: [jdk23] Integrated: 8334333: MissingResourceCauseTestRun.java fails if
 run by root
In-Reply-To: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>
References: <N8fgPKl7xIIoQvqURFCeN_wTnIcPhngtwIzPaaxXNN8=.4024297b-0902-4336-8082-f6b437d37028@github.com>
Message-ID: <bM33ZiREELuA_3xei0lPlFIHPjoTkFl47jAnAO8bwro=.389ca614-ca34-4060-9bd4-c72fada6c569@github.com>

On Fri, 21 Jun 2024 00:49:33 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [de8ee977](https://github.com/openjdk/jdk/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 20 Jun 2024 and was reviewed by Naoto Sato and Justin Lu.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 21514931
Author:    SendaoYan <syan at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/215149310c49b01dee671afde7ad2da47ee3b8e4
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8334333: MissingResourceCauseTestRun.java fails if run by root

Reviewed-by: naoto
Backport-of: de8ee97718d7e12b541b310cf5b67f3e10e91ad9

-------------

PR: https://git.openjdk.org/jdk/pull/19817

From stigdoessing at gmail.com  Fri Jun 21 17:12:00 2024
From: stigdoessing at gmail.com (=?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?=)
Date: Fri, 21 Jun 2024 19:12:00 +0200
Subject: Incorrect note in Javadoc for a few RandomGenerator methods
Message-ID: <CAG09ER1CPsh45p8bwgaOfhsAUgb=OyPqKhLXxXbHznNzFecsqA@mail.gmail.com>

Hi,

The Javadoc for RandomGenerator.nextLong(long origin, long bound) has this
to say:

Implementation Requirements:The default implementation checks that origin
and bound are positive longs

This doesn't seem to be true. The default implementation checks that origin
and bound are a valid range (that bound >= origin). The implementation
doesn't reject negative inputs.

The same note appears in the two-arg version of nextInt.

The note for e.g. nextDouble is correct and says "The default
implementation verifies that the origin and bound are valid"

I'm wondering if the notes for nextLong and nextInt should be updated to
match?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240621/ab0c66d2/attachment.htm>

From jlu at openjdk.org  Fri Jun 21 17:05:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 21 Jun 2024 17:05:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <El-GvNiBNotMNr7lkQogDGi4vCI-rOMYOAZNZEp-S6E=.c12af922-9f2d-4666-a4a1-d4c453b34e18@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <bwzVGsQPnmZgto9MjL8VC3TJK6ulyn_itq-RYBkEngw=.f79d0520-2b38-4e6f-8c5f-458fccba2e7c@github.com>
 <chyUATkwMLuzNBY9RMVc76AENpjfZTk33Z9qi9lc1f8=.93b45ae7-a5ab-465d-9dbc-5992e62481d7@github.com>
 <El-GvNiBNotMNr7lkQogDGi4vCI-rOMYOAZNZEp-S6E=.c12af922-9f2d-4666-a4a1-d4c453b34e18@github.com>
Message-ID: <JCEHOUvIJvRIMoNV1Fld-7Du32d2O-W6Jn1gDcqDk-w=.5c414e36-825d-42b1-855e-a77752d7872b@github.com>

On Fri, 21 Jun 2024 02:10:59 GMT, lingjun-cg <duke at openjdk.org> wrote:

> If do that ,there is some performance degradation.

Thanks for taking the time to do benchmarks. If that is the case, then lets stick with the proxy solution then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2183118752

From raffaello.giulietti at oracle.com  Fri Jun 21 17:27:23 2024
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 21 Jun 2024 19:27:23 +0200
Subject: Incorrect note in Javadoc for a few RandomGenerator methods
In-Reply-To: <CAG09ER1CPsh45p8bwgaOfhsAUgb=OyPqKhLXxXbHznNzFecsqA@mail.gmail.com>
References: <CAG09ER1CPsh45p8bwgaOfhsAUgb=OyPqKhLXxXbHznNzFecsqA@mail.gmail.com>
Message-ID: <11163cf0-df48-4a80-a2f7-f63e2b7e37ac@oracle.com>

Hi,

your observation seems correct.

In order to file a properly tracked bug report, please proceed according 
to this guide:

https://docs.oracle.com/en/java/javase/22/troubleshoot/submit-bug-report.html

Thanks



On 2024-06-21 19:12, Stig Rohde D?ssing wrote:
> Hi,
> 
> The Javadoc for RandomGenerator.nextLong(long?origin, long?bound) has 
> this to say:
> 
> Implementation Requirements:
> The default implementation checks that |origin| and |bound| are positive 
> |longs|
> 
> |This doesn't seem to be true. The default implementation checks that 
> origin and bound are a valid range (that bound >= origin). The 
> implementation doesn't reject negative inputs.|
> |
> |
> |The same note appears in the two-arg version of nextInt.|
> |
> |
> |The note for e.g. nextDouble is correct and says "|The default 
> implementation verifies that the |origin| and |bound| are valid"
> 
> I'm wondering if the notes for nextLong and nextInt should be updated to 
> match?

From jlahoda at openjdk.org  Fri Jun 21 18:35:14 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Jun 2024 18:35:14 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v7]
In-Reply-To: <UKoCu-vjDZ4cNxaFCwS6tuzI_5sORE4Uol0p2y3bDZw=.de8b6657-ccd9-4bec-bf7e-4eb6fd6f3384@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <UKoCu-vjDZ4cNxaFCwS6tuzI_5sORE4Uol0p2y3bDZw=.de8b6657-ccd9-4bec-bf7e-4eb6fd6f3384@github.com>
Message-ID: <xRVHqXeTMsBZ78tOCLXgazDzF8nrBsnypToXVuzOJXc=.d97d3ac6-880d-4602-8903-8939681bf99c@github.com>

On Thu, 20 Jun 2024 19:45:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add extra test for missing root modules

Overall looks great to me. Some minor comments inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 87:

> 85:     @Override
> 86:     public PlatformDescription getPlatform(String platformName, String options) throws PlatformNotSupported {
> 87:         if (Source.lookup(platformName) == null) {

`Source.lookup` is probably not the right way to check whether the platform is supported - the `Source` enum may (and does) contain versions for which we don't have the historical API record. I think `SUPPORTED_JAVA_PLATFORM_VERSIONS.contains(platformName)` would work better, since the content is read directly from `ct.sym`.

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java line 417:

> 415:                 return false;
> 416:             }
> 417:             JavaFileManager fm = pp.getPlatformTrusted(release).getFileManager();

Not sure if this change is necessary. I believe `release` is verified to be a valid platform name at this point, so even with the new check, it should still work. (And `getPlatformTrusted` could possibly be eliminated.) But maybe I am missing something?

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java line 125:

> 123:         private static Map<String, String> packageToSystemModule(JavaFileManager platformFileManager) {
> 124:             try {
> 125:                 Set<JavaFileManager.Location> locations = platformFileManager.listLocationsForModules(

FWIW: +1 on using the modules from the `ct.sym` rather than runtime modules here!

test/langtools/tools/jnativescan/TestJNativeScan.java line 174:

> 172:                                   "-add-modules", "org.singlejar,org.myapp",
> 173:                                   "--print-native-access"))
> 174:                 .stdoutShouldContain("org.singlejar")

It is a small thing, bu was there a consideration for a stronger assert on the output, checking that the output is precisely something like `--enable-native-access org.lib,org.service,org.singlejar`? Would require that the output is stable, which may be tricky, but also not a bad property. Just an idea for consideration.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2133198642
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649303668
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649307310
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649297021
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649294137

From jlahoda at openjdk.org  Fri Jun 21 18:35:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Jun 2024 18:35:15 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v7]
In-Reply-To: <7WkZwa41PggNvizNuEeUAsUce2yIyqhO7uLcCkzorMc=.1b198bd6-414d-4cdc-aa17-3bb008d64275@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <aC-o0l0yU3ZZne9YyCzUfj8xl98T3EkZV9QDXViz2Y4=.c474e914-0ecf-48a6-9979-a716b323d4a3@github.com>
 <7WkZwa41PggNvizNuEeUAsUce2yIyqhO7uLcCkzorMc=.1b198bd6-414d-4cdc-aa17-3bb008d64275@github.com>
Message-ID: <fqGfvlQF9xhpZTWfoqn-xiwwkQBz4uFqh5xDtsQyv1Q=.f806a5eb-db48-4db9-81e7-f7f8ad40a87b@github.com>

On Thu, 20 Jun 2024 16:58:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 93:
>> 
>>> 91:     }
>>> 92: 
>>> 93:     public PlatformDescription getPlatformTrusted(String platformName) {
>> 
>> I noticed that `getPlatform` was not throwing an exception if the release was not valid, which then later results in an NPE. I've added an explicit check here instead. The caller can then catch the exception.
>
> I see the "options" arg is not used so maybe another approach here is a one-arg getPlatform that throws PlatformNotSupported and then migrate the other usages at another time. 
> 
> (This is just a passing comment, not important for the core of this feature).

We probably can eliminate the `options` (which is a historical artifact), but I don't think it needs to be done here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649307870

From jlahoda at openjdk.org  Fri Jun 21 18:35:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Jun 2024 18:35:16 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <QRYmX9kxA82Xkq6QKe-OMTyUiPnKBdufDrUgZNGBO4s=.a8fad8c3-74be-4f66-a5a2-ba43cae5e13d@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
 <J7pSRoT9jBwnYtznnH46TZDaJaHStiogsf0_H5kGvHU=.59bfad41-e552-40c7-a874-1d0e954d411d@github.com>
 <QRYmX9kxA82Xkq6QKe-OMTyUiPnKBdufDrUgZNGBO4s=.a8fad8c3-74be-4f66-a5a2-ba43cae5e13d@github.com>
Message-ID: <cMSrHv5K3m7iHI1BLZ6YJnzywDbua_SsN0G23v2B_Vc=.52cb8677-cce6-40f2-bc20-51c9cd737def@github.com>

On Thu, 20 Jun 2024 17:44:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 113:
>> 
>>> 111:                     // Class-Path attribute specifies that jars that
>>> 112:                     // are not found are simply ignored. Do the same here
>>> 113:                     classPathJars.offer(otherJar);
>> 
>> The expansion of the class path looks right but the Class-Path attribute is awkward to deal with as its relative URI rather than a file path. More on this this later.
>
> Not important for now but the expansion will probably need to"visited" set to detect cycles (yes, it is possible).
> 
> In addition to cycles, it is possible to have several JAR files with the same Class-Path value, e.g. lib/logging.jar, so a visited set would be useful for that too.

FWIW, javac has `com.sun.tools.javac.file.FSInfo.getJarClassPath`, which is not transitive, and is implemented a bit differently, but I wonder if there's a chance for some code sharing. Maybe not now, but eventually.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649296334

From jiangli at openjdk.org  Fri Jun 21 18:40:11 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 18:40:11 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <c7dVhp6HO89vlyjBip2sfry-83Npm6ybT-FUrPyqgV4=.da96113c-ffc6-4f5b-a784-d02500ce0d68@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

src/hotspot/os/bsd/os_bsd.cpp line 1:

> 1: /*

The changes in os_bsd.cpp are new and are not from https://github.com/openjdk/leyden/tree/hermetic-java-runtime/. Have you tested the bsd port?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1649312808

From jvernee at openjdk.org  Fri Jun 21 18:41:12 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Jun 2024 18:41:12 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v7]
In-Reply-To: <xRVHqXeTMsBZ78tOCLXgazDzF8nrBsnypToXVuzOJXc=.d97d3ac6-880d-4602-8903-8939681bf99c@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <UKoCu-vjDZ4cNxaFCwS6tuzI_5sORE4Uol0p2y3bDZw=.de8b6657-ccd9-4bec-bf7e-4eb6fd6f3384@github.com>
 <xRVHqXeTMsBZ78tOCLXgazDzF8nrBsnypToXVuzOJXc=.d97d3ac6-880d-4602-8903-8939681bf99c@github.com>
Message-ID: <wp-BMubCo7SmyyjmKpAvF07TNRALGJWZegEyY7_XMEs=.3326d898-b13b-4b0a-8530-46b10bb3e5d7@github.com>

On Fri, 21 Jun 2024 18:31:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add extra test for missing root modules
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java line 417:
> 
>> 415:                 return false;
>> 416:             }
>> 417:             JavaFileManager fm = pp.getPlatformTrusted(release).getFileManager();
> 
> Not sure if this change is necessary. I believe `release` is verified to be a valid platform name at this point, so even with the new check, it should still work. (And `getPlatformTrusted` could possibly be eliminated.) But maybe I am missing something?

I wanted to avoid adding exception handling code here, since `PlatformNotSupported` is a checked exception.

> test/langtools/tools/jnativescan/TestJNativeScan.java line 174:
> 
>> 172:                                   "-add-modules", "org.singlejar,org.myapp",
>> 173:                                   "--print-native-access"))
>> 174:                 .stdoutShouldContain("org.singlejar")
> 
> It is a small thing, bu was there a consideration for a stronger assert on the output, checking that the output is precisely something like `--enable-native-access org.lib,org.service,org.singlejar`? Would require that the output is stable, which may be tricky, but also not a bad property. Just an idea for consideration.

Good point. The result should be 'clean' and directly forward-able to `--enable-native-access`. (So in this case it should be exactly `org.singlejar`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649312391
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649313272

From jlahoda at openjdk.org  Fri Jun 21 18:44:12 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Jun 2024 18:44:12 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v7]
In-Reply-To: <wp-BMubCo7SmyyjmKpAvF07TNRALGJWZegEyY7_XMEs=.3326d898-b13b-4b0a-8530-46b10bb3e5d7@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <UKoCu-vjDZ4cNxaFCwS6tuzI_5sORE4Uol0p2y3bDZw=.de8b6657-ccd9-4bec-bf7e-4eb6fd6f3384@github.com>
 <xRVHqXeTMsBZ78tOCLXgazDzF8nrBsnypToXVuzOJXc=.d97d3ac6-880d-4602-8903-8939681bf99c@github.com>
 <wp-BMubCo7SmyyjmKpAvF07TNRALGJWZegEyY7_XMEs=.3326d898-b13b-4b0a-8530-46b10bb3e5d7@github.com>
Message-ID: <QghNCu39o588CS3eZXXeJ19IxE7HRzEbXY1DRE_W_vA=.09e0bb00-674c-4078-9a58-38ba5115c5ec@github.com>

On Fri, 21 Jun 2024 18:37:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java line 417:
>> 
>>> 415:                 return false;
>>> 416:             }
>>> 417:             JavaFileManager fm = pp.getPlatformTrusted(release).getFileManager();
>> 
>> Not sure if this change is necessary. I believe `release` is verified to be a valid platform name at this point, so even with the new check, it should still work. (And `getPlatformTrusted` could possibly be eliminated.) But maybe I am missing something?
>
> I wanted to avoid adding exception handling code here, since `PlatformNotSupported` is a checked exception.

Ah, OK, I didn't realize that. Seems fine then!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649315863

From jiangli at openjdk.org  Fri Jun 21 19:05:13 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 19:05:13 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <Rk3XzH9mY7W9MQTareIzrDMBIK8nUrms98L-cpyu3us=.d74f6868-1969-40df-b973-8913025d9284@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

src/hotspot/share/runtime/os.cpp line 521:

> 519:     char ebuf[1024];
> 520: 
> 521:     if (vm_is_statically_linked()) {

This block can be moved before the two variable declarations above, since they are not needed in the static case. https://github.com/openjdk/leyden/blob/c1c5fc686c1452550e1b3663a320fba652248505/src/hotspot/share/runtime/os.cpp#L507 handles it that way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1649333382

From jiangli at openjdk.org  Fri Jun 21 19:16:11 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 19:16:11 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <oBspXOAoMdr0t576VRd8sj4dxiB19z8_HtHPYwu0Gnk=.8a867131-0c80-4f53-86e4-b2e01da4e116@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

src/hotspot/share/utilities/zipLibrary.cpp line 63:

> 61: 
> 62: static void* dll_lookup(const char* name, const char* path, bool vm_exit_on_failure) {
> 63:   if (vm_is_statically_linked()) {

I like this change. It is cleaner than the hermetic Java branch change that does the `if` static check in `store_function_pointers` (https://github.com/openjdk/leyden/blob/c1c5fc686c1452550e1b3663a320fba652248505/src/hotspot/share/utilities/zipLibrary.cpp#L75).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1649341844

From jiangli at openjdk.org  Fri Jun 21 19:23:11 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 19:23:11 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <icTPPdnVNaMnAmWhldIvtUbhzrBqNxtZLr352ASLWnw=.a6240fb4-54a6-4107-a570-0c8df4f83de6@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

src/java.base/macosx/native/libjli/java_md_macosx.m line 1:

> 1: /*

In the mailing list email discussion thread on hermetic Java, you mentioned running on macosx with a build from hermtic Java branch crashed for you during startup. Is that fully resolved with the changes in this PR? The hermetic Java branch does not have any changes for macosx port. What tests are done for the macosx port for static support?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1649348777

From jiangli at openjdk.org  Fri Jun 21 19:34:11 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 19:34:11 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <tuGZpkTIdXTh9eCCau0IMYkDAjaUQNGKLEy9dVg6BOU=.b3507427-6767-4089-ad4e-b3b0b895dba6@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

src/java.base/unix/native/libjli/java_md.c line 316:

> 314:     SetExecname(*pargv);
> 315: 
> 316:     if (!JLI_IsStaticallyLinked()) {

Any reason this is diverted from the change in hermetic Java branch, https://github.com/openjdk/leyden/blob/c1c5fc686c1452550e1b3663a320fba652248505/src/java.base/unix/native/libjli/java_md.c#L300? I think the setenv part below is not needed for static/hermetic support either. There is no $JRE/lib with a single executable image. All natives are statically linked with the executable image.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1649356484

From jiangli at openjdk.org  Fri Jun 21 19:54:11 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Jun 2024 19:54:11 GMT
Subject: RFR: 8333268: Fixes for static build [v4]
In-Reply-To: <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
 <fEy1RUfkGdCO7jsGIg6E0mMpihJ24jkYnPCHeXCDYJ4=.7becda45-2ccb-45ad-8abb-b86e85d2e8f6@github.com>
Message-ID: <WMhlN_Fv1Q3ZHIgTrxQBpeETE8DxmC38xy3lJ5T7nSw=.a0858690-5d43-41fe-9e84-48d41b6ad691@github.com>

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

I've looked through all JDK and VM changes and left comments in various places. All the rest changes in PR look good. Thanks again for extracting these changes from the leyden/hermeticJava branch and integrating with mainline!

My other main question is why the `javastatic` linking work is not included in the PR together with these runtime changes. 

IIUC from our meetings and mailing list discussions, the initial integration PR needs to include the part for statically linking the `javastatic`. That's a minimum requirement for testing/verifying the runtime changes when integrating into the mainline, which is also the reason why we haven't starting integrating any of the runtime changes so far. Has that been changed?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19478#pullrequestreview-2133328296

From stigdoessing at gmail.com  Fri Jun 21 20:30:34 2024
From: stigdoessing at gmail.com (=?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?=)
Date: Fri, 21 Jun 2024 22:30:34 +0200
Subject: Incorrect note in Javadoc for a few RandomGenerator methods
In-Reply-To: <11163cf0-df48-4a80-a2f7-f63e2b7e37ac@oracle.com>
References: <CAG09ER1CPsh45p8bwgaOfhsAUgb=OyPqKhLXxXbHznNzFecsqA@mail.gmail.com>
 <11163cf0-df48-4a80-a2f7-f63e2b7e37ac@oracle.com>
Message-ID: <CAG09ER21KJs=WFa-MXP12AStD6tjQSxzQCNQzPAnQAi-zuOLAQ@mail.gmail.com>

Thanks, filed 9077206.

Den fre. 21. jun. 2024 kl. 21.06 skrev Raffaello Giulietti <
raffaello.giulietti at oracle.com>:

> Hi,
>
> your observation seems correct.
>
> In order to file a properly tracked bug report, please proceed according
> to this guide:
>
>
> https://docs.oracle.com/en/java/javase/22/troubleshoot/submit-bug-report.html
>
> Thanks
>
>
>
> On 2024-06-21 19:12, Stig Rohde D?ssing wrote:
> > Hi,
> >
> > The Javadoc for RandomGenerator.nextLong(long origin, long bound) has
> > this to say:
> >
> > Implementation Requirements:
> > The default implementation checks that |origin| and |bound| are positive
> > |longs|
> >
> > |This doesn't seem to be true. The default implementation checks that
> > origin and bound are a valid range (that bound >= origin). The
> > implementation doesn't reject negative inputs.|
> > |
> > |
> > |The same note appears in the two-arg version of nextInt.|
> > |
> > |
> > |The note for e.g. nextDouble is correct and says "|The default
> > implementation verifies that the |origin| and |bound| are valid"
> >
> > I'm wondering if the notes for nextLong and nextInt should be updated to
> > match?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240621/ccad2087/attachment.htm>

From jvernee at openjdk.org  Fri Jun 21 20:54:17 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Jun 2024 20:54:17 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v7]
In-Reply-To: <wp-BMubCo7SmyyjmKpAvF07TNRALGJWZegEyY7_XMEs=.3326d898-b13b-4b0a-8530-46b10bb3e5d7@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <UKoCu-vjDZ4cNxaFCwS6tuzI_5sORE4Uol0p2y3bDZw=.de8b6657-ccd9-4bec-bf7e-4eb6fd6f3384@github.com>
 <xRVHqXeTMsBZ78tOCLXgazDzF8nrBsnypToXVuzOJXc=.d97d3ac6-880d-4602-8903-8939681bf99c@github.com>
 <wp-BMubCo7SmyyjmKpAvF07TNRALGJWZegEyY7_XMEs=.3326d898-b13b-4b0a-8530-46b10bb3e5d7@github.com>
Message-ID: <k42PRdLdpwIU1PBDwQXbW0fjRwBBOgYO9WKCuZ2HPmg=.8fcd3d6d-699e-4c18-91c2-a3ec32d52d97@github.com>

On Fri, 21 Jun 2024 18:38:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> test/langtools/tools/jnativescan/TestJNativeScan.java line 174:
>> 
>>> 172:                                   "-add-modules", "org.singlejar,org.myapp",
>>> 173:                                   "--print-native-access"))
>>> 174:                 .stdoutShouldContain("org.singlejar")
>> 
>> It is a small thing, bu was there a consideration for a stronger assert on the output, checking that the output is precisely something like `--enable-native-access org.lib,org.service,org.singlejar`? Would require that the output is stable, which may be tricky, but also not a bad property. Just an idea for consideration.
>
> Good point. The result should be 'clean' and directly forward-able to `--enable-native-access`. (So in this case it should be exactly `org.singlejar`)

I'm fixing this test, and also making the output sorted. That is required for the output stability, but I also thought that would be a nice property in case a user wants to diff the tool's outputs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649418854

From jlu at openjdk.org  Fri Jun 21 21:01:30 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 21 Jun 2024 21:01:30 GMT
Subject: RFR: 8331342: Convert Base64 tests to JUnit [v2]
In-Reply-To: <9b7rZt1fLHoDtfpK78fcKL2EVEh_HocxFC4j5_tSXx4=.00a33121-882b-4198-9415-271eac5f9c51@github.com>
References: <9b7rZt1fLHoDtfpK78fcKL2EVEh_HocxFC4j5_tSXx4=.00a33121-882b-4198-9415-271eac5f9c51@github.com>
Message-ID: <XsPSqSwwfvMBK-75AVF8Y-Z4_8y72ZZHY7oUFwXU3dU=.73a7ef5d-9141-47ba-bb99-df7f0b9a9ed5@github.com>

> Please review this test-only clean up PR which converts the java.util.Base64 tests to run under JUnit.
> 
> In general, this allows for the tests to run independently, separates the data providers from the tests, as well being able to utilize the built in JUnit utility test methods to reduce boilerplate testing code.

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:

 - Merge branch 'master' into java.util.Base64-JUnit-conversions
 - Additional clarifying comments
 - convert TestBase64.java
 - convert TestBase64Golden.java
 - convert Base64GetEncoderTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19337/files
  - new: https://git.openjdk.org/jdk/pull/19337/files/945bc482..706293d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19337&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19337&range=00-01

  Stats: 166493 lines in 2916 files changed: 110047 ins; 41299 del; 15147 mod
  Patch: https://git.openjdk.org/jdk/pull/19337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19337/head:pull/19337

PR: https://git.openjdk.org/jdk/pull/19337

From jvernee at openjdk.org  Fri Jun 21 21:17:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Jun 2024 21:17:46 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v8]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <MlYPZy249yxNbJbDWBxjqf2LVQ_BXI0pcXYjCi5tU10=.2d0cf86e-618d-4212-b311-b29a507cfc19@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:

 - Add support for module directories + class path directories
 - sort output for easier diffs
 - Jan comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/a4723494..a046f6fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=06-07

  Stats: 275 lines in 8 files changed: 156 ins; 58 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From jvernee at openjdk.org  Fri Jun 21 21:17:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Jun 2024 21:17:46 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v8]
In-Reply-To: <WJfH2ULLY138ofx9uwWkK9-_eMzWTWsZ18ibeOQixSU=.47df4a28-5135-48cc-bf12-4424d9bc1be2@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <wN7MphwgpmzUS7Iu2EByjTzJ3YfNpLKJEUqE9c1LBgo=.3c9180e1-a791-47bf-a1d9-006a45c9cf29@github.com>
 <D_MQ4c6s7n1qldn9CHeYZKfHaUgGclpU6murkDtsjuY=.dff9a39b-9db8-4ebb-b10f-4c0e36cea555@github.com>
 <2r8s2SU2XAXtfb8KUesb8VMMc80KPrvhWSCxJQmFXQY=.a2fad386-3ace-4ef0-badf-23f8ef2f88b2@github.com>
 <WJfH2ULLY138ofx9uwWkK9-_eMzWTWsZ18ibeOQixSU=.47df4a28-5135-48cc-bf12-4424d9bc1be2@github.com>
Message-ID: <aawXySY3WfXX2waGTw-2CiODFfBZlvfG0xL4BU9WLmE=.f6895267-4ac4-430a-9533-d818b6636059@github.com>

On Thu, 20 Jun 2024 17:25:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Something like that yes
>
> An altermative is to use ResolvedModule::reference to get a ModuleReference, then use its open method to open the contents of the module to get a ModuleReader. That will give you a stream over the names of all resources in the module. It will work for all exploded and packaged modules.

I took a look at this. I had to refactor a bit and introduce an intermediate abstraction (`ClassFileSource`) to abstract over classes loaded from a `JarFile` (for the class path) and a `ModuleReader` (for module path). At that point, it was also easy to add a third option for directories of class files on that class path, so I've done that as well.

See: https://github.com/openjdk/jdk/pull/19774/commits/a046f6fe9465feda63609dd50014338ca218923f

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1649434411

From mcimadamore at openjdk.org  Fri Jun 21 21:23:23 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Jun 2024 21:23:23 GMT
Subject: RFR: 8334708: FFM: two javadoc problems
In-Reply-To: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
References: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
Message-ID: <X-zbPkWPmpJR8ln_KXQCS3Q2_KtDUvK_jkzJOK-nFL4=.2e88b153-7378-42d1-bbaf-ffc6d339b98b@github.com>

On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Addresses two simple problems regarding javadocs in the FFM API.

Yes, javadoc fixes such as this can be backported. Just use the `/backport` command:

https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/backport

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19820#issuecomment-2183478163

From liach at openjdk.org  Fri Jun 21 22:36:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Jun 2024 22:36:27 GMT
Subject: [jdk23] Integrated: 8333854: IllegalAccessError with proxies after
 JDK-8332457
In-Reply-To: <WGrnxZdxr_gKg43KmfVaEH-YRQdrxwU5-hdsgNGzFtc=.fb280ea0-b829-4d79-9c92-209ebfca8036@github.com>
References: <WGrnxZdxr_gKg43KmfVaEH-YRQdrxwU5-hdsgNGzFtc=.fb280ea0-b829-4d79-9c92-209ebfca8036@github.com>
Message-ID: <7f2G83RPGbHOkvetHUmWejHjxaTLt_lPUzhgacSv8_U=.109409fc-155f-4ef1-9a18-e3bb1eca0fcb@github.com>

On Thu, 20 Jun 2024 20:11:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch, which is a backport of the fix in #19615 to JDK 23.
> 
> This is not a clean patch, because the old patch was done on JDK-8333479 (#19585) which was absent in JDK 23; however, the conflicts were small, and the only real changes were that `methodTypeDesc` and `classDesc` from `ConstantUtils` were not available, so the original approaches were retained. There is also import adjustments.
> 
> Testing: tier 1-3

This pull request has now been integrated.

Changeset: 1dbad805
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1dbad8058b79c4e31e389913a7259323a9b8ab93
Stats:     238 lines in 2 files changed: 161 ins; 9 del; 68 mod

8333854: IllegalAccessError with proxies after JDK-8332457

Reviewed-by: asotona
Backport-of: 91bd85d65dff9cea91b88da7ef241be5c7b85f94

-------------

PR: https://git.openjdk.org/jdk/pull/19815

From liach at openjdk.org  Fri Jun 21 22:41:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Jun 2024 22:41:20 GMT
Subject: Integrated: 8333748: javap crash - Fatal error: Unmatched bit position
 0x2 for location CLASS
In-Reply-To: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
References: <UOV8KZ-qvjz1FFo21-ZRvzJcd5ZuNgES2AoDY__Ud0Q=.880b04b4-47cc-40cb-8837-308e4f69ac34@github.com>
Message-ID: <vZGlkJyqa_uPZjzpg-D2rjg8XmO0ezhPYirKVzoZNVE=.393fcad4-1ebc-4986-9961-d90f1fe66783@github.com>

On Thu, 13 Jun 2024 17:50:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, javap crashes for class files that have set non-zero values for undefined access flag bits, as `java.lang.reflect.AccessFlag.maskToAccessFlag` and `java.lang.classfile.AccessFlags.flags` fail. In contrast, the JVMS, though asking for these bits to be set to 0, requires VM to proceed and ignore these bits. javap should emulate the VM behavior and proceed rendering, ignoring these undefined bits.
> 
> In addition, a few bytecode generation utilities in the JDK set unused bits, such as in `java.lang.invoke.MethodHandleImpl.BindCaller#generateInvokerTemplate` and `java.lang.invoke.GenerateJLIClassesHelper#generateCodeBytesForLFs`. Those can be updated in a later cleanup.

This pull request has now been integrated.

Changeset: 7e55ed3b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e55ed3b106ed08956d2d38b7c99fb81704667c9
Stats:     228 lines in 4 files changed: 168 ins; 44 del; 16 mod

8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/19708

From liach at openjdk.org  Sat Jun 22 00:32:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 22 Jun 2024 00:32:25 GMT
Subject: [jdk23] RFR: 8333748: javap crash - Fatal error: Unmatched bit
 position 0x2 for location CLASS
Message-ID: <YmIBADgZyX5JQRkQ01cWvieUCPW-kCN2BUcPiyPcadg=.941a0ca9-021d-448c-aef2-fd458ef9e07f@github.com>

Please review this clean backport of #19708, to make javap recover and continue after encountering undefined access flag bits set while still exiting with a code of error, allowing it to error against improper bits while still providing as much output as possible.

-------------

Commit messages:
 - Backport 7e55ed3b106ed08956d2d38b7c99fb81704667c9

Changes: https://git.openjdk.org/jdk/pull/19839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333748
  Stats: 228 lines in 4 files changed: 168 ins; 44 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19839/head:pull/19839

PR: https://git.openjdk.org/jdk/pull/19839

From syan at openjdk.org  Sat Jun 22 08:12:33 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Jun 2024 08:12:33 GMT
Subject: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as manual
Message-ID: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>

Hi all,

This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.

Thanks!

-------------

Commit messages:
 - Backport 8e1d2b091c9a311d98a0b886a803fb18d4405d8a

Changes: https://git.openjdk.org/jdk/pull/19841/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19841&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334441
  Stats: 160 lines in 10 files changed: 5 ins; 2 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/19841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19841/head:pull/19841

PR: https://git.openjdk.org/jdk/pull/19841

From duke at openjdk.org  Sat Jun 22 08:58:42 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 22 Jun 2024 08:58:42 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm
Message-ID: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>

I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).

The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into patchSqrt
 - An optimization
 - Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into patchSqrt
 - Merge branch 'openjdk:master' into patchSqrt
 - An optimization
 - An optimization
 - Optimized memory usage of square root algorithm
 - An optimization
 - Update comment
 - Update MutableBigInteger.java
 - ... and 17 more: https://git.openjdk.org/jdk/compare/50bed6c6...d95f9e7f

Changes: https://git.openjdk.org/jdk/pull/19710/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334755
  Stats: 182 lines in 2 files changed: 172 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Sat Jun 22 08:58:43 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 22 Jun 2024 08:58:43 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>

On Thu, 13 Jun 2024 18:31:33 GMT, fabioromano1 <duke at openjdk.org> wrote:

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

src/java.base/share/classes/java/math/MutableBigInteger.java line 265:

> 263:      */
> 264:     final int compare(MutableBigInteger b) {
> 265:         this.normalize();

See [JDK-8334483](http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8334483)

src/java.base/share/classes/java/math/MutableBigInteger.java line 293:

> 291:      */
> 292:     private int compareShifted(MutableBigInteger b, int ints) {
> 293:         this.normalize();

See [JDK-8334483](http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8334483)

src/java.base/share/classes/java/math/MutableBigInteger.java line 826:

> 824:         while (x > 0 && y > 0) {
> 825:             x--; y--;
> 826:             int bval = y < addend.intLen ? addend.value[y+addend.offset] : 0;

See [JDK-8334434](https://bugs.openjdk.org/browse/JDK-8334434)

src/java.base/share/classes/java/math/MutableBigInteger.java line 897:

> 895:         rstart -= x;
> 896: 
> 897:         int len = Math.min(y, addend.intLen);

See [JDK-8334434](https://bugs.openjdk.org/browse/JDK-8334434)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1644669348
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1644669676
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1644037011
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1644037695

From duke at openjdk.org  Sat Jun 22 09:08:24 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 22 Jun 2024 09:08:24 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v2]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <THKBlz9jFVKqs-NpmO_1JMu6kh3gY_b2HHT3QbiIIb8=.f770345e-f75b-4218-84d7-0c601648e2be@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision:

 - Inserted author
 - Merge branch 'openjdk:master' into patchSqrt
 - Merge branch 'openjdk:master' into patchSqrt
 - An optimization
 - Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into patchSqrt
 - Merge branch 'openjdk:master' into patchSqrt
 - An optimization
 - An optimization
 - Optimized memory usage of square root algorithm
 - An optimization
 - ... and 19 more: https://git.openjdk.org/jdk/compare/4ba48068...ddd6d736

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/d95f9e7f..ddd6d736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=00-01

  Stats: 18281 lines in 220 files changed: 12473 ins; 4295 del; 1513 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Sat Jun 22 09:32:37 2024
From: duke at openjdk.org (Oussama Louati)
Date: Sat, 22 Jun 2024 09:32:37 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v12]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <5P7NHERlwLSZ0EvtbkySU4jDvLvIDLWDndAXndkC60k=.72ca6230-dd08-4588-b416-bf38e4cf7d3d@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with eight additional commits since the last revision:

 - fix: work done
 - fix: work in progress
 - fix: one pass transformation per method
 - fix: one pass transformation per method
 - fix: one pass transformation per method
 - fix: fixing
 - commit before disaster
 - fix: remove adding NOPS into method instruction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/f869cce8..7e928ced

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=10-11

  Stats: 112 lines in 1 file changed: 15 ins; 53 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From duke at openjdk.org  Sat Jun 22 09:39:46 2024
From: duke at openjdk.org (Oussama Louati)
Date: Sat, 22 Jun 2024 09:39:46 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v13]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <fId2BaL6MEtn2fzXx1M1y2DNPzJgdovzOgY9i8pe2qg=.57510f4b-00f9-406e-80c3-0483d6f736e7@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with six additional commits since the last revision:

 - Update test/jdk/java/lang/invoke/indify/Indify.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update test/jdk/java/lang/invoke/indify/Indify.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update test/jdk/java/lang/invoke/indify/Indify.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update test/jdk/java/lang/invoke/indify/Indify.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update test/jdk/java/lang/invoke/indify/Indify.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - fix: work done

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/7e928ced..f80fd483

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=11-12

  Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From duke at openjdk.org  Sat Jun 22 09:44:17 2024
From: duke at openjdk.org (Oussama Louati)
Date: Sat, 22 Jun 2024 09:44:17 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v13]
In-Reply-To: <9l-tSZGQ3LgJm95ZcSQyUwHIS6ptgQ6WzRixg39L3xc=.c8658387-c3e3-4f6b-8cf5-e110e0a62cf4@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
 <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>
 <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
 <9l-tSZGQ3LgJm95ZcSQyUwHIS6ptgQ6WzRixg39L3xc=.c8658387-c3e3-4f6b-8cf5-e110e0a62cf4@github.com>
Message-ID: <14A-OBSZ-E6i8N2jFA80HtWKjS_YJHO-OcLRNSnBmqk=.0631e7d4-1fae-4b18-8563-f41a3c401f74@github.com>

On Mon, 17 Jun 2024 08:33:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> We need a boolean value to determine if we should proceed after replacing the appropriate "pop" instruction with an "invokedynamic" instruction. However, instead of using just a boolean field, we use a stack. The reason for this is that within the lambda expression, we can only use final variables. By using a stack, we can update its value as needed, which is why this approach is chosen.
>
> I see here an iteration over instructions of a method, where the whole class is retransformed in certain situations and some status is passed back in a stack of booleans.
> The whole conversion should be implemented in a single transformation.
> Original code repeatedly replaced instructions inline (that is BTW reason why added nops below), however architecture of ClassFile API is different, you are transforming one class into completely new class (free to remove and add as many elements as you need). You can compose transformations into complex trees and you can also collect information before the transformation, however the class transformation should be executed only once.

Done. The code has been refactored to perform the transformation in one go.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649620002

From hgreule at openjdk.org  Sat Jun 22 12:19:12 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Sat, 22 Jun 2024 12:19:12 GMT
Subject: Integrated: 8334708: FFM: two javadoc problems
In-Reply-To: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
References: <AqfJiDNXhmpFVYFkR6E-kfE8baF2aaEUJW0u2WlxxzE=.41cf07d3-c4f7-4f6b-8d82-5638d1125fd4@github.com>
Message-ID: <s0W_0gRI71RRu8N-0RbW6_bjv-QPWjjfAyfN0Ybf_qM=.3cdb460b-0d5e-4e17-944f-03d0fc7a973e@github.com>

On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Addresses two simple problems regarding javadocs in the FFM API.

This pull request has now been integrated.

Changeset: 72ca7baf
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8334708: FFM: two javadoc problems

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/19820

From liach at openjdk.org  Sat Jun 22 13:37:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 22 Jun 2024 13:37:21 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v13]
In-Reply-To: <fId2BaL6MEtn2fzXx1M1y2DNPzJgdovzOgY9i8pe2qg=.57510f4b-00f9-406e-80c3-0483d6f736e7@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <fId2BaL6MEtn2fzXx1M1y2DNPzJgdovzOgY9i8pe2qg=.57510f4b-00f9-406e-80c3-0483d6f736e7@github.com>
Message-ID: <1VvSeqYn-4WfWD73C69fUyTkbZG4oxa7VSLiRKQy79o=.5901dbae-c30f-4d91-9bf0-beb82f5fe4e0@github.com>

On Sat, 22 Jun 2024 09:39:46 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Update test/jdk/java/lang/invoke/indify/Indify.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update test/jdk/java/lang/invoke/indify/Indify.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update test/jdk/java/lang/invoke/indify/Indify.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update test/jdk/java/lang/invoke/indify/Indify.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update test/jdk/java/lang/invoke/indify/Indify.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - fix: work done

test/jdk/java/lang/invoke/indify/Indify.java line 378:

> 376: 
> 377:     void writeNewClassFile(ClassModel newClassModel, Boolean changed, File sourceFile) throws IOException {
> 378:         byte[] new_bytes = transformToBytes(newClassModel);

`newBytes`

test/jdk/java/lang/invoke/indify/Indify.java line 379:

> 377:     void writeNewClassFile(ClassModel newClassModel, Boolean changed, File sourceFile) throws IOException {
> 378:         byte[] new_bytes = transformToBytes(newClassModel);
> 379:         if(changed || all){

If you are using idea, select this whole method body and run ctrl+alt+L to format the code. A few improper formatting.

test/jdk/java/lang/invoke/indify/Indify.java line 478:

> 476:             Logic logic = new Logic(model);
> 477:             Boolean changed = logic.transform();
> 478:             if (verbose && changed) System.err.println("(no change)");

Suggestion:

            if (verbose && !changed) System.err.println("(no change)");

test/jdk/java/lang/invoke/indify/Indify.java line 480:

> 478:             if (verbose && changed) System.err.println("(no change)");
> 479:             logic.reportPatternMethods(!verbose, keepgoing);
> 480:             byte[] new_Bytes = transformToBytes(logic.classModel);

`newBytes`

test/jdk/java/lang/invoke/indify/Indify.java line 501:

> 499:             if (!findPatternMethods()) return false;
> 500: 
> 501:             Stack<PoolEntry> pendingIndy = new Stack<>(); // stack to hold the pending invokedynamic constant to replace the invokeExact

Please use `Deque` and `ArrayDeque` instead.

test/jdk/java/lang/invoke/indify/Indify.java line 536:

> 534:                         pendingIndy.push(newConstant);
> 535:                         if (!quiet) {
> 536:                             System.err.println(":::Transforming the Method Class for: " + ((InvokeInstruction) e).method().name() +

Suggestion:

                            System.err.println(":::Transforming the Method Class for: " + invokeInstruction.method().name() +

test/jdk/java/lang/invoke/indify/Indify.java line 545:

> 543:                     } else {
> 544:                         if (!quiet) {
> 545:                             System.err.println(":::Transforming the Method Call of: " + ((InvokeInstruction) e).method().name() +

Suggestion:

                            System.err.println(":::Transforming the Method Call of: " + invokeInstruction.method().name() +

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649697535
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649697624
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649697501
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649697679
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649698078
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649699193
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649699115

From duke at openjdk.org  Sat Jun 22 15:45:44 2024
From: duke at openjdk.org (Oussama Louati)
Date: Sat, 22 Jun 2024 15:45:44 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v14]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <eAN6hpfknoFcqsAHUbrIpVBS5ZzqsgfwIT_t3VfADHw=.b9339ffa-37aa-43cd-a93f-9edbf57856f5@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  fix: review addressing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/f80fd483..03ec3ed6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=12-13

  Stats: 53 lines in 1 file changed: 2 ins; 16 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From duke at openjdk.org  Sat Jun 22 15:50:43 2024
From: duke at openjdk.org (Oussama Louati)
Date: Sat, 22 Jun 2024 15:50:43 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v15]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <Wo3_An4oZy9Z_AmmnYVkQxYm34ka-KV3FBbyvBh76W4=.37920192-5196-4b06-a4c2-dddb29c00fe4@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  fix: review addressing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/03ec3ed6..c5a08302

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From duke at openjdk.org  Sat Jun 22 15:55:28 2024
From: duke at openjdk.org (Oussama Louati)
Date: Sat, 22 Jun 2024 15:55:28 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <bDDWvgroHrJd2QuR7xgWfYnIGzp6-guhSseqQdUTEZ4=.41c2a09e-0b47-4db7-bc5a-4850e8fb64e3@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  remove: removed unnecessary logging

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/c5a08302..02347415

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From duke at openjdk.org  Sat Jun 22 16:34:22 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 22 Jun 2024 16:34:22 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v3]
In-Reply-To: <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@github.com>
Message-ID: <aS3B-bnFfVvO9KEmqmRO2TEiFikuZgxS-zpES7ftIEI=.c3400fb1-3204-47bd-a6a6-aaded8c4c026@github.com>

On Mon, 29 May 2023 07:25:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
>> 
>> switch (obj) {
>>     case String s when s.isEmpty() -> {}
>>     case String s -> {}
>>     case CharSequence cs -> {}
>>     ...
>> }
>> 
>> 
>> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
>> 
>> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
>> 
>> obj == null ? -1
>>                   : switch (restartIndex) {
>>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>>                         ...
>>                         default -> <labels-count>;
>>                     }
>> 
>> 
>> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
>> 
>> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
>> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
>> 
>> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
>> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
>> 
>> 
>> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291966
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 327:

> 325: 
> 326:         MethodHandle target;
> 327:         boolean constantsOnly = Stream.of(labels).allMatch(l -> enumClass.isAssignableFrom(EnumDesc.class));

This?expression is?always?false, it?should?be:
Suggestion:

        boolean constantsOnly = Stream.of(labels).allMatch(l -> l.isAssignableFrom(EnumDesc.class));

-------------

PR Review: https://git.openjdk.org/jdk/pull/9779#pullrequestreview-2133851725
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1649740572

From clanger at openjdk.org  Sat Jun 22 16:49:09 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 22 Jun 2024 16:49:09 GMT
Subject: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as
 manual
In-Reply-To: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
References: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
Message-ID: <Dut_xRz089GHRCb5A2QVqgL1GwyS3UEfTY1QT4-bZUI=.f17ce666-59aa-4c1a-9155-fab35ae900f5@github.com>

On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.
> 
> Thanks!

Thanks for doing the backport.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19841#pullrequestreview-2133855195

From redestad at openjdk.org  Sat Jun 22 18:30:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 22 Jun 2024 18:30:21 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v3]
In-Reply-To: <XqLJ4xChgeGDY5zK_NrenDYn0Bmx2PUcfeZ_xoKAzpg=.02b77bdc-70b6-4ece-81c8-6e33cdda3c97@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@github.com>
 <XqLJ4xChgeGDY5zK_NrenDYn0Bmx2PUcfeZ_xoKAzpg=.02b77bdc-70b6-4ece-81c8-6e33cdda3c97@github.com>
Message-ID: <nfuei1AUbsMS9uBvzF-VdR1a3LPj_77CrmcTNmJRhOI=.8fcee1a6-2bb3-4dc3-b155-72e72b447541@github.com>

On Wed, 3 Apr 2024 16:17:57 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reflecting review feedback.
>>  - Merge branch 'master' into JDK-8291966
>>  - Adding comments
>>  - Improving performance
>>  - Merge branch 'master' into JDK-8291966
>>  - 8291966: SwitchBootstrap.typeSwitch could be faster
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 389:
> 
>> 387:             }
>> 388:         }
>> 389:         return enumMap.map[value.ordinal()];
> 
> `enumMap.map` never?gets?set before?this?line.

There's a bug filed for this already: https://bugs.openjdk.org/browse/JDK-8332522 

@lahodaj explained that this broken code is part of an optimization which is never attempted (IIRC due to the bug you noted on line 327). JDK-833522 seem like a good place to continue this conversation..?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1649761928

From duke at openjdk.org  Sat Jun 22 19:16:21 2024
From: duke at openjdk.org (duke)
Date: Sat, 22 Jun 2024 19:16:21 GMT
Subject: Withdrawn: 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: <eTAg5Bp9b3-2P4AbaN_4ED02lCY-aDNnuf1kjNq66bs=.91ec824c-0950-442b-bf77-bd6df6b5b7a0@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..

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18177

From duke at openjdk.org  Sat Jun 22 20:29:22 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 22 Jun 2024 20:29:22 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v3]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <Qv1miGsb2FNb34cxCESWDhDhgw1zlhGKBfz0L26iwZI=.7b0103dd-dc62-434a-a78e-1f664cf64a9a@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Special cases and base case optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/ddd6d736..54fc5fee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=01-02

  Stats: 47 lines in 1 file changed: 18 ins; 10 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Sat Jun 22 21:09:21 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 22 Jun 2024 21:09:21 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v4]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <HGi5zpIhXdWwfC3ax3mvrzR1BM83hsvi-jg3pu4KJTc=.a7e796d9-da4f-4988-b18f-cb47becc78fa@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Simplification of code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/54fc5fee..7ea50cc8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=02-03

  Stats: 29 lines in 1 file changed: 19 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Sat Jun 22 21:12:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 22 Jun 2024 21:12:36 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <qVqeSWVD9DlyJn-CXVwbyVG3K1yep2WMh8HNM4VMDLQ=.61cdd134-3605-4fa2-aed2-883a51864838@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/7ea50cc8..9a3bdc2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From syan at openjdk.org  Sun Jun 23 00:37:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Jun 2024 00:37:09 GMT
Subject: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as
 manual
In-Reply-To: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
References: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
Message-ID: <JclxbYiWzL5w7suXCWGo2AxMLQwvnmxav20sMYsKd34=.2b3a4217-b3d9-4b8f-9ca0-d186c92882ec@github.com>

On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.
> 
> Thanks!

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19841#issuecomment-2184269585

From djelinski at openjdk.org  Sun Jun 23 06:22:17 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 23 Jun 2024 06:22:17 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <qVqeSWVD9DlyJn-CXVwbyVG3K1yep2WMh8HNM4VMDLQ=.61cdd134-3605-4fa2-aed2-883a51864838@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <qVqeSWVD9DlyJn-CXVwbyVG3K1yep2WMh8HNM4VMDLQ=.61cdd134-3605-4fa2-aed2-883a51864838@github.com>
Message-ID: <50ILb0yG-6tgB1Gyhj9P94l30qK7tCSVMeIy0ZZw0eo=.ec10fd71-37c4-465b-aed1-67127fe32997@github.com>

On Sat, 22 Jun 2024 21:12:36 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>> 
>> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused import

Thanks for contributing to the OpenJDK!
What tests did you run for this change? How did you compare the performance of the new vs the original method? How can we reproduce the results?

Please add a JMH benchmark for your changes. JMH benchmarks are the standard method of evaluating performance improvements.

-------------

Changes requested by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19710#pullrequestreview-2134108121

From djelinski at openjdk.org  Sun Jun 23 06:22:18 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 23 Jun 2024 06:22:18 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
Message-ID: <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>

On Tue, 18 Jun 2024 15:34:16 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused import
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 293:
> 
>> 291:      */
>> 292:     private int compareShifted(MutableBigInteger b, int ints) {
>> 293:         this.normalize();
> 
> See [JDK-8334483](http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8334483)

It is the responsibility of the caller to ensure that the parameters are normalized. Calling normalize isn't free, and it's usually easy to tell when a number needs to be normalized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1649935313

From hgreule at openjdk.org  Sun Jun 23 06:37:34 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Sun, 23 Jun 2024 06:37:34 GMT
Subject: [jdk23] RFR: 8334708: FFM: two javadoc problems
Message-ID: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>

Hi all,

This pull request contains a backport of commit [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Hannes Greule on 22 Jun 2024 and was reviewed by Maurizio Cimadamore.

Thanks!

-------------

Commit messages:
 - Backport 72ca7bafcd49a98c1fe09da72e4e47683f052e9d

Changes: https://git.openjdk.org/jdk/pull/19846/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334708
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19846/head:pull/19846

PR: https://git.openjdk.org/jdk/pull/19846

From duke at openjdk.org  Sun Jun 23 08:47:25 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 23 Jun 2024 08:47:25 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v13]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <F-rioR0rIUORqyBP2vZV3aQaJo9F78NtNGQ11UeZAGw=.61e5fb1b-bbfe-43d8-8946-65a939491821@github.com>

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  private static final field `UNSAFE`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/fa72999a..6be002ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=11-12

  Stats: 6 lines in 1 file changed: 2 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From duke at openjdk.org  Sun Jun 23 08:59:10 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 08:59:10 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
 <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>
Message-ID: <IZM8TWASMzh9IywUR1IuTGUo2dEkNTNy2AZiagNHIhk=.71d7e18a-9f37-4caf-9585-bb5bc0ca159a@github.com>

On Sun, 23 Jun 2024 05:57:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 293:
>> 
>>> 291:      */
>>> 292:     private int compareShifted(MutableBigInteger b, int ints) {
>>> 293:         this.normalize();
>> 
>> See [JDK-8334483](http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8334483)
>
> It is the responsibility of the caller to ensure that the parameters are normalized. Calling normalize isn't free, and it's usually easy to tell when a number needs to be normalized.

@djelinski So, why the documentation does not specify that the method assumes the arguments are normalized? And why the method `subtract(MutableBigInteger)` does not call `normalize()` on arguments before calling `compare(MutableBigInteger)`? Does `subtract` assume implicitly that the arguments are normalized?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1650022336

From duke at openjdk.org  Sun Jun 23 09:04:10 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 09:04:10 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <50ILb0yG-6tgB1Gyhj9P94l30qK7tCSVMeIy0ZZw0eo=.ec10fd71-37c4-465b-aed1-67127fe32997@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <qVqeSWVD9DlyJn-CXVwbyVG3K1yep2WMh8HNM4VMDLQ=.61cdd134-3605-4fa2-aed2-883a51864838@github.com>
 <50ILb0yG-6tgB1Gyhj9P94l30qK7tCSVMeIy0ZZw0eo=.ec10fd71-37c4-465b-aed1-67127fe32997@github.com>
Message-ID: <ey6dRRuK2OZtgT-gHz4WYyW8VFajS1B9c6HYfO61N-k=.7594d234-c321-40fc-8f7f-9224048d5f71@github.com>

On Sun, 23 Jun 2024 06:19:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused import
>
> Thanks for contributing to the OpenJDK!
> What tests did you run for this change? How did you compare the performance of the new vs the original method? How can we reproduce the results?
> 
> Please add a JMH benchmark for your changes. JMH benchmarks are the standard method of evaluating performance improvements.

@djelinski I ran the tests for BigInteger's square root and remainder in the test class [BigIntegerTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/math/BigInteger/BigIntegerTest.java).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2184909896

From djelinski at openjdk.org  Sun Jun 23 09:51:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 23 Jun 2024 09:51:09 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <IZM8TWASMzh9IywUR1IuTGUo2dEkNTNy2AZiagNHIhk=.71d7e18a-9f37-4caf-9585-bb5bc0ca159a@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
 <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>
 <IZM8TWASMzh9IywUR1IuTGUo2dEkNTNy2AZiagNHIhk=.71d7e18a-9f37-4caf-9585-bb5bc0ca159a@github.com>
Message-ID: <uaeVT8T9xJa6eOOVHdc4R8qoyVVJuTMlcf92ny_6szQ=.e28e7e09-38c5-45a5-a49e-961b4da09444@github.com>

On Sun, 23 Jun 2024 08:55:17 GMT, fabioromano1 <duke at openjdk.org> wrote:

> why the documentation does not specify that the method assumes the arguments are normalized?

Well, the best answer I can offer is "because no one documented it yet". `MutableBigInteger` is an internal class, so most people never see its documentation.
> And why the method subtract(MutableBigInteger) does not call normalize() on arguments before calling compare(MutableBigInteger)? Does subtract assume implicitly that the arguments are normalized too?

Most likely. If you check the code you'll notice that most methods that change the `MutableBigInteger` value (like `subtract`) call `normalize` after performing the operation, so the values should be normalized most of the time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1650032491

From duke at openjdk.org  Sun Jun 23 09:56:09 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 09:56:09 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <uaeVT8T9xJa6eOOVHdc4R8qoyVVJuTMlcf92ny_6szQ=.e28e7e09-38c5-45a5-a49e-961b4da09444@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
 <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>
 <IZM8TWASMzh9IywUR1IuTGUo2dEkNTNy2AZiagNHIhk=.71d7e18a-9f37-4caf-9585-bb5bc0ca159a@github.com>
 <uaeVT8T9xJa6eOOVHdc4R8qoyVVJuTMlcf92ny_6szQ=.e28e7e09-38c5-45a5-a49e-961b4da09444@github.com>
Message-ID: <uaZ17EJyhUMJydTFKeLFoNTcsXjs8EC60IlgF-suWT0=.60720712-ae1d-4c75-a4eb-28b6fc44bdd4@github.com>

On Sun, 23 Jun 2024 09:48:59 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Most likely. If you check the code you'll notice that most methods that change the `MutableBigInteger` value (like `subtract`) call `normalize` after performing the operation, so the values should be normalized most of the time.

@djelinski Unfortunately, this is not always true. In fact, without forcing normalization before comparing, the program leads to failure in thousands of cases, while forcing the normalization resolves all the failures...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1650033332

From duke at openjdk.org  Sun Jun 23 09:57:19 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 23 Jun 2024 09:57:19 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v12]
In-Reply-To: <rYEbV8xlwLh3Cf7YgmBIZqzGlImRrnYX9rdugdgLCUE=.37968711-d1dc-4ef7-895c-7e1c961b3434@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <d7kEmw8X84iZgGkLLa7XYSVipLSkiLZUz2p83dL_TEw=.941a9357-530b-4ec7-b815-7079302a990f@github.com>
 <rYEbV8xlwLh3Cf7YgmBIZqzGlImRrnYX9rdugdgLCUE=.37968711-d1dc-4ef7-895c-7e1c961b3434@github.com>
Message-ID: <bNJ4y2hSDfReqk0zVAOVXe7DBRr-JX1OXvPJvOoflgI=.1c6d3cb5-9ca3-40ae-9a90-afb45992daea@github.com>

On Thu, 20 Jun 2024 09:54:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Utf16 case remove `append first utf16 char`
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 832:
> 
>> 830:         // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
>> 831:         long address  = Unsafe.ARRAY_BYTE_BASE_OFFSET + index;
>> 832:         Unsafe UNSAFE = Unsafe.getUnsafe();
> 
> Perhaps better to put in a `private static final` field

already using `private static final UNSAFE`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1650033405

From djelinski at openjdk.org  Sun Jun 23 10:26:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 23 Jun 2024 10:26:09 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <uaZ17EJyhUMJydTFKeLFoNTcsXjs8EC60IlgF-suWT0=.60720712-ae1d-4c75-a4eb-28b6fc44bdd4@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
 <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>
 <IZM8TWASMzh9IywUR1IuTGUo2dEkNTNy2AZiagNHIhk=.71d7e18a-9f37-4caf-9585-bb5bc0ca159a@github.com>
 <uaeVT8T9xJa6eOOVHdc4R8qoyVVJuTMlcf92ny_6szQ=.e28e7e09-38c5-45a5-a49e-961b4da09444@github.com>
 <uaZ17EJyhUMJydTFKeLFoNTcsXjs8EC60IlgF-suWT0=.60720712-ae1d-4c75-a4eb-28b6fc44bdd4@github.com>
Message-ID: <ZeRlbXbegqeQnBXz28_fEmWAp981qNmULseKRC02qGw=.04a61c6b-48e6-43b2-a5e0-46ad4fe8ffcf@github.com>

On Sun, 23 Jun 2024 09:53:48 GMT, fabioromano1 <duke at openjdk.org> wrote:

>>> why the documentation does not specify that the method assumes the arguments are normalized?
>> 
>> Well, the best answer I can offer is "because no one documented it yet". `MutableBigInteger` is an internal class, so most people never see its documentation.
>>> And why the method subtract(MutableBigInteger) does not call normalize() on arguments before calling compare(MutableBigInteger)? Does subtract assume implicitly that the arguments are normalized too?
>> 
>> Most likely. If you check the code you'll notice that most methods that change the `MutableBigInteger` value (like `subtract`) call `normalize` after performing the operation, so the values should be normalized most of the time.
>
>> Most likely. If you check the code you'll notice that most methods that change the `MutableBigInteger` value (like `subtract`) call `normalize` after performing the operation, so the values should be normalized most of the time.
> 
> @djelinski Unfortunately, this is not always true. In fact, without forcing normalization before comparing, the program leads to failure in thousands of cases, while forcing the normalization resolves all the failures...
> 
> So, the question is: since it is not always guaranteed that the arguments are normalized, is it responsibility of `subtract` to normalize arguments?

Which program are you referring to?

It is the responsibility of the caller of `subtract` to ensure that the arguments are normalized. This may or may not require calling `normalize`, depending on whether the argument is normalized or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1650038762

From duke at openjdk.org  Sun Jun 23 10:36:10 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 10:36:10 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <ZeRlbXbegqeQnBXz28_fEmWAp981qNmULseKRC02qGw=.04a61c6b-48e6-43b2-a5e0-46ad4fe8ffcf@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
 <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>
 <IZM8TWASMzh9IywUR1IuTGUo2dEkNTNy2AZiagNHIhk=.71d7e18a-9f37-4caf-9585-bb5bc0ca159a@github.com>
 <uaeVT8T9xJa6eOOVHdc4R8qoyVVJuTMlcf92ny_6szQ=.e28e7e09-38c5-45a5-a49e-961b4da09444@github.com>
 <uaZ17EJyhUMJydTFKeLFoNTcsXjs8EC60IlgF-suWT0=.60720712-ae1d-4c75-a4eb-28b6fc44bdd4@github.com>
 <ZeRlbXbegqeQnBXz28_fEmWAp981qNmULseKRC02qGw=.04a61c6b-48e6-43b2-a5e0-46ad4fe8ffcf@github.com>
Message-ID: <UJBhbrzVigwUcE9UzdZiQYsI9ip5mTfTDIhEPbJ_8ZU=.fde09365-db70-4af6-8f65-52ce5d4e1318@github.com>

On Sun, 23 Jun 2024 10:23:15 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> Most likely. If you check the code you'll notice that most methods that change the `MutableBigInteger` value (like `subtract`) call `normalize` after performing the operation, so the values should be normalized most of the time.
>> 
>> @djelinski Unfortunately, this is not always true. In fact, without forcing normalization before comparing, the program leads to failure in thousands of cases, while forcing the normalization resolves all the failures...
>> 
>> So, the question is: since it is not always guaranteed that the arguments are normalized, is it responsibility of `subtract` to normalize arguments?
>
> Which program are you referring to?
> 
> It is the responsibility of the caller of `subtract` to ensure that the arguments are normalized. This may or may not require calling `normalize`, depending on whether the argument is normalized or not.

@djelinski I'm referring to the tests of square root for BigIntegers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1650040731

From djelinski at openjdk.org  Sun Jun 23 10:55:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 23 Jun 2024 10:55:10 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <UJBhbrzVigwUcE9UzdZiQYsI9ip5mTfTDIhEPbJ_8ZU=.fde09365-db70-4af6-8f65-52ce5d4e1318@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
 <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>
 <IZM8TWASMzh9IywUR1IuTGUo2dEkNTNy2AZiagNHIhk=.71d7e18a-9f37-4caf-9585-bb5bc0ca159a@github.com>
 <uaeVT8T9xJa6eOOVHdc4R8qoyVVJuTMlcf92ny_6szQ=.e28e7e09-38c5-45a5-a49e-961b4da09444@github.com>
 <uaZ17EJyhUMJydTFKeLFoNTcsXjs8EC60IlgF-suWT0=.60720712-ae1d-4c75-a4eb-28b6fc44bdd4@github.com>
 <ZeRlbXbegqeQnBXz28_fEmWAp981qNmULseKRC02qGw=.04a61c6b-48e6-43b2-a5e0-46ad4fe8ffcf@github.com>
 <UJBhbrzVigwUcE9UzdZiQYsI9ip5mTfTDIhEPbJ_8ZU=.fde09365-db70-4af6-8f65-52ce5d4e1318@github.com>
Message-ID: <G7r_G2mzzFsl6x1WCs_G76Dr0AB9r_hfF8nMw5lRPuE=.0b41b817-b9b0-4080-9f8e-af4fc4ee3e3a@github.com>

On Sun, 23 Jun 2024 10:33:08 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Which program are you referring to?
>> 
>> It is the responsibility of the caller of `subtract` to ensure that the arguments are normalized. This may or may not require calling `normalize`, depending on whether the argument is normalized or not.
>
> @djelinski I'm referring to the tests of square root for BigIntegers.

ah, so before your changes, the arguments were always normalized, and now they are not?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1650044094

From duke at openjdk.org  Sun Jun 23 11:21:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 11:21:36 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v6]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <bwzjmvMIBDOhcFvvW3JIVtI8Oz-8a0bh7pPRFwnOIIE=.850a9065-7d3c-481a-8ff6-ae8560299536@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Normalize blocks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/9a3bdc2c..0baab1b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=04-05

  Stats: 19 lines in 1 file changed: 6 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Sun Jun 23 11:21:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 11:21:36 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v6]
In-Reply-To: <G7r_G2mzzFsl6x1WCs_G76Dr0AB9r_hfF8nMw5lRPuE=.0b41b817-b9b0-4080-9f8e-af4fc4ee3e3a@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <uafBuZ_iEXKANdEBdY-LI8L8WhjjxGq9OBND6ZCAeZk=.75fa705e-cf4b-42f4-97b4-25df4fa6d3be@github.com>
 <gJHp8pHZ0QTK7eQVh-XncoH3EOAGoGWQvrAStirjhCQ=.603e5405-24d9-481c-84f4-5eb63eff02d1@github.com>
 <IZM8TWASMzh9IywUR1IuTGUo2dEkNTNy2AZiagNHIhk=.71d7e18a-9f37-4caf-9585-bb5bc0ca159a@github.com>
 <uaeVT8T9xJa6eOOVHdc4R8qoyVVJuTMlcf92ny_6szQ=.e28e7e09-38c5-45a5-a49e-961b4da09444@github.com>
 <uaZ17EJyhUMJydTFKeLFoNTcsXjs8EC60IlgF-suWT0=.60720712-ae1d-4c75-a4eb-28b6fc44bdd4@github.com>
 <ZeRlbXbegqeQnBXz28_fEmWAp981qNmULseKRC02qGw=.04a61c6b-48e6-43b2-a5e0-46ad4fe8ffcf@github.com>
 <UJBhbrzVigwUcE9UzdZiQYsI9ip5mTfTDIhEPbJ_8ZU=.fde09365-db70-4af6-8f65-52ce5d4e1318@github.com>
 <G7r_G2mzzFsl6x1WCs_G76Dr0AB9r_hfF8nMw5lRPuE=.0b41b817-b9b0-4080-9f8e-af4fc4ee3e3a@github.com>
Message-ID: <uExi-KHDD6khYysD9JIWXyQ0wnZUmGCcW0Za877ULn0=.1ac0569e-346c-4ec7-a6da-73c5d5f831a7@github.com>

On Sun, 23 Jun 2024 10:52:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> @djelinski I'm referring to the tests of square root for BigIntegers.
>
> ah, so before your changes, the arguments were always normalized, and now they are not?

@djelinski Now I found the issue and resolved it normalizing the Zimmerman's blocks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1650048901

From jpai at openjdk.org  Sun Jun 23 12:56:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 23 Jun 2024 12:56:09 GMT
Subject: [jdk23] RFR: 8334708: FFM: two javadoc problems
In-Reply-To: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>
References: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>
Message-ID: <JjppqhYLI6x2uCB30jT6w94rEn79U267SG7gzP6I41s=.0a72953e-c7b3-4f9c-87bd-7744196e5dc4@github.com>

On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hannes Greule on 22 Jun 2024 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

This doc-only clean backport looks fine to me for 23.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19846#pullrequestreview-2134273139

From duke at openjdk.org  Sun Jun 23 12:58:32 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 12:58:32 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v7]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <qr_Comfg9jyxC2NkMvQPeJQcLG7VduNicGbDDeYxcUk=.94b2109c-6f86-44d0-a2df-b198f1329ef0@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 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 34 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patchSqrt
 - Normalize blocks
 - Removed unused import
 - Simplification of code
 - Special cases and base case optimization
 - Inserted author
 - Merge branch 'openjdk:master' into patchSqrt
 - Merge branch 'openjdk:master' into patchSqrt
 - An optimization
 - Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into patchSqrt
 - ... and 24 more: https://git.openjdk.org/jdk/compare/f8f85818...67c44eee

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/0baab1b9..67c44eee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=05-06

  Stats: 49 lines in 9 files changed: 7 ins; 5 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Sun Jun 23 14:11:37 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 14:11:37 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v8]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <--ig6O2tjGP0w9WGp5BXfHEhkrxmX46ioJkiC8EvIKM=.c244e0ac-8130-4e77-87db-493126965849@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into patchSqrt
 - Added JMH benchmark class for Square Root

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/67c44eee..a6559a56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=06-07

  Stats: 110 lines in 2 files changed: 109 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Sun Jun 23 14:15:11 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 14:15:11 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v5]
In-Reply-To: <50ILb0yG-6tgB1Gyhj9P94l30qK7tCSVMeIy0ZZw0eo=.ec10fd71-37c4-465b-aed1-67127fe32997@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <qVqeSWVD9DlyJn-CXVwbyVG3K1yep2WMh8HNM4VMDLQ=.61cdd134-3605-4fa2-aed2-883a51864838@github.com>
 <50ILb0yG-6tgB1Gyhj9P94l30qK7tCSVMeIy0ZZw0eo=.ec10fd71-37c4-465b-aed1-67127fe32997@github.com>
Message-ID: <zxdd6A3JXw8sUy1OP3Xf8m5bXwDnkxH9-S9oA9mimho=.35dd3e17-7eda-4d6d-8dfb-5cad8e1fb515@github.com>

On Sun, 23 Jun 2024 06:19:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused import
>
> Thanks for contributing to the OpenJDK!
> What tests did you run for this change? How did you compare the performance of the new vs the original method? How can we reproduce the results?
> 
> Please add a JMH benchmark for your changes. JMH benchmarks are the standard method of evaluating performance improvements.

@djelinski Just added a JMH benchmark to evaluate the performance improvement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2185006281

From syan at openjdk.org  Sun Jun 23 15:16:31 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Jun 2024 15:16:31 GMT
Subject: [jdk23] RFR: 8333358: java/io/IO/IO.java test fails intermittently
Message-ID: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>

Hi all,

This pull request contains a backport of commit [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and was reviewed by Naoto Sato.

Thanks!

-------------

Commit messages:
 - Backport 1b1dba8082969244effa86ac03c6053b3b0ddc43

Changes: https://git.openjdk.org/jdk/pull/19847/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19847&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333358
  Stats: 69 lines in 3 files changed: 63 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19847/head:pull/19847

PR: https://git.openjdk.org/jdk/pull/19847

From liach at openjdk.org  Sun Jun 23 16:43:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Jun 2024 16:43:11 GMT
Subject: RFR: 8334394: Race condition in Class::protectionDomain [v2]
In-Reply-To: <Y_-dtrQSFf-aMn7biqRH7Sn2wmgkyjJDlKTkqk0QG08=.24828899-992c-4e1f-a0cc-7279be51dc86@github.com>
References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com>
 <Y_-dtrQSFf-aMn7biqRH7Sn2wmgkyjJDlKTkqk0QG08=.24828899-992c-4e1f-a0cc-7279be51dc86@github.com>
Message-ID: <kJHD5b0JOs2ueLqBhD26xWuvC2377Qx6eXgtlOheBLk=.cbe3e945-939e-4dba-951d-2aa41b07d84f@github.com>

On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Make sure `pd` is always the same object when `getProtectionDomain0` is null.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   explain why the test is related to the fix

Marked as reviewed by liach (Committer).

I think the move of protectionDomain and signers fields from injected to explicit should be done in a separate RFE: created https://bugs.openjdk.org/browse/JDK-8334772 to track that.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19752#pullrequestreview-2134339047
PR Comment: https://git.openjdk.org/jdk/pull/19752#issuecomment-2185147789

From syan at openjdk.org  Sun Jun 23 16:46:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Jun 2024 16:46:15 GMT
Subject: [jdk23] Integrated: 8334441: Mark tests in jdk_security_infra group as
 manual
In-Reply-To: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
References: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
Message-ID: <qN3U8jgina59iUU6qLDdo_TIhFUwCPUbn9CBXs9f1n8=.aa6c16e6-db5e-460a-95e4-bbc9220f7def@github.com>

On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 10d81a33
Author:    SendaoYan <syan at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10d81a337d45d4ab05ffdbc722ffc7dd832f5c82
Stats:     160 lines in 10 files changed: 5 ins; 2 del; 153 mod

8334441: Mark tests in jdk_security_infra group as manual

Reviewed-by: clanger
Backport-of: 8e1d2b091c9a311d98a0b886a803fb18d4405d8a

-------------

PR: https://git.openjdk.org/jdk/pull/19841

From duke at openjdk.org  Sun Jun 23 19:03:38 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 23 Jun 2024 19:03:38 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v9]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <rG6GcXc9p37UcRq6Ewnkuy97Q8F1FddjrrPT-GdMh0g=.a4fdc45d-ff1d-41a4-adc1-253d82f2dfbf@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/a6559a56..073c6046

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=07-08

  Stats: 15 lines in 2 files changed: 1 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From syan at openjdk.org  Mon Jun 24 00:44:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Jun 2024 00:44:22 GMT
Subject: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as
 manual
In-Reply-To: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
References: <6UHbqeqwA0i3OzrgMFQeU9Rar0Zn4agxDRxJ5x5nMxY=.84e02e7f-ef2d-48c2-8076-bc964eb71be9@github.com>
Message-ID: <Maq17kbCJSqljaKUsdt98yw5_r4XCFxj81_L8oFBVSc=.6e481ddd-b1f5-4913-8bcc-7f3ad99e0934@github.com>

On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan.
> 
> Thanks!

Thanks for the sponsor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19841#issuecomment-2185391474

From fyang at openjdk.org  Mon Jun 24 02:24:12 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 24 Jun 2024 02:24:12 GMT
Subject: RFR: 8334397: RISC-V: verify perf of ReverseBytesS/US
In-Reply-To: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
References: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
Message-ID: <vXYze1RNhsqxTVuanC5l9YX5GHD5n_4-cHge8TR09tg=.d6232f93-08bd-40d3-8561-d79e187f9c10@github.com>

On Fri, 21 Jun 2024 14:24:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> Thanks!
> 
> This is similar with previous JDK-8334396.
> Added some tests.
> 
> ###?Test
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> ? | Tests | Scores | Errors | Unit
> -- | -- | -- | -- | --
> Intrinsic, +zbb, +rvv | Characters.reverseBytes | 1654.535 | 69.36 | ns/op
> ? | Shorts.reverseBytes | 1795.403 | 44.015 | ns/op
> Intrinsic, +zbb, -rvv | Characters.reverseBytes | 1649.752 | 74.965 | ns/op
> ? | Shorts.reverseBytes | 1798.637 | 49.52 | ns/op
> Intrinsic, -zbb, +rvv | Characters.reverseBytes | 2279.588 | 44.222 | ns/op
> ? | Shorts.reverseBytes | 2441.674 | 63.895 | ns/op
> Intrinsic, -zbb, -rvv | Characters.reverseBytes | 2288.876 | 49.099 | ns/op
> ? | Shorts.reverseBytes | 2454.454 | 94.004 | ns/op
> No intrinsic | Characters.reverseBytes | 1629.722 | 23.656 | ns/op
> ? | Shorts.reverseBytes | 2108.81 | 43.378 | ns/op
> 
> </google-sheets-html-origin>

LGTM. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19830#pullrequestreview-2134513429

From duke at openjdk.org  Mon Jun 24 04:37:37 2024
From: duke at openjdk.org (Yude Lin)
Date: Mon, 24 Jun 2024 04:37:37 GMT
Subject: RFR: 8334810: Redo: Un-ProblemList LocaleProvidersRun and
 CalendarDataRegression
Message-ID: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>

[JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed LocaleProvidersRun and CalendarDataRegression, and [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. I'm guessing it's a mistake in resolving merge conflict.

-------------

Commit messages:
 - 8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression

Changes: https://git.openjdk.org/jdk/pull/19849/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334810
  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19849.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19849/head:pull/19849

PR: https://git.openjdk.org/jdk/pull/19849

From hgreule at openjdk.org  Mon Jun 24 06:12:09 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 24 Jun 2024 06:12:09 GMT
Subject: [jdk23] RFR: 8334708: FFM: two javadoc problems
In-Reply-To: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>
References: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>
Message-ID: <BhMV7uDlnXchNHvMpVslvjzmvjobehgE5fNHQ26UL6U=.eede83a3-61a1-4458-8608-235597e82693@github.com>

On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hannes Greule on 22 Jun 2024 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

Thank you for your review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19846#issuecomment-2185687899

From hgreule at openjdk.org  Mon Jun 24 06:33:13 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 24 Jun 2024 06:33:13 GMT
Subject: [jdk23] Integrated: 8334708: FFM: two javadoc problems
In-Reply-To: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>
References: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>
Message-ID: <ZKJy0nfO1qLZaDdbmrt7QuW-XlEuVh4eerVfWVZvWHg=.3a1a5e38-d5d7-49cf-b7ff-edd1598fb0e7@github.com>

On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hannes Greule on 22 Jun 2024 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3edf379b
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3edf379b671c1d8d5a29870ec33fddd7133cf00d
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8334708: FFM: two javadoc problems

Reviewed-by: jpai
Backport-of: 72ca7bafcd49a98c1fe09da72e4e47683f052e9d

-------------

PR: https://git.openjdk.org/jdk/pull/19846

From asotona at openjdk.org  Mon Jun 24 07:30:10 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Jun 2024 07:30:10 GMT
Subject: RFR: 8334734: Remove specialized readXxxEntry methods from
 ClassReader
In-Reply-To: <7G5zGUXmAmiZUZ1g8K4ksYA73NmGnF2EZIIAO4cmf1I=.529a63f1-1592-450e-a9fb-f3679e670741@github.com>
References: <7G5zGUXmAmiZUZ1g8K4ksYA73NmGnF2EZIIAO4cmf1I=.529a63f1-1592-450e-a9fb-f3679e670741@github.com>
Message-ID: <lJ6lYlEiqIYtgASLHrKTDjHwYHaBsDg8ktGYepS9V_s=.c69d09ae-d45f-4258-8150-450a29010f5b@github.com>

On Fri, 21 Jun 2024 15:52:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> `ClassReader.readXxxEntry` were added before we had generic, type-aware `readEntry` and `readEntryOrNull` APIs (#19330). We should remove these specialized versions in favor of the generic version to reduce API bloating.

Looks good to me, thanks.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19833#pullrequestreview-2134895664

From mcimadamore at openjdk.org  Mon Jun 24 09:29:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Jun 2024 09:29:13 GMT
Subject: [jdk23] RFR: 8334708: FFM: two javadoc problems
In-Reply-To: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>
References: <XhHDbdlgkFEQwt5XU2oAQkSUBVUJAwQXpAZ4iy9obcU=.aedabeba-2ca9-45a4-bb11-5dac9f9e3329@github.com>
Message-ID: <PA_nONzWJIe-ElvzU76Sz23f6Q0Skb8EGpZiLRJFV9w=.45b2d164-3981-4c07-8fbc-3412074da79d@github.com>

On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hannes Greule on 22 Jun 2024 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19846#issuecomment-2186031401

From prappo at openjdk.org  Mon Jun 24 09:44:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 24 Jun 2024 09:44:16 GMT
Subject: [jdk23] RFR: 8333358: java/io/IO/IO.java test fails intermittently
In-Reply-To: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>
References: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>
Message-ID: <QzTVP3nNxhFj9-yNNerTtUMYYffZaTDP2R-9mjzjdPE=.7760de0f-0b2b-4ef0-9796-6f2ec31ea042@github.com>

On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and was reviewed by Naoto Sato.
> 
> Thanks!

Marked as reviewed by prappo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19847#pullrequestreview-2135235884

From clanger at openjdk.org  Mon Jun 24 09:46:53 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 24 Jun 2024 09:46:53 GMT
Subject: [jdk23] RFR: 8222884: ConcurrentClassDescLookup.java times out
 intermittently
Message-ID: <CMRoOvwt8gFeAjj7Gl0qB8Q0B4P0Ekqm8e95dJp7tfM=.3cedaaa2-7217-42f2-81a3-5542fda4b7e2@github.com>

Hi all,

This pull request contains a backport of [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jaikiran Pai on 12 Jun 2024 and was reviewed by Roger Riggs and Matthias Baesken.

Thanks!

-------------

Commit messages:
 - Backport bd046d9b9e79e4eea89c72af358961ef6e98e660

Changes: https://git.openjdk.org/jdk/pull/19853/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19853&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8222884
  Stats: 36 lines in 1 file changed: 7 ins; 7 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19853/head:pull/19853

PR: https://git.openjdk.org/jdk/pull/19853

From syan at openjdk.org  Mon Jun 24 09:48:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Jun 2024 09:48:15 GMT
Subject: [jdk23] RFR: 8333358: java/io/IO/IO.java test fails intermittently
In-Reply-To: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>
References: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>
Message-ID: <9guoe_u5wfZeNPFk1Gh_grkHlFkzDo20zGxITAbb4j0=.d18a3f86-7ad3-4ddc-a294-a653579906b9@github.com>

On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and was reviewed by Naoto Sato.
> 
> Thanks!

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19847#issuecomment-2186073017

From syan at openjdk.org  Mon Jun 24 09:56:32 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Jun 2024 09:56:32 GMT
Subject: [jdk23] Integrated: 8333358: java/io/IO/IO.java test fails
 intermittently
In-Reply-To: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>
References: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>
Message-ID: <N1g0t4Ap6lVjA5acdNH5zm5czcASS4phEQehavLI4uU=.94b3913e-7688-4eed-9a19-d10df00a1a47@github.com>

On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and was reviewed by Naoto Sato.
> 
> Thanks!

This pull request has now been integrated.

Changeset: bd66b6b6
Author:    SendaoYan <syan at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd66b6b6f9bb0b415b686f06231ccd85dab459da
Stats:     69 lines in 3 files changed: 63 ins; 2 del; 4 mod

8333358: java/io/IO/IO.java test fails intermittently

Reviewed-by: prappo
Backport-of: 1b1dba8082969244effa86ac03c6053b3b0ddc43

-------------

PR: https://git.openjdk.org/jdk/pull/19847

From syan at openjdk.org  Mon Jun 24 09:59:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Jun 2024 09:59:23 GMT
Subject: [jdk23] RFR: 8333358: java/io/IO/IO.java test fails intermittently
In-Reply-To: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>
References: <QeGC7U_NbFJ0Cs1TYZexsU2iUHjzx6VYtQPBmC5CABs=.d68de838-0bbc-49de-806f-f7649de84f3a@github.com>
Message-ID: <Ak1IoNYdcCF2ULK_1QB_EQWy1MSvgwyJXsFNq7Xtogg=.6b092a78-fab5-4d6c-8820-e48f0b78ea60@github.com>

On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and was reviewed by Naoto Sato.
> 
> Thanks!

Thansk for the sponsor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19847#issuecomment-2186097277

From mdoerr at openjdk.org  Mon Jun 24 12:04:10 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 24 Jun 2024 12:04:10 GMT
Subject: [jdk23] RFR: 8222884: ConcurrentClassDescLookup.java times out
 intermittently
In-Reply-To: <CMRoOvwt8gFeAjj7Gl0qB8Q0B4P0Ekqm8e95dJp7tfM=.3cedaaa2-7217-42f2-81a3-5542fda4b7e2@github.com>
References: <CMRoOvwt8gFeAjj7Gl0qB8Q0B4P0Ekqm8e95dJp7tfM=.3cedaaa2-7217-42f2-81a3-5542fda4b7e2@github.com>
Message-ID: <X-0QqrGTd3Q-TJeapEZCHATADfWLo2QqAt4KbOWAjOU=.add9c298-0014-4ed0-8b74-320e8d721909@github.com>

On Mon, 24 Jun 2024 09:40:14 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jaikiran Pai on 12 Jun 2024 and was reviewed by Roger Riggs and Matthias Baesken.
> 
> Thanks!

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19853#pullrequestreview-2135601316

From asotona at openjdk.org  Mon Jun 24 12:53:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Jun 2024 12:53:09 GMT
Subject: [jdk23] RFR: 8333748: javap crash - Fatal error: Unmatched bit
 position 0x2 for location CLASS
In-Reply-To: <YmIBADgZyX5JQRkQ01cWvieUCPW-kCN2BUcPiyPcadg=.941a0ca9-021d-448c-aef2-fd458ef9e07f@github.com>
References: <YmIBADgZyX5JQRkQ01cWvieUCPW-kCN2BUcPiyPcadg=.941a0ca9-021d-448c-aef2-fd458ef9e07f@github.com>
Message-ID: <TQuP0DSagjqyUbyyaM8agfGinTZCIp71VjLzh2Q2Pxg=.f0764fa9-2671-4fbf-8db2-3126e658b7fe@github.com>

On Sat, 22 Jun 2024 00:26:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this clean backport of #19708, to make javap recover and continue after encountering undefined access flag bits set while still exiting with a code of error, allowing it to error against improper bits while still providing as much output as possible.

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19839#pullrequestreview-2135714317

From jvernee at openjdk.org  Mon Jun 24 12:57:39 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Jun 2024 12:57:39 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v9]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  de-dupe on path, not module name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/a046f6fe..40ca91ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=07-08

  Stats: 22 lines in 2 files changed: 19 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From alanb at openjdk.org  Mon Jun 24 12:58:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Jun 2024 12:58:14 GMT
Subject: RFR: 8334287: Man page update for jstatd deprecation
In-Reply-To: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
References: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
Message-ID: <-5O9RdLLw4o4hoKN30LrsA5zcmOaY0KloCLOvhVOcmk=.6c14a542-624b-4fee-971c-4408849c090e@github.com>

On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Man page update for JDK-8327793 which marked jstatd as deprecated for removal in JDK 24.

I assume we should hold off reviewing until the warning and the experiment note are combined.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19829#issuecomment-2186517543

From liach at openjdk.org  Mon Jun 24 13:00:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Jun 2024 13:00:17 GMT
Subject: [jdk23] Integrated: 8333748: javap crash - Fatal error: Unmatched bit
 position 0x2 for location CLASS
In-Reply-To: <YmIBADgZyX5JQRkQ01cWvieUCPW-kCN2BUcPiyPcadg=.941a0ca9-021d-448c-aef2-fd458ef9e07f@github.com>
References: <YmIBADgZyX5JQRkQ01cWvieUCPW-kCN2BUcPiyPcadg=.941a0ca9-021d-448c-aef2-fd458ef9e07f@github.com>
Message-ID: <q6o5_wGtiZssW3HLZZ1kb30af7koKL9K-uiKLRG769o=.8de63212-2b02-4a73-bfce-f8e94216609e@github.com>

On Sat, 22 Jun 2024 00:26:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this clean backport of #19708, to make javap recover and continue after encountering undefined access flag bits set while still exiting with a code of error, allowing it to error against improper bits while still providing as much output as possible.

This pull request has now been integrated.

Changeset: a124e6e5
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a124e6e5c7ae7493edd6fe95dde7b21d13af1c8b
Stats:     228 lines in 4 files changed: 168 ins; 44 del; 16 mod

8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS

Reviewed-by: asotona
Backport-of: 7e55ed3b106ed08956d2d38b7c99fb81704667c9

-------------

PR: https://git.openjdk.org/jdk/pull/19839

From jvernee at openjdk.org  Mon Jun 24 13:08:13 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 24 Jun 2024 13:08:13 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v9]
In-Reply-To: <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
Message-ID: <HD-I2PA8fsA98TDSSOiD0yo2LjyO5CAb6wrirIz2_78=.625e76af-8c2b-4f4a-9839-669ef75531e7@github.com>

On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   de-dupe on path, not module name

Fixed a small bug: https://github.com/openjdk/jdk/pull/19774/commits/40ca91ed47be7697cb720c1b1155d5192e262cc3

I think there's potentially more cleanup that can be done. `ClassResolver` is trying to do too many things atm, I think. It can both iterate over all classes, and do lookups of individual classes, but we only either use one or the other, either to find all classes to scan, or to lookup system classes (the system resolver doesn't even support iterating). I think `ClassResolver` would be better off if it just supported lookups, and then `NativeMethodFinder` operated on individual `ClassModules` instead of iterating over all classes. The iteration can be lifted into `JNativeScanTask::run`, and this spreads out the nesting a bit as well so code doesn't become too hard to follow. I sketched out that idea, and it looks better to me, but there's quite a lot of code motion, without any functional difference ([commit]), so I'll leave it for a followup (unless people want it in this PR).

[commit]: https://github.com/JornVernee/jdk/compare/jnativescan...JornVernee:jdk:jnativescan_Refactor

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2186538931

From sgehwolf at openjdk.org  Mon Jun 24 14:33:51 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 24 Jun 2024 14:33:51 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v33]
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: <7MIX-3emJ0epp2GHVCT3ulfXMB0yFMxSQ-u2-KFLN6Y=.f84b6d3e-2485-43e0-8de0-5b292242b5d7@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 137 commits:

 - JLinkDedupTestBatchSizeOne.java test fix
   
   Run only the packaged modules version if we have a linkable JDK runtime
   with packaged modules available as well in the JDK install.
 - Enable IncludeLocalesPluginTest
 - Enable GenerateJLIClassesPluginTest.java test
 - Enable JLinkReproducibleTest.java for linkable JDK images
 - Remove restriction on directory based modules
   
   Enable the following tests:
   - JLink100Modules.java
   - JLinkDedupTestBatchSizeOne.java
 - Comment fix in JRTArchive. Long line in JlinkTask
 - Comment fixes in ImageFileCreator
 - Comments and clean-up in JlinkTask
 - Helper support for linkable JDK runtimes
 - Test clean-up. class-file API module.
 - ... and 127 more: https://git.openjdk.org/jdk/compare/5cad0b4d...04cd98f8

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=32
  Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 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 asotona at openjdk.org  Mon Jun 24 16:06:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Jun 2024 16:06:18 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing since
 JDK-8294960
Message-ID: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>

After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.

This patch converts all lambdas in ClassSpecializer into anonymous inner classes.

Please review and test on a BigEndian platform.

Thanks,
Adam

-------------

Commit messages:
 - 8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960

Changes: https://git.openjdk.org/jdk/pull/19863/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19863&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334872
  Stats: 239 lines in 1 file changed: 65 ins; 45 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/19863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19863/head:pull/19863

PR: https://git.openjdk.org/jdk/pull/19863

From syan at openjdk.org  Mon Jun 24 16:21:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Jun 2024 16:21:22 GMT
Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp
 fails exitValue = 137
Message-ID: <zmH1rIdQ9exNWrseqcQTHuaIYKQ_1sw7y9jKag5_10I=.c3fbbbbf-179a-4e1a-929a-5cfeb15313a2@github.com>

Hi all,
  After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
  Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase.
  Only change the testcase, the change has been verified, no risk.

-------------

Commit messages:
 - 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137

Changes: https://git.openjdk.org/jdk/pull/19864/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19864&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334771
  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19864/head:pull/19864

PR: https://git.openjdk.org/jdk/pull/19864

From naoto at openjdk.org  Mon Jun 24 17:03:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Jun 2024 17:03:09 GMT
Subject: RFR: 8334810: Redo: Un-ProblemList LocaleProvidersRun and
 CalendarDataRegression
In-Reply-To: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
References: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
Message-ID: <Y19tXVQOqnTl2VqoYBzBO1h7qAz3EU8-ljUG9RGC0Wo=.532f5016-e021-433f-9d97-c423beb9a384@github.com>

On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin <duke at openjdk.org> wrote:

> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed LocaleProvidersRun and CalendarDataRegression, and [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. I'm guessing it's a mistake in resolving merge conflict.

Thanks for spotting that out. It does seem to be a merge error.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19849#pullrequestreview-2136332923

From djelinski at openjdk.org  Mon Jun 24 17:12:13 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Jun 2024 17:12:13 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v9]
In-Reply-To: <rG6GcXc9p37UcRq6Ewnkuy97Q8F1FddjrrPT-GdMh0g=.a4fdc45d-ff1d-41a4-adc1-253d82f2dfbf@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <rG6GcXc9p37UcRq6Ewnkuy97Q8F1FddjrrPT-GdMh0g=.a4fdc45d-ff1d-41a4-adc1-253d82f2dfbf@github.com>
Message-ID: <ZNRWBnP9Zbr43zZtJ4w8Zejiyk7tnaZZMLAahUAcnhQ=.9e8d1bf4-ca33-4628-a79a-6c1201bc99d6@github.com>

On Sun, 23 Jun 2024 19:03:38 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>> 
>> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code optimization

Thanks. That's a very nice performance improvement, on my Windows machine the `testHuge...` test is about 2-3x faster, and the other 2 are slightly faster too.

This needs a proper review for correctness, which might take a while.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2187034545

From jlu at openjdk.org  Mon Jun 24 17:24:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Jun 2024 17:24:10 GMT
Subject: RFR: 8334810: Redo: Un-ProblemList LocaleProvidersRun and
 CalendarDataRegression
In-Reply-To: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
References: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
Message-ID: <zZrYdpX34s4oOtY6dffWMX_aoI7xtnVZwyWNUFPkxjY=.d60eb97f-5e5b-4e8c-a39a-9af48bbb7ad3@github.com>

On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin <duke at openjdk.org> wrote:

> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed LocaleProvidersRun and CalendarDataRegression, and [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. I'm guessing it's a mistake in resolving merge conflict.

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19849#pullrequestreview-2136371650

From redestad at openjdk.org  Mon Jun 24 17:28:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 24 Jun 2024 17:28:12 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960
In-Reply-To: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
Message-ID: <FFvTYpcARjxojTHvMH0sGtFUR-QGlWLTbvKn_B5uimc=.8c4dbda9-3882-48bc-bec6-047de6ac8ac2@github.com>

On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
> 
> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
> 
> Please review and test on a BigEndian platform.
> 
> Thanks,
> Adam

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19863#pullrequestreview-2136378062

From duke at openjdk.org  Mon Jun 24 20:21:29 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 24 Jun 2024 20:21:29 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v10]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <rPkqHO7Zri96RHcIakEClzEb-2BK4KvmTrpKhDhQr-I=.accb1a38-1772-4d13-8930-16cf3893cb1c@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 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 39 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patchSqrt
 - Removed useless instruction
 - Code optimization
 - Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into patchSqrt
 - Merge branch 'openjdk:master' into patchSqrt
 - Added JMH benchmark class for Square Root
 - Normalize blocks
 - Removed unused import
 - Simplification of code
 - Special cases and base case optimization
 - ... and 29 more: https://git.openjdk.org/jdk/compare/651eb76a...d3270015

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/073c6046..d3270015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=08-09

  Stats: 729 lines in 41 files changed: 494 ins; 132 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From luhenry at openjdk.org  Mon Jun 24 21:04:13 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 24 Jun 2024 21:04:13 GMT
Subject: RFR: 8334397: RISC-V: verify perf of ReverseBytesS/US
In-Reply-To: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
References: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
Message-ID: <dP3zGe1YWY1rnkx4cwKh30cxX2R61-QblaRJYevdlGI=.06e88db3-9a4b-4ec0-90e1-6fb72843e8af@github.com>

On Fri, 21 Jun 2024 14:24:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> Thanks!
> 
> This is similar with previous JDK-8334396.
> Added some tests.
> 
> ###?Test
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> ? | Tests | Scores | Errors | Unit
> -- | -- | -- | -- | --
> Intrinsic, +zbb, +rvv | Characters.reverseBytes | 1654.535 | 69.36 | ns/op
> ? | Shorts.reverseBytes | 1795.403 | 44.015 | ns/op
> Intrinsic, +zbb, -rvv | Characters.reverseBytes | 1649.752 | 74.965 | ns/op
> ? | Shorts.reverseBytes | 1798.637 | 49.52 | ns/op
> Intrinsic, -zbb, +rvv | Characters.reverseBytes | 2279.588 | 44.222 | ns/op
> ? | Shorts.reverseBytes | 2441.674 | 63.895 | ns/op
> Intrinsic, -zbb, -rvv | Characters.reverseBytes | 2288.876 | 49.099 | ns/op
> ? | Shorts.reverseBytes | 2454.454 | 94.004 | ns/op
> No intrinsic | Characters.reverseBytes | 1629.722 | 23.656 | ns/op
> ? | Shorts.reverseBytes | 2108.81 | 43.378 | ns/op
> 
> </google-sheets-html-origin>

test/micro/org/openjdk/bench/java/lang/Characters.java line 69:

> 67: 
> 68:     @Benchmark
> 69:     public void reverseBytes() {

I'm not sure we want to be adding that benchmark to this class. Could you move to a different class that will test exclusively `reverseBytes` on `char[]`? You can then move the code from `test/micro/org/openjdk/bench/java/lang/Shorts.java` into that same class or a similarly named class for `short[]`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19830#discussion_r1651605527

From rrich at openjdk.org  Mon Jun 24 22:14:16 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 24 Jun 2024 22:14:16 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960
In-Reply-To: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
Message-ID: <XMSRiR7tChBjXb0EVjiuM1PQAbr3PdOUAmrEPPvmHMA=.34f23e72-2678-4ed7-a9e9-ba91066e380b@github.com>

On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
> 
> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
> 
> Please review and test on a BigEndian platform.
> 
> Thanks,
> Adam

Hi Adam,

I've tested this change on a Linux PPC64 big endian system. Sadly I still get StackOverflowErrors.
I've run only test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java. I've experimented with `ThreadStackSize` and `VMThreadStackSize` without success.

When running the test standalone I get the following message:


./jdk/bin/java
-cp testclasses:jtreg_latest/lib/testng-7.3.0.jar:jtreg_latest/lib/jcommander-1.82.jar
-XX:+UnlockDiagnosticVMOptions
-XX:UseBootstrapCallInfo=3
-Xint
org.testng.TestNG
-testclass
ConstantBootstrapsTest
Error occurred during initialization of boot layer
java.lang.StackOverflowError


It's likely not a byte ordering problem since @offamitkumar cannot reproduce the failures on s390x.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2187498690

From duke at openjdk.org  Mon Jun 24 22:52:43 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 24 Jun 2024 22:52:43 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v11]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <ZKPRtP2GBLSO1yqQmodXMX4hM7OCWjTI4BDmJDbxbRg=.210754d5-6736-4eda-8aa1-da2872b69f0a@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/d3270015..f895b63b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From liach at openjdk.org  Mon Jun 24 23:21:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Jun 2024 23:21:08 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960
In-Reply-To: <XMSRiR7tChBjXb0EVjiuM1PQAbr3PdOUAmrEPPvmHMA=.34f23e72-2678-4ed7-a9e9-ba91066e380b@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
 <XMSRiR7tChBjXb0EVjiuM1PQAbr3PdOUAmrEPPvmHMA=.34f23e72-2678-4ed7-a9e9-ba91066e380b@github.com>
Message-ID: <L3Nr65FA2mMs8KZpk0fjLOB6rA2K0iOTfJ-nLn6IkSA=.a86b6901-c4a8-49a6-a3ee-2df1c4983989@github.com>

On Mon, 24 Jun 2024 22:11:55 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
>> 
>> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
>> 
>> Please review and test on a BigEndian platform.
>> 
>> Thanks,
>> Adam
>
> Hi Adam,
> 
> I've tested this change on a Linux PPC64 big endian system. Sadly I still get StackOverflowErrors.
> I've run only test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java. I've experimented with `ThreadStackSize` and `VMThreadStackSize` without success.
> 
> When running the test standalone I get the following message:
> 
> 
> ./jdk/bin/java
> -cp testclasses:jtreg_latest/lib/testng-7.3.0.jar:jtreg_latest/lib/jcommander-1.82.jar
> -XX:+UnlockDiagnosticVMOptions
> -XX:UseBootstrapCallInfo=3
> -Xint
> org.testng.TestNG
> -testclass
> ConstantBootstrapsTest
> Error occurred during initialization of boot layer
> java.lang.StackOverflowError
> 
> 
> It's likely not a byte ordering problem since @offamitkumar cannot reproduce the failures on s390x.

@reinrich Could you try running with `-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames` and share the full stacktrace again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2187588334

From duke at openjdk.org  Tue Jun 25 02:01:11 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 25 Jun 2024 02:01:11 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v8]
In-Reply-To: <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>
 <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
Message-ID: <-w_24oYBK4mkgmt252jiOOUlNB_qyANavids5PHEYgI=.1ad8587a-5187-4b4e-9ef7-8b164b7a8806@github.com>

On Sun, 16 Jun 2024 21:25:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code format
>
> Just suggesting some improvements

All suggestions have been fixed, can this PR be integrated? @cl4es  @liach

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19730#issuecomment-2187784845

From duke at openjdk.org  Tue Jun 25 02:41:12 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 25 Jun 2024 02:41:12 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <julUD8fYOzQKcVXJIvBs0XdHwkigMmCB2gNg_sWonjE=.ad9fddd3-91c7-4fbe-a578-7886ad46edb4@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <julUD8fYOzQKcVXJIvBs0XdHwkigMmCB2gNg_sWonjE=.ad9fddd3-91c7-4fbe-a578-7886ad46edb4@github.com>
Message-ID: <egfZHDtR7yuU3YUiNP9hqbLgnr27_ft8FM1BduR3dYo=.460bb614-2b00-4991-b333-4671e37d9562@github.com>

On Thu, 20 Jun 2024 18:58:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> I did not mean to introduce a public API for this change (if we do, the fix cannot be backported). I thought we could define a package private one, but based on your observation, it may get messier... So I agree that falling back to `StringBuf` is the way to go, IMO.

So, considering all the information given, is it enough to start our new review process? @naotoj @liach @justin-curtis-lu

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2187842086

From liach at openjdk.org  Tue Jun 25 03:03:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Jun 2024 03:03:23 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v10]
In-Reply-To: <zipIuEv-5EWDGQOywhB1igaVbC5dkuN8NHru0oljHBE=.8584e76c-fac0-4708-b2eb-68ed33c3a840@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <zipIuEv-5EWDGQOywhB1igaVbC5dkuN8NHru0oljHBE=.8584e76c-fac0-4708-b2eb-68ed33c3a840@github.com>
Message-ID: <a-Qpv0GQ-N10G1ZoFlbnjWGz2hgwFpCuM4BW3NYrVDo=.bf6fec62-7d22-4bc6-823d-323994ce6b41@github.com>

On Fri, 21 Jun 2024 07:25:27 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

src/java.base/share/classes/java/text/Format.java line 456:

> 454:         }
> 455: 
> 456:         final class StringBufferImpl implements StringBuf {

Please don't nest this in an interface; anything nested in an interface is public, so is the generated nested class, which can be publicly accessed via reflection or MethodHandle.Lookup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1651915645

From liach at openjdk.org  Tue Jun 25 03:15:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Jun 2024 03:15:15 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v13]
In-Reply-To: <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>
Message-ID: <CaytkDf9wFeg6aaN8n-i9ILSutQN345j1eVEKFSZoUQ=.cfbd93a3-dc0d-4fac-b5ff-4994508c7fe2@github.com>

On Mon, 17 Jun 2024 04:58:41 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Utf16 case remove `append first utf16 char`

I would request a review from @rgiulietti, author of the original code.

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 154:

> 152:         int length = s.length();
> 153:         if (coder == LATIN1) {
> 154:             for (int i = 0; i < length; ++i) {

Can we use `s.getBytes(0, length, str, index)` and add `@SuppressWarnings("deprecation")` for performance?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19730#pullrequestreview-2137225522
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1651921455

From clanger at openjdk.org  Tue Jun 25 03:41:19 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 25 Jun 2024 03:41:19 GMT
Subject: [jdk23] Integrated: 8222884: ConcurrentClassDescLookup.java times out
 intermittently
In-Reply-To: <CMRoOvwt8gFeAjj7Gl0qB8Q0B4P0Ekqm8e95dJp7tfM=.3cedaaa2-7217-42f2-81a3-5542fda4b7e2@github.com>
References: <CMRoOvwt8gFeAjj7Gl0qB8Q0B4P0Ekqm8e95dJp7tfM=.3cedaaa2-7217-42f2-81a3-5542fda4b7e2@github.com>
Message-ID: <3L-V87KqZxFVLeqLlAb2IV6aY5KS_uwpRJbCYo-6NUw=.a7f6357d-3ec5-42a2-9806-09d8cd9341e4@github.com>

On Mon, 24 Jun 2024 09:40:14 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jaikiran Pai on 12 Jun 2024 and was reviewed by Roger Riggs and Matthias Baesken.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 08c7c383
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08c7c38342809c60f5fdea70717362a72b00f6e9
Stats:     36 lines in 1 file changed: 7 ins; 7 del; 22 mod

8222884: ConcurrentClassDescLookup.java times out intermittently

Reviewed-by: mdoerr
Backport-of: bd046d9b9e79e4eea89c72af358961ef6e98e660

-------------

PR: https://git.openjdk.org/jdk/pull/19853

From duke at openjdk.org  Tue Jun 25 03:57:16 2024
From: duke at openjdk.org (Yude Lin)
Date: Tue, 25 Jun 2024 03:57:16 GMT
Subject: RFR: 8334810: Redo: Un-ProblemList LocaleProvidersRun and
 CalendarDataRegression
In-Reply-To: <Y19tXVQOqnTl2VqoYBzBO1h7qAz3EU8-ljUG9RGC0Wo=.532f5016-e021-433f-9d97-c423beb9a384@github.com>
References: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
 <Y19tXVQOqnTl2VqoYBzBO1h7qAz3EU8-ljUG9RGC0Wo=.532f5016-e021-433f-9d97-c423beb9a384@github.com>
Message-ID: <KByPlqeNCWq_7ACyeIApYI-oPVwDhtbXC6NUmrc7PgY=.6cbad1e6-8f5e-441b-9811-b117841d4bb2@github.com>

On Mon, 24 Jun 2024 17:00:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed LocaleProvidersRun and CalendarDataRegression, and [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. I'm guessing it's a mistake in resolving merge conflict.
>
> Thanks for spotting that out. It does seem to be a merge error.

Thanks for the review. @naotoj Do you mind sponsoring the change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19849#issuecomment-2187920188

From duke at openjdk.org  Tue Jun 25 04:15:49 2024
From: duke at openjdk.org (lingjun-cg)
Date: Tue, 25 Jun 2024 04:15:49 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v11]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <sTlfi6hmDZ0ZfeJJoHIBg2ukU4IDVZxQIFNhiTAcpKc=.7238d172-8f86-4a1a-8dae-aad23cd1ba3b@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/67c724c7..b6646c5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=09-10

  Stats: 305 lines in 6 files changed: 158 ins; 122 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From dholmes at openjdk.org  Tue Jun 25 06:41:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Jun 2024 06:41:12 GMT
Subject: RFR: 8334287: Man page update for jstatd deprecation
In-Reply-To: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
References: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
Message-ID: <cSC_owccxU4aRf9J_W9uNnSjzzbquPBffuqg9sIkrYc=.8e31495a-731a-4e81-aaf3-e23bf91c58ff@github.com>

On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Man page update for JDK-8327793 which marked jstatd as deprecated for removal in JDK 24.

Sorry this got left "pending" yesterday

src/jdk.jstatd/share/man/jstatd.1 line 49:

> 47: future release.
> 48: .PP
> 49: \f[B]Note:\f[R] This command is experimental and unsupported.

Can we combine the new warning with the old note e.g.

> This command is deprecated and will be removed in a future release. It was designated as experimental and unsupported.

?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19829#pullrequestreview-2134703147
PR Review Comment: https://git.openjdk.org/jdk/pull/19829#discussion_r1650378180

From jpai at openjdk.org  Tue Jun 25 06:51:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 06:51:10 GMT
Subject: RFR: 8334810: Redo: Un-ProblemList LocaleProvidersRun and
 CalendarDataRegression
In-Reply-To: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
References: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
Message-ID: <azqb2Gq_oKxdBcKpZ_9fW60GRHC3L2RoGCn-1j8qwig=.3bc3d815-69d2-402d-8302-66009c5e0640@github.com>

On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin <duke at openjdk.org> wrote:

> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed LocaleProvidersRun and CalendarDataRegression, and [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. I'm guessing it's a mistake in resolving merge conflict.

Hello Yude, can you do `/issue add 8268379` so that even 8268379 gets resolved when this PR gets integrated? Otherwise, 8268379 will still remain open after removing the tests from the problem listing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19849#issuecomment-2188111502

From rrich at openjdk.org  Tue Jun 25 07:17:11 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 25 Jun 2024 07:17:11 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960
In-Reply-To: <XMSRiR7tChBjXb0EVjiuM1PQAbr3PdOUAmrEPPvmHMA=.34f23e72-2678-4ed7-a9e9-ba91066e380b@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
 <XMSRiR7tChBjXb0EVjiuM1PQAbr3PdOUAmrEPPvmHMA=.34f23e72-2678-4ed7-a9e9-ba91066e380b@github.com>
Message-ID: <wKUJU8-XSrDzzn1D1X0nfAZkiTMrzJ2Vr3Osb2TCP_w=.d40133d0-59bb-4db2-9527-8df8fa7d7192@github.com>

On Mon, 24 Jun 2024 22:11:55 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
>> 
>> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
>> 
>> Please review and test on a BigEndian platform.
>> 
>> Thanks,
>> Adam
>
> Hi Adam,
> 
> I've tested this change on a Linux PPC64 big endian system. Sadly I still get StackOverflowErrors.
> I've run only test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java. I've experimented with `ThreadStackSize` and `VMThreadStackSize` without success.
> 
> When running the test standalone I get the following message:
> 
> 
> ./jdk/bin/java
> -cp testclasses:jtreg_latest/lib/testng-7.3.0.jar:jtreg_latest/lib/jcommander-1.82.jar
> -XX:+UnlockDiagnosticVMOptions
> -XX:UseBootstrapCallInfo=3
> -Xint
> org.testng.TestNG
> -testclass
> ConstantBootstrapsTest
> Error occurred during initialization of boot layer
> java.lang.StackOverflowError
> 
> 
> It's likely not a byte ordering problem since @offamitkumar cannot reproduce the failures on s390x.

> @reinrich Could you try running with `-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames` and share the full stacktrace again?

I've done that now. Please find it in the description/attachment of the [JBS-item](https://bugs.openjdk.org/browse/JDK-8334872).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2188155291

From mli at openjdk.org  Tue Jun 25 08:15:14 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 25 Jun 2024 08:15:14 GMT
Subject: RFR: 8334397: RISC-V: verify perf of ReverseBytesS/US
In-Reply-To: <dP3zGe1YWY1rnkx4cwKh30cxX2R61-QblaRJYevdlGI=.06e88db3-9a4b-4ec0-90e1-6fb72843e8af@github.com>
References: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
 <dP3zGe1YWY1rnkx4cwKh30cxX2R61-QblaRJYevdlGI=.06e88db3-9a4b-4ec0-90e1-6fb72843e8af@github.com>
Message-ID: <cDHjcXAAbsJv3ELYQ-8-ptnihRN6Q498k2u4jKmTO6w=.7e08b1eb-f24e-4e12-835b-81c877752a7a@github.com>

On Mon, 24 Jun 2024 21:01:14 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This is similar with previous JDK-8334396.
>> Added some tests.
>> 
>> ###?Test
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> ? | Tests | Scores | Errors | Unit
>> -- | -- | -- | -- | --
>> Intrinsic, +zbb, +rvv | Characters.reverseBytes | 1654.535 | 69.36 | ns/op
>> ? | Shorts.reverseBytes | 1795.403 | 44.015 | ns/op
>> Intrinsic, +zbb, -rvv | Characters.reverseBytes | 1649.752 | 74.965 | ns/op
>> ? | Shorts.reverseBytes | 1798.637 | 49.52 | ns/op
>> Intrinsic, -zbb, +rvv | Characters.reverseBytes | 2279.588 | 44.222 | ns/op
>> ? | Shorts.reverseBytes | 2441.674 | 63.895 | ns/op
>> Intrinsic, -zbb, -rvv | Characters.reverseBytes | 2288.876 | 49.099 | ns/op
>> ? | Shorts.reverseBytes | 2454.454 | 94.004 | ns/op
>> No intrinsic | Characters.reverseBytes | 1629.722 | 23.656 | ns/op
>> ? | Shorts.reverseBytes | 2108.81 | 43.378 | ns/op
>> 
>> </google-sheets-html-origin>
>
> test/micro/org/openjdk/bench/java/lang/Characters.java line 69:
> 
>> 67: 
>> 68:     @Benchmark
>> 69:     public void reverseBytes() {
> 
> I'm not sure we want to be adding that benchmark to this class. Could you move to a different class that will test exclusively `reverseBytes` on `char[]`? You can then move the code from `test/micro/org/openjdk/bench/java/lang/Shorts.java` into that same class or a similarly named class for `short[]`.

Not sure if I understand you correctly.
The test is for reverseBytes of a char, not char[]. And it's quite similar as existing test in for integer at: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/Integers.java#L171

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19830#discussion_r1652215989

From kevinw at openjdk.org  Tue Jun 25 08:27:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Jun 2024 08:27:38 GMT
Subject: RFR: 8334287: Man page update for jstatd deprecation [v2]
In-Reply-To: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
References: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
Message-ID: <tPxzQN7Lr_W3ObfDXvhhchzSwysB9PM37hAZ0pDYkYQ=.1b62a89d-698d-45b6-9314-1e758b818dff@github.com>

> Man page update for JDK-8327793 which marked jstatd as deprecated for removal in JDK 24.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  text update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19829/files
  - new: https://git.openjdk.org/jdk/pull/19829/files/55f6dbea..6c41666a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19829&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19829&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19829/head:pull/19829

PR: https://git.openjdk.org/jdk/pull/19829

From alanb at openjdk.org  Tue Jun 25 08:27:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Jun 2024 08:27:38 GMT
Subject: RFR: 8334287: Man page update for jstatd deprecation [v2]
In-Reply-To: <tPxzQN7Lr_W3ObfDXvhhchzSwysB9PM37hAZ0pDYkYQ=.1b62a89d-698d-45b6-9314-1e758b818dff@github.com>
References: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
 <tPxzQN7Lr_W3ObfDXvhhchzSwysB9PM37hAZ0pDYkYQ=.1b62a89d-698d-45b6-9314-1e758b818dff@github.com>
Message-ID: <DG2qcRw7IAaWLmTD8iQ0oqiWQtnqSAd2WLqC-zN4jOI=.93e5c478-74f6-45a6-ab5f-ca65ba195f23@github.com>

On Tue, 25 Jun 2024 08:25:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Man page update for JDK-8327793 which marked jstatd as deprecated for removal in JDK 24.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   text update

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19829#pullrequestreview-2137853292

From kevinw at openjdk.org  Tue Jun 25 08:27:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Jun 2024 08:27:38 GMT
Subject: RFR: 8334287: Man page update for jstatd deprecation
In-Reply-To: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
References: <e4j4BNWVFJ3B3b5WQqQGYHLCObmgBnyHn88MgQQt-DY=.8ff763da-b241-481b-bcc3-f7b667935388@github.com>
Message-ID: <UnWsojQHKAPbQgTOO4TxBB5WBd-8CFwAtqrcbB5UPAo=.a230a25a-0543-4523-a5a0-c7e1b725c8e0@github.com>

On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Man page update for JDK-8327793 which marked jstatd as deprecated for removal in JDK 24.

Thanks Alan and David, moving to a single line:


JSTATD(1)                                                             JDK Commands                                                            JSTATD(1)

NAME
       jstatd - monitor the creation and termination of instrumented Java HotSpot VMs

SYNOPSIS
       WARNING: This command is experimental, unsupported, and deprecated.  It will be removed in a future release.

       jstatd [options]

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19829#issuecomment-2188272502

From nbenalla at openjdk.org  Tue Jun 25 08:29:42 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 25 Jun 2024 08:29:42 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v10]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <J1AlirvH4VWsU32jz7kTUnjVleI33dkiHsrLDPO1Vww=.57e84d9f-8dd4-4bdb-901e-d0c519169a29@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Move the tests to module/module_name directory for clearer naming
 - (C)
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
   
   # Conflicts:
   #	test/jdk/TEST.groups
 - Improve checker report messages
 - Merge branch 'master' into source-based-since-checker
 - - removed unused parameter `i`
   - make rest of methods private
   - ".toString" instead of "toString"
   
   Signed-off-by: Nizar Benalla <nizar.benalla at oracle.com>
 - Add a few more legacy methods, needed a few more after changes to the checker
 - checking for null values directly rather than catching NPE
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Now only skipping the common methods that every record class will have, and will never need a new `@since`
 - ... and 10 more: https://git.openjdk.org/jdk/compare/7baddc20...62aebb0b

-------------

Changes: https://git.openjdk.org/jdk/pull/18934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=09
  Stats: 959 lines in 3 files changed: 957 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From redestad at openjdk.org  Tue Jun 25 08:32:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 25 Jun 2024 08:32:10 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960
In-Reply-To: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
Message-ID: <woV3OsNdacrZ5WpvRlZjxa5Eh839AZRfMdGPXMqSoNI=.548f68cb-29fe-48c0-afec-a8d19c691f0a@github.com>

On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
> 
> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
> 
> Please review and test on a BigEndian platform.
> 
> Thanks,
> Adam

Looks like there is a bootstrap cycle initializing this lambda in ClassBuilder: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/classfile/ClassBuilder.java#L202

I'm not sure, but it looks like the PPC VM might be passing args to the bootstrap method differently, which triggers adapting code in BootstrapMethodInvoker::pushMePullYou - this might be enough to start this cycle.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2188298757

From asotona at openjdk.org  Tue Jun 25 08:39:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Jun 2024 08:39:09 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960
In-Reply-To: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
Message-ID: <CadR_uMCVIROA7gGdFLtsawFaX0fnZ6ZhuJsEuZGmCU=.f1b89648-5281-497d-9e59-e4dde85dd608@github.com>

On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
> 
> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
> 
> Please review and test on a BigEndian platform.
> 
> Thanks,
> Adam

Yes, I'm working on it. Class-File API avoids lambdas on critical JDK paths only. Unfortunately we did not have the full map of the critical paths on all platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2188311520

From duke at openjdk.org  Tue Jun 25 09:16:29 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 25 Jun 2024 09:16:29 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v12]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <aCNMA4dSwnHRPnAryZ1m1hq0xhVOlMTAQw-ujNCzejs=.3d4de46c-3102-4065-9182-e25d13c8b03b@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimized multiplication

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/f895b63b..923b3475

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=10-11

  Stats: 28 lines in 1 file changed: 10 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From asotona at openjdk.org  Tue Jun 25 09:36:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Jun 2024 09:36:37 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960 [v2]
In-Reply-To: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
Message-ID: <OFL3Nm8t-Yllo4xWoB59xO5ra6KQ5L5EAFeBaGWJz3s=.af6bfd05-addf-434c-9c50-25fd3b7bfc8c@github.com>

> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
> 
> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
> 
> Please review and test on a BigEndian platform.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  more lambdas conversions to fix bootstrap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19863/files
  - new: https://git.openjdk.org/jdk/pull/19863/files/ac8fb2d5..357d36a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19863&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19863&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19863/head:pull/19863

PR: https://git.openjdk.org/jdk/pull/19863

From asotona at openjdk.org  Tue Jun 25 09:36:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Jun 2024 09:36:37 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960
In-Reply-To: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
Message-ID: <wvoVpCEUtm0PusX-zs6UPF_7co8THLDIbaXb0EsBYJE=.f81675ac-5fbf-461f-b70f-c15f94756c2c@github.com>

On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
> 
> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
> 
> Please review and test on a BigEndian platform.
> 
> Thanks,
> Adam

More lambdas converted, hopefully it is the last round.
@reinrich Please re-test.

Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2188431487

From luhenry at openjdk.org  Tue Jun 25 12:54:13 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 25 Jun 2024 12:54:13 GMT
Subject: RFR: 8334397: RISC-V: verify perf of ReverseBytesS/US
In-Reply-To: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
References: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
Message-ID: <QJgr5YqCuDuRkNJoJ7rrkYlIsrk1ylpMF1q7ZtGDvW8=.c723155b-328f-4b6d-98c5-1b11122a9dfb@github.com>

On Fri, 21 Jun 2024 14:24:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> Thanks!
> 
> This is similar with previous JDK-8334396.
> Added some tests.
> 
> ###?Test
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> ? | Tests | Scores | Errors | Unit
> -- | -- | -- | -- | --
> Intrinsic, +zbb, +rvv | Characters.reverseBytes | 1654.535 | 69.36 | ns/op
> ? | Shorts.reverseBytes | 1795.403 | 44.015 | ns/op
> Intrinsic, +zbb, -rvv | Characters.reverseBytes | 1649.752 | 74.965 | ns/op
> ? | Shorts.reverseBytes | 1798.637 | 49.52 | ns/op
> Intrinsic, -zbb, +rvv | Characters.reverseBytes | 2279.588 | 44.222 | ns/op
> ? | Shorts.reverseBytes | 2441.674 | 63.895 | ns/op
> Intrinsic, -zbb, -rvv | Characters.reverseBytes | 2288.876 | 49.099 | ns/op
> ? | Shorts.reverseBytes | 2454.454 | 94.004 | ns/op
> No intrinsic | Characters.reverseBytes | 1629.722 | 23.656 | ns/op
> ? | Shorts.reverseBytes | 2108.81 | 43.378 | ns/op
> 
> </google-sheets-html-origin>

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19830#pullrequestreview-2138583857

From luhenry at openjdk.org  Tue Jun 25 12:54:15 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 25 Jun 2024 12:54:15 GMT
Subject: RFR: 8334397: RISC-V: verify perf of ReverseBytesS/US
In-Reply-To: <cDHjcXAAbsJv3ELYQ-8-ptnihRN6Q498k2u4jKmTO6w=.7e08b1eb-f24e-4e12-835b-81c877752a7a@github.com>
References: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
 <dP3zGe1YWY1rnkx4cwKh30cxX2R61-QblaRJYevdlGI=.06e88db3-9a4b-4ec0-90e1-6fb72843e8af@github.com>
 <cDHjcXAAbsJv3ELYQ-8-ptnihRN6Q498k2u4jKmTO6w=.7e08b1eb-f24e-4e12-835b-81c877752a7a@github.com>
Message-ID: <ewTVwYv04zvqE7_Ei0aH-PkPpBJ3-4VE-Zud9CSMMlg=.a3aaceee-b14b-49ce-8899-c3131d63586d@github.com>

On Tue, 25 Jun 2024 08:12:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/Characters.java line 69:
>> 
>>> 67: 
>>> 68:     @Benchmark
>>> 69:     public void reverseBytes() {
>> 
>> I'm not sure we want to be adding that benchmark to this class. Could you move to a different class that will test exclusively `reverseBytes` on `char[]`? You can then move the code from `test/micro/org/openjdk/bench/java/lang/Shorts.java` into that same class or a similarly named class for `short[]`.
>
> Not sure if I understand you correctly.
> The test is for reverseBytes of a char, not char[]. And it's quite similar as existing test in for integer at: https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/Integers.java#L171

I meant put this `reverseBytes` benchmark in a different class, but given it's how it's done in https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/lang/Integers.java#L171, please ignore this comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19830#discussion_r1652763769

From rrich at openjdk.org  Tue Jun 25 12:56:13 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 25 Jun 2024 12:56:13 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960 [v2]
In-Reply-To: <OFL3Nm8t-Yllo4xWoB59xO5ra6KQ5L5EAFeBaGWJz3s=.af6bfd05-addf-434c-9c50-25fd3b7bfc8c@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
 <OFL3Nm8t-Yllo4xWoB59xO5ra6KQ5L5EAFeBaGWJz3s=.af6bfd05-addf-434c-9c50-25fd3b7bfc8c@github.com>
Message-ID: <6lDuk1lAlZzQdKzCWt6Y6CE39TBU4t2EcQawCtHyk40=.62b4d930-a2ca-4c5d-8b0c-44f1e0e0c345@github.com>

On Tue, 25 Jun 2024 09:36:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
>> 
>> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
>> 
>> Please review and test on a BigEndian platform.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more lambdas conversions to fix bootstrap

Unfortunately it is still failing. This is the exception stack trace:
[StackOverflow2.log](https://github.com/user-attachments/files/15971514/StackOverflow2.log)

Thanks, Richard.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2188858307

From asotona at openjdk.org  Tue Jun 25 13:04:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Jun 2024 13:04:20 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16]
In-Reply-To: <bDDWvgroHrJd2QuR7xgWfYnIGzp6-guhSseqQdUTEZ4=.41c2a09e-0b47-4db7-bc5a-4850e8fb64e3@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <bDDWvgroHrJd2QuR7xgWfYnIGzp6-guhSseqQdUTEZ4=.41c2a09e-0b47-4db7-bc5a-4850e8fb64e3@github.com>
Message-ID: <C_tJBHfV_XGc_nG0O0940oatXVy4k45X3uD4J6Nf6og=.941517ef-58bf-404d-ae02-1be46acb7538@github.com>

On Sat, 22 Jun 2024 15:55:28 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> ### Purpose of Indify
>> 
>> -  **Transformation Tool**: `Indify` transforms existing class files to leverage `invokedynamic` and other JSR 292 features. This transformation allows for dynamic method calls.
>> 
>> ### Key Functions
>> 
>> - **Method Handle and Method Type Constants**:
>>     - **MH_x and MT_x Methods**: These methods are used to generate `MethodHandle` and `MethodType` constants. The tool transforms calls to these methods into `CONSTANT_MethodHandle` and `CONSTANT_MethodType` "ldc" (load constant) instructions.
>> -  **Invokedynamic Call Sites**:
>>     - **INDY_x Methods**: These methods generate `invokedynamic` call sites. Each `INDY_x` method starts with a call to an `MH_x` method, which acts as the bootstrap method. This is followed by an `invokeExact` call.
>>     - **Transformation**: The tool transforms pairs of calls (to `INDY_x` followed by `invokeExact`) into `invokedynamic` instructions. This mimics the JVM's handling of `invokedynamic` instructions, creating dynamic call sites that are linked at runtime.
>> 
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove: removed unnecessary logging

Unfortunately this pull request is not converging to an acceptable state.

Core transformation should be designed  from top to down, with understanding of the functionality and with respect to Class-File API architecture. Currently proposed implementation is confusing mix of the original code, glued together with fragments of Class-File API.

The patch also contains many cosmetic changes and unrelated semantic changes making the patch very hard to read.

The PR could not be finished just by requesting reviewers attention and partly reflecting their suggestions, it should be significantly re-designed.

-------------

Changes requested by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2138609501

From asotona at openjdk.org  Tue Jun 25 13:20:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Jun 2024 13:20:18 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16]
In-Reply-To: <bDDWvgroHrJd2QuR7xgWfYnIGzp6-guhSseqQdUTEZ4=.41c2a09e-0b47-4db7-bc5a-4850e8fb64e3@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <bDDWvgroHrJd2QuR7xgWfYnIGzp6-guhSseqQdUTEZ4=.41c2a09e-0b47-4db7-bc5a-4850e8fb64e3@github.com>
Message-ID: <HO3Ju2zVj3nBDujmc8k94cwSuChxOnIJ5CZhjLUHHH0=.ffd562fe-bd8c-4712-94cb-b616512543e0@github.com>

On Sat, 22 Jun 2024 15:55:28 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> ### Purpose of Indify
>> 
>> -  **Transformation Tool**: `Indify` transforms existing class files to leverage `invokedynamic` and other JSR 292 features. This transformation allows for dynamic method calls.
>> 
>> ### Key Functions
>> 
>> - **Method Handle and Method Type Constants**:
>>     - **MH_x and MT_x Methods**: These methods are used to generate `MethodHandle` and `MethodType` constants. The tool transforms calls to these methods into `CONSTANT_MethodHandle` and `CONSTANT_MethodType` "ldc" (load constant) instructions.
>> -  **Invokedynamic Call Sites**:
>>     - **INDY_x Methods**: These methods generate `invokedynamic` call sites. Each `INDY_x` method starts with a call to an `MH_x` method, which acts as the bootstrap method. This is followed by an `invokeExact` call.
>>     - **Transformation**: The tool transforms pairs of calls (to `INDY_x` followed by `invokeExact`) into `invokedynamic` instructions. This mimics the JVM's handling of `invokedynamic` instructions, creating dynamic call sites that are linked at runtime.
>> 
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove: removed unnecessary logging

test/jdk/java/lang/invoke/indify/Indify.java line 386:

> 384: 
> 385:     byte[] transformToBytes(ClassModel classModel) {
> 386:         return of().transform(classModel, ClassTransform.ACCEPT_ALL);

What is the purpose of this transformation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1652808158

From jkratochvil at openjdk.org  Tue Jun 25 13:42:14 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 25 Jun 2024 13:42:14 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v6]
In-Reply-To: <ZBtopTZicUFg1h2ck9567ccbp4ReUXcMUWWuMypiyw4=.04c04d2d-5ba5-47f1-8d8f-126c060cf2cb@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <ZBtopTZicUFg1h2ck9567ccbp4ReUXcMUWWuMypiyw4=.04c04d2d-5ba5-47f1-8d8f-126c060cf2cb@github.com>
Message-ID: <J74FB-XA2rmYsqWG7dtd3ZZAfM40mlZF4Tb1dWMoxOc=.1734af9b-1064-4414-a330-b85df00b9770@github.com>

On Thu, 20 Jun 2024 12:06:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove problem listing of PlainRead which is reworked here

Currently this patch conflicts a lot with #19085 (jerboaa:jdk-8331560-cgroup-controller-delegation).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2188994651

From sgehwolf at openjdk.org  Tue Jun 25 13:45:18 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Jun 2024 13:45:18 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v6]
In-Reply-To: <J74FB-XA2rmYsqWG7dtd3ZZAfM40mlZF4Tb1dWMoxOc=.1734af9b-1064-4414-a330-b85df00b9770@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <ZBtopTZicUFg1h2ck9567ccbp4ReUXcMUWWuMypiyw4=.04c04d2d-5ba5-47f1-8d8f-126c060cf2cb@github.com>
 <J74FB-XA2rmYsqWG7dtd3ZZAfM40mlZF4Tb1dWMoxOc=.1734af9b-1064-4414-a330-b85df00b9770@github.com>
Message-ID: <m6pDesd0wlqVH8mTMWfHYRtyqoVq8euJFjR-dvaaH-c=.0f15ec5a-8ec8-45ab-8efe-7b932393e67b@github.com>

On Tue, 25 Jun 2024 13:39:07 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Currently this patch conflicts a lot with #19085 (jerboaa:jdk-8331560-cgroup-controller-delegation).

Yes, I'll resolve it one way or another depending on which one goes in first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2189001364

From asotona at openjdk.org  Tue Jun 25 13:47:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Jun 2024 13:47:39 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960 [v3]
In-Reply-To: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
Message-ID: <3ddEdbTdCaDgKKBxuV8tSCL2CSdHfMwMLdVVtUV-6FE=.7dd77242-ae63-4910-b0ab-bbb6a79ac44d@github.com>

> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
> 
> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
> 
> Please review and test on a BigEndian platform.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  more de-lambda work on ClassSpecializer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19863/files
  - new: https://git.openjdk.org/jdk/pull/19863/files/357d36a0..1416d4d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19863&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19863&range=01-02

  Stats: 53 lines in 1 file changed: 4 ins; 0 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/19863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19863/head:pull/19863

PR: https://git.openjdk.org/jdk/pull/19863

From asotona at openjdk.org  Tue Jun 25 13:47:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Jun 2024 13:47:39 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960 [v2]
In-Reply-To: <OFL3Nm8t-Yllo4xWoB59xO5ra6KQ5L5EAFeBaGWJz3s=.af6bfd05-addf-434c-9c50-25fd3b7bfc8c@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
 <OFL3Nm8t-Yllo4xWoB59xO5ra6KQ5L5EAFeBaGWJz3s=.af6bfd05-addf-434c-9c50-25fd3b7bfc8c@github.com>
Message-ID: <1tgr5hYV2IWdv80QVeHw3y8H2468dgWHRWmY8_NuRAs=.74ece32e-e867-4465-aa77-bcbb8c571b1d@github.com>

On Tue, 25 Jun 2024 09:36:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
>> 
>> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
>> 
>> Please review and test on a BigEndian platform.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more lambdas conversions to fix bootstrap

Thanks for the report and patience.
Yes, CodeBuilder::withMethodBody is also internally using lambda.
Another version of the patch is ready for test.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2189005614

From duke at openjdk.org  Tue Jun 25 13:48:22 2024
From: duke at openjdk.org (Oussama Louati)
Date: Tue, 25 Jun 2024 13:48:22 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16]
In-Reply-To: <HO3Ju2zVj3nBDujmc8k94cwSuChxOnIJ5CZhjLUHHH0=.ffd562fe-bd8c-4712-94cb-b616512543e0@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <bDDWvgroHrJd2QuR7xgWfYnIGzp6-guhSseqQdUTEZ4=.41c2a09e-0b47-4db7-bc5a-4850e8fb64e3@github.com>
 <HO3Ju2zVj3nBDujmc8k94cwSuChxOnIJ5CZhjLUHHH0=.ffd562fe-bd8c-4712-94cb-b616512543e0@github.com>
Message-ID: <_wFrh1u4zLnKZG8lvbcANwo1KaLWCx_Ssem51ohzPwI=.c3e4d975-97c8-4e32-9865-d26328f11221@github.com>

On Tue, 25 Jun 2024 13:17:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove: removed unnecessary logging
>
> test/jdk/java/lang/invoke/indify/Indify.java line 386:
> 
>> 384: 
>> 385:     byte[] transformToBytes(ClassModel classModel) {
>> 386:         return of().transform(classModel, ClassTransform.ACCEPT_ALL);
> 
> What is the purpose of this transformation?

Transforming the classModel back to the bytes array in order to write the transformed classfile

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1652854265

From asotona at openjdk.org  Tue Jun 25 13:52:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Jun 2024 13:52:23 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16]
In-Reply-To: <_wFrh1u4zLnKZG8lvbcANwo1KaLWCx_Ssem51ohzPwI=.c3e4d975-97c8-4e32-9865-d26328f11221@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <bDDWvgroHrJd2QuR7xgWfYnIGzp6-guhSseqQdUTEZ4=.41c2a09e-0b47-4db7-bc5a-4850e8fb64e3@github.com>
 <HO3Ju2zVj3nBDujmc8k94cwSuChxOnIJ5CZhjLUHHH0=.ffd562fe-bd8c-4712-94cb-b616512543e0@github.com>
 <_wFrh1u4zLnKZG8lvbcANwo1KaLWCx_Ssem51ohzPwI=.c3e4d975-97c8-4e32-9865-d26328f11221@github.com>
Message-ID: <hgoEMKPJJ7zDJDrSPjBzcyI8TnouI0rbqglxHw4K4ek=.052eee26-3f90-4ab2-b245-c96e28aab2f0@github.com>

On Tue, 25 Jun 2024 13:45:17 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/indify/Indify.java line 386:
>> 
>>> 384: 
>>> 385:     byte[] transformToBytes(ClassModel classModel) {
>>> 386:         return of().transform(classModel, ClassTransform.ACCEPT_ALL);
>> 
>> What is the purpose of this transformation?
>
> Transforming the classModel back to the bytes array in order to write the transformed classfile

And what is the purpose of parsing a model from bytes and transforming it back to bytes without a change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1652861409

From sgehwolf at openjdk.org  Tue Jun 25 13:54:46 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Jun 2024 13:54:46 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v7]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Refactor mount info matching to helper function
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Remove problem listing of PlainRead which is reworked here
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Add doc for mountinfo scanning.
 - Unify naming of variables
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - jcheck fixes
 - ... and 7 more: https://git.openjdk.org/jdk/compare/baafa662...532ea33b

-------------

Changes: https://git.openjdk.org/jdk/pull/18201/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=06
  Stats: 411 lines in 20 files changed: 305 ins; 79 del; 27 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 sgehwolf at openjdk.org  Tue Jun 25 13:54:47 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Jun 2024 13:54:47 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v6]
In-Reply-To: <3garHvE8lhPovujClt422-1pcIcs7z7zpqpngEHDd6w=.8776bce8-2b79-44bd-8355-d753562a75cf@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <ZBtopTZicUFg1h2ck9567ccbp4ReUXcMUWWuMypiyw4=.04c04d2d-5ba5-47f1-8d8f-126c060cf2cb@github.com>
 <3garHvE8lhPovujClt422-1pcIcs7z7zpqpngEHDd6w=.8776bce8-2b79-44bd-8355-d753562a75cf@github.com>
Message-ID: <Oryc-Hc4DBMtl2mBTh95VaFCA5ILLoh-v59QBbaz0DY=.7a42ee14-b640-4410-a9b9-3a6101219ca1@github.com>

On Thu, 20 Jun 2024 17:37:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove problem listing of PlainRead which is reworked here
>
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 422:
> 
>> 420:      * (12)   super options:   matched with '%s' and captured in 'tmpcgroups'
>> 421:      */
>> 422:     if (sscanf(p, "%*d %*d %*d:%*d %s %s %s%*[^-]- %s %*s %s", tmproot, tmpmount, mount_opts, tmp_fs_type, tmpcgroups) == 5) {
> 
> The only difference to v1 is that we parse the super options (12), right? Could we factor out the parsing into a helper function? Or, alternatively, at least `#define` the scanf format somewhere up top, including the nice comment, and reuse that format string?

That's correct. I've moved it into a local helper function. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1652863523

From duke at openjdk.org  Tue Jun 25 13:57:19 2024
From: duke at openjdk.org (Oussama Louati)
Date: Tue, 25 Jun 2024 13:57:19 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16]
In-Reply-To: <hgoEMKPJJ7zDJDrSPjBzcyI8TnouI0rbqglxHw4K4ek=.052eee26-3f90-4ab2-b245-c96e28aab2f0@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <bDDWvgroHrJd2QuR7xgWfYnIGzp6-guhSseqQdUTEZ4=.41c2a09e-0b47-4db7-bc5a-4850e8fb64e3@github.com>
 <HO3Ju2zVj3nBDujmc8k94cwSuChxOnIJ5CZhjLUHHH0=.ffd562fe-bd8c-4712-94cb-b616512543e0@github.com>
 <_wFrh1u4zLnKZG8lvbcANwo1KaLWCx_Ssem51ohzPwI=.c3e4d975-97c8-4e32-9865-d26328f11221@github.com>
 <hgoEMKPJJ7zDJDrSPjBzcyI8TnouI0rbqglxHw4K4ek=.052eee26-3f90-4ab2-b245-c96e28aab2f0@github.com>
Message-ID: <XCoudTTF3a5j8Yj5KTzn3BPMAQtYXTNxsSmU1AR3aco=.29edc558-c01e-4f23-8c49-f36f78f430bb@github.com>

On Tue, 25 Jun 2024 13:49:31 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Transforming the classModel back to the bytes array in order to write the transformed classfile
>
> And what is the purpose of parsing a model from bytes and transforming it back to bytes without a change?

This transformation is called only after the `classModel` is transformed: 
- at line 472  and 380 when the `transformToBytes()` method is called is after effectively transforming the `classModel` inside the `Logic` class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1652868906

From mli at openjdk.org  Tue Jun 25 14:09:22 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 25 Jun 2024 14:09:22 GMT
Subject: RFR: 8334397: RISC-V: verify perf of ReverseBytesS/US
In-Reply-To: <QJgr5YqCuDuRkNJoJ7rrkYlIsrk1ylpMF1q7ZtGDvW8=.c723155b-328f-4b6d-98c5-1b11122a9dfb@github.com>
References: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
 <QJgr5YqCuDuRkNJoJ7rrkYlIsrk1ylpMF1q7ZtGDvW8=.c723155b-328f-4b6d-98c5-1b11122a9dfb@github.com>
Message-ID: <XPhjMV0jrMSQEil4szGjQUNpR-X2kOUiju55JoVSsLE=.ab738c22-794a-4f1c-b72b-112a90c8fadf@github.com>

On Tue, 25 Jun 2024 12:51:46 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This is similar with previous JDK-8334396.
>> Added some tests.
>> 
>> ###?Test
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> ? | Tests | Scores | Errors | Unit
>> -- | -- | -- | -- | --
>> Intrinsic, +zbb, +rvv | Characters.reverseBytes | 1654.535 | 69.36 | ns/op
>> ? | Shorts.reverseBytes | 1795.403 | 44.015 | ns/op
>> Intrinsic, +zbb, -rvv | Characters.reverseBytes | 1649.752 | 74.965 | ns/op
>> ? | Shorts.reverseBytes | 1798.637 | 49.52 | ns/op
>> Intrinsic, -zbb, +rvv | Characters.reverseBytes | 2279.588 | 44.222 | ns/op
>> ? | Shorts.reverseBytes | 2441.674 | 63.895 | ns/op
>> Intrinsic, -zbb, -rvv | Characters.reverseBytes | 2288.876 | 49.099 | ns/op
>> ? | Shorts.reverseBytes | 2454.454 | 94.004 | ns/op
>> No intrinsic | Characters.reverseBytes | 1629.722 | 23.656 | ns/op
>> ? | Shorts.reverseBytes | 2108.81 | 43.378 | ns/op
>> 
>> </google-sheets-html-origin>
>
> Marked as reviewed by luhenry (Committer).

Thanks @luhenry @RealFYang for your reviewing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19830#issuecomment-2189053398

From mli at openjdk.org  Tue Jun 25 14:09:25 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 25 Jun 2024 14:09:25 GMT
Subject: Integrated: 8334397: RISC-V: verify perf of ReverseBytesS/US
In-Reply-To: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
References: <cmVP5G6Nm_WKTXdioBGr60Gc5CbWRszZQbn7cHG5GXA=.0a4b6956-5f5a-40d9-bfc2-b9fa212c2e3e@github.com>
Message-ID: <2R_LdNR0Hh1P1zp75Jk80i9eNs5w71qVPZ4Bffoh3Ic=.2b25b2e3-944a-4a7e-b4fb-364244a0c46a@github.com>

On Fri, 21 Jun 2024 14:24:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> Thanks!
> 
> This is similar with previous JDK-8334396.
> Added some tests.
> 
> ###?Test
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> ? | Tests | Scores | Errors | Unit
> -- | -- | -- | -- | --
> Intrinsic, +zbb, +rvv | Characters.reverseBytes | 1654.535 | 69.36 | ns/op
> ? | Shorts.reverseBytes | 1795.403 | 44.015 | ns/op
> Intrinsic, +zbb, -rvv | Characters.reverseBytes | 1649.752 | 74.965 | ns/op
> ? | Shorts.reverseBytes | 1798.637 | 49.52 | ns/op
> Intrinsic, -zbb, +rvv | Characters.reverseBytes | 2279.588 | 44.222 | ns/op
> ? | Shorts.reverseBytes | 2441.674 | 63.895 | ns/op
> Intrinsic, -zbb, -rvv | Characters.reverseBytes | 2288.876 | 49.099 | ns/op
> ? | Shorts.reverseBytes | 2454.454 | 94.004 | ns/op
> No intrinsic | Characters.reverseBytes | 1629.722 | 23.656 | ns/op
> ? | Shorts.reverseBytes | 2108.81 | 43.378 | ns/op
> 
> </google-sheets-html-origin>

This pull request has now been integrated.

Changeset: cae94b26
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cae94b268d633b0557a54e3b21eff60d7f0edc2d
Stats:     129 lines in 4 files changed: 98 ins; 31 del; 0 mod

8334397: RISC-V: verify perf of ReverseBytesS/US

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/19830

From sgehwolf at openjdk.org  Tue Jun 25 14:13:27 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Jun 2024 14:13:27 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v33]
In-Reply-To: <7MIX-3emJ0epp2GHVCT3ulfXMB0yFMxSQ-u2-KFLN6Y=.f84b6d3e-2485-43e0-8de0-5b292242b5d7@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <7MIX-3emJ0epp2GHVCT3ulfXMB0yFMxSQ-u2-KFLN6Y=.f84b6d3e-2485-43e0-8de0-5b292242b5d7@github.com>
Message-ID: <AAH9yOrR514HflYqjfxJMqDxCobmL57ngROgrWnoy5M=.417d7c8c-4011-40e6-8b57-b1e6e3e04320@github.com>

On Mon, 24 Jun 2024 14:33:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 137 commits:
> 
>  - JLinkDedupTestBatchSizeOne.java test fix
>    
>    Run only the packaged modules version if we have a linkable JDK runtime
>    with packaged modules available as well in the JDK install.
>  - Enable IncludeLocalesPluginTest
>  - Enable GenerateJLIClassesPluginTest.java test
>  - Enable JLinkReproducibleTest.java for linkable JDK images
>  - Remove restriction on directory based modules
>    
>    Enable the following tests:
>    - JLink100Modules.java
>    - JLinkDedupTestBatchSizeOne.java
>  - Comment fix in JRTArchive. Long line in JlinkTask
>  - Comment fixes in ImageFileCreator
>  - Comments and clean-up in JlinkTask
>  - Helper support for linkable JDK runtimes
>  - Test clean-up. class-file API module.
>  - ... and 127 more: https://git.openjdk.org/jdk/compare/5cad0b4d...04cd98f8

I've pushed some clean-up fixes to this PR so as to fix the overly long lines and added comments to relevant methods. The latest GHA failure on MacOSX x86_64 is infra related.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2189072464

From mdoerr at openjdk.org  Tue Jun 25 14:27:11 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 25 Jun 2024 14:27:11 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960 [v3]
In-Reply-To: <3ddEdbTdCaDgKKBxuV8tSCL2CSdHfMwMLdVVtUV-6FE=.7dd77242-ae63-4910-b0ab-bbb6a79ac44d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
 <3ddEdbTdCaDgKKBxuV8tSCL2CSdHfMwMLdVVtUV-6FE=.7dd77242-ae63-4910-b0ab-bbb6a79ac44d@github.com>
Message-ID: <qXd8Ux0EmWokWp21t3UqeubveEY-3HIhiTP5C-EGbq4=.6cf4b592-0305-4c31-b988-14e586814611@github.com>

On Tue, 25 Jun 2024 13:47:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
>> 
>> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
>> 
>> Please review and test on a BigEndian platform.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more de-lambda work on ClassSpecializer

Thanks! This looks better. `jtreg:test/jdk/java/lang/invoke/condy` have passed on linux ppc64 Big Endian. I'll put it in our nightly tests to run it on AIX, too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2189112288

From rgiulietti at openjdk.org  Tue Jun 25 15:02:20 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 25 Jun 2024 15:02:20 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v13]
In-Reply-To: <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>
Message-ID: <aKM-WbdLbyfJned-2LkQ6V-G7IfPvqapn2G77re39R8=.4f831602-d8cc-431b-8b05-2a1670a1ef47@github.com>

On Mon, 17 Jun 2024 04:58:41 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Utf16 case remove `append first utf16 char`

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 43:

> 41: public final class DoubleToDecimal extends ToDecimal {
> 42:     /**
> 43:      * Use LATIN1 encoding to process the input byte[] str

Suggestion:

     * Use LATIN1 encoding to process the in-out byte[] str

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 49:

> 47: 
> 48:     /**
> 49:      * Use UTF16 encoding to process the input byte[] str

Suggestion:

     * Use UTF16 encoding to process the in-out byte[] str

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 175:

> 173:      */
> 174:     public int putDecimal(byte[] str, int index, double v) {
> 175:         assert index >= 0 && index + MAX_CHARS <= length(str) : "Trusted caller missed bounds check";

Suggestion:

        assert 0 <= index && index <= length(str) - MAX_CHARS : "Trusted caller missed bounds check";

This avoids a potential overflow.
But if you want to enforce the check, you should probably avoid using `assert` since assertions might be disabled.

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 236:

> 234:                     dk = -1;
> 235:                 }
> 236:                 return toDecimal(str, index, Q_MIN, t, dk, fd) - start;

I suggest restoring the original logic like so:

                /* subnormal value */
                return (t < C_TINY
                        ? toDecimal(str, index, Q_MIN, 10 * t, -1, fd)
                        : toDecimal(str, index, Q_MIN, t, 0, fd)) - start;

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 452:

> 450:         if (l != 0) {
> 451:             put8Digits(str, index, l);
> 452:             index += 8;

As discussed in `ToDecimal`, all `put...` methods should return the updated `index`. Then this code can be rewritten as
Suggestion:

            index = put8Digits(str, index, l);

so that the caller doesn't need to know how many characters were added.

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 460:

> 458:         putChar(str, index++, 'E');
> 459:         if (e < 0) {
> 460:             putChar(str, index++, '-');

By the same logic as suggested above for `put8Digits`
Suggestion:

            index = putChar(str, index, '-');


and other places as well.

src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java line 41:

> 39:  * This class exposes a method to render a {@code float} as a string.
> 40:  */
> 41: public final class FloatToDecimal extends ToDecimal {

The review of this class is the same as for `DoubleToDecimal`, so I won't repeat it here.

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 34:

> 32: import static java.lang.Math.multiplyHigh;
> 33: 
> 34: sealed class ToDecimal permits DoubleToDecimal, FloatToDecimal {

I think this should better be

Suggestion:

abstract sealed class ToDecimal permits DoubleToDecimal, FloatToDecimal {


since we don't want/need to instantiate this class.

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 45:

> 43:     static final int PLUS_INF    = 0x300;
> 44:     static final int MINUS_INF   = 0x400;
> 45:     static final int NAN         = 0x500;

These constants could be like the original ones (0, 1, 2, ...).
This would make the switch over them a `tableswitch` rather than a `lookupswitch` in bytecode. I'm not sure whether this would improve machine code, however.
Of course, logic would need to be changed in some places (`<< 8`, `>>> 8`, etc.)

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 63:

> 61:     }
> 62: 
> 63:     final void putChar(byte[] str, int index, int c) {

I think it would be better for all the `put...` methods here to return the updated `index`, hence replacing the return type from `void` to `int`.

This would make usages easier, as there's no need to remember at the call sites by how much the index must be incremented after the usage.

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 71:

> 69:     }
> 70: 
> 71:     final void putCharsAt(byte[] str, int index, int c1, int c2) {

This method is used to put at least one digit. This means that the caller has to remember to add a '0' explicitly, which is questionable.
I suggest removing this method and invoke the correct combination of `putChar` and `putDigit` for more readable code.

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 165:

> 163:     }
> 164: 
> 165:     int length(byte[] str) {

Suggestion:

    final int length(byte[] str) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652975219
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652975321
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652972922
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652978056
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652984938
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652987069
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652991581
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652933181
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652993152
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652993281
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652993363
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1652993591

From duke at openjdk.org  Tue Jun 25 15:29:27 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 25 Jun 2024 15:29:27 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v14]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <OYt_5Zu1l_f1U7XWIia5MUjCoob6nc2SrCfqErUQa60=.cf68d112-36aa-43f5-a54d-5a319b25b151@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Update src/java.base/share/classes/jdk/internal/math/ToDecimal.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/b8e80428..e3830386

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=12-13

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From szaldana at openjdk.org  Tue Jun 25 15:52:19 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 25 Jun 2024 15:52:19 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal class
 names
Message-ID: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>

Hi all, 

This PR addresses [JDK-8333308](https://bugs.openjdk.org/browse/JDK-8333308) enabling `javap -system` to handle internal class names. 

Thanks, 
Sonia

-------------

Commit messages:
 - 8333308: javap --system handling doesn't work on internal class names

Changes: https://git.openjdk.org/jdk/pull/19883/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19883&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333308
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19883.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19883/head:pull/19883

PR: https://git.openjdk.org/jdk/pull/19883

From duke at openjdk.org  Tue Jun 25 16:18:43 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 25 Jun 2024 16:18:43 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v15]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <zu8FYwQazWdYznWcSyRBrkWCjSvew2R3F0QCBy-5SJ4=.a320cb0f-3cc1-4f55-bf8b-a28381641337@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/math/ToDecimal.java
  
  Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/e3830386..884757fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Tue Jun 25 16:58:25 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 25 Jun 2024 16:58:25 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v16]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <xheX3RaOb43GvFNlA8qQfPUe-ptc-J8RogI-6E5rRV8=.83528cac-9895-46c3-bebd-aa88a83c66fa@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  refactor from @rgiulietti

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/884757fa..47ae33d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=14-15

  Stats: 62 lines in 3 files changed: 4 ins; 13 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Tue Jun 25 17:05:39 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 25 Jun 2024 17:05:39 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v17]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <dvNiIj3XfEivCN7UJtmXOx9fTX5xo2u7xAqxAfTL3X8=.220cebd9-440b-4d8c-9a0d-44765b5b4dc2@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - fix assert from @rgiulietti
 - fix comment from @rgiulietti

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/47ae33d0..a18c1a1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=15-16

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From duke at openjdk.org  Tue Jun 25 17:05:40 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 25 Jun 2024 17:05:40 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v13]
In-Reply-To: <aKM-WbdLbyfJned-2LkQ6V-G7IfPvqapn2G77re39R8=.4f831602-d8cc-431b-8b05-2a1670a1ef47@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>
 <aKM-WbdLbyfJned-2LkQ6V-G7IfPvqapn2G77re39R8=.4f831602-d8cc-431b-8b05-2a1670a1ef47@github.com>
Message-ID: <OS_Zpb7lQn5_-kq7yKCvYQXM-cuqkL59H3uc2rpF2jg=.b1d1d7d4-c18e-40e7-abb4-b49113c1b7f4@github.com>

On Tue, 25 Jun 2024 14:47:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Utf16 case remove `append first utf16 char`
>
> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 236:
> 
>> 234:                     dk = -1;
>> 235:                 }
>> 236:                 return toDecimal(str, index, Q_MIN, t, dk, fd) - start;
> 
> I suggest restoring the original logic like so:
> 
>                 /* subnormal value */
>                 return (t < C_TINY
>                         ? toDecimal(str, index, Q_MIN, 10 * t, -1, fd)
>                         : toDecimal(str, index, Q_MIN, t, 0, fd)) - start;

I like the new implementation, the code is cleaner, is your suggestion to revert to the original version due to smaller changes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1653210427

From epeter at openjdk.org  Tue Jun 25 17:17:23 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 25 Jun 2024 17:17:23 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v13]
In-Reply-To: <F-rioR0rIUORqyBP2vZV3aQaJo9F78NtNGQ11UeZAGw=.61e5fb1b-bbfe-43d8-8946-65a939491821@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <F-rioR0rIUORqyBP2vZV3aQaJo9F78NtNGQ11UeZAGw=.61e5fb1b-bbfe-43d8-8946-65a939491821@github.com>
Message-ID: <enAmDbMsntMjOhHUfvhQsH4lRLFjyEWPf0uKtAB2YXs=.3a929baf-6146-4a82-80d3-dc19b288f668@github.com>

On Sun, 23 Jun 2024 08:47:25 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   private static final field `UNSAFE`

I'm running your benchmark [PutCharTest.java](https://github.com/user-attachments/files/15974672/PutCharTest.txt) with:

/oracle-work/jdk-fork2/build/linux-x64-slowdebug/jdk/bin/java --add-modules java.base --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports java.base/jdk.internal.util=ALL-UNNAMED -XX:+TraceMergeStores -Xbatch -XX:CompileCommand=printcompilation,PutCharTest::* -XX:CompileCommand=compileonly,PutCharTest::put* -XX:+PrintIdeal PutCharTest.java


Aha, I found the limitation in `MergeStores`:
https://github.com/openjdk/jdk/blob/f7862bd6b9994814c6dfd43d471122408601f288/src/hotspot/share/opto/memnode.cpp#L2982-L2986

Basically, I require the `store` to have the same data-size as the element-size of the array.
But the `putChar` ends up as a 2-byte `StoreC`, and the array is a `byte[]` with 1-byte elements.

I quickly removed this check:

diff --git a/src/hotspot/share/opto/memnode.cpp b/src/hotspot/share/opto/memnode.cpp
index d0b6c59637f..78efda2db13 100644
--- a/src/hotspot/share/opto/memnode.cpp
+++ b/src/hotspot/share/opto/memnode.cpp
@@ -2980,10 +2980,10 @@ StoreNode* MergePrimitiveArrayStores::run() {
     return nullptr;
   }
   BasicType bt = aryptr_t->elem()->array_element_basic_type();
-  if (!is_java_primitive(bt) ||
-      type2aelembytes(bt) != _store->memory_size()) {
-    return nullptr;
-  }
+  //if (!is_java_primitive(bt) ||
+  //    type2aelembytes(bt) != _store->memory_size()) {
+  //  return nullptr;
+  //}
 
   // The _store must be the "last" store in a chain. If we find a use we could merge with
   // then that use or a store further down is the "last" store.
@@ -3033,13 +3033,13 @@ bool MergePrimitiveArrayStores::is_compatible_store(const StoreNode* other_store
   if (!is_java_primitive(aryptr_bt1) || !is_java_primitive(aryptr_bt2)) {
     return false;
   }
-  int size1 = type2aelembytes(aryptr_bt1);
-  int size2 = type2aelembytes(aryptr_bt2);
-  if (size1 != size2 ||
-      size1 != _store->memory_size() ||
-      _store->memory_size() != other_store->memory_size()) {
-    return false;
-  }
+  //int size1 = type2aelembytes(aryptr_bt1);
+  //int size2 = type2aelembytes(aryptr_bt2);
+  //if (size1 != size2 ||
+  //    size1 != _store->memory_size() ||
+  //    _store->memory_size() != other_store->memory_size()) {
+  //  return false;
+  //}
   return true;
 }
 


And now it optimizes:


15523  103    b  4       PutCharTest::putNull (14 bytes)
[TraceMergeStores]: Replace
  74  StoreC  === 62 7 73 22  [[ 99 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; mismatched unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: PutCharTest::putChar @ bci:14 (line 14) PutCharTest::putCharsAt @ bci:4 (line 7) PutCharTest::putNull @ bci:10 (line 23)
  99  StoreC  === 62 74 98 23  [[ 124 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; mismatched unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: PutCharTest::putChar @ bci:14 (line 14) PutCharTest::putCharsAt @ bci:13 (line 8) PutCharTest::putNull @ bci:10 (line 23)
 124  StoreC  === 62 99 123 24  [[ 150 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; mismatched unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: PutCharTest::putChar @ bci:14 (line 14) PutCharTest::putCharsAt @ bci:23 (line 9) PutCharTest::putNull @ bci:10 (line 23)
 150  StoreC  === 62 124 149 24  [[ 17 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; mismatched unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; !jvms: PutCharTest::putChar @ bci:14 (line 14) PutCharTest::putCharsAt @ bci:33 (line 10) PutCharTest::putNull @ bci:10 (line 23)
[TraceMergeStores]: with
 155  ConL  === 0  [[ 156 ]]  #long:30399761348886638
 156  StoreL  === 62 7 73 155  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=4;


I will file an RFE to enable this use-case as well. @wenshao thanks for the standalone test, that was really helpful!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2189509983

From epeter at openjdk.org  Tue Jun 25 17:22:12 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 25 Jun 2024 17:22:12 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <dKtXgrAuwD5ZkbCJYZaCPKgCjgK5Gt_0CIqk0Dp4cBs=.cfb43f8b-fdc1-46b9-add8-1454964313d0@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
 <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
 <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>
 <nIWEJwBl6I1MnZtAftoVz7Nt4_u2p66CvnJghrU2KF4=.bc7f4242-5106-4a17-bd46-9fa500f9d269@github.com>
 <Vc4OgDPfVE7ZtFrp7fWW8QL6ZKpWsaR9EpnPETShlns=.719b479f-611f-4d31-8331-53c53e42089b@github.com>
 <dKtXgrAuwD5ZkbCJYZaCPKgCjgK5Gt_0CIqk0Dp4cBs=.cfb43f8b-fdc1-46b9-add8-1454964313d0@github.com>
Message-ID: <P5EVfwztNl3bf7fP5CVb4OELzS7UlSlWBAf1tS1fO_M=.652dc93b-ae91-4d02-87d4-19ab7720fae1@github.com>

On Thu, 20 Jun 2024 14:32:25 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> @cl4es  @wenshao I think we should probably work on `putChar`, or at least figure out what blocks `MergeStore` for `putChar`. Can someone produce a simple stand-alone `.java` file that uses `putChar`, so that I can investigate why `MergeStore` does not work for it?
>> 
>> Otherwise, I agree with @cl4es : the code here may be ok for now, but we would have to revert it again later, should `MergeStore` eventually do the trick.
>
> @eme64 
> 
> simple stand-alone java
> 
> import jdk.internal.misc.Unsafe;
> 
> public class PutCharTest {
>     static final Unsafe UNSAFE = Unsafe.getUnsafe();
> 
>     static void putCharsAt(byte[] val, int index, int c1, int c2, int c3, int c4) {
>         putChar(val, index    , (char)(c1));
>         putChar(val, index + 1, (char)(c2));
>         putChar(val, index + 2, (char)(c3));
>         putChar(val, index + 3, (char)(c4));
>     }
>     
>     static void putChar(byte[] bytes, int index, int c) {
>         UNSAFE.putChar(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1), (char)(c));
>     }
> 
>     static void putChar0(byte[] bytes, int index, int c) {
>         UNSAFE.putByte(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1), (byte)(c));
>         UNSAFE.putByte(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1) + 1, (byte)(c << 8));
>     }
> 
>     static void putNull(byte[] bytes, int index) {
>         putCharsAt(bytes, index, 'n', 'u', 'l', 'l');
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 5; i++) {
>             testNull();
>         }
> 
>         System.out.println("done");
>     }
> 
>     private static void testNull() {
>         byte[] bytes = new byte[8192];
> 
>         for (int i = 0; i < 1000; i++) {
>             int index = 0;
>             for (int j = 0; j < 1024; j++) {
>                 putNull(bytes, index);
>                 index += 4;
>             }
>         }
>     }
> }

@wenshao @cl4es I think this use-case is quite a valid one, and deserves an extension. I filed:

[JDK-8335113](https://bugs.openjdk.org/browse/JDK-8335113): C2 MergeStores: allow merging of putChar and other larger stores on smaller array elements

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2189523984

From duke at openjdk.org  Tue Jun 25 17:29:04 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 25 Jun 2024 17:29:04 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v18]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <zqQH21YTFDv7OoAzu90gYCUz5lJUWJmLED-v8SdN_JU=.6de3dcd4-117b-4e87-b922-765a343e2969@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @liach: use s.getBytes for performance

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/a18c1a1b..5d3405f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=16-17

  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From liach at openjdk.org  Tue Jun 25 17:33:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Jun 2024 17:33:49 GMT
Subject: RFR: 8335110: Fix instruction name and API spec inconsistencies in
 CodeBuilder
Message-ID: <qLmT7YdAmvl46N4WnUigB1YwZJs4vhXVJdnQmLoq86Y=.793a83f5-a67d-469e-97be-408e5aeda909@github.com>

This is a collection of fixes and improvements to CodeBuilder, plus 2 renames.

Fixes include:
1. `CodeBuilder::receiverSlot` typo
2. `CodeAttribute::labelToBci` update spec
3. `CodeBuilder::exceptionCatch` implementation
4. `CodeBuilder::if_nonnull`/`if_null` -> `ifnonnull`/`ifnull`
5. Docs for what instructions factories emit, and to explain why some factories have name mismatch; also a section in summary.

-------------

Commit messages:
 - Describe extra types of instructions that can be generated
 - Minor polishing to CodeBuilder

Changes: https://git.openjdk.org/jdk/pull/19889/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19889&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335110
  Stats: 123 lines in 6 files changed: 106 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19889/head:pull/19889

PR: https://git.openjdk.org/jdk/pull/19889

From andrew at openjdk.org  Tue Jun 25 17:48:32 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 25 Jun 2024 17:48:32 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
 <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
Message-ID: <wGZSAaOyNa_ihdZyOXe2Wk2p0z-AitonYkxdgH4Ie2g=.8262bc97-3864-4822-8aa9-18c3e39c1197@github.com>

On Fri, 21 Jun 2024 16:11:34 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Updated all the tests that depend on external infrastructure services as manual. These tests may fail with external reasons, for instance - change in CA test portal, certificate status updates, or network issues.
>
> Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typos

Is there still going to be some monitoring of these tests? Making it harder to run these tests potentially means that genuine failures can go unnoticed and JDK certificates are not updated when needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19814#issuecomment-2189601735

From duke at openjdk.org  Tue Jun 25 18:22:16 2024
From: duke at openjdk.org (Yude Lin)
Date: Tue, 25 Jun 2024 18:22:16 GMT
Subject: Integrated: 8334810: Redo: Un-ProblemList LocaleProvidersRun and
 CalendarDataRegression
In-Reply-To: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
References: <MXtQSQm4Xo_03_kX82eWJxrDjqERSho98gqahiPRFuI=.cb827c0c-6a01-447e-86ee-25aa78bf46be@github.com>
Message-ID: <1TXY6Y2BTyM-tnd-9b2GmjpopAXBEWhSn9KO4ePt1zs=.8a2422c7-7eef-4ff3-a0a4-721a29a7769f@github.com>

On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin <duke at openjdk.org> wrote:

> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed LocaleProvidersRun and CalendarDataRegression, and [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back. I'm guessing it's a mistake in resolving merge conflict.

This pull request has now been integrated.

Changeset: f8bf470b
Author:    Yude Lin <yude.lyd at alibaba-inc.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8bf470b773884911290fa6ce059f7cc13686186
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression
8268379: java/util/Locale/LocaleProvidersRun.java and sun/util/locale/provider/CalendarDataRegression.java timed out

Reviewed-by: naoto, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/19849

From jlu at openjdk.org  Tue Jun 25 19:08:13 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Jun 2024 19:08:13 GMT
Subject: RFR: 8334418: Update IANA Language Subtag Registry to Version
 2024-06-14
In-Reply-To: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
References: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
Message-ID: <068BhwBFUs3TqG_Ny0eWMBQYpWP1IGFBs1CxHGPxLeY=.c9001f11-516d-4df5-88fb-468c7addd8d3@github.com>

On Mon, 17 Jun 2024 21:05:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a trivial update of the IANA subtag registry to version 2024-06-14. 
> Announcement: https://mm.icann.org/pipermail/ietf-languages-announcements/2024-June/000092.html

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19757#issuecomment-2189763247

From jlu at openjdk.org  Tue Jun 25 19:08:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Jun 2024 19:08:22 GMT
Subject: Integrated: 8334653: ISO 4217 Amendment 177 Update
In-Reply-To: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
References: <w-UcTNYL-g5Zs8M3b36YnHE1P2mTfGKOsccJb6TMGaM=.f3c6f6ee-69d6-4592-b3cb-a38bd32d50dd@github.com>
Message-ID: <LBU8CZ_f06EFPGyFZU4xK3cmyleuz8-8DObz9sDEi-c=.02e67458-ad90-476f-8332-22a32415da2a@github.com>

On Thu, 20 Jun 2024 18:01:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which incorporates the ISO 4217 Amendment 177 Update.
> 
> Specifically, the introduction of the new currency, Zimbabwe Gold.

This pull request has now been integrated.

Changeset: 86b0cf25
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91
Stats:     23 lines in 6 files changed: 3 ins; 0 del; 20 mod

8334653: ISO 4217 Amendment 177 Update

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/19813

From jlu at openjdk.org  Tue Jun 25 19:08:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Jun 2024 19:08:14 GMT
Subject: Integrated: 8334418: Update IANA Language Subtag Registry to Version
 2024-06-14
In-Reply-To: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
References: <pEiPgmBmj_1ybmBG7isRq3wGHRSSRxI4JudxK0R9Ytk=.ad9c574e-c95e-48fe-98a9-7006f821bdfe@github.com>
Message-ID: <fKw1m8CBgS-VHNL_q-z3t_SL6LCIkgOCLBDS51eZf2k=.7799c2b3-6a50-411a-a0e2-b282664e390a@github.com>

On Mon, 17 Jun 2024 21:05:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which is a trivial update of the IANA subtag registry to version 2024-06-14. 
> Announcement: https://mm.icann.org/pipermail/ietf-languages-announcements/2024-June/000092.html

This pull request has now been integrated.

Changeset: 861aefca
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49
Stats:     7 lines in 2 files changed: 4 ins; 0 del; 3 mod

8334418: Update IANA Language Subtag Registry to Version 2024-06-14

Reviewed-by: lancea, iris, srl, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/19757

From naoto at openjdk.org  Tue Jun 25 19:35:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Jun 2024 19:35:12 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <julUD8fYOzQKcVXJIvBs0XdHwkigMmCB2gNg_sWonjE=.ad9fddd3-91c7-4fbe-a578-7886ad46edb4@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <julUD8fYOzQKcVXJIvBs0XdHwkigMmCB2gNg_sWonjE=.ad9fddd3-91c7-4fbe-a578-7886ad46edb4@github.com>
Message-ID: <fzhyfD_RFKPTKh7Fy1gPkAck6DElQkoInCSLcICs31U=.d5418456-4698-47e3-b187-5f0aae5b7c34@github.com>

On Thu, 20 Jun 2024 18:58:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> I did not mean to introduce a public API for this change (if we do, the fix cannot be backported). I thought we could define a package private one, but based on your observation, it may get messier... So I agree that falling back to `StringBuf` is the way to go, IMO.

> So, considering all the information given, is it enough to start our new review process? @naotoj @liach @justin-curtis-lu

Well, I was suggesting the same buffer proxying for other Format classes than NumberFormat subclasses, such as DateFormat so that they would have the same performance benefit. Would you be willing to do that too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2189821715

From liach at openjdk.org  Tue Jun 25 19:52:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Jun 2024 19:52:10 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
Message-ID: <R-kNIAyvmpLXtz7PbAstrOEdBttKldvDCXYpjeYI9cw=.a8f17e52-67b1-4e16-9754-19de01fd5031@github.com>

On Tue, 25 Jun 2024 13:59:35 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [JDK-8333308](https://bugs.openjdk.org/browse/JDK-8333308) enabling `javap -system` to handle internal class names. 
> 
> Thanks, 
> Sonia

Technically javap accepts both notations of `a.b.C` and `a/b/C.class` and accepts both `.` and `$` as inner class separators. So this is fine. However it's hard to verify that the jdk in `--system` is really used, so I put a noreg-hard label on the original JBS issue; it's hard to create a suitable argument for the `--system` flag as you need a whole JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19883#issuecomment-2189848518

From duke at openjdk.org  Tue Jun 25 20:20:17 2024
From: duke at openjdk.org (duke)
Date: Tue, 25 Jun 2024 20:20:17 GMT
Subject: Withdrawn: 8310994: Add JFR event for selection operations
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <t0BtaH8CotU90nWxbLlQcnnJX1LlRbARHc5lFdgpHxI=.c345f2f0-ff20-4c0a-9d6e-f1e714ee1c8d@github.com>

On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16710

From liach at openjdk.org  Tue Jun 25 21:22:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Jun 2024 21:22:34 GMT
Subject: RFR: 8335110: Fix instruction name and API spec inconsistencies in
 CodeBuilder [v2]
In-Reply-To: <qLmT7YdAmvl46N4WnUigB1YwZJs4vhXVJdnQmLoq86Y=.793a83f5-a67d-469e-97be-408e5aeda909@github.com>
References: <qLmT7YdAmvl46N4WnUigB1YwZJs4vhXVJdnQmLoq86Y=.793a83f5-a67d-469e-97be-408e5aeda909@github.com>
Message-ID: <vfvh6xTdGOEugILrpyuHQ8QgL8e3Y1Z3Tg91H4sbKUQ=.04eda6e0-a506-41dc-b415-bbb71dd68be0@github.com>

> This is a collection of fixes and improvements to CodeBuilder, plus 2 renames.
> 
> Fixes include:
> 1. `CodeBuilder::receiverSlot` typo
> 2. `CodeAttribute::labelToBci` update spec
> 3. `CodeBuilder::exceptionCatch` implementation
> 4. `CodeBuilder::if_nonnull`/`if_null` -> `ifnonnull`/`ifnull`
> 5. Docs for what instructions factories emit, and to explain why some factories have name mismatch; also a section in summary.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Patch in csr but forgot to upload

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19889/files
  - new: https://git.openjdk.org/jdk/pull/19889/files/013a5cf2..8fe07e1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19889&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19889&range=00-01

  Stats: 15 lines in 1 file changed: 0 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/19889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19889/head:pull/19889

PR: https://git.openjdk.org/jdk/pull/19889

From duke at openjdk.org  Wed Jun 26 01:08:23 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 26 Jun 2024 01:08:23 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v13]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <KeVfcKcecyaFTybKG5VF0XX8hO6PYeqHLESShlR-he8=.5fb5bd2b-dbd1-44d4-94dd-d92e15fa5264@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimized to compute the remainder only if needed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/923b3475..0368a19b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=11-12

  Stats: 47 lines in 2 files changed: 22 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Wed Jun 26 01:38:33 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 26 Jun 2024 01:38:33 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v14]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <-8UD2hq4wzpJST1BAnPI5h5NhECZeBFz5guo1fSLkN8=.46dec51a-28a5-4f39-84fb-36434184d438@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/0368a19b..203d3f67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=12-13

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From stuefe at openjdk.org  Wed Jun 26 06:07:13 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Jun 2024 06:07:13 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <R-kNIAyvmpLXtz7PbAstrOEdBttKldvDCXYpjeYI9cw=.a8f17e52-67b1-4e16-9754-19de01fd5031@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
 <R-kNIAyvmpLXtz7PbAstrOEdBttKldvDCXYpjeYI9cw=.a8f17e52-67b1-4e16-9754-19de01fd5031@github.com>
Message-ID: <oCtXWM_OvYIXp9H75pHl_Gr6gW52y3uNGwm-aywM9XE=.9c5c9c0e-2f4b-4040-a93e-85ee1e554a8c@github.com>

On Tue, 25 Jun 2024 19:49:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Technically javap accepts both notations of `a.b.C` and `a/b/C.class` and accepts both `.` and `$` as inner class separators. So this is fine. However it's hard to verify that the jdk in `--system` is really used, so I put a noreg-hard label on the original JBS issue; it's hard to create a suitable argument for the `--system` flag as you need a whole JDK.

Question, what is the noreg-hard label used for?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19883#issuecomment-2190783227

From asotona at openjdk.org  Wed Jun 26 06:57:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Jun 2024 06:57:20 GMT
Subject: RFR: 8335060: ClassCastException after JDK-8294960
Message-ID: <MyQRbEQtGTryYU7dN4VmlQshseeptxabnXlV8W8EsQg=.94ce72e1-94bd-45f9-bb13-04821e4a87aa@github.com>

Conversion of `java.lang.invoke` package to Class-File API is failing to execute method handles with specific type conversion requirements. Root cause is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` implementation. Original code has been matching the types by hash code and it mistakenly appeared to be matching the primitive types.

This patch fixes `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` and adds tests to better cover `TypeConvertingMethodAdapter` functionality.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8335060: ClassCastException after JDK-8294960

Changes: https://git.openjdk.org/jdk/pull/19898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19898&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335060
  Stats: 806 lines in 2 files changed: 798 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19898/head:pull/19898

PR: https://git.openjdk.org/jdk/pull/19898

From alanb at openjdk.org  Wed Jun 26 07:57:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Jun 2024 07:57:11 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <oCtXWM_OvYIXp9H75pHl_Gr6gW52y3uNGwm-aywM9XE=.9c5c9c0e-2f4b-4040-a93e-85ee1e554a8c@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
 <R-kNIAyvmpLXtz7PbAstrOEdBttKldvDCXYpjeYI9cw=.a8f17e52-67b1-4e16-9754-19de01fd5031@github.com>
 <oCtXWM_OvYIXp9H75pHl_Gr6gW52y3uNGwm-aywM9XE=.9c5c9c0e-2f4b-4040-a93e-85ee1e554a8c@github.com>
Message-ID: <wc-_-Ibxi9OpEmPinHlrRkLp35yEnR26aKtNKCxUloE=.e33c9e53-0434-4248-853a-173c01c2072c@github.com>

On Wed, 26 Jun 2024 06:04:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Question, what is the noreg-hard label used for?

It's the label to mean that it's too hard or impossible write a regression test. It is documented in the [JBS label dictionary](https://openjdk.org/guide/#jbs-label-dictionary) but may not be widely known.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19883#issuecomment-2191053610

From stuefe at openjdk.org  Wed Jun 26 08:16:10 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Jun 2024 08:16:10 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <wc-_-Ibxi9OpEmPinHlrRkLp35yEnR26aKtNKCxUloE=.e33c9e53-0434-4248-853a-173c01c2072c@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
 <R-kNIAyvmpLXtz7PbAstrOEdBttKldvDCXYpjeYI9cw=.a8f17e52-67b1-4e16-9754-19de01fd5031@github.com>
 <oCtXWM_OvYIXp9H75pHl_Gr6gW52y3uNGwm-aywM9XE=.9c5c9c0e-2f4b-4040-a93e-85ee1e554a8c@github.com>
 <wc-_-Ibxi9OpEmPinHlrRkLp35yEnR26aKtNKCxUloE=.e33c9e53-0434-4248-853a-173c01c2072c@github.com>
Message-ID: <lQemaK6yGNKd7GZIIJFtamw423fRLqn7MopM9_rBgfY=.8034909a-5685-4b48-809f-d7de7ef9c30f@github.com>

On Wed, 26 Jun 2024 07:54:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Question, what is the noreg-hard label used for?
> 
> It's the label to mean that it's too hard or impossible write a regression test. It is documented in the [JBS label dictionary](https://openjdk.org/guide/#jbs-label-dictionary) but may not be widely known.

Ah, thank you, and I never knew this documentation either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19883#issuecomment-2191089714

From mdoerr at openjdk.org  Wed Jun 26 08:31:11 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 26 Jun 2024 08:31:11 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960 [v3]
In-Reply-To: <3ddEdbTdCaDgKKBxuV8tSCL2CSdHfMwMLdVVtUV-6FE=.7dd77242-ae63-4910-b0ab-bbb6a79ac44d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
 <3ddEdbTdCaDgKKBxuV8tSCL2CSdHfMwMLdVVtUV-6FE=.7dd77242-ae63-4910-b0ab-bbb6a79ac44d@github.com>
Message-ID: <5veuny1TAQ8ij5TOzH6O1y3UbIh3keto3dh5wlENJaw=.fc28ea8e-ec9b-43ef-955c-48cce2abfa5b@github.com>

On Tue, 25 Jun 2024 13:47:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
>> 
>> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
>> 
>> Please review and test on a BigEndian platform.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more de-lambda work on ClassSpecializer

The tests have passed on AIX, too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2191118572

From asotona at openjdk.org  Wed Jun 26 09:12:16 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Jun 2024 09:12:16 GMT
Subject: RFR: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960 [v3]
In-Reply-To: <3ddEdbTdCaDgKKBxuV8tSCL2CSdHfMwMLdVVtUV-6FE=.7dd77242-ae63-4910-b0ab-bbb6a79ac44d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
 <3ddEdbTdCaDgKKBxuV8tSCL2CSdHfMwMLdVVtUV-6FE=.7dd77242-ae63-4910-b0ab-bbb6a79ac44d@github.com>
Message-ID: <suIDtFpp-gITdOU_DxGM7952iaZRRbQ6QsqyK-isRS8=.e2d8613a-a3f3-4d59-bbfa-10f9f143ac7f@github.com>

On Tue, 25 Jun 2024 13:47:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
>> 
>> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
>> 
>> Please review and test on a BigEndian platform.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more de-lambda work on ClassSpecializer

Thank you for confirmation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19863#issuecomment-2191198224

From asotona at openjdk.org  Wed Jun 26 09:12:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Jun 2024 09:12:17 GMT
Subject: Integrated: 8334872: BigEndian: java/lang/invoke/condy Tests failing
 since JDK-8294960
In-Reply-To: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
References: <GQnVd9yk23gmezb55LmRLcJW1yluVznCkR9BPxtZF_Q=.eb5ecd32-4209-4439-8f40-831bfdf00e8d@github.com>
Message-ID: <oaIQmLdwz_M4CkvYG5VPxLTcDrUoxiC-yIRpeRWKM3Y=.875c4555-6aa3-4e55-b0cd-7ab5ddf8d3a0@github.com>

On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code generation and unfortunately it causes StackOverflow on BigEndian platforms.
> 
> This patch converts all lambdas in ClassSpecializer into anonymous inner classes.
> 
> Please review and test on a BigEndian platform.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 7f6804ce
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f6804ceb63568d72e825d45b02d08f314c9b0fc
Stats:     290 lines in 1 file changed: 110 ins; 84 del; 96 mod

8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/19863

From asotona at openjdk.org  Wed Jun 26 09:22:10 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Jun 2024 09:22:10 GMT
Subject: RFR: 8335110: Fix instruction name and API spec inconsistencies in
 CodeBuilder [v2]
In-Reply-To: <vfvh6xTdGOEugILrpyuHQ8QgL8e3Y1Z3Tg91H4sbKUQ=.04eda6e0-a506-41dc-b415-bbb71dd68be0@github.com>
References: <qLmT7YdAmvl46N4WnUigB1YwZJs4vhXVJdnQmLoq86Y=.793a83f5-a67d-469e-97be-408e5aeda909@github.com>
 <vfvh6xTdGOEugILrpyuHQ8QgL8e3Y1Z3Tg91H4sbKUQ=.04eda6e0-a506-41dc-b415-bbb71dd68be0@github.com>
Message-ID: <sBzCOAYjr8sNsN0fUxPYN5MnEQMnWX1wBG_aXdKhWhc=.f921ef7e-5406-4e04-a1ad-5cf7c67d777a@github.com>

On Tue, 25 Jun 2024 21:22:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is a collection of fixes and improvements to CodeBuilder, plus 2 renames.
>> 
>> Fixes include:
>> 1. `CodeBuilder::receiverSlot` typo
>> 2. `CodeAttribute::labelToBci` update spec
>> 3. `CodeBuilder::exceptionCatch` implementation
>> 4. `CodeBuilder::if_nonnull`/`if_null` -> `ifnonnull`/`ifnull`
>> 5. Docs for what instructions factories emit, and to explain why some factories have name mismatch; also a section in summary.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Patch in csr but forgot to upload

Looks good to me, thank you.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19889#pullrequestreview-2141230227

From jlahoda at openjdk.org  Wed Jun 26 09:28:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Jun 2024 09:28:10 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
Message-ID: <YnZ5RcpRlNIID15l_ylPP9ML6FJEtAz2EvpN3Ob7XEs=.a218c7d1-6c31-4f89-bdb9-7a9935aa2ce0@github.com>

On Tue, 25 Jun 2024 13:59:35 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [JDK-8333308](https://bugs.openjdk.org/browse/JDK-8333308) enabling `javap -system` to handle internal class names. 
> 
> Thanks, 
> Sonia

For a test, I agree it is quite difficult. For the `--system` parameter, it would probably be possible to create a directory (e.g. `$DIR`), and inside it `$DIR/lib`, and copy suitable `jrt-fs.jar` and  `modules` to it from `$JDK/lib`. And the use `--system $DIR`. But, it would still be fairly difficult to be sure the class' content is read from `$DIR`, not from the runtime JDK - `modules` would presumably need to be modified/different than the one for the runtime JDK, and that is not very easy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19883#issuecomment-2191232755

From duke at openjdk.org  Wed Jun 26 09:43:32 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 26 Jun 2024 09:43:32 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v12]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/b6646c5d..7eb9b523

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=10-11

  Stats: 242 lines in 9 files changed: 220 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From sgehwolf at openjdk.org  Wed Jun 26 10:04:13 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 26 Jun 2024 10:04:13 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v7]
In-Reply-To: <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
Message-ID: <ohJIqA365qC6IlLfSR2rm9_RK75ZLCGqj7h8bAvoXCw=.a69cefce-289b-42af-8d1b-d0550de2c62d@github.com>

On Tue, 25 Jun 2024 13:54:46 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refactor mount info matching to helper function
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Remove problem listing of PlainRead which is reworked here
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/baafa662...532ea33b

Could I get a second review on this please? @larry-cable maybe? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2191300003

From duke at openjdk.org  Wed Jun 26 10:08:16 2024
From: duke at openjdk.org (lingjun-cg)
Date: Wed, 26 Jun 2024 10:08:16 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8]
In-Reply-To: <fzhyfD_RFKPTKh7Fy1gPkAck6DElQkoInCSLcICs31U=.d5418456-4698-47e3-b187-5f0aae5b7c34@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com>
 <julUD8fYOzQKcVXJIvBs0XdHwkigMmCB2gNg_sWonjE=.ad9fddd3-91c7-4fbe-a578-7886ad46edb4@github.com>
 <fzhyfD_RFKPTKh7Fy1gPkAck6DElQkoInCSLcICs31U=.d5418456-4698-47e3-b187-5f0aae5b7c34@github.com>
Message-ID: <jKX-wdt4LpJylmmjroleGxhb-pqDgCfU9tzfgC_o6ds=.821437b7-9870-4314-b640-4ce7f812c37c@github.com>

On Tue, 25 Jun 2024 19:33:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > So, considering all the information given, is it enough to start our new review process? @naotoj @liach @justin-curtis-lu
> 
> Well, I was suggesting the same buffer proxying for other Format classes than NumberFormat subclasses, such as DateFormat so that they would have the same performance benefit. Would you be willing to do that too?

Sure. All `Format`'s subclasses has been replaced with buffer proxying. After that I run the benchmark test with averageTime mode. The result show the StringBuilder has take effect. 
Please review again. @naotoj @liach @justin-curtis-lu 

| Testcase | JDK 11  | JDK 22 | Current JDK |
| ------------- | ------------- |------------- | ------------- |
| java.text.NumberFormat#format(double)| 362.221  | 636.049 | 351.913|
| java.text.DateFormat#format(java.util.Date)| 362.273|944.733|317.436|
|java.text.MessageFormat#format| 599.146| 937.717|499.584|
|java.text.ListFormat#format| N/A | 464.123|318.978|

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2191307113

From nbenalla at openjdk.org  Wed Jun 26 10:08:38 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 26 Jun 2024 10:08:38 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v5]
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <L94kTAbSvAWLYlRP870eWS7GD4KSXlyL916kJm7fMCI=.03ea394a-47a3-4ad9-99ea-95b866398af6@github.com>

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Nizar Benalla 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:

 - Merge remote-tracking branch 'upstream/master' into 8330954
 - Merge remote-tracking branch 'upstream/master' into 8330954
 - (C)
 - (C)
 - Move security classes changes to pr18373
 - remove couple extra lines
 - Pull request is now only about `@since` tags, might add an other commit
 - add one more `{inheritDoc}` to `CompletableFuture.state`
 - add `@throws` declarations to javadoc
 - add ``{@inheritDoc}`` to new javadoc comments
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5654cccb...dbef517a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18954/files
  - new: https://git.openjdk.org/jdk/pull/18954/files/b3574b97..dbef517a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=03-04

  Stats: 141869 lines in 2684 files changed: 97659 ins; 31514 del; 12696 mod
  Patch: https://git.openjdk.org/jdk/pull/18954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18954/head:pull/18954

PR: https://git.openjdk.org/jdk/pull/18954

From redestad at openjdk.org  Wed Jun 26 10:30:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 10:30:20 GMT
Subject: RFR: 8334437: De-duplicate ProxyMethod list creation
In-Reply-To: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
References: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
Message-ID: <O5dYJssjtAkU9Bo794W1VyM0CQ2ZnSPh1KCV6gj4OKE=.2e7e4189-f2a7-4d6a-90b3-73675f5fd5d9@github.com>

On Tue, 18 Jun 2024 07:41:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simple refactoring to extract identical, simple lambda expressions. Improve code clarity and reduce classes generated.

Friendly reminder that this trivial improvement needs a reviewer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19760#issuecomment-2191352440

From redestad at openjdk.org  Wed Jun 26 10:32:14 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 10:32:14 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps [v3]
In-Reply-To: <OVmK9shSdckDHbxyLjdQADmRADEXp5eR-B_r9L-zZic=.ed696fcb-f490-466c-85a1-295d4e55376f@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
 <OVmK9shSdckDHbxyLjdQADmRADEXp5eR-B_r9L-zZic=.ed696fcb-f490-466c-85a1-295d4e55376f@github.com>
Message-ID: <sNgGX8vqO0UjkZS5_kV2Fh2rJI6uMum6-KmpGEEdoAU=.c7cdddbe-9d08-4255-963a-40c096623f54@github.com>

On Tue, 18 Jun 2024 10:00:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes

Friendly reminder that this improvement needs a Reviewer. While it'd be great if javac can make this redundant this is adding overhead in the meantime, and the temporary workaround doesn't obfuscate the code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19477#issuecomment-2191356136

From rgiulietti at openjdk.org  Wed Jun 26 11:33:10 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 26 Jun 2024 11:33:10 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v8]
In-Reply-To: <-w_24oYBK4mkgmt252jiOOUlNB_qyANavids5PHEYgI=.1ad8587a-5187-4b4e-9ef7-8b164b7a8806@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>
 <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
 <-w_24oYBK4mkgmt252jiOOUlNB_qyANavids5PHEYgI=.1ad8587a-5187-4b4e-9ef7-8b164b7a8806@github.com>
Message-ID: <aBBcZtS9QY0zf74yZ9oXybYsg0Vmk8ERqdrKS1Q4yQU=.819d23ff-1c6b-43af-9e8a-2ac5ba5e579b@github.com>

On Tue, 25 Jun 2024 01:58:29 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Just suggesting some improvements
>
> All suggestions have been fixed, can this PR be integrated? @cl4es  @liach

@wenshao Looks good, thanks for the improvements.

Let me know when you are finished with your changes.
Once approved, you should refrain from adding other commits without further approvals.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19730#issuecomment-2191464714

From duke at openjdk.org  Wed Jun 26 12:00:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 12:00:13 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v8]
In-Reply-To: <aBBcZtS9QY0zf74yZ9oXybYsg0Vmk8ERqdrKS1Q4yQU=.819d23ff-1c6b-43af-9e8a-2ac5ba5e579b@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <cCigQgOqd7ck_Cq_VY0cuuimfjcoVxVrBZqaD1DoMPQ=.0c194952-b34d-4c9f-9495-8adc4cfea851@github.com>
 <5tVkGJf-Lzm2g3JWMCUUaXa4u_Q7WcSxpZCY9wYwAEA=.e5de7992-b45f-4d64-87ec-7fc6243601b8@github.com>
 <-w_24oYBK4mkgmt252jiOOUlNB_qyANavids5PHEYgI=.1ad8587a-5187-4b4e-9ef7-8b164b7a8806@github.com>
 <aBBcZtS9QY0zf74yZ9oXybYsg0Vmk8ERqdrKS1Q4yQU=.819d23ff-1c6b-43af-9e8a-2ac5ba5e579b@github.com>
Message-ID: <lUAG3Jb7b1eg_IswXCcPSyo7K3zoGIkYKAt0S7MhnNc=.ce2edaaa-9dda-49e2-bc3e-74e98c94480a@github.com>

On Wed, 26 Jun 2024 11:30:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All suggestions have been fixed, can this PR be integrated? @cl4es  @liach
>
> @wenshao Looks good, thanks for the improvements.
> 
> Let me know when you are finished with your changes.
> Once approved, you should refrain from adding other commits without further approvals.

@rgiulietti 
Thanks for your review. I have completed all the work I wanted to do on this PR. I will not make any changes without further suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19730#issuecomment-2191509819

From asotona at openjdk.org  Wed Jun 26 12:07:12 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Jun 2024 12:07:12 GMT
Subject: RFR: 8334437: De-duplicate ProxyMethod list creation
In-Reply-To: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
References: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
Message-ID: <QQTlS35bE7TJqHjkXBQKVPf_I8lxWvP19tmrhXQ4j88=.5a4bc415-9c6c-41c1-b6ad-030fcd760ee8@github.com>

On Tue, 18 Jun 2024 07:41:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simple refactoring to extract identical, simple lambda expressions. Improve code clarity and reduce classes generated.

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19760#pullrequestreview-2141591212

From syan at openjdk.org  Wed Jun 26 12:20:34 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 12:20:34 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock
 enviroment
Message-ID: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>

Hi all,
Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test.

Only change the testcase, the change has been verified locally, no risk.

-------------

Commit messages:
 - 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment

Changes: https://git.openjdk.org/jdk/pull/19905/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19905&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335150
  Stats: 23 lines in 1 file changed: 15 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19905/head:pull/19905

PR: https://git.openjdk.org/jdk/pull/19905

From jlahoda at openjdk.org  Wed Jun 26 12:37:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Jun 2024 12:37:23 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array
Message-ID: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>

For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.

There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:


enum E {A, B, C}
E e = ...;
switch (e) {
     case null -> {}
     case A a -> {}
     case C c -> {}
     case B b -> {}
}


We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.

The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).

This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).

When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.

I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.

I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:

Benchmark                           Mode  Cnt   Score   Error  Units
SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
SwitchEnum.enumSwitchWithBootstrap  avgt   15  24.668 ? 1.037  ns/op


and with this patch:

Benchmark                           Mode  Cnt   Score   Error  Units
SwitchEnum.enumSwitchTraditional    avgt   15  11.550 ? 0.157  ns/op
SwitchEnum.enumSwitchWithBootstrap  avgt   15  13.225 ? 0.173  ns/op


So, this seems like a clear improvement to me.

-------------

Commit messages:
 - 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array

Changes: https://git.openjdk.org/jdk/pull/19906/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332522
  Stats: 187 lines in 2 files changed: 149 ins; 18 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/19906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19906/head:pull/19906

PR: https://git.openjdk.org/jdk/pull/19906

From liach at openjdk.org  Wed Jun 26 12:39:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 12:39:17 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v5]
In-Reply-To: <L94kTAbSvAWLYlRP870eWS7GD4KSXlyL916kJm7fMCI=.03ea394a-47a3-4ad9-99ea-95b866398af6@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <L94kTAbSvAWLYlRP870eWS7GD4KSXlyL916kJm7fMCI=.03ea394a-47a3-4ad9-99ea-95b866398af6@github.com>
Message-ID: <lqYTkklXHXDKsHOBdzH2Pj0X8PTCJR-aS75TjjZvoPQ=.cb252d68-e6eb-4fe3-bf0b-54682517d409@github.com>

On Wed, 26 Jun 2024 10:08:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - Merge remote-tracking branch 'upstream/master' into 8330954
>  - (C)
>  - (C)
>  - Move security classes changes to pr18373
>  - remove couple extra lines
>  - Pull request is now only about `@since` tags, might add an other commit
>  - add one more `{inheritDoc}` to `CompletableFuture.state`
>  - add `@throws` declarations to javadoc
>  - add ``{@inheritDoc}`` to new javadoc comments
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/6e3c8053...dbef517a

Marked as reviewed by liach (Committer).

src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 44:

> 42:     List<Signature.TypeParam> typeParameters();
> 43: 
> 44:     /** {@return the instantiation of the superclass in this signature}

Suggestion:

    /**
     * {@return the instantiation of the superclass in this signature}

I think this is our preference if we have multi-line specs.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18954#pullrequestreview-2141680174
PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1654739868

From redestad at openjdk.org  Wed Jun 26 12:49:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 12:49:10 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array
In-Reply-To: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
Message-ID: <7kR-zkSZ4D2ddmou4q3caXjH_DF8jxV6betLIv2Hd2o=.60e33d6c-8ef0-46f7-944c-2bf6b94fea90@github.com>

On Wed, 26 Jun 2024 12:32:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
> 
> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
> 
> 
> enum E {A, B, C}
> E e = ...;
> switch (e) {
>      case null -> {}
>      case A a -> {}
>      case C c -> {}
>      case B b -> {}
> }
> 
> 
> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
> 
> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
> 
> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
> 
> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
> 
> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
> 
> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
> 
> Benchmark                           Mode  Cnt   Score   Error  Units
> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
> SwitchEnum.enumSwitchWithBootstrap  avgt   15  24.668 ? 1.037  ...

test/micro/org/openjdk/bench/java/lang/runtime/SwitchEnum.java line 57:

> 55:         for (E e : inputs) {
> 56:             sum += switch (e) {
> 57:                 case null -> -1;

As this `null` case adds a case relative to the `-Traditional` test then maybe removing one of the `E0, E1, ...` cases would make the test a little bit more apples-to-apples?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1654753822

From rgiulietti at openjdk.org  Wed Jun 26 12:53:16 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 26 Jun 2024 12:53:16 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v13]
In-Reply-To: <OS_Zpb7lQn5_-kq7yKCvYQXM-cuqkL59H3uc2rpF2jg=.b1d1d7d4-c18e-40e7-abb4-b49113c1b7f4@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>
 <aKM-WbdLbyfJned-2LkQ6V-G7IfPvqapn2G77re39R8=.4f831602-d8cc-431b-8b05-2a1670a1ef47@github.com>
 <OS_Zpb7lQn5_-kq7yKCvYQXM-cuqkL59H3uc2rpF2jg=.b1d1d7d4-c18e-40e7-abb4-b49113c1b7f4@github.com>
Message-ID: <mgBZXktUUoNPdoo26hEsQxAM1MdwwSDEKTPNz4Quul8=.28d6fcb7-0581-4b25-9fc1-c6e66a9fdd97@github.com>

On Tue, 25 Jun 2024 17:02:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 236:
>> 
>>> 234:                     dk = -1;
>>> 235:                 }
>>> 236:                 return toDecimal(str, index, Q_MIN, t, dk, fd) - start;
>> 
>> I suggest restoring the original logic like so:
>> 
>>                 /* subnormal value */
>>                 return (t < C_TINY
>>                         ? toDecimal(str, index, Q_MIN, 10 * t, -1, fd)
>>                         : toDecimal(str, index, Q_MIN, t, 0, fd)) - start;
>
> I like the new implementation, the code is cleaner, is your suggestion to revert to the original version due to smaller changes?

In principle, you should not arbitrarily change code that is correct, and only limit your changes to reach the goal of the PR.
My suggestion is the minimal change required, yours is more than strictly needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1654762216

From redestad at openjdk.org  Wed Jun 26 13:01:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 13:01:10 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array
In-Reply-To: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
Message-ID: <Tk8mmuhAvtI_Dceiq38MGXmQ1NBpwW_8_Yap25amX0o=.737a6995-339f-4e70-8d80-1b3a1066fe4b@github.com>

On Wed, 26 Jun 2024 12:32:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
> 
> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
> 
> 
> enum E {A, B, C}
> E e = ...;
> switch (e) {
>      case null -> {}
>      case A a -> {}
>      case C c -> {}
>      case B b -> {}
> }
> 
> 
> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
> 
> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
> 
> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
> 
> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
> 
> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
> 
> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
> 
> Benchmark                           Mode  Cnt   Score   Error  Units
> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
> SwitchEnum.enumSwitchWithBootstrap  avgt   15  24.668 ? 1.037  ...

Marked as reviewed by redestad (Reviewer).

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 280:

> 278: 
> 279:         Class<?> enumClass = invocationType.parameterType(0);
> 280:         labels = Stream.of(labels).map(l -> convertEnumConstants(lookup, enumClass, l)).toArray();

You could create `EnumDesc[] enumDescLabels` here and remove the `Arrays.copyOf` on line 290. The `labels.clone()` on line 277 also seem redundant since we only iterate over the `labels` argument once.

While this case is likely fine I generally recommend using a minimal amount of streams/lambdas in bootstrap sensitive code like these dynamic bootstraps methods.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19906#pullrequestreview-2141731748
PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1654771207

From jlahoda at openjdk.org  Wed Jun 26 13:05:11 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Jun 2024 13:05:11 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array
In-Reply-To: <7kR-zkSZ4D2ddmou4q3caXjH_DF8jxV6betLIv2Hd2o=.60e33d6c-8ef0-46f7-944c-2bf6b94fea90@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
 <7kR-zkSZ4D2ddmou4q3caXjH_DF8jxV6betLIv2Hd2o=.60e33d6c-8ef0-46f7-944c-2bf6b94fea90@github.com>
Message-ID: <jZ1FplcUVjHEhuI-OMgExDZKDRf46JRxCTqjNMKUY1w=.8d27a56e-4f8b-458a-a893-abcbfe0cbe4d@github.com>

On Wed, 26 Jun 2024 12:46:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
>> 
>> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
>> 
>> 
>> enum E {A, B, C}
>> E e = ...;
>> switch (e) {
>>      case null -> {}
>>      case A a -> {}
>>      case C c -> {}
>>      case B b -> {}
>> }
>> 
>> 
>> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
>> 
>> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
>> 
>> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
>> 
>> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
>> 
>> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
>> 
>> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
>> 
>> Benchmark                           Mode  Cnt   Score   Error  Units
>> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
>> Swi...
>
> test/micro/org/openjdk/bench/java/lang/runtime/SwitchEnum.java line 57:
> 
>> 55:         for (E e : inputs) {
>> 56:             sum += switch (e) {
>> 57:                 case null -> -1;
> 
> As this `null` case adds a case relative to the `-Traditional` test then maybe removing one of the `E0, E1, ...` cases would make the test a little bit more apples-to-apples?

Using `case null -> ` will push javac to use the new code, but all switches do some kind of null check for the selector value. The difference is that if there's no `case null`, there will be `Objects.requireNonNull` generated for the selector value (which will throw an NPE if the value is `null`), while here it will jump to the given case.

So, `case null` does not have the same weight as a normal case, so I don't think it would be fair to remove a full case to compensate for it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1654784712

From redestad at openjdk.org  Wed Jun 26 13:17:14 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 13:17:14 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v18]
In-Reply-To: <zqQH21YTFDv7OoAzu90gYCUz5lJUWJmLED-v8SdN_JU=.6de3dcd4-117b-4e87-b922-765a343e2969@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <zqQH21YTFDv7OoAzu90gYCUz5lJUWJmLED-v8SdN_JU=.6de3dcd4-117b-4e87-b922-765a343e2969@github.com>
Message-ID: <og7117hLVxWs1l-nfLQN43X4e5f55h8o_xxPWM4V9LA=.c93512f7-1259-426d-973d-47288a4965f6@github.com>

On Tue, 25 Jun 2024 17:29:04 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @liach: use s.getBytes for performance

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 47:

> 45:     static final int NAN         = 5 << 8;
> 46: 
> 47:     static final byte LATIN1 = 0;

I think this somewhat unnecessarily copies names and internal implementation details from `String` (where the `coder` value is used both as a pseudo-boolean and as a shift operand, which is not applicable here). In this context we could use something like `private final boolean latin1;` (all uses of `coder` are just `if (coder == LATIN1)` so it would be simplified to `if (latin1)`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1654812101

From fguallini at openjdk.org  Wed Jun 26 13:19:10 2024
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 26 Jun 2024 13:19:10 GMT
Subject: RFR: 8334562: Automate
 com/sun/security/auth/callback/TextCallbackHandler/Default.java test
In-Reply-To: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
References: <tvKQTJMqR6giKq6XYEURYgwswvz4nj5fak-t58jVhu4=.7ed4b2e6-7846-4958-b3b2-b63ca5231a6a@github.com>
Message-ID: <6S1leYCzb7SNfjp1NR1JJ6hAulsZb7PoJWPf2IJJPXo=.67e840cb-47e7-452a-bc58-cbad308818ae@github.com>

On Wed, 19 Jun 2024 12:47:33 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The following test: **com/sun/security/auth/callback/TextCallbackHandler/Default.java** is currently marked to be run manually because user inputs are required in the console, but instead it can be automated by providing a custom inputStream to System.in in the actual test to simulate sequential user input.
> 
> In addition, this patch is removing the test from the problemList as it passes, and from manual test list.

Please, I would need a review on this PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19790#issuecomment-2191674728

From duke at openjdk.org  Wed Jun 26 13:23:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 13:23:10 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v13]
In-Reply-To: <mgBZXktUUoNPdoo26hEsQxAM1MdwwSDEKTPNz4Quul8=.28d6fcb7-0581-4b25-9fc1-c6e66a9fdd97@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>
 <aKM-WbdLbyfJned-2LkQ6V-G7IfPvqapn2G77re39R8=.4f831602-d8cc-431b-8b05-2a1670a1ef47@github.com>
 <OS_Zpb7lQn5_-kq7yKCvYQXM-cuqkL59H3uc2rpF2jg=.b1d1d7d4-c18e-40e7-abb4-b49113c1b7f4@github.com>
 <mgBZXktUUoNPdoo26hEsQxAM1MdwwSDEKTPNz4Quul8=.28d6fcb7-0581-4b25-9fc1-c6e66a9fdd97@github.com>
Message-ID: <KSDU60ePyc8O9GL3Bu4Ho87PLNsfVYWQ1Ss9x2oBTrs=.eca1dca1-582b-4490-9f2f-d766889fd415@github.com>

On Wed, 26 Jun 2024 12:50:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I like the new implementation, the code is cleaner, is your suggestion to revert to the original version due to smaller changes?
>
> In principle, you should not arbitrarily change code that is correct, and only limit your changes to reach the goal of the PR.
> My suggestion is the minimal change required, yours is more than strictly needed.

Got it, should I change it back?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1654828664

From duke at openjdk.org  Wed Jun 26 13:26:12 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 13:26:12 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v18]
In-Reply-To: <og7117hLVxWs1l-nfLQN43X4e5f55h8o_xxPWM4V9LA=.c93512f7-1259-426d-973d-47288a4965f6@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <zqQH21YTFDv7OoAzu90gYCUz5lJUWJmLED-v8SdN_JU=.6de3dcd4-117b-4e87-b922-765a343e2969@github.com>
 <og7117hLVxWs1l-nfLQN43X4e5f55h8o_xxPWM4V9LA=.c93512f7-1259-426d-973d-47288a4965f6@github.com>
Message-ID: <C7RWd-zewH3afQmKVMwtzBHFzQy54_cb_7ZUMGCF4r0=.1ad96fdf-e26c-4042-86f4-84eee21fbe0b@github.com>

On Wed, 26 Jun 2024 13:14:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   from @liach: use s.getBytes for performance
>
> src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 47:
> 
>> 45:     static final int NAN         = 5 << 8;
>> 46: 
>> 47:     static final byte LATIN1 = 0;
> 
> I think this somewhat unnecessarily copies names and internal implementation details from `String` (where the `coder` value is used both as a pseudo-boolean and as a shift operand, which is not applicable here). In this context we could use something like `private final boolean latin1;` (all uses of `coder` are just `if (coder == LATIN1)` so it would be simplified to `if (latin1)`)

I have written a version using boolean locally, but because this class is mainly used by String and StringBuilder, it uses the same style as String/StringBuilder.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1654832167

From liach at openjdk.org  Wed Jun 26 13:37:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 13:37:12 GMT
Subject: RFR: 8334437: De-duplicate ProxyMethod list creation
In-Reply-To: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
References: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
Message-ID: <AYzbdSk4UqIhySJxCFlOpsjWelNDWOTdVI9pGKReTaY=.beea786c-2b69-4809-aa47-1ca5c973cd49@github.com>

On Tue, 18 Jun 2024 07:41:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simple refactoring to extract identical, simple lambda expressions. Improve code clarity and reduce classes generated.

Marked as reviewed by liach (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19760#pullrequestreview-2141860506

From liach at openjdk.org  Wed Jun 26 13:44:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 13:44:11 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array
In-Reply-To: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
Message-ID: <FG9s6pfdKqhFbKg54nW-GTdFN-35VG3aEgiRa880PV4=.aa6bb18b-de20-49d0-bed0-4af191c781f4@github.com>

On Wed, 26 Jun 2024 12:32:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
> 
> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
> 
> 
> enum E {A, B, C}
> E e = ...;
> switch (e) {
>      case null -> {}
>      case A a -> {}
>      case C c -> {}
>      case B b -> {}
> }
> 
> 
> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
> 
> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
> 
> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
> 
> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
> 
> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
> 
> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
> 
> Benchmark                           Mode  Cnt   Score   Error  Units
> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
> SwitchEnum.enumSwitchWithBootstrap  avgt   15  24.668 ? 1.037  ...

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 336:

> 334:                                 generateTypeSwitch(lookup, enumClass, labels)
> 335:                                         .asType(MethodType.methodType(int.class,
> 336:                                                                       enumClass,

We might have to do `Object.class` so we can call `invokeExact` below

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 426:

> 424:         public volatile int[] constantsMap;
> 425:         @Stable
> 426:         public volatile MethodHandle generatedSwitch;

We probably don't need these 2 volatiles:
1. Arrays are already safely published (See https://bugs.openjdk.org/browse/JDK-8333791?focusedId=14680594&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14680594) and we can only access array elements after the array is fully initialized then published. Thus it's a safe publication, and reads don't require explicit volatile read.
2. `MethodHandle` is immutable and safely published, thus volatile read is redundant as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1654860151
PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1654773322

From rgiulietti at openjdk.org  Wed Jun 26 13:56:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 26 Jun 2024 13:56:11 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v13]
In-Reply-To: <KSDU60ePyc8O9GL3Bu4Ho87PLNsfVYWQ1Ss9x2oBTrs=.eca1dca1-582b-4490-9f2f-d766889fd415@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <LbHRMWz6_i9H166CBVNRMWr-ThQzTu50klsPtkzA80Q=.90b3ce1b-703e-4e76-bffd-cb06316fa115@github.com>
 <aKM-WbdLbyfJned-2LkQ6V-G7IfPvqapn2G77re39R8=.4f831602-d8cc-431b-8b05-2a1670a1ef47@github.com>
 <OS_Zpb7lQn5_-kq7yKCvYQXM-cuqkL59H3uc2rpF2jg=.b1d1d7d4-c18e-40e7-abb4-b49113c1b7f4@github.com>
 <mgBZXktUUoNPdoo26hEsQxAM1MdwwSDEKTPNz4Quul8=.28d6fcb7-0581-4b25-9fc1-c6e66a9fdd97@github.com>
 <KSDU60ePyc8O9GL3Bu4Ho87PLNsfVYWQ1Ss9x2oBTrs=.eca1dca1-582b-4490-9f2f-d766889fd415@github.com>
Message-ID: <Gkni7iqSQV8zAB0JoxzWHUGf4_2hykpo6AAWPe18ET4=.67eb22b9-bda8-488a-867f-1479fd59ac0b@github.com>

On Wed, 26 Jun 2024 13:20:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> In principle, you should not arbitrarily change code that is correct, and only limit your changes to reach the goal of the PR.
>> My suggestion is the minimal change required, yours is more than strictly needed.
>
> Got it, should I change it back?

If there's nothing else, no, there's no need to switch back.

Sorry if I sound pedantic on some principles that I feel are important for the good health of OpenJDK ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1654905660

From redestad at openjdk.org  Wed Jun 26 14:03:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 14:03:12 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v18]
In-Reply-To: <C7RWd-zewH3afQmKVMwtzBHFzQy54_cb_7ZUMGCF4r0=.1ad96fdf-e26c-4042-86f4-84eee21fbe0b@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <zqQH21YTFDv7OoAzu90gYCUz5lJUWJmLED-v8SdN_JU=.6de3dcd4-117b-4e87-b922-765a343e2969@github.com>
 <og7117hLVxWs1l-nfLQN43X4e5f55h8o_xxPWM4V9LA=.c93512f7-1259-426d-973d-47288a4965f6@github.com>
 <C7RWd-zewH3afQmKVMwtzBHFzQy54_cb_7ZUMGCF4r0=.1ad96fdf-e26c-4042-86f4-84eee21fbe0b@github.com>
Message-ID: <xxLdafGVB13rsva7ebCJO0P54VROqsDkS3noy7h6Dko=.fe31c936-45cf-4c95-a7f1-cbe1f8b898dc@github.com>

On Wed, 26 Jun 2024 13:23:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 47:
>> 
>>> 45:     static final int NAN         = 5 << 8;
>>> 46: 
>>> 47:     static final byte LATIN1 = 0;
>> 
>> I think this somewhat unnecessarily copies names and internal implementation details from `String` (where the `coder` value is used both as a pseudo-boolean and as a shift operand, which is not applicable here). In this context we could use something like `private final boolean latin1;` (all uses of `coder` are just `if (coder == LATIN1)` so it would be simplified to `if (latin1)`)
>
> I have written a version using boolean locally, but because this class is mainly used by String and StringBuilder, it uses the same style as String/StringBuilder.

Yeah, I'm just musing about the perils of leaking/replicating those implementation details, but as you say this is internal code only used by `String` and `StringBuilder` to it's loosely part of that complex. Not requesting any changes here for now..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1654924418

From rhalade at openjdk.org  Wed Jun 26 14:17:14 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 26 Jun 2024 14:17:14 GMT
Subject: RFR: 8334441: Mark tests in jdk_security_infra group as manual
 [v2]
In-Reply-To: <wGZSAaOyNa_ihdZyOXe2Wk2p0z-AitonYkxdgH4Ie2g=.8262bc97-3864-4822-8aa9-18c3e39c1197@github.com>
References: <pPDiK9kAeal043pa4hl9XdKkE8i7-r46yZ6GQj9fEUU=.35c3df30-d90a-4c66-a290-75617c413d6c@github.com>
 <sPWTyuJyS3T2RORRSw32xBYgc1hxZQSpJliFLg-4cdw=.b7ba1497-a69f-4f1a-a5cb-de76bc4905ed@github.com>
 <wGZSAaOyNa_ihdZyOXe2Wk2p0z-AitonYkxdgH4Ie2g=.8262bc97-3864-4822-8aa9-18c3e39c1197@github.com>
Message-ID: <RDhfkZcyfOWCgNcR_4w_gtnQiQTQK-gFNug9RntF6OE=.da006239-f38f-41cb-9636-13e3ea503837@github.com>

On Tue, 25 Jun 2024 17:45:23 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Is there still going to be some monitoring of these tests? Making it harder to run these tests potentially means that genuine failures can go unnoticed and JDK certificates are not updated when needed.

Tracking won?t be any different than other manual tests in the test suite. Within Oracle, we recommend that developers working on security libraries fixes run these tests before integration. All manual tests are definitely run during the release certification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19814#issuecomment-2191822556

From duke at openjdk.org  Wed Jun 26 14:20:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 14:20:13 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v18]
In-Reply-To: <xxLdafGVB13rsva7ebCJO0P54VROqsDkS3noy7h6Dko=.fe31c936-45cf-4c95-a7f1-cbe1f8b898dc@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <zqQH21YTFDv7OoAzu90gYCUz5lJUWJmLED-v8SdN_JU=.6de3dcd4-117b-4e87-b922-765a343e2969@github.com>
 <og7117hLVxWs1l-nfLQN43X4e5f55h8o_xxPWM4V9LA=.c93512f7-1259-426d-973d-47288a4965f6@github.com>
 <C7RWd-zewH3afQmKVMwtzBHFzQy54_cb_7ZUMGCF4r0=.1ad96fdf-e26c-4042-86f4-84eee21fbe0b@github.com>
 <xxLdafGVB13rsva7ebCJO0P54VROqsDkS3noy7h6Dko=.fe31c936-45cf-4c95-a7f1-cbe1f8b898dc@github.com>
Message-ID: <k7kPhSSvWH2lOkAW-m7DUq5cbfkc7qdMr9ZaX1fakFA=.64917194-453e-48b0-b242-1c11d8dad810@github.com>

On Wed, 26 Jun 2024 14:00:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I have written a version using boolean locally, but because this class is mainly used by String and StringBuilder, it uses the same style as String/StringBuilder.
>
> Yeah, I'm just musing about the perils of leaking/replicating those implementation details, but as you say this is internal code only used by `String` and `StringBuilder` to it's loosely part of that complex. Not requesting any changes here for now..

I looked at it again and I think @cl4es 's suggestion is correct. Can I submit the change? @rgiulietti

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1654964989

From rgiulietti at openjdk.org  Wed Jun 26 14:25:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 26 Jun 2024 14:25:11 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v18]
In-Reply-To: <k7kPhSSvWH2lOkAW-m7DUq5cbfkc7qdMr9ZaX1fakFA=.64917194-453e-48b0-b242-1c11d8dad810@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <zqQH21YTFDv7OoAzu90gYCUz5lJUWJmLED-v8SdN_JU=.6de3dcd4-117b-4e87-b922-765a343e2969@github.com>
 <og7117hLVxWs1l-nfLQN43X4e5f55h8o_xxPWM4V9LA=.c93512f7-1259-426d-973d-47288a4965f6@github.com>
 <C7RWd-zewH3afQmKVMwtzBHFzQy54_cb_7ZUMGCF4r0=.1ad96fdf-e26c-4042-86f4-84eee21fbe0b@github.com>
 <xxLdafGVB13rsva7ebCJO0P54VROqsDkS3noy7h6Dko=.fe31c936-45cf-4c95-a7f1-cbe1f8b898dc@github.com>
 <k7kPhSSvWH2lOkAW-m7DUq5cbfkc7qdMr9ZaX1fakFA=.64917194-453e-48b0-b242-1c11d8dad810@github.com>
Message-ID: <OSyw2HW5rbwKlZ0nb0wHhdwjA9uqsL1wPWyThUuSywQ=.fbbe893c-df3d-4629-b08f-8ffaa8c65726@github.com>

On Wed, 26 Jun 2024 14:17:47 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Yeah, I'm just musing about the perils of leaking/replicating those implementation details, but as you say this is internal code only used by `String` and `StringBuilder` to it's loosely part of that complex. Not requesting any changes here for now..
>
> I looked at it again and I think @cl4es 's suggestion is correct. Can I submit the change? @rgiulietti

Of course, nothing has been approved as of now.

Since you are preparing a commit anyway, may I ask you to revert back the changes [here](https://github.com/openjdk/jdk/pull/19730#discussion_r1652978056)? Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1654972151

From redestad at openjdk.org  Wed Jun 26 14:42:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 14:42:16 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <P5EVfwztNl3bf7fP5CVb4OELzS7UlSlWBAf1tS1fO_M=.652dc93b-ae91-4d02-87d4-19ab7720fae1@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
 <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
 <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>
 <nIWEJwBl6I1MnZtAftoVz7Nt4_u2p66CvnJghrU2KF4=.bc7f4242-5106-4a17-bd46-9fa500f9d269@github.com>
 <Vc4OgDPfVE7ZtFrp7fWW8QL6ZKpWsaR9EpnPETShlns=.719b479f-611f-4d31-8331-53c53e42089b@github.com>
 <dKtXgrAuwD5ZkbCJYZaCPKgCjgK5Gt_0CIqk0Dp4cBs=.cfb43f8b-fdc1-46b9-add8-1454964313d0@github.com>
 <P5EVfwztNl3bf7fP5CVb4OELzS7UlSlWBAf
 1tS1fO_M=.652dc93b-ae91-4d02-87d4-19ab7720fae1@github.com>
Message-ID: <w6GOcSaCuWSwuZNeSAZ5clgQXuSDiOQLOUsDRbGIT3g=.a0984e80-b16d-4c55-9244-ab05472fc26f@github.com>

On Tue, 25 Jun 2024 17:19:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> I filed:
> 
> [JDK-8335113](https://bugs.openjdk.org/browse/JDK-8335113): C2 MergeStores: allow merging of putChar and other larger stores on smaller array elements

Great! Should we hold off on this optimization and see if we can avoid the need for `Unsafe` here - or go ahead integrating this PR and leave it to JDK-8335113 to revert any no-longer-needed changes made here?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2191878373

From epeter at openjdk.org  Wed Jun 26 14:42:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 26 Jun 2024 14:42:17 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <w6GOcSaCuWSwuZNeSAZ5clgQXuSDiOQLOUsDRbGIT3g=.a0984e80-b16d-4c55-9244-ab05472fc26f@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
 <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
 <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>
 <nIWEJwBl6I1MnZtAftoVz7Nt4_u2p66CvnJghrU2KF4=.bc7f4242-5106-4a17-bd46-9fa500f9d269@github.com>
 <Vc4OgDPfVE7ZtFrp7fWW8QL6ZKpWsaR9EpnPETShlns=.719b479f-611f-4d31-8331-53c53e42089b@github.com>
 <dKtXgrAuwD5ZkbCJYZaCPKgCjgK5Gt_0CIqk0Dp4cBs=.cfb43f8b-fdc1-46b9-add8-1454964313d0@github.com>
 <P5EVfwztNl3bf7fP5CVb4OELzS7UlSlWBAf
 1tS1fO_M=.652dc93b-ae91-4d02-87d4-19ab7720fae1@github.com>
 <w6GOcSaCuWSwuZNeSAZ5clgQXuSDiOQLOUsDRbGIT3g=.a0984e80-b16d-4c55-9244-ab05472fc26f@github.com>
Message-ID: <rk2JOrQEtTdpO4qx5fvCS4P-taFsBb5-vug6icv0kIg=.204d2752-0516-4807-966a-7adafce092de@github.com>

On Wed, 26 Jun 2024 14:38:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @wenshao @cl4es I think this use-case is quite a valid one, and deserves an extension. I filed:
>> 
>> [JDK-8335113](https://bugs.openjdk.org/browse/JDK-8335113): C2 MergeStores: allow merging of putChar and other larger stores on smaller array elements
>
>> I filed:
>> 
>> [JDK-8335113](https://bugs.openjdk.org/browse/JDK-8335113): C2 MergeStores: allow merging of putChar and other larger stores on smaller array elements
> 
> Great! Should we hold off on this optimization and see if we can avoid the need for `Unsafe` here - or go ahead integrating this PR and leave it to JDK-8335113 to revert any no-longer-needed changes made here?

@cl4es I would wait, to be honest. I'm currently quite busy, but I hope I can do something here in the next 2-3 weeks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2191882317

From duke at openjdk.org  Wed Jun 26 14:43:44 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 14:43:44 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v19]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <XmbdXwZ27rxvqTAMpQ8myuCU-0LVdIfuj_qBsPOTg5Q=.89a6852a-8664-4765-9ae6-742108fcfd03@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  1. revert code change.
  2. use boolean latin1.
  3. replace `index++` to `index = `

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/5d3405f9..a3d216dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=17-18

  Stats: 34 lines in 3 files changed: 0 ins; 9 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From redestad at openjdk.org  Wed Jun 26 14:49:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 14:49:13 GMT
Subject: RFR: 8334437: De-duplicate ProxyMethod list creation
In-Reply-To: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
References: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
Message-ID: <Film85JllL3hv_cjN8qZ44LKO1jVKX_TDuQOPNdJ0Ys=.b5bffd44-737d-44b2-a44b-96f4295cccf7@github.com>

On Tue, 18 Jun 2024 07:41:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simple refactoring to extract identical, simple lambda expressions. Improve code clarity and reduce classes generated.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19760#issuecomment-2191894639

From redestad at openjdk.org  Wed Jun 26 14:49:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 14:49:13 GMT
Subject: Integrated: 8334437: De-duplicate ProxyMethod list creation
In-Reply-To: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
References: <4V_LIIg54nbo4o7YkZ_bsGeHYdJ6bjTjycBW9vZMOog=.cabe06f8-86fd-4809-a145-9e727a8e2dbb@github.com>
Message-ID: <ULiapBY6LcD6nWewknLZ8r8MpsAQIzaKPshWPl9VyZI=.5b5ac97d-2664-4e14-9836-1a145b7ece90@github.com>

On Tue, 18 Jun 2024 07:41:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simple refactoring to extract identical, simple lambda expressions. Improve code clarity and reduce classes generated.

This pull request has now been integrated.

Changeset: 5883a20b
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5883a20b822bb8acb719076e4f7abee8403061cb
Stats:     10 lines in 1 file changed: 4 ins; 4 del; 2 mod

8334437: De-duplicate ProxyMethod list creation

Reviewed-by: asotona, liach

-------------

PR: https://git.openjdk.org/jdk/pull/19760

From duke at openjdk.org  Wed Jun 26 14:55:44 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 14:55:44 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v20]
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  1. revert code change.
  2. comment remove space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19730/files
  - new: https://git.openjdk.org/jdk/pull/19730/files/a3d216dd..b4f2d875

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19730&range=18-19

  Stats: 7 lines in 2 files changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19730/head:pull/19730

PR: https://git.openjdk.org/jdk/pull/19730

From syan at openjdk.org  Wed Jun 26 15:30:10 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 15:30:10 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment
In-Reply-To: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
Message-ID: <xmU2rHVHoOrnlw0XHA2viupJ7OQkdb1NLcyFnltIHJU=.309a3313-7e18-41d6-b51b-2334650572eb@github.com>

On Wed, 26 Jun 2024 12:15:33 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test.
> 
> Only change the testcase, the change has been verified locally, no risk.

The GHA test runner report a failure, I think it's unrelated to this PR.

1. linux x86 fastdebug run test `compiler/interpreter/Test6833129.java` crash `oopDesc::size_given_klass`, seems similar to [JDK-8334760](https://bugs.openjdk.org/browse/JDK-8334760)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2191995696

From syan at openjdk.org  Wed Jun 26 15:40:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Jun 2024 15:40:36 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment [v2]
In-Reply-To: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
Message-ID: <J7wuQEgQrJCeqWCr1ZveYXbgqEmmKBjoWHrOXwIj-E8=.4aa0e7d7-5c80-4f2f-9048-4ef5cf95aa15@github.com>

> Hi all,
> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test.
> 
> Only change the testcase, the change has been verified locally, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  add a word throw

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19905/files
  - new: https://git.openjdk.org/jdk/pull/19905/files/54ac1747..8931debe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19905&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19905&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19905/head:pull/19905

PR: https://git.openjdk.org/jdk/pull/19905

From duke at openjdk.org  Wed Jun 26 15:56:12 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 15:56:12 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v18]
In-Reply-To: <OSyw2HW5rbwKlZ0nb0wHhdwjA9uqsL1wPWyThUuSywQ=.fbbe893c-df3d-4629-b08f-8ffaa8c65726@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <zqQH21YTFDv7OoAzu90gYCUz5lJUWJmLED-v8SdN_JU=.6de3dcd4-117b-4e87-b922-765a343e2969@github.com>
 <og7117hLVxWs1l-nfLQN43X4e5f55h8o_xxPWM4V9LA=.c93512f7-1259-426d-973d-47288a4965f6@github.com>
 <C7RWd-zewH3afQmKVMwtzBHFzQy54_cb_7ZUMGCF4r0=.1ad96fdf-e26c-4042-86f4-84eee21fbe0b@github.com>
 <xxLdafGVB13rsva7ebCJO0P54VROqsDkS3noy7h6Dko=.fe31c936-45cf-4c95-a7f1-cbe1f8b898dc@github.com>
 <k7kPhSSvWH2lOkAW-m7DUq5cbfkc7qdMr9ZaX1fakFA=.64917194-453e-48b0-b242-1c11d8dad810@github.com>
 <OSyw2HW5rbwKlZ0nb0wHhdwjA9uqsL1wPWyThUuSywQ=.fbbe893c-df3d-4629-b08f-8ffaa8c65726@github.com>
Message-ID: <YWgEYDCX7jZO7lEA88A2GpSp1gsAiq2N6JZiroU_NFE=.121cc0a2-1a8e-4640-8535-25b53697b01a@github.com>

On Wed, 26 Jun 2024 14:22:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I looked at it again and I think @cl4es 's suggestion is correct. Can I submit the change? @rgiulietti
>
> Of course, nothing has been approved as of now.
> 
> Since you are preparing a commit anyway, may I ask you to revert back the changes [here](https://github.com/openjdk/jdk/pull/19730#discussion_r1652978056)? Thanks.

I have completed all the suggested changes. Please continue to review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1655132555

From nbenalla at openjdk.org  Wed Jun 26 17:07:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 26 Jun 2024 17:07:27 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v6]
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <HZMLvPBwQh4LuAlmkcx-VdofH-9WC6YNrWUuUXR3BBg=.a9215b3c-d581-413c-a36e-9fd7810f4e4b@github.com>

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Add new line when having multi-line doc comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18954/files
  - new: https://git.openjdk.org/jdk/pull/18954/files/dbef517a..91df97f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18954/head:pull/18954

PR: https://git.openjdk.org/jdk/pull/18954

From jlu at openjdk.org  Wed Jun 26 17:13:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Jun 2024 17:13:14 GMT
Subject: Integrated: 8333755: NumberFormat integer only parsing breaks when
 format has suffix
In-Reply-To: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
References: <0ooKw741vH_u28T1VWA1yI6YapgcOXaX0yQ05g-dA0s=.c42f47fe-ae32-4c3e-bd69-34cc466484e8@github.com>
Message-ID: <9QDP4tSqgd3ZSQ7BLnZalzeYvUxpjnZvQe8ilpZ-1Ic=.21634e94-f17b-4213-9073-b5ae21293310@github.com>

On Tue, 11 Jun 2024 17:25:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8333920) which corrects a bug where NumberFormat cannot successfully parse values in integer only mode, when the format expects a suffix.
> 
> For example,
> 
> // a format that expects a currency suffix
> var fmt = NumberFormat.getCurrencyInstance(Locale.FRANCE);
> fmt.setParseIntegerOnly(true);
> failFmt.parse("5,00 ?"); // throws ParseException when you would have expected 5 returned
> 
> 
> When parsing in integer only mode, instead of breaking upon a decimal symbol encounter, we should store the index but continue to fully parse so that we can verify the entire string and increment our position to search for and match the suffix. Upon a successful suffix match, we can then set `ParsePosition.index` back to the stored decimal index.
> 
> It should be noted that CompactNumberFormat did previously have code that would traverse the rest of the String, to allow matching of the suffix. The difference is that NumberFormat returns the index upon decimal symbol encounter, while CompactNumberFormat was implemented to return the index reflected by the entire string traversal. Such differences cannot be standardized due to behavioral compatibility concerns.
> 
> Thus while parsing in integer only, CNF sets index to the `Position.fullPos()`, while DF sets index to the `Position.intPos()`.

This pull request has now been integrated.

Changeset: bffc8484
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bffc8484c32ad6c3205f7cebe4e262a2dc9de57e
Stats:     204 lines in 5 files changed: 102 ins; 34 del; 68 mod

8333755: NumberFormat integer only parsing breaks when format has suffix

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/19664

From nbenalla at openjdk.org  Wed Jun 26 17:14:16 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 26 Jun 2024 17:14:16 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v5]
In-Reply-To: <lqYTkklXHXDKsHOBdzH2Pj0X8PTCJR-aS75TjjZvoPQ=.cb252d68-e6eb-4fe3-bf0b-54682517d409@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <L94kTAbSvAWLYlRP870eWS7GD4KSXlyL916kJm7fMCI=.03ea394a-47a3-4ad9-99ea-95b866398af6@github.com>
 <lqYTkklXHXDKsHOBdzH2Pj0X8PTCJR-aS75TjjZvoPQ=.cb252d68-e6eb-4fe3-bf0b-54682517d409@github.com>
Message-ID: <2CF2J54uumuu3mWVO0aRQuzsvpvb_EzyL-atYj2ofIY=.48966ae1-942a-40be-a287-4e442dad1aa1@github.com>

On Wed, 26 Jun 2024 12:36:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Nizar Benalla 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:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8330954
>>  - Merge remote-tracking branch 'upstream/master' into 8330954
>>  - (C)
>>  - (C)
>>  - Move security classes changes to pr18373
>>  - remove couple extra lines
>>  - Pull request is now only about `@since` tags, might add an other commit
>>  - add one more `{inheritDoc}` to `CompletableFuture.state`
>>  - add `@throws` declarations to javadoc
>>  - add ``{@inheritDoc}`` to new javadoc comments
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/82b51c65...dbef517a
>
> src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 44:
> 
>> 42:     List<Signature.TypeParam> typeParameters();
>> 43: 
>> 44:     /** {@return the instantiation of the superclass in this signature}
> 
> Suggestion:
> 
>     /**
>      * {@return the instantiation of the superclass in this signature}
> 
> I think this is our preference if we have multi-line specs.

Fixed in [91df97f](https://github.com/openjdk/jdk/pull/18954/commits/91df97f7661774bf4f262260e0732507399bce68), Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1655253281

From liach at openjdk.org  Wed Jun 26 17:29:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 17:29:15 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v6]
In-Reply-To: <HZMLvPBwQh4LuAlmkcx-VdofH-9WC6YNrWUuUXR3BBg=.a9215b3c-d581-413c-a36e-9fd7810f4e4b@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <HZMLvPBwQh4LuAlmkcx-VdofH-9WC6YNrWUuUXR3BBg=.a9215b3c-d581-413c-a36e-9fd7810f4e4b@github.com>
Message-ID: <RfDzRu48VB_-rvAqf9M6QcCDZdbGPSC03meOjzTDpow=.7dbdee21-3af6-4a10-bd12-90c6fd3f7ab5@github.com>

On Wed, 26 Jun 2024 17:07:27 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new line when having multi-line doc comment

Marked as reviewed by liach (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18954#pullrequestreview-2142538134

From rgiulietti at openjdk.org  Wed Jun 26 17:32:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 26 Jun 2024 17:32:14 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v20]
In-Reply-To: <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
Message-ID: <S1-PNdUBaMZNqtVUxSCowEa4V29afrYDtqueqs5m81c=.d0a4f087-a8b6-48a7-93c3-ed02150aed57@github.com>

On Wed, 26 Jun 2024 14:55:44 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. revert code change.
>   2. comment remove space

LGTM

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19730#pullrequestreview-2142544887

From liach at openjdk.org  Wed Jun 26 17:34:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 17:34:11 GMT
Subject: RFR: 8335060: ClassCastException after JDK-8294960
In-Reply-To: <MyQRbEQtGTryYU7dN4VmlQshseeptxabnXlV8W8EsQg=.94ce72e1-94bd-45f9-bb13-04821e4a87aa@github.com>
References: <MyQRbEQtGTryYU7dN4VmlQshseeptxabnXlV8W8EsQg=.94ce72e1-94bd-45f9-bb13-04821e4a87aa@github.com>
Message-ID: <ZeWCtgpumWBQznyN_nzg1HKGTgvmwK4NPwUJ14MScPQ=.9eb92fa8-d955-47e4-bbf0-7cf2f142e533@github.com>

On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Conversion of `java.lang.invoke` package to Class-File API is failing to execute method handles with specific type conversion requirements. Root cause is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` implementation. Original code has been matching the types by hash code and it mistakenly appeared to be matching the primitive types.
> 
> This patch fixes `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` and adds tests to better cover `TypeConvertingMethodAdapter` functionality.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by liach (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19898#pullrequestreview-2142548635

From liach at openjdk.org  Wed Jun 26 17:45:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 17:45:12 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v20]
In-Reply-To: <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
Message-ID: <Kzkj19rF4CiEBQnSFyK7WMdPuEB6LEjJM64hJTlyX6I=.00766b51-74e1-4223-ae1b-55eb96623573@github.com>

On Wed, 26 Jun 2024 14:55:44 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. revert code change.
>   2. comment remove space

Changes requested by liach (Committer).

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 194:

> 192:      *     otherwise NON_SPECIAL
> 193:      */
> 194:     private int toDecimal(byte[] str, int index, double v, FormattedFPDecimal fd) {

This `toDecimal` returns packed int with info but the other returns the new index; this is extremely confusing for future readers, especially that they have very similar signatures (difference in signature is in the middle). I recommend making this return a `long` so when it's downcasted to an int, it's just the size (like String concat's coderIndex)

-------------

PR Review: https://git.openjdk.org/jdk/pull/19730#pullrequestreview-2142568839
PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1655287303

From naoto at openjdk.org  Wed Jun 26 17:56:15 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Jun 2024 17:56:15 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v6]
In-Reply-To: <HZMLvPBwQh4LuAlmkcx-VdofH-9WC6YNrWUuUXR3BBg=.a9215b3c-d581-413c-a36e-9fd7810f4e4b@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <HZMLvPBwQh4LuAlmkcx-VdofH-9WC6YNrWUuUXR3BBg=.a9215b3c-d581-413c-a36e-9fd7810f4e4b@github.com>
Message-ID: <zm6P-21k9UV7I5SsYWRnJJLDwmcfnbbuasAaGr84j78=.ef06df37-0245-4be5-9acc-639030a0b034@github.com>

On Wed, 26 Jun 2024 17:07:27 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new line when having multi-line doc comment

Marked as reviewed by naoto (Reviewer).

src/java.base/share/classes/java/text/ChoiceFormat.java line 591:

> 589:     /**
> 590:      * @since 23
> 591:      */

IIUC, this addition will add & inherit the javadoc from `NumberFormat`, which is not the case before. The description for NumberFormat does not fit with ChoiceFormat. Probably that needs to be addressed with a different issue.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18954#pullrequestreview-2142589023
PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1655299166

From naoto at openjdk.org  Wed Jun 26 18:02:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Jun 2024 18:02:13 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v6]
In-Reply-To: <zm6P-21k9UV7I5SsYWRnJJLDwmcfnbbuasAaGr84j78=.ef06df37-0245-4be5-9acc-639030a0b034@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <HZMLvPBwQh4LuAlmkcx-VdofH-9WC6YNrWUuUXR3BBg=.a9215b3c-d581-413c-a36e-9fd7810f4e4b@github.com>
 <zm6P-21k9UV7I5SsYWRnJJLDwmcfnbbuasAaGr84j78=.ef06df37-0245-4be5-9acc-639030a0b034@github.com>
Message-ID: <HgibBYeS227Tp9KwigoZTV9vv__9x-nogCCXkpmYSj4=.a87f590e-8aa2-422c-ab28-015104072222@github.com>

On Wed, 26 Jun 2024 17:53:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add new line when having multi-line doc comment
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 591:
> 
>> 589:     /**
>> 590:      * @since 23
>> 591:      */
> 
> IIUC, this addition will add & inherit the javadoc from `NumberFormat`, which is not the case before. The description for NumberFormat does not fit with ChoiceFormat. Probably that needs to be addressed with a different issue.

My review is for the ChoiceFormat class only. So asking for more Reviews for other area

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1655309499

From nbenalla at openjdk.org  Wed Jun 26 18:08:13 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 26 Jun 2024 18:08:13 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v6]
In-Reply-To: <HgibBYeS227Tp9KwigoZTV9vv__9x-nogCCXkpmYSj4=.a87f590e-8aa2-422c-ab28-015104072222@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <HZMLvPBwQh4LuAlmkcx-VdofH-9WC6YNrWUuUXR3BBg=.a9215b3c-d581-413c-a36e-9fd7810f4e4b@github.com>
 <zm6P-21k9UV7I5SsYWRnJJLDwmcfnbbuasAaGr84j78=.ef06df37-0245-4be5-9acc-639030a0b034@github.com>
 <HgibBYeS227Tp9KwigoZTV9vv__9x-nogCCXkpmYSj4=.a87f590e-8aa2-422c-ab28-015104072222@github.com>
Message-ID: <RAstVrIjklLuiZkB85E1jfCrjCNHZKjKcVmgPky2bWI=.98c14238-cd51-4262-8701-1ff129206c27@github.com>

On Wed, 26 Jun 2024 17:59:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/ChoiceFormat.java line 591:
>> 
>>> 589:     /**
>>> 590:      * @since 23
>>> 591:      */
>> 
>> IIUC, this addition will add & inherit the javadoc from `NumberFormat`, which is not the case before. The description for NumberFormat does not fit with ChoiceFormat. Probably that needs to be addressed with a different issue.
>
> My review is for the ChoiceFormat class only. So asking for more Reviews for other area

Thanks, I will leave this open for a few more days to let more people from the relevant areas review it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1655315793

From nbenalla at openjdk.org  Wed Jun 26 18:11:45 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 26 Jun 2024 18:11:45 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java [v2]
In-Reply-To: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
Message-ID: <eegXVDbCK3NE3hergX3pFItkeyLUi7TM_H9QjBOSv0U=.fa4b5596-4030-436b-b581-3e8ba3faa87d@github.com>

> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files.
> 
> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `<body>` and `<html>`. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file.
> 
> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - use javadoc standards
 - Merge remote-tracking branch 'upstream/master' into naming
 - remove whitespace
 - 8332072: Convert package.html files in `java.naming` to package-info.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19529/files
  - new: https://git.openjdk.org/jdk/pull/19529/files/768eebf5..1826633f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19529&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19529&range=00-01

  Stats: 67137 lines in 1456 files changed: 42388 ins; 18751 del; 5998 mod
  Patch: https://git.openjdk.org/jdk/pull/19529.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19529/head:pull/19529

PR: https://git.openjdk.org/jdk/pull/19529

From nbenalla at openjdk.org  Wed Jun 26 18:11:45 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 26 Jun 2024 18:11:45 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java [v2]
In-Reply-To: <eegXVDbCK3NE3hergX3pFItkeyLUi7TM_H9QjBOSv0U=.fa4b5596-4030-436b-b581-3e8ba3faa87d@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
 <eegXVDbCK3NE3hergX3pFItkeyLUi7TM_H9QjBOSv0U=.fa4b5596-4030-436b-b581-3e8ba3faa87d@github.com>
Message-ID: <RfEBMMdihF3Qu-DF73RnuujZFGBl6TE8nWtacg1I_Cw=.7a8b940e-d73b-41a8-a51e-010ed9be889c@github.com>

On Wed, 26 Jun 2024 18:09:10 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files.
>> 
>> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `<body>` and `<html>`. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file.
>> 
>> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - use javadoc standards
>  - Merge remote-tracking branch 'upstream/master' into naming
>  - remove whitespace
>  - 8332072: Convert package.html files in `java.naming` to package-info.java

I have converted this to use some of the now-current javadoc convetions.

src/java.naming/share/classes/javax/naming/ldap/package-info.java line 200:

> 198:  * if (respCtls != null) {
> 199:  *     // Find the one we want
> 200:  *     for (int i = 0; i < respCtls.length; i++) {

This is the only change that isn't a direct 1:1 conversion, I hope this ok.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19529#pullrequestreview-2142622498
PR Review Comment: https://git.openjdk.org/jdk/pull/19529#discussion_r1655320955

From redestad at openjdk.org  Wed Jun 26 18:34:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 18:34:11 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v20]
In-Reply-To: <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
Message-ID: <wxSuAlYmIOWQwkr4PXwaty7HheTverhQxmEGEXkm0-4=.d773b346-5ee0-4e62-913f-092326baf0d3@github.com>

On Wed, 26 Jun 2024 14:55:44 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. revert code change.
>   2. comment remove space

LGTM2

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19730#pullrequestreview-2142672406

From redestad at openjdk.org  Wed Jun 26 18:45:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 18:45:11 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array
In-Reply-To: <jZ1FplcUVjHEhuI-OMgExDZKDRf46JRxCTqjNMKUY1w=.8d27a56e-4f8b-458a-a893-abcbfe0cbe4d@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
 <7kR-zkSZ4D2ddmou4q3caXjH_DF8jxV6betLIv2Hd2o=.60e33d6c-8ef0-46f7-944c-2bf6b94fea90@github.com>
 <jZ1FplcUVjHEhuI-OMgExDZKDRf46JRxCTqjNMKUY1w=.8d27a56e-4f8b-458a-a893-abcbfe0cbe4d@github.com>
Message-ID: <-659e3wyGoUBD29EcElQ0ZcuM1hFT5NOEjOMTrdpZu0=.64413981-93b1-49ad-a070-fd8c5492973b@github.com>

On Wed, 26 Jun 2024 13:02:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/runtime/SwitchEnum.java line 57:
>> 
>>> 55:         for (E e : inputs) {
>>> 56:             sum += switch (e) {
>>> 57:                 case null -> -1;
>> 
>> As this `null` case adds a case relative to the `-Traditional` test then maybe removing one of the `E0, E1, ...` cases would make the test a little bit more apples-to-apples?
>
> Using `case null -> ` will push javac to use the new code, but all switches do some kind of null check for the selector value. The difference is that if there's no `case null`, there will be `Objects.requireNonNull` generated for the selector value (which will throw an NPE if the value is `null`), while here it will jump to the given case.
> 
> So, `case null` does not have the same weight as a normal case, so I don't think it would be fair to remove a full case to compensate for it.

Fair enough, and I guess ~1.6ns/op is reasonable overhead for the added semantics.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1655364063

From redestad at openjdk.org  Wed Jun 26 19:18:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Jun 2024 19:18:12 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v4]
In-Reply-To: <dKtXgrAuwD5ZkbCJYZaCPKgCjgK5Gt_0CIqk0Dp4cBs=.cfb43f8b-fdc1-46b9-add8-1454964313d0@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <rRR6ZGxH5aJjNqGRiDaX-26lncMaY7NNQS2KV5vyypY=.048b39ca-ba01-479e-b04d-6ac5b1a97cb8@github.com>
 <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com>
 <dDgbpocMLIwGH-pHcNwf5P61UoH4nFLzRoOhWu1xHH0=.9e2f4d37-a352-461a-b965-7f02ff60bf6c@github.com>
 <L8-AAn2z0Jm0CueY3U6nY0vk27Y-CGuSYJ1D2Fw0JJM=.e3eb15e0-6126-48b1-b0a4-21d5697f9385@github.com>
 <x2gdmu7b6kpSmnnitxTEgVI4lECGLd97v-0untHGHXk=.9f68cc4c-9e4e-4db6-8f07-b3ad0713037f@github.com>
 <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com>
 <nIWEJwBl6I1MnZtAftoVz7Nt4_u2p66CvnJghrU2KF4=.bc7f4242-5106-4a17-bd46-9fa500f9d269@github.com>
 <Vc4OgDPfVE7ZtFrp7fWW8QL6ZKpWsaR9EpnPETShlns=.719b479f-611f-4d31-8331-53c53e42089b@github.com>
 <dKtXgrAuwD5ZkbCJYZaCPKgCjgK5Gt_0CIqk0Dp4cBs=.cfb43f8b-fdc1-46b9-add8-1454964313d0@github.com>
Message-ID: <Gyk3gu2j-aZ47ULJjkN-FwjAPMtqz-CKeVjQRvJB56M=.e4756d64-75d1-4957-a311-615666270875@github.com>

On Thu, 20 Jun 2024 14:32:25 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> @cl4es  @wenshao I think we should probably work on `putChar`, or at least figure out what blocks `MergeStore` for `putChar`. Can someone produce a simple stand-alone `.java` file that uses `putChar`, so that I can investigate why `MergeStore` does not work for it?
>> 
>> Otherwise, I agree with @cl4es : the code here may be ok for now, but we would have to revert it again later, should `MergeStore` eventually do the trick.
>
> @eme64 
> 
> simple stand-alone java
> 
> import jdk.internal.misc.Unsafe;
> 
> public class PutCharTest {
>     static final Unsafe UNSAFE = Unsafe.getUnsafe();
> 
>     static void putCharsAt(byte[] val, int index, int c1, int c2, int c3, int c4) {
>         putChar(val, index    , (char)(c1));
>         putChar(val, index + 1, (char)(c2));
>         putChar(val, index + 2, (char)(c3));
>         putChar(val, index + 3, (char)(c4));
>     }
>     
>     static void putChar(byte[] bytes, int index, int c) {
>         UNSAFE.putChar(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1), (char)(c));
>     }
> 
>     static void putChar0(byte[] bytes, int index, int c) {
>         UNSAFE.putByte(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1), (byte)(c));
>         UNSAFE.putByte(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + (index << 1) + 1, (byte)(c << 8));
>     }
> 
>     static void putNull(byte[] bytes, int index) {
>         putCharsAt(bytes, index, 'n', 'u', 'l', 'l');
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 5; i++) {
>             testNull();
>         }
> 
>         System.out.println("done");
>     }
> 
>     private static void testNull() {
>         byte[] bytes = new byte[8192];
> 
>         for (int i = 0; i < 1000; i++) {
>             int index = 0;
>             for (int j = 0; j < 1024; j++) {
>                 putNull(bytes, index);
>                 index += 4;
>             }
>         }
>     }
> }

As long as @wenshao is OK with that I'm happy to let this wait. I'll have limited availability myself in the coming weeks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2192459124

From szaldana at openjdk.org  Wed Jun 26 19:56:09 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 26 Jun 2024 19:56:09 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
Message-ID: <oHP14SokZjuDzI220egHCv4LtiB660VBst_7BGiQ9X0=.9a65df04-b8f3-4766-8c68-2aeed4e632c3@github.com>

On Tue, 25 Jun 2024 13:59:35 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [JDK-8333308](https://bugs.openjdk.org/browse/JDK-8333308) enabling `javap -system` to handle internal class names. 
> 
> Thanks, 
> Sonia

Hi everyone, thanks for taking a look. 

Seeing the challenges involved with creating a jtreg test, what would you recommend as a viable way forward with this patch?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19883#issuecomment-2192516991

From liach at openjdk.org  Wed Jun 26 20:02:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 20:02:09 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
Message-ID: <VGamW2lWhBwiHd2fPrKZqnQKZL7o0Fbi9f1eO-IaM-E=.673d43e4-1c68-415b-b3d1-fd5a6d763ee4@github.com>

On Tue, 25 Jun 2024 13:59:35 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [JDK-8333308](https://bugs.openjdk.org/browse/JDK-8333308) enabling `javap -system` to handle internal class names. 
> 
> Thanks, 
> Sonia

noreg means no regression test. Since we cannot really create a shadow system modules to place alternative class files to render in javap, we probably just don't use a regression test.

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19883#pullrequestreview-2142826727

From jjg at openjdk.org  Wed Jun 26 20:44:12 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 26 Jun 2024 20:44:12 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java [v2]
In-Reply-To: <RfEBMMdihF3Qu-DF73RnuujZFGBl6TE8nWtacg1I_Cw=.7a8b940e-d73b-41a8-a51e-010ed9be889c@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
 <eegXVDbCK3NE3hergX3pFItkeyLUi7TM_H9QjBOSv0U=.fa4b5596-4030-436b-b581-3e8ba3faa87d@github.com>
 <RfEBMMdihF3Qu-DF73RnuujZFGBl6TE8nWtacg1I_Cw=.7a8b940e-d73b-41a8-a51e-010ed9be889c@github.com>
Message-ID: <FvLJK11mHMM4Tgxbk0k_8-YvXquhv8O8c_oJ0516Q9Y=.59942841-ef6f-4101-9fa0-91d03f932c85@github.com>

On Wed, 26 Jun 2024 18:08:21 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - use javadoc standards
>>  - Merge remote-tracking branch 'upstream/master' into naming
>>  - remove whitespace
>>  - 8332072: Convert package.html files in `java.naming` to package-info.java
>
> src/java.naming/share/classes/javax/naming/ldap/package-info.java line 200:
> 
>> 198:  * if (respCtls != null) {
>> 199:  *     // Find the one we want
>> 200:  *     for (int i = 0; i < respCtls.length; i++) {
> 
> This is the only change that isn't a direct 1:1 conversion, I hope this ok.

This seems reasonable for what is an obvious but minor bug

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19529#discussion_r1655501908

From duke at openjdk.org  Wed Jun 26 22:05:11 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 22:05:11 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v20]
In-Reply-To: <Kzkj19rF4CiEBQnSFyK7WMdPuEB6LEjJM64hJTlyX6I=.00766b51-74e1-4223-ae1b-55eb96623573@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
 <Kzkj19rF4CiEBQnSFyK7WMdPuEB6LEjJM64hJTlyX6I=.00766b51-74e1-4223-ae1b-55eb96623573@github.com>
Message-ID: <-EON2g8_r8sMC4BXwbqdyTbRx98DommlRlKPctjZaLc=.f71c184e-b1e0-49ff-9ff4-5f1acefd175d@github.com>

On Wed, 26 Jun 2024 17:42:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. revert code change.
>>   2. comment remove space
>
> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 194:
> 
>> 192:      *     otherwise NON_SPECIAL
>> 193:      */
>> 194:     private int toDecimal(byte[] str, int index, double v, FormattedFPDecimal fd) {
> 
> This `toDecimal` returns packed int with info but the other returns the new index; this is extremely confusing for future readers, especially that they have very similar signatures (difference in signature is in the middle). I recommend making this return a `long` so when it's downcasted to an int, it's just the size (like String concat's coderIndex)

The maximum length of float to decimal is 15, and the maximum length of double to decimal is 24, so one byte is enough. If we use the long return type, we have to add `cast int to long` and `cast long to int` to the code, which is redundant. It will also confuse people, thinking that float to decimal and double to decimal will have a large length, just like the size of string concat, which requires a complete int.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19730#discussion_r1655573216

From duke at openjdk.org  Wed Jun 26 22:10:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 26 Jun 2024 22:10:18 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v13]
In-Reply-To: <F-rioR0rIUORqyBP2vZV3aQaJo9F78NtNGQ11UeZAGw=.61e5fb1b-bbfe-43d8-8946-65a939491821@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <F-rioR0rIUORqyBP2vZV3aQaJo9F78NtNGQ11UeZAGw=.61e5fb1b-bbfe-43d8-8946-65a939491821@github.com>
Message-ID: <82UtTKfixQpdRpoE6p1-bZYHNAjA0H1btVh9aI3UVfM=.2adb4948-de62-42e4-b954-91f331f86520@github.com>

On Sun, 23 Jun 2024 08:47:25 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   private static final field `UNSAFE`

Optimizing in C2 is a better approach and worth waiting for.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2192703305

From naoto at openjdk.org  Wed Jun 26 22:11:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Jun 2024 22:11:18 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v12]
In-Reply-To: <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>
Message-ID: <ahiilI_Y99mpiCegFQB1GMWOK9ysTznCi2LzNBLXI4Y=.cde56509-4e11-4b7c-b3a5-479506164233@github.com>

On Wed, 26 Jun 2024 09:43:32 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Thanks for the changes. Since this is a performance improvement, I also would like to have the microbenchmark that you used as the test case.

src/java.base/share/classes/java/text/Format.java line 427:

> 425:     /**
> 426:      * Used to distinguish JDK internal subclass and user-defined subclass
> 427:      * of {code Format}.

There are a lot of places which is missing `@` for `code` tag in the comments.

src/java.base/share/classes/java/text/Format.java line 434:

> 432:     boolean isInternalSubclass() {
> 433:         return false;
> 434:     }

Do we need this? Should comparing the package name with 'java.text' be sufficient?

src/java.base/share/classes/java/text/Format.java line 438:

> 436:     /**
> 437:      * StringBuf is the minimal common interface of {code StringBuffer} and {code StringBuilder}.
> 438:      * It used by the various {code Format} implementations as the internal string buffer.

typo: "is" is missing

src/java.base/share/classes/java/text/Format.java line 440:

> 438:      * It used by the various {code Format} implementations as the internal string buffer.
> 439:      */
> 440:     interface StringBuf {

Can we make it `sealed`?

src/java.base/share/classes/java/text/ListFormat.java line 365:

> 363:             return format(input, new StringBuffer(),
> 364:                     DontCareFieldPosition.INSTANCE).toString();
> 365:         }

Since `ListFormat` is a final class, no need to have a condition, always use StringBuilder version.

src/java.base/share/classes/java/text/StringBufFactory.java line 35:

> 33:  * a better performance.
> 34:  */
> 35: final class StringBufFactory {

Add a private no-arg constructor so that no instance can be created for `StringBufFactory` itself.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2143027077
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655560390
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655563089
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655565976
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655559020
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655566915
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655571771

From liach at openjdk.org  Wed Jun 26 22:55:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 22:55:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v12]
In-Reply-To: <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>
Message-ID: <BnpC_nGeLdTioGYj43a9GO2RIOY2PqUWkOxqiih2RcE=.fe95c1fd-d0c1-4294-9ff7-a7f94ecc4499@github.com>

On Wed, 26 Jun 2024 09:43:32 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

src/java.base/share/classes/java/text/Format.java line 193:

> 191: 
> 192:     StringBuilder format(Object obj,
> 193:                          StringBuilder toAppendTo,

Can we change this type to `StringBuf`, like `StringBuf format(Object obj, StringBuf toAppendTo, FieldPosition pos)`? Then we can remove a few `StringBuilder` overloads by just using the `StringBuf` version.

src/java.base/share/classes/java/text/NumberFormat.java line 424:

> 422: 
> 423:     StringBuilder format(double number,
> 424:                          StringBuilder toAppendTo,

Same remark, `StringBuf format(double number, StringBuf toAppendTo, FieldPosition pos)`

src/java.base/share/classes/java/text/SimpleDateFormat.java line 1034:

> 1032:     @Override
> 1033:     public AttributedCharacterIterator formatToCharacterIterator(Object obj) {
> 1034:         StringBuilder sb = new StringBuilder();

On second thought, we can just make this `StringBuf sb = StringBufFactory.of(new StringBuilder())` - or just add `StringBufFactory.of()` which defaults to create a StringBuilder-backed buf.

src/java.base/share/classes/java/text/SimpleDateFormat.java line 1448:

> 1446:         numberFormat.setMaximumIntegerDigits(maxDigits);
> 1447:         if (buffer.isProxyStringBuilder()) {
> 1448:             numberFormat.format((long)value, buffer.asStringBuilder(), DontCareFieldPosition.INSTANCE);

This `numberFormat` might be a user class; if that's the case, we might do something like:

if (buffer.isProxyStringBuilder()) {
    var nf = numberFormat; // field is protected, users can change it even with races!
    if (nf.isInternalSubclass()) {
        nf.format((long)value, buffer.asStringBuilder(), DontCareFieldPosition.INSTANCE);
    } else {
        // format to stringbuffer, and add that buffer to the builder
        buffer.append(nf.format((long)value, new StringBuffer(), DontCareFieldPosition.INSTANCE));
    }
} else { // existing code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655595282
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655596623
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655605616
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1655603917

From liach at openjdk.org  Thu Jun 27 05:16:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jun 2024 05:16:15 GMT
Subject: RFR: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal [v20]
In-Reply-To: <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
 <U0RWtpaQqJjo0NJXs-QVMPU5vqqaHB80D1lq5GavRig=.6f628c67-28b6-4e18-8cda-1d65314e0b74@github.com>
Message-ID: <LoqqiAqZ5WrSRptIqlMDk6nUSFgamnb0YIqSPVdcUm4=.2ad08588-6946-4d1f-aa0d-f905c953c1bb@github.com>

On Wed, 26 Jun 2024 14:55:44 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
>> 
>> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
>> 
>> The following code comments the allocated objects to be removed.
>> 
>> 
>> class FloatToDecimal {
>>     public static String toString(float v) {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(float v, Appendable app)
>>             throws IOException {
>>         // allocate object FloatToDecimal
>>         return new FloatToDecimal().appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(float v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>                 if (app instanceof StringBuilder builder) {
>>                     return builder.append(chars);
>>                 }
>>                 if (app instanceof StringBuffer buffer) {
>>                     return buffer.append(chars);
>>                 }
>>                 for (char c : chars) {
>>                     app.append(c);
>>                 }
>>                 return app;
>>             // ...
>>         }
>>     }
>> }
>> 
>> class DoubleToDecimal {
>>     public static String toString(double v) {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).toDecimalString(v);
>>     }
>> 
>>     public static Appendable appendTo(double v, Appendable app)
>>             throws IOException {
>>         // allocate object DoubleToDecimal
>>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>>     }
>> 
>>     private Appendable appendDecimalTo(double v, Appendable app)
>>             throws IOException {
>>         switch (toDecimal(v, null)) {
>>             case NON_SPECIAL:
>>                 // allocate object char[]
>>                 char[] chars = new char[index + 1];
>>                 for (int i = 0; i < chars.length; ++i) {
>>                     chars[i] = (char) bytes[i];
>>                 }
>>             ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. revert code change.
>   2. comment remove space

Tier 1-3 tests look good. Thanks Wen Shaojin!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19730#issuecomment-2193714370

From duke at openjdk.org  Thu Jun 27 05:16:17 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 27 Jun 2024 05:16:17 GMT
Subject: Integrated: 8334328: Reduce object allocation for FloatToDecimal and
 DoubleToDecimal
In-Reply-To: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
References: <I_nUj_dLjWAKwyY2G0R23sSajiUigWEcYfLFRQDJh9U=.5a93d8e8-c886-4922-a212-7d55ff066903@github.com>
Message-ID: <lw_Jk2B2heBP_p-UflqBEKBZwITgQv3cqjZw7wPim0A=.e8c54ef6-cdfe-444c-adfd-2f2cc3a10c0e@github.com>

On Sat, 15 Jun 2024 01:59:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current versions of FloatToDecimal and DoubleToDecimal allocate additional objects. Reducing these allocations can improve the performance of Float/Double.toString and AbstractStringBuilder's append(float/double).
> 
> This patch is just a code refactoring to reduce object allocation, but does not change the Float/Double to decimal algorithm.
> 
> The following code comments the allocated objects to be removed.
> 
> 
> class FloatToDecimal {
>     public static String toString(float v) {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(float v, Appendable app)
>             throws IOException {
>         // allocate object FloatToDecimal
>         return new FloatToDecimal().appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(float v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>                 if (app instanceof StringBuffer buffer) {
>                     return buffer.append(chars);
>                 }
>                 for (char c : chars) {
>                     app.append(c);
>                 }
>                 return app;
>             // ...
>         }
>     }
> }
> 
> class DoubleToDecimal {
>     public static String toString(double v) {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).toDecimalString(v);
>     }
> 
>     public static Appendable appendTo(double v, Appendable app)
>             throws IOException {
>         // allocate object DoubleToDecimal
>         return new DoubleToDecimal(false).appendDecimalTo(v, app);
>     }
> 
>     private Appendable appendDecimalTo(double v, Appendable app)
>             throws IOException {
>         switch (toDecimal(v, null)) {
>             case NON_SPECIAL:
>                 // allocate object char[]
>                 char[] chars = new char[index + 1];
>                 for (int i = 0; i < chars.length; ++i) {
>                     chars[i] = (char) bytes[i];
>                 }
>                 if (app instanceof StringBuilder builder) {
>                     return builder.append(chars);
>                 }
>               ...

This pull request has now been integrated.

Changeset: 9d20b58f
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d20b58f40275002afa0348d94d5592a26894e88
Stats:     613 lines in 5 files changed: 264 ins; 212 del; 137 mod

8334328: Reduce object allocation for FloatToDecimal and DoubleToDecimal

Reviewed-by: redestad, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/19730

From jlu at openjdk.org  Thu Jun 27 05:36:17 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Jun 2024 05:36:17 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v12]
In-Reply-To: <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>
Message-ID: <s01aPch5oEG1X1JS5FxWoBG2jT43Qvk6O312zkRQk-M=.82c11e99-be6f-49cc-868b-26b8842fc8c6@github.com>

On Wed, 26 Jun 2024 09:43:32 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

Thanks for all the updates. Looks good to me pending the other's comments.

(BTW, the benchmark can go to -> _test/micro/org/openjdk/bench/java/text/_ as opposed to _test/jdk/java/text_)

src/java.base/share/classes/java/text/CompactNumberFormat.java line 569:

> 567:     @Override
> 568:     StringBuilder format(Object number,
> 569:                                      StringBuilder toAppendTo,

nit: indentation seems odd here/not consistent with the other corresponding method.

src/java.base/share/classes/java/text/SimpleDateFormat.java line 1330:

> 1328: 
> 1329:             int num = (value / 60) * 100 + (value % 60);
> 1330:             if (buffer.isProxyStringBuilder()) {

If we made the implementations of `StringBuf` records, we could use record patterns and do away with the `isProxyStringBuilder()` method. Although we would have to change the visibility of the implementations, so maybe not...

src/java.base/share/classes/java/text/StringBufFactory.java line 29:

> 27: 
> 28: /**
> 29:  * StringBufFactory create {code Format.StringBuf}'s implements that

Nit: Just to improve some grammar, how about something like,


 * {@code StringBufFactory} creates implementations of {@code Format.StringBuf},
 * which is an interface with the minimum overlap required to support {@code StringBuffer}
 * and {@code StringBuilder} in {@code Format}. This allows for {@code StringBuilder} to be used
 * in place of {@code StringBuffer} to provide performance benefits for JDK internal 
 * {@code Format} subclasses.

src/java.base/share/classes/java/text/StringBufFactory.java line 37:

> 35: final class StringBufFactory {
> 36: 
> 37:     static Format.StringBuf of(StringBuffer sb) {

At least for the factory class, let's just `import java.text.Format.StringBuf;`, so we don't have to use the full name everywhere.

src/java.base/share/classes/java/text/StringBufFactory.java line 45:

> 43:     }
> 44: 
> 45:     private static class StringBufferImpl implements Format.StringBuf {

The implementations may be more concise as a `record class`

-------------

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2144190566
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1656424171
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1656446980
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1656412306
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1656413186
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1656420349

From stuefe at openjdk.org  Thu Jun 27 05:42:10 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 27 Jun 2024 05:42:10 GMT
Subject: RFR: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
Message-ID: <86LJvkNFwp3NaoiaijH5OTQ-vbvn-wVvneviAln1KDo=.3e806320-53fe-4884-89cc-67070d3736fd@github.com>

On Tue, 25 Jun 2024 13:59:35 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [JDK-8333308](https://bugs.openjdk.org/browse/JDK-8333308) enabling `javap -system` to handle internal class names. 
> 
> Thanks, 
> Sonia

+1

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19883#pullrequestreview-2144277865

From aefimov at openjdk.org  Thu Jun 27 10:38:14 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 27 Jun 2024 10:38:14 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java [v2]
In-Reply-To: <eegXVDbCK3NE3hergX3pFItkeyLUi7TM_H9QjBOSv0U=.fa4b5596-4030-436b-b581-3e8ba3faa87d@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
 <eegXVDbCK3NE3hergX3pFItkeyLUi7TM_H9QjBOSv0U=.fa4b5596-4030-436b-b581-3e8ba3faa87d@github.com>
Message-ID: <oubR0VYjzHiC9Jvs8cwX0ARLvN3743FJL-P1zHC5Zsg=.47e0d27a-139a-4627-97c5-65ff66afe4ed@github.com>

On Wed, 26 Jun 2024 18:11:45 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files.
>> 
>> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `<body>` and `<html>`. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file.
>> 
>> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - use javadoc standards
>  - Merge remote-tracking branch 'upstream/master' into naming
>  - remove whitespace
>  - 8332072: Convert package.html files in `java.naming` to package-info.java

src/java.naming/share/classes/javax/naming/ldap/spi/package-info.java line 29:

> 27:  *
> 28:  * Extends the {@code javax.naming.ldap} package to provide the classes
> 29:  * and interfaces for the Service Provider Interface (SPI) for LDAP

The?`javax.naming.ldap.spi`?package only contains SPI classes that can customize DNS lookups when performing LDAP operations. It was added by [JDK-8160768](https://bugs.openjdk.org/browse/JDK-8160768)/[CSR](https://bugs.openjdk.org/browse/JDK-8192975).  
Since the package only contains classes related to this SPI maybe we could change the wording to something like this:
Suggestion:

 * Provides the Service Provider Interface for DNS lookups when
 * performing LDAP operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19529#discussion_r1656892104

From aefimov at openjdk.org  Thu Jun 27 10:38:11 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 27 Jun 2024 10:38:11 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java [v2]
In-Reply-To: <FvLJK11mHMM4Tgxbk0k_8-YvXquhv8O8c_oJ0516Q9Y=.59942841-ef6f-4101-9fa0-91d03f932c85@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
 <eegXVDbCK3NE3hergX3pFItkeyLUi7TM_H9QjBOSv0U=.fa4b5596-4030-436b-b581-3e8ba3faa87d@github.com>
 <RfEBMMdihF3Qu-DF73RnuujZFGBl6TE8nWtacg1I_Cw=.7a8b940e-d73b-41a8-a51e-010ed9be889c@github.com>
 <FvLJK11mHMM4Tgxbk0k_8-YvXquhv8O8c_oJ0516Q9Y=.59942841-ef6f-4101-9fa0-91d03f932c85@github.com>
Message-ID: <BfZwMBYaiM9QyjybOc5f6ccrhhpO5HHUeBPMAWWOSJI=.ea0bae2b-060d-4893-a6b5-5157ed2a96c1@github.com>

On Wed, 26 Jun 2024 20:41:56 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.naming/share/classes/javax/naming/ldap/package-info.java line 200:
>> 
>>> 198:  * if (respCtls != null) {
>>> 199:  *     // Find the one we want
>>> 200:  *     for (int i = 0; i < respCtls.length; i++) {
>> 
>> This is the only change that isn't a direct 1:1 conversion, I hope this ok.
>
> This seems reasonable for what is an obvious but minor bug

The change looks correct to me too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19529#discussion_r1656893835

From duke at openjdk.org  Thu Jun 27 11:09:27 2024
From: duke at openjdk.org (lingjun-cg)
Date: Thu, 27 Jun 2024 11:09:27 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v13]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <pimwJozMjJsQUuRHx9p8v9uVDe6Z99NYlhXSJMnwu_s=.99fe2290-0999-451d-81dc-fc91f75b974b@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:

  8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/7eb9b523..f1b88f36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=11-12

  Stats: 247 lines in 11 files changed: 78 ins; 63 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From duke at openjdk.org  Thu Jun 27 11:22:14 2024
From: duke at openjdk.org (lingjun-cg)
Date: Thu, 27 Jun 2024 11:22:14 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v12]
In-Reply-To: <s01aPch5oEG1X1JS5FxWoBG2jT43Qvk6O312zkRQk-M=.82c11e99-be6f-49cc-868b-26b8842fc8c6@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>
 <s01aPch5oEG1X1JS5FxWoBG2jT43Qvk6O312zkRQk-M=.82c11e99-be6f-49cc-868b-26b8842fc8c6@github.com>
Message-ID: <YYiDb-IxmJRJaavH2u5Qu_l92EkKuLPg4sbOSFOjaOg=.7c3544c6-1d3e-44c8-bc95-5b3ce5d9c017@github.com>

On Thu, 27 Jun 2024 05:08:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/StringBufFactory.java line 45:
> 
>> 43:     }
>> 44: 
>> 45:     private static class StringBufferImpl implements Format.StringBuf {
> 
> The implementations may be more concise as a `record class`

I know little about `record class`, it seems `record class` is help to model data aggregation, but here it act as a proxy class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1656957129

From duke at openjdk.org  Thu Jun 27 12:04:35 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 27 Jun 2024 12:04:35 GMT
Subject: RFR: 8335252: Use ImmutableBitSetPredicate optimize
 j.u.Formatter.Conversion#isValid
Message-ID: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>

Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.

use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:

@ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big


current version

@ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
  @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)

-------------

Commit messages:
 - use ImmutableBitSetPredicate optimize Formatter.Conversion#isValid

Changes: https://git.openjdk.org/jdk/pull/19926/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19926&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335252
  Stats: 36 lines in 1 file changed: 12 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/19926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19926/head:pull/19926

PR: https://git.openjdk.org/jdk/pull/19926

From duke at openjdk.org  Thu Jun 27 12:04:35 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 27 Jun 2024 12:04:35 GMT
Subject: RFR: 8335252: Use ImmutableBitSetPredicate optimize
 j.u.Formatter.Conversion#isValid
In-Reply-To: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
Message-ID: <InV5Bc5S8sz2vBb_mYcxNOdC7PYctKrEEfyi4pekKFg=.45450125-dcd0-4817-b4fb-c6ebabac20f0@github.com>

On Thu, 27 Jun 2024 11:14:30 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
> 
> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
> 
> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
> 
> 
> current version
> 
> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)

@cl4es This is a scenario optimized using ImmutableBitSetPredicate

Execute the following command, we can see that the `java.util.Formatter$Conversion.isValid` method generates a tableswitch of size 85. This large tableswitch makes the code size 358 bytes. Can C2 be optimized to use `jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate`?


javap -c java.util.Formatter.Conversion


* byte codes of `Conversion.isValid`

static boolean isValid(char);
    Code:
       0: iload_0
       1: tableswitch   { // 37 to 120
                    37: 352
                    38: 356
                    39: 356
                    40: 356
                    41: 356
                    42: 356
                    43: 356
                    44: 356
                    45: 356
                    46: 356
                    47: 356
                    48: 356
                    49: 356
                    50: 356
                    51: 356
                    52: 356
                    53: 356
                    54: 356
                    55: 356
                    56: 356
                    57: 356
                    58: 356
                    59: 356
                    60: 356
                    61: 356
                    62: 356
                    63: 356
                    64: 356
                    65: 352
                    66: 352
                    67: 352
                    68: 356
                    69: 352
                    70: 356
                    71: 352
                    72: 352
                    73: 356
                    74: 356
                    75: 356
                    76: 356
                    77: 356
                    78: 356
                    79: 356
                    80: 356
                    81: 356
                    82: 356
                    83: 352
                    84: 356
                    85: 356
                    86: 356
                    87: 356
                    88: 352
                    89: 356
                    90: 356
                    91: 356
                    92: 356
                    93: 356
                    94: 356
                    95: 356
                    96: 356
                    97: 352
                    98: 352
                    99: 352
                   100: 352
                   101: 352
                   102: 352
                   103: 352
                   104: 352
                   105: 356
                   106: 356
                   107: 356
                   108: 356
                   109: 356
                   110: 352
                   111: 352
                   112: 356
                   113: 356
                   114: 356
                   115: 352
                   116: 356
                   117: 356
                   118: 356
                   119: 356
                   120: 352
               default: 356
          }
     352: iconst_1
     353: goto          357
     356: iconst_0
     357: ireturn

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2194416329
PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2194470276

From redestad at openjdk.org  Thu Jun 27 12:23:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 27 Jun 2024 12:23:09 GMT
Subject: RFR: 8335252: Use ImmutableBitSetPredicate optimize
 j.u.Formatter.Conversion#isValid
In-Reply-To: <InV5Bc5S8sz2vBb_mYcxNOdC7PYctKrEEfyi4pekKFg=.45450125-dcd0-4817-b4fb-c6ebabac20f0@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <InV5Bc5S8sz2vBb_mYcxNOdC7PYctKrEEfyi4pekKFg=.45450125-dcd0-4817-b4fb-c6ebabac20f0@github.com>
Message-ID: <mgcRjnoCQU9X7n3h49cm3o9gpzX6gFglSHoR5cooBzg=.1fb8770c-6c1a-472a-96fb-a2a8c33cbcbd@github.com>

On Thu, 27 Jun 2024 11:48:56 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> * byte codes of `Conversion.isValid`

It's surprising that javac generates synthetic cases identical to the default case for every char in the 37 to 120 range (the bounds seem to be the lowest and highest of the constants). 

Is there a benchmark where you see a benefit from this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2194540522

From redestad at openjdk.org  Thu Jun 27 12:31:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 27 Jun 2024 12:31:20 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
Message-ID: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>

This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
(only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 

Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):


Name                                    Cnt     Base     Error      Test     Error  Unit  Change
StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
StringConcat.concatMix4String            50   89.243 ?   0.436    71.866 ?   0.894 ns/op   1.24x (p = 0.000*)
StringConcatStartup.MixedLarge.run       10  655.436 ?  29.787   649.730 ?  26.053 ms/op   1.01x (p = 0.500 )
StringConcatStartup.MixedSmall.run       20   51.676 ?   2.324    50.724 ?   5.050 ms/op   1.02x (p = 0.512 )
StringConcatStartup.StringLarge.run      10  166.022 ?  15.672   165.300 ?  14.433 ms/op   1.00x (p = 0.873 )
StringConcatStartup.StringSingle.run     40    0.168 ?   0.016     0.178 ?   0.024 ms/op   0.94x (p = 0.234 )
* = significant


Startup-wise it's more or less neutral as evidenced by the added `StringConcatStartup` micro (a simplified and JMH:ified version of some startup stress tests I've been tinkering with over the years). This PR does not change the total number of classes generated and loaded by this test (3359 total, 2499 generated).

-------------

Commit messages:
 - Add StringConcatStartup JMH
 - Merge branch 'master' into consolidated_prependers
 - Simplify
 - Remove getBytes changes
 - Streamline newArray
 - Consolidate to always end with newArrayWithSuffix
 - Merge branch 'master' into consolidated_prependers
 - Streamline prependers
 - Fix compilation errors from removing non-prefixed prepend methods
 - Remove non-prefix prepender methods, inline logic into prefixed variant
 - ... and 1 more: https://git.openjdk.org/jdk/compare/efb905e5...6525e945

Changes: https://git.openjdk.org/jdk/pull/19927/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19927&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335182
  Stats: 565 lines in 6 files changed: 412 ins; 114 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/19927.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19927/head:pull/19927

PR: https://git.openjdk.org/jdk/pull/19927

From szaldana at openjdk.org  Thu Jun 27 13:25:15 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 27 Jun 2024 13:25:15 GMT
Subject: Integrated: 8333308: javap --system handling doesn't work on internal
 class names
In-Reply-To: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
References: <ArSyDIcPYcdbfNJXGLw1yrfujzsrarUrneGiCZ9JpDs=.3c374b71-a9a2-498d-b148-acf9202a5d94@github.com>
Message-ID: <4j_v_2XykFsR69HV4C9-9-s1wkIuANhlGi7DrQbv8SE=.4b71ced0-285c-4b4b-8401-00cd6f79348e@github.com>

On Tue, 25 Jun 2024 13:59:35 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [JDK-8333308](https://bugs.openjdk.org/browse/JDK-8333308) enabling `javap -system` to handle internal class names. 
> 
> Thanks, 
> Sonia

This pull request has now been integrated.

Changeset: d5375c7d
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5375c7db658de491c1f5bad053040d21b82941e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8333308: javap --system handling doesn't work on internal class names

Reviewed-by: liach, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/19883

From jlahoda at openjdk.org  Thu Jun 27 13:41:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 27 Jun 2024 13:41:15 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v9]
In-Reply-To: <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
Message-ID: <NHcp9qA3EJx-dHLRCfUuetkINfxnk4qYeJvLdZ_lKyc=.de10ea34-b166-4b31-b824-19eb453491d9@github.com>

On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   de-dupe on path, not module name

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2145411864

From jlahoda at openjdk.org  Thu Jun 27 14:06:42 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 27 Jun 2024 14:06:42 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array [v2]
In-Reply-To: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
Message-ID: <pn53yPWi1IdWZ5SkMT_5NL6WimV5Hio6-m1-hb61tOA=.c7f5f2ab-11c3-492b-9db0-83d7395e17a7@github.com>

> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
> 
> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
> 
> 
> enum E {A, B, C}
> E e = ...;
> switch (e) {
>      case null -> {}
>      case A a -> {}
>      case C c -> {}
>      case B b -> {}
> }
> 
> 
> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
> 
> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
> 
> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
> 
> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
> 
> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
> 
> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
> 
> Benchmark                           Mode  Cnt   Score   Error  Units
> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
> SwitchEnum.enumSwitchWithBootstrap  avgt   15  24.668 ? 1.037  ...

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19906/files
  - new: https://git.openjdk.org/jdk/pull/19906/files/8ab9ee64..79b3a76f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=00-01

  Stats: 17 lines in 1 file changed: 9 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19906/head:pull/19906

PR: https://git.openjdk.org/jdk/pull/19906

From duke at openjdk.org  Thu Jun 27 14:12:36 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 27 Jun 2024 14:12:36 GMT
Subject: RFR: 8335252: Use ImmutableBitSetPredicate optimize
 j.u.Formatter.Conversion#isValid [v2]
In-Reply-To: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
Message-ID: <6al-jx7cKio1G4swwQ9W_FXrtOnqFNbnTNUrzEPczFA=.1af6db38-f7a5-41df-9092-bd754cdae0cf@github.com>

> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
> 
> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
> 
> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
> 
> 
> current version
> 
> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  revert & use `@ForceInline`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19926/files
  - new: https://git.openjdk.org/jdk/pull/19926/files/fb5c8001..d2bebbdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19926&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19926&range=00-01

  Stats: 59 lines in 1 file changed: 23 ins; 32 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19926/head:pull/19926

PR: https://git.openjdk.org/jdk/pull/19926

From duke at openjdk.org  Thu Jun 27 14:16:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 27 Jun 2024 14:16:10 GMT
Subject: RFR: 8335252: Use ImmutableBitSetPredicate optimize
 j.u.Formatter.Conversion#isValid [v2]
In-Reply-To: <6al-jx7cKio1G4swwQ9W_FXrtOnqFNbnTNUrzEPczFA=.1af6db38-f7a5-41df-9092-bd754cdae0cf@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <6al-jx7cKio1G4swwQ9W_FXrtOnqFNbnTNUrzEPczFA=.1af6db38-f7a5-41df-9092-bd754cdae0cf@github.com>
Message-ID: <zkowNn8igfIgTfKu2beeMI1_W-No-RaKmRsijVfYJKs=.68cf35b4-f695-4b91-92cb-6a5d1f796fe6@github.com>

On Thu, 27 Jun 2024 14:12:36 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert & use `@ForceInline`

I found using @ForceInline gave me better performance with smaller code changes,

Here are the performance numbers running on Mac M1 Max:

# baseline
Benchmark                     Mode  Cnt   Score   Error  Units
StringFormat.stringIntFormat  avgt   15  93.299 ? 1.268  ns/op

# WebRevs 00 fb5c8001
Benchmark                     Mode  Cnt   Score   Error  Units
StringFormat.stringIntFormat  avgt   15  89.164 ? 2.188  ns/op

# ForceInline
Benchmark                     Mode  Cnt   Score   Error  Units
StringFormat.stringIntFormat  avgt   15  84.473 ? 4.287  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2194818165

From liach at openjdk.org  Thu Jun 27 15:28:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jun 2024 15:28:11 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array [v2]
In-Reply-To: <pn53yPWi1IdWZ5SkMT_5NL6WimV5Hio6-m1-hb61tOA=.c7f5f2ab-11c3-492b-9db0-83d7395e17a7@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
 <pn53yPWi1IdWZ5SkMT_5NL6WimV5Hio6-m1-hb61tOA=.c7f5f2ab-11c3-492b-9db0-83d7395e17a7@github.com>
Message-ID: <76XBUWAY8CtVyCl9czJYLdCZWkxT3PeeRZ9fBAdjjZc=.46b32d3d-501b-4b47-95e9-05af2dc7ca1b@github.com>

On Thu, 27 Jun 2024 14:06:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
>> 
>> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
>> 
>> 
>> enum E {A, B, C}
>> E e = ...;
>> switch (e) {
>>      case null -> {}
>>      case A a -> {}
>>      case C c -> {}
>>      case B b -> {}
>> }
>> 
>> 
>> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
>> 
>> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
>> 
>> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
>> 
>> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
>> 
>> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
>> 
>> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
>> 
>> Benchmark                           Mode  Cnt   Score   Error  Units
>> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
>> Swi...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 286:

> 284:             labels[i] = convertedLabel;
> 285:             constantsOnly &=
> 286:                     EnumDesc.class.isAssignableFrom(convertedLabel.getClass());

Suggestion:

            if (constantsOnly)
                constantsOnly = EnumDesc.class.isAssignableFrom(convertedLabel.getClass());


`&=` does not short-circuit the `isAssignableFrom` evaluation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1657342829

From jlahoda at openjdk.org  Thu Jun 27 15:32:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 27 Jun 2024 15:32:38 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array [v3]
In-Reply-To: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
Message-ID: <7hbLdZNdVwH6NOfd0sb78V0YcVzKYYbr05XsJwGYXeg=.99f25d99-e09e-4b7f-b9ad-79364f43c608@github.com>

> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
> 
> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
> 
> 
> enum E {A, B, C}
> E e = ...;
> switch (e) {
>      case null -> {}
>      case A a -> {}
>      case C c -> {}
>      case B b -> {}
> }
> 
> 
> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
> 
> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
> 
> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
> 
> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
> 
> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
> 
> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
> 
> Benchmark                           Mode  Cnt   Score   Error  Units
> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
> SwitchEnum.enumSwitchWithBootstrap  avgt   15  24.668 ? 1.037  ...

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19906/files
  - new: https://git.openjdk.org/jdk/pull/19906/files/79b3a76f..d7c97845

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19906/head:pull/19906

PR: https://git.openjdk.org/jdk/pull/19906

From jvernee at openjdk.org  Thu Jun 27 15:37:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Jun 2024 15:37:11 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
In-Reply-To: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
Message-ID: <VDpq5Qg3ZUGvNPoxiUGEc38uNY7dacqZoZRpOc3E19I=.77c66597-b460-4183-9d53-ed642c41e399@github.com>

On Thu, 27 Jun 2024 12:27:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
> 
> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
> 
> 
> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
> StringConcat.concatMix4String        ...

Ok, so, it turns out that specializing no-prefix prependers is actually slower than using `""` as a prefix. Nice catch

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19927#pullrequestreview-2145774085

From psandoz at openjdk.org  Thu Jun 27 16:03:12 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 27 Jun 2024 16:03:12 GMT
Subject: RFR: 8335252: ForceInline j.u.Formatter.Conversion#isValid [v2]
In-Reply-To: <6al-jx7cKio1G4swwQ9W_FXrtOnqFNbnTNUrzEPczFA=.1af6db38-f7a5-41df-9092-bd754cdae0cf@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <6al-jx7cKio1G4swwQ9W_FXrtOnqFNbnTNUrzEPczFA=.1af6db38-f7a5-41df-9092-bd754cdae0cf@github.com>
Message-ID: <PWoam2Z5HYYwhCTcmKZiUc5v_GgoiuzrpUsVVOpH0VA=.1047dfd6-3906-40d5-bab0-78d221e3f4fd@github.com>

On Thu, 27 Jun 2024 14:12:36 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert & use `@ForceInline`

Can you provide some additional context here? I think we need to be very careful about the general use @ForceInline in core libraries. While you show a modest performance benefit using a the micro benchmark, will it actually make any difference overall given formatting strings is not particular efficient?

String templates, currently removed, provided good string formatting performance, and the redesign will i think also provide good performance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2195095064

From liach at openjdk.org  Thu Jun 27 16:10:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jun 2024 16:10:13 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
In-Reply-To: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
Message-ID: <IKh8aIpw-Oxj5Sg5J9RLk2thgvFtE3WG-RnX8VlukBI=.b9e2a627-4b25-466e-a6b9-8e4777efb7f2@github.com>

On Thu, 27 Jun 2024 12:27:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
> 
> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
> 
> 
> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
> StringConcat.concatMix4String        ...

src/java.base/share/classes/java/lang/StringConcatHelper.java line 157:

> 155:             }
> 156:             index -= prefix.length();
> 157:             prefix.getBytes(buf, index, String.LATIN1);

Since we are now passing in a lot of empty prefix, I wonder how this call is elided; is there some specific JIT intrinsic? The java code has no shortcut for `length == 0`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1657409710

From redestad at openjdk.org  Thu Jun 27 17:31:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 27 Jun 2024 17:31:44 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
In-Reply-To: <IKh8aIpw-Oxj5Sg5J9RLk2thgvFtE3WG-RnX8VlukBI=.b9e2a627-4b25-466e-a6b9-8e4777efb7f2@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
 <IKh8aIpw-Oxj5Sg5J9RLk2thgvFtE3WG-RnX8VlukBI=.b9e2a627-4b25-466e-a6b9-8e4777efb7f2@github.com>
Message-ID: <962u_Z64emw2woyTXBL3pNKk7-qM9fluY6SqSnS5vfU=.b56c8e79-6d85-4b87-a6b4-7bf37c5fd891@github.com>

On Thu, 27 Jun 2024 16:05:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
>> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
>> 
>> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
>> 
>> 
>> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
>> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
>> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
>> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
>> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
>> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
>> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
>> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
>> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
>> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
>> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
>> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
>> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
>> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
>> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
>> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
>> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
>> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p...
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 157:
> 
>> 155:             }
>> 156:             index -= prefix.length();
>> 157:             prefix.getBytes(buf, index, String.LATIN1);
> 
> Since we are now passing in a lot of empty prefix, I wonder how this call is elided; is there some specific JIT intrinsic? The java code has no shortcut for `length == 0`.

Remember that the prefixes are all constants and bound into the MH at each call site, so one view is that this PR is mostly about tickling the code into something that just-so happens to be easier for the JIT to swallow

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1657513167

From duke at openjdk.org  Thu Jun 27 17:34:27 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 27 Jun 2024 17:34:27 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v15]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <VwFvSeZTV91PUm6YLWU0DzcRPwWQlvnKlbe7EaXlZrc=.58f8c179-4939-413c-8696-31d5d14da9f3@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Simplified computing square root of BigDecimal using BigInteger.sqrt()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/203d3f67..d90c5963

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=13-14

  Stats: 179 lines in 1 file changed: 29 ins; 115 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Thu Jun 27 17:34:28 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 27 Jun 2024 17:34:28 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v9]
In-Reply-To: <ZNRWBnP9Zbr43zZtJ4w8Zejiyk7tnaZZMLAahUAcnhQ=.9e8d1bf4-ca33-4628-a79a-6c1201bc99d6@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <rG6GcXc9p37UcRq6Ewnkuy97Q8F1FddjrrPT-GdMh0g=.a4fdc45d-ff1d-41a4-adc1-253d82f2dfbf@github.com>
 <ZNRWBnP9Zbr43zZtJ4w8Zejiyk7tnaZZMLAahUAcnhQ=.9e8d1bf4-ca33-4628-a79a-6c1201bc99d6@github.com>
Message-ID: <jorxxr6yS3WoRLroZV4qjFlg7G30F-RUW-sIjxSTSAM=.7d32b0f6-5434-49a3-ac73-19ffdf3d052e@github.com>

On Mon, 24 Jun 2024 17:09:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code optimization
>
> Thanks. That's a very nice performance improvement, on my Windows machine the `testHuge...` test is about 2-3x faster, and the other 2 are slightly faster too.
> 
> This needs a proper review for correctness, which might take a while.

@djelinski I also improved the `BigDecimal.sqrt()` algorithm exploiting `BigInteger.sqrtAndRemainder()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2195275197

From duke at openjdk.org  Thu Jun 27 17:59:46 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 27 Jun 2024 17:59:46 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v16]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <xvpQnAVAoQwDB0UG_c88f0jJSKGF1DC9gaxaW-BbGgQ=.f7bbff89-4b3b-4b0a-92f1-e19e7b7caa54@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct BigDecimal.sqrt()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/d90c5963..549c0969

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=14-15

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From liach at openjdk.org  Thu Jun 27 18:08:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jun 2024 18:08:18 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
In-Reply-To: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
Message-ID: <6Fvzdxc1DMGrfqk2ITKDDf1qOSrfh8x9UsoidlY3_9U=.d15ee23f-1f20-4858-b66c-3bec467fcb4d@github.com>

On Thu, 27 Jun 2024 12:27:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
> 
> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
> 
> 
> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
> StringConcat.concatMix4String        ...

Great cleanup! `StringConcatHelper` needs a copyright year bump.

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19927#pullrequestreview-2146139871

From jlu at openjdk.org  Thu Jun 27 18:34:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Jun 2024 18:34:26 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v13]
In-Reply-To: <pimwJozMjJsQUuRHx9p8v9uVDe6Z99NYlhXSJMnwu_s=.99fe2290-0999-451d-81dc-fc91f75b974b@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <pimwJozMjJsQUuRHx9p8v9uVDe6Z99NYlhXSJMnwu_s=.99fe2290-0999-451d-81dc-fc91f75b974b@github.com>
Message-ID: <VnWjMV8RFu40vLSgqtpvXcxYjExkjo0LUcK7_A9XvZA=.f80cb82c-575e-4b36-a992-2f3412b90171@github.com>

On Thu, 27 Jun 2024 11:09:27 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 72:

> 70:             1.23, 1.49, 1.80, 1.7, 0.0, -1.49, -1.50, 9999.9123, 1.494, 1.495, 1.03, 25.996, -25.996
> 71:         };
> 72:         date = new Date();

Not sure how others feel, but I think it is probably best that the benchmark is a separate test file, as opposed to being added to an existing benchmark. Otherwise if we stick with this file, copyright needs to be updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1657634289

From jlu at openjdk.org  Thu Jun 27 18:40:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Jun 2024 18:40:23 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v12]
In-Reply-To: <YYiDb-IxmJRJaavH2u5Qu_l92EkKuLPg4sbOSFOjaOg=.7c3544c6-1d3e-44c8-bc95-5b3ce5d9c017@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <3xnIg8_xta9FL19zb94_84n5rgM0YIV_IASSQ4LYIz0=.24bd0d46-7add-4270-a9c1-1c85ee22228e@github.com>
 <s01aPch5oEG1X1JS5FxWoBG2jT43Qvk6O312zkRQk-M=.82c11e99-be6f-49cc-868b-26b8842fc8c6@github.com>
 <YYiDb-IxmJRJaavH2u5Qu_l92EkKuLPg4sbOSFOjaOg=.7c3544c6-1d3e-44c8-bc95-5b3ce5d9c017@github.com>
Message-ID: <CH4G32DOZTdalm1csg-EQSbcGgwwrjvmiBoHfQmiyRM=.1109ddc5-73bd-481c-8aa6-f7031e59cf94@github.com>

On Thu, 27 Jun 2024 11:19:44 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/StringBufFactory.java line 45:
>> 
>>> 43:     }
>>> 44: 
>>> 45:     private static class StringBufferImpl implements Format.StringBuf {
>> 
>> The implementations may be more concise as a `record class`
>
> I know little about `record class`, it seems `record class` is help to model data aggregation, but here it act as a proxy class.

Yes, but since these implementations are just proxy classes, I think it is even more the reason to make them as simple/concise as possible since we don't care too much about what they do. (Since for most part it's the same as normal StringBuf/Bldr)

Either is fine here, we can stick with as is if you prefer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1657646453

From duke at openjdk.org  Thu Jun 27 18:42:22 2024
From: duke at openjdk.org (Larry Cable)
Date: Thu, 27 Jun 2024 18:42:22 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v7]
In-Reply-To: <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
Message-ID: <MoUVyHBhULriXYOy3Oe0DZSGPwDPe2qjR3E_4MDIURE=.559b5686-d2db-4740-8575-0478fbe3222f@github.com>

On Tue, 25 Jun 2024 13:54:46 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refactor mount info matching to helper function
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Remove problem listing of PlainRead which is reworked here
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/baafa662...532ea33b

src/hotspot/share/prims/jvm.cpp line 504:

> 502: JVM_LEAF(jboolean, JVM_IsContainerized(void))
> 503: #ifdef LINUX
> 504:   if (OSContainer::is_containerized()) {

// nit: personal preference...

return OSContainer::isContainerized() ? JNI_TRUE : JNI_FALSE;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1657650139

From duke at openjdk.org  Thu Jun 27 19:04:26 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Jun 2024 19:04:26 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array [v2]
In-Reply-To: <76XBUWAY8CtVyCl9czJYLdCZWkxT3PeeRZ9fBAdjjZc=.46b32d3d-501b-4b47-95e9-05af2dc7ca1b@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
 <pn53yPWi1IdWZ5SkMT_5NL6WimV5Hio6-m1-hb61tOA=.c7f5f2ab-11c3-492b-9db0-83d7395e17a7@github.com>
 <76XBUWAY8CtVyCl9czJYLdCZWkxT3PeeRZ9fBAdjjZc=.46b32d3d-501b-4b47-95e9-05af2dc7ca1b@github.com>
Message-ID: <doidwVXfXdbTA8l5Z3ZFIcW8_dFrBuiVcuiurz8tez4=.6e5d0a47-ea7e-4347-85c4-18be184dc15c@github.com>

On Thu, 27 Jun 2024 15:25:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 286:
> 
>> 284:             labels[i] = convertedLabel;
>> 285:             constantsOnly &=
>> 286:                     EnumDesc.class.isAssignableFrom(convertedLabel.getClass());
> 
> Suggestion:
> 
>             if (constantsOnly)
>                 constantsOnly = EnumDesc.class.isAssignableFrom(convertedLabel.getClass());
> 
> 
> `&=` does not short-circuit the `isAssignableFrom` evaluation.

It?d?have to?be?`&&=`, but?I?don?t think **Java** supports?that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1657679033

From duke at openjdk.org  Thu Jun 27 19:08:21 2024
From: duke at openjdk.org (Larry Cable)
Date: Thu, 27 Jun 2024 19:08:21 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v7]
In-Reply-To: <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
Message-ID: <G3bVFCktJ8ZfX41HSEJV2euXV6BI6bqgdIYKnIFrix0=.e849f25d-8794-4c34-bace-f65fa6bd887f@github.com>

On Tue, 25 Jun 2024 13:54:46 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refactor mount info matching to helper function
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Remove problem listing of PlainRead which is reworked here
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/baafa662...532ea33b

Marked as reviewed by larry-cable at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18201#pullrequestreview-2146294816

From duke at openjdk.org  Thu Jun 27 19:09:27 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Jun 2024 19:09:27 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array [v3]
In-Reply-To: <7hbLdZNdVwH6NOfd0sb78V0YcVzKYYbr05XsJwGYXeg=.99f25d99-e09e-4b7f-b9ad-79364f43c608@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
 <7hbLdZNdVwH6NOfd0sb78V0YcVzKYYbr05XsJwGYXeg=.99f25d99-e09e-4b7f-b9ad-79364f43c608@github.com>
Message-ID: <Rj35E-iWpSxkqTtRkMYRubrATTmy_PFcoRqeDx_NaTs=.4ac1aef3-11a6-4a33-a812-8daeb270426f@github.com>

On Thu, 27 Jun 2024 15:32:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
>> 
>> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
>> 
>> 
>> enum E {A, B, C}
>> E e = ...;
>> switch (e) {
>>      case null -> {}
>>      case A a -> {}
>>      case C c -> {}
>>      case B b -> {}
>> }
>> 
>> 
>> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
>> 
>> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
>> 
>> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
>> 
>> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
>> 
>> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
>> 
>> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
>> 
>> Benchmark                           Mode  Cnt   Score   Error  Units
>> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
>> Swi...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Since?`labels` is?no?longer eagerly?cloned, it?s?important to?store the?converted?labels into?a?local?array to?avoid leaking?them to?user?code.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 287:

> 285:             if (constantsOnly)
> 286:                 constantsOnly = EnumDesc.class.isAssignableFrom(convertedLabel.getClass());
> 287:         }

Suggestion:

        boolean constantsOnly = true;
        int len = labels.length;

        Object[] convertedLabels = new Object[len];
        for (int i = 0; i < len; i++) {
            Object convertedLabel =
                    convertEnumConstants(lookup, enumClass, labels[i]);
            convertedLabels[i] = convertedLabel;
            if (constantsOnly)
                constantsOnly = EnumDesc.class.isAssignableFrom(convertedLabel.getClass());
        }

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 297:

> 295:             //else return "typeSwitch(labels)"
> 296:             EnumDesc<?>[] enumDescLabels =
> 297:                     Arrays.copyOf(labels, labels.length, EnumDesc[].class);

Suggestion:

            EnumDesc<?>[] enumDescLabels =
                    Arrays.copyOf(convertedLabels, len, EnumDesc[].class);

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 300:

> 298:             target = MethodHandles.insertArguments(StaticHolders.MAPPED_ENUM_SWITCH, 2, lookup, enumClass, enumDescLabels, new MappedEnumCache());
> 299:         } else {
> 300:             target = generateTypeSwitch(lookup, invocationType.parameterType(0), labels);

Suggestion:

            target = generateTypeSwitch(lookup, invocationType.parameterType(0), convertedLabels);

-------------

PR Review: https://git.openjdk.org/jdk/pull/19906#pullrequestreview-2146292192
PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1657681541
PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1657681804
PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1657682159

From jlahoda at openjdk.org  Thu Jun 27 19:30:39 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 27 Jun 2024 19:30:39 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array [v4]
In-Reply-To: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
Message-ID: <QstIYQuaMw1cQapTRAPOuvnwhgwnclAfGQEPaXzQ3RU=.dd329c98-be6d-4378-b628-e192b71c8b3f@github.com>

> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input.
> 
> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like:
> 
> 
> enum E {A, B, C}
> E e = ...;
> switch (e) {
>      case null -> {}
>      case A a -> {}
>      case C c -> {}
>      case B b -> {}
> }
> 
> 
> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums.
> 
> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly).
> 
> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`).
> 
> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index.
> 
> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used.
> 
> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like:
> 
> Benchmark                           Mode  Cnt   Score   Error  Units
> SwitchEnum.enumSwitchTraditional    avgt   15  11.719 ? 0.333  ns/op
> SwitchEnum.enumSwitchWithBootstrap  avgt   15  24.668 ? 1.037  ...

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Clone the labels.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19906/files
  - new: https://git.openjdk.org/jdk/pull/19906/files/d7c97845..512a802a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=02-03

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19906/head:pull/19906

PR: https://git.openjdk.org/jdk/pull/19906

From jlahoda at openjdk.org  Thu Jun 27 19:30:39 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 27 Jun 2024 19:30:39 GMT
Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused
 array [v3]
In-Reply-To: <Rj35E-iWpSxkqTtRkMYRubrATTmy_PFcoRqeDx_NaTs=.4ac1aef3-11a6-4a33-a812-8daeb270426f@github.com>
References: <CI38gUcbLjqL9uKZ-zeR532WN6O5YcjMtnu46qsDQzc=.6ada1503-c634-4b5d-b237-28adde41dd74@github.com>
 <7hbLdZNdVwH6NOfd0sb78V0YcVzKYYbr05XsJwGYXeg=.99f25d99-e09e-4b7f-b9ad-79364f43c608@github.com>
 <Rj35E-iWpSxkqTtRkMYRubrATTmy_PFcoRqeDx_NaTs=.4ac1aef3-11a6-4a33-a812-8daeb270426f@github.com>
Message-ID: <hzqv1dj-i4tK9qE890xF4pNMSWZEiYfOI1kK7OYSaSA=.da2a55a2-3902-476b-ab01-cef4a91f4568@github.com>

On Thu, 27 Jun 2024 19:07:07 GMT, ExE Boss <duke at openjdk.org> wrote:

> Since `labels` is no longer eagerly cloned, it?s important to store the converted labels into a local array to avoid leaking them to user code.

True. But it is easier and cleaner, IMO, to simply put back cloning of the labels.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19906#issuecomment-2195515947

From shade at openjdk.org  Thu Jun 27 19:35:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 27 Jun 2024 19:35:39 GMT
Subject: RFR: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum should
 be final
Message-ID: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>

I was auditing the current uses of `@Stable` before relaxing its barriers ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an easy spot. 

`resolvedEnum` is not `final`. So technically publishing the object via data race can show `resolvedEnum` as `null`, which would break `test()` that does not expect it. Currently not a practical problem since its safety is covered by adjacent `final` fields, but should be more precise.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/19933/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19933&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335274
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19933.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19933/head:pull/19933

PR: https://git.openjdk.org/jdk/pull/19933

From liach at openjdk.org  Thu Jun 27 19:41:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jun 2024 19:41:17 GMT
Subject: RFR: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum
 should be final
In-Reply-To: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
References: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
Message-ID: <6Elm6cEMlrCiZxxYzebKf2SykXO1BjXkUiraYeHCNVo=.dcc0585b-5777-4425-83dc-9135832a8726@github.com>

On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I was auditing the current uses of `@Stable` before relaxing its barriers ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an easy spot. 
> 
> `resolvedEnum` is not `final`. So technically publishing the object via data race can show `resolvedEnum` as `null`, which would break `test()` that does not expect it. Currently not a practical problem since its safety is covered by adjacent `final` fields, but should be more precise.

Indeed, the missing final on a stable array usually indicates a level of laziness on the array itself. It's clearly not the case here.

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19933#pullrequestreview-2146358637

From liach at openjdk.org  Thu Jun 27 19:57:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Jun 2024 19:57:23 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v13]
In-Reply-To: <pimwJozMjJsQUuRHx9p8v9uVDe6Z99NYlhXSJMnwu_s=.99fe2290-0999-451d-81dc-fc91f75b974b@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <pimwJozMjJsQUuRHx9p8v9uVDe6Z99NYlhXSJMnwu_s=.99fe2290-0999-451d-81dc-fc91f75b974b@github.com>
Message-ID: <HGo8F0hmenJgKORmoL6Vk2_jrrIN4Elf_ebMXUBT-sA=.89bc88f5-8d3d-44c2-9fed-2223c10a7135@github.com>

On Thu, 27 Jun 2024 11:09:27 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8333396: Performance regression of DecimalFormat.format

src/java.base/share/classes/java/text/CompactNumberFormat.java line 814:

> 812:      * @see FieldPosition
> 813:      */
> 814:     private StringBuffer format(BigDecimal number, StringBuffer result,

Can we update this private method's signature to `StringBuf` safely?

src/java.base/share/classes/java/text/CompactNumberFormat.java line 909:

> 907:      * @see FieldPosition
> 908:      */
> 909:     private StringBuffer format(BigInteger number, StringBuffer result,

Same question, no need to keep StringBuffer signature in private methods

test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 97:

> 95:     @Benchmark
> 96:     public void testDateFormat(final Blackhole blackhole) {
> 97:         blackhole.consume(dateFormat.format(date));

We usually just return the value if the blackhole only consumes one value. Blackhole is usually used for producing multiple values, such as running in a loop and ensure each iteration's result is used (as in testDefNumberFormatter)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1657725192
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1657725559
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1657738836

From naoto at openjdk.org  Thu Jun 27 20:02:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Jun 2024 20:02:24 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v13]
In-Reply-To: <VnWjMV8RFu40vLSgqtpvXcxYjExkjo0LUcK7_A9XvZA=.f80cb82c-575e-4b36-a992-2f3412b90171@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <pimwJozMjJsQUuRHx9p8v9uVDe6Z99NYlhXSJMnwu_s=.99fe2290-0999-451d-81dc-fc91f75b974b@github.com>
 <VnWjMV8RFu40vLSgqtpvXcxYjExkjo0LUcK7_A9XvZA=.f80cb82c-575e-4b36-a992-2f3412b90171@github.com>
Message-ID: <r0e8uvyAiJkQE0Oehfr1eQqeYKyAXn1rqwTN3QUoAoQ=.38d49731-d752-4b08-84d3-b1817ebc52ce@github.com>

On Thu, 27 Jun 2024 18:31:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 72:
> 
>> 70:             1.23, 1.49, 1.80, 1.7, 0.0, -1.49, -1.50, 9999.9123, 1.494, 1.495, 1.03, 25.996, -25.996
>> 71:         };
>> 72:         date = new Date();
> 
> Not sure how others feel, but I think it is probably best that the benchmark is a separate test file, as opposed to being added to an existing benchmark. Otherwise if we stick with this file, copyright needs to be updated.

+1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1657744470

From duke at openjdk.org  Thu Jun 27 20:08:42 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 27 Jun 2024 20:08:42 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v17]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <9CwNzciDhob1NRx-sKZMDthHVKrKoNX2woDoLI19aHM=.ccdd96c0-b5c8-4e32-b70c-34e3b37430b7@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 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 47 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patchSqrt
 - Added "throw" to throw the ArithmeticException created
 - Correct BigDecimal.sqrt()
 - Simplified computing square root of BigDecimal using BigInteger.sqrt()
 - Removed unnecessary variable
 - Optimized to compute the remainder only if needed
 - Optimized multiplication
 - Code optimization
 - Merge branch 'openjdk:master' into patchSqrt
 - Removed useless instruction
 - ... and 37 more: https://git.openjdk.org/jdk/compare/b0e0dbc8...d3ca0d4f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/549c0969..d3ca0d4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=15-16

  Stats: 7267 lines in 207 files changed: 4535 ins; 1905 del; 827 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From darcy at openjdk.org  Thu Jun 27 20:13:28 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 27 Jun 2024 20:13:28 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v17]
In-Reply-To: <9CwNzciDhob1NRx-sKZMDthHVKrKoNX2woDoLI19aHM=.ccdd96c0-b5c8-4e32-b70c-34e3b37430b7@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <9CwNzciDhob1NRx-sKZMDthHVKrKoNX2woDoLI19aHM=.ccdd96c0-b5c8-4e32-b70c-34e3b37430b7@github.com>
Message-ID: <TxlScxI6QNYT31O6P-GqWQ4DTLaPJEOcvrgjGbWo8Y0=.8e0f2d6c-688d-4659-8fc9-7ed0bed5f5a9@github.com>

On Thu, 27 Jun 2024 20:08:42 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>> 
>> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.
>
> fabioromano1 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 47 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patchSqrt
>  - Added "throw" to throw the ArithmeticException created
>  - Correct BigDecimal.sqrt()
>  - Simplified computing square root of BigDecimal using BigInteger.sqrt()
>  - Removed unnecessary variable
>  - Optimized to compute the remainder only if needed
>  - Optimized multiplication
>  - Code optimization
>  - Merge branch 'openjdk:master' into patchSqrt
>  - Removed useless instruction
>  - ... and 37 more: https://git.openjdk.org/jdk/compare/861563ea...d3ca0d4f

Please separate out any changes to BigDecimal.sqrt to separate follow-up work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2195589860

From duke at openjdk.org  Thu Jun 27 20:34:50 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 27 Jun 2024 20:34:50 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v18]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <xrQ5uloyoKkobr1Jcb2XaNKqNS1jFGMGy1yT3xA7PRU=.be30da1e-80dc-455f-84f3-3c170a478a93@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Reverted changes in BigDecimal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/d3ca0d4f..781ad35b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=16-17

  Stats: 181 lines in 1 file changed: 116 ins; 31 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Fri Jun 28 04:12:08 2024
From: duke at openjdk.org (lingjun-cg)
Date: Fri, 28 Jun 2024 04:12:08 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v14]
In-Reply-To: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
Message-ID: <qOVDXoFneudZhSqvCcLNuNYTZPYtZHrmE-sqgUmkFtg=.9a860676-b261-4235-9f82-a62161d9698c@github.com>

> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
> So I added support for some new methods that accept StringBuilder which is lock-free.
> 
> ### Benchmark testcase
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     private DecimalFormat format;
> 
>     @Setup(Level.Trial)
>     public void setup() {
>         format = new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testNewAndFormat() throws InterruptedException {
>         new DecimalFormat("#0.00000").format(9524234.1236457);
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> 
>     @Benchmark
>     public void testFormatOnly() throws InterruptedException {
>         format.format(9524234.1236457);
>     }
> }
> 
> 
> ### Test result
> #### Current JDK before optimize
> 
>  Benchmark                             Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> #### Current JDK after optimize
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> ### JDK 11 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op

lingjun-cg has updated the pull request incrementally with two additional commits since the last revision:

 - 8333396: Performance regression of DecimalFormat.format
 - 8333396: Performance regression of DecimalFormat.format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19513/files
  - new: https://git.openjdk.org/jdk/pull/19513/files/f1b88f36..b5bdc733

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=12-13

  Stats: 310 lines in 6 files changed: 233 ins; 71 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513

PR: https://git.openjdk.org/jdk/pull/19513

From duke at openjdk.org  Fri Jun 28 05:03:32 2024
From: duke at openjdk.org (He-Pin (kerr))
Date: Fri, 28 Jun 2024 05:03:32 GMT
Subject: RFR: 8312436: CompletableFuture never completes when
 'Throwable.toString()' method throws Exception
In-Reply-To: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
References: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
Message-ID: <JxiSfkLUTj6YPHGslmjGCOOS7FzhW566Ed-FQnCghkM=.e1b0041f-086f-469b-b80b-6a40a7b03024@github.com>

On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.
> 
> Nevertheless, there is some things we can do, as witnessed in this PR.

Will  this be backported to JDK21U?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18988#issuecomment-2196143083

From jlahoda at openjdk.org  Fri Jun 28 08:43:20 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Jun 2024 08:43:20 GMT
Subject: RFR: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum
 should be final
In-Reply-To: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
References: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
Message-ID: <tDKSHPt0UwlTvYlMa5hobQwHR1eMnCwl2dmtK62mae4=.03e19a7b-4e5e-4a9b-bf38-b43bc670f604@github.com>

On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I was auditing the current uses of `@Stable` before relaxing its barriers ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an easy spot. 
> 
> `resolvedEnum` is not `final`. So technically publishing the object via data race can show `resolvedEnum` as `null`, which would break `test()` that does not expect it. Currently not a practical problem since its safety is covered by adjacent `final` fields, but should be more precise.

Looks good to me.

Marked as reviewed by jlahoda (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19933#pullrequestreview-2147390630
PR Review: https://git.openjdk.org/jdk/pull/19933#pullrequestreview-2147390890

From sgehwolf at openjdk.org  Fri Jun 28 08:43:31 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Jun 2024 08:43:31 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v7]
In-Reply-To: <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
Message-ID: <mkkI6rCYplyB4LqZZ4_b4THEgUU6R-j0xcv37w2xA9s=.ad526e58-e9dc-44a3-ab5a-c85e6d642546@github.com>

On Tue, 25 Jun 2024 13:54:46 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refactor mount info matching to helper function
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Remove problem listing of PlainRead which is reworked here
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/baafa662...532ea33b

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2196421487

From jlahoda at openjdk.org  Fri Jun 28 09:31:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Jun 2024 09:31:19 GMT
Subject: RFR: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum
 should be final
In-Reply-To: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
References: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
Message-ID: <ay0DhXTwpynk1I1hZBfwDpvsBCLgVOfaTpw_aKh5PDQ=.607f2db6-a660-4f16-a48d-54ad07a95408@github.com>

On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I was auditing the current uses of `@Stable` before relaxing its barriers ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an easy spot. 
> 
> `resolvedEnum` is not `final`. So technically publishing the object via data race can show `resolvedEnum` as `null`, which would break `test()` that does not expect it. Currently not a practical problem since its safety is covered by adjacent `final` fields, but should be more precise.

FWIW, there are more `@Stable` uses here:
https://github.com/openjdk/jdk/pull/19906

if you would have a moment to check that, it may be helpful. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19933#issuecomment-2196499286

From shade at openjdk.org  Fri Jun 28 09:36:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jun 2024 09:36:18 GMT
Subject: RFR: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum
 should be final
In-Reply-To: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
References: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
Message-ID: <tNRw7n4sDwULFXauPc-6HXGGVVzfUHgAb4ykIWagI1s=.4c1c31b0-e3bb-4333-8d6a-320373843c23@github.com>

On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I was auditing the current uses of `@Stable` before relaxing its barriers ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an easy spot. 
> 
> `resolvedEnum` is not `final`. So technically publishing the object via data race can show `resolvedEnum` as `null`, which would break `test()` that does not expect it. Currently not a practical problem since its safety is covered by adjacent `final` fields, but should be more precise.

> FWIW, there are more `@Stable` uses here: #19906
> if you would have a moment to check that, it may be helpful. Thanks.

That one looks fine: it is set outside of constructor, is intrinsically racy, and it has AFAICS the recovery paths when we read `null` out of `MappedEnumCache.generatedSwitch` or `MappedEnumCache.constantsMap`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19933#issuecomment-2196506663

From redestad at openjdk.org  Fri Jun 28 10:25:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Jun 2024 10:25:22 GMT
Subject: RFR: 8335252: ForceInline j.u.Formatter.Conversion#isValid [v2]
In-Reply-To: <6al-jx7cKio1G4swwQ9W_FXrtOnqFNbnTNUrzEPczFA=.1af6db38-f7a5-41df-9092-bd754cdae0cf@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <6al-jx7cKio1G4swwQ9W_FXrtOnqFNbnTNUrzEPczFA=.1af6db38-f7a5-41df-9092-bd754cdae0cf@github.com>
Message-ID: <as3RnAQTqMhWe_Dd4AD5M0-BCBWA5xHqUYNb16XLuQ0=.c743cc48-c352-4cb4-b32e-465b5d1245c9@github.com>

On Thu, 27 Jun 2024 14:12:36 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert & use `@ForceInline`

So the compound issue here is that there's a heuristic which prevents inlining of large methods, and that a tableswitch on inputs spanning from `'%' (37)` to `'x' (120)` become expansive enough (350bytes) to make the JIT enforce that rule.

As an alternative to `@ForceInline` I tested splitting uppercase and lowercase chars into two switches. This looks a bit nasty, but actually reduces the size of the method:

diff --git a/src/java.base/share/classes/java/util/Formatter.java b/src/java.base/share/classes/java/util/Formatter.java
index a7d95ee5780..50419f1ea23 100644
--- a/src/java.base/share/classes/java/util/Formatter.java
+++ b/src/java.base/share/classes/java/util/Formatter.java
@@ -4947,30 +4947,36 @@ static class Conversion {
         static final char PERCENT_SIGN        = '%';

         static boolean isValid(char c) {
-            return switch (c) {
-                case BOOLEAN,
-                     BOOLEAN_UPPER,
-                     STRING,
-                     STRING_UPPER,
-                     HASHCODE,
-                     HASHCODE_UPPER,
-                     CHARACTER,
-                     CHARACTER_UPPER,
-                     DECIMAL_INTEGER,
-                     OCTAL_INTEGER,
-                     HEXADECIMAL_INTEGER,
-                     HEXADECIMAL_INTEGER_UPPER,
-                     SCIENTIFIC,
-                     SCIENTIFIC_UPPER,
-                     GENERAL,
-                     GENERAL_UPPER,
-                     DECIMAL_FLOAT,
-                     HEXADECIMAL_FLOAT,
-                     HEXADECIMAL_FLOAT_UPPER,
-                     LINE_SEPARATOR,
-                     PERCENT_SIGN -> true;
-                default -> false;
-            };
+            if (c >= 'a') {
+                return switch (c) {
+                    case BOOLEAN,
+                         STRING,
+                         HASHCODE,
+                         CHARACTER,
+                         DECIMAL_INTEGER,
+                         OCTAL_INTEGER,
+                         HEXADECIMAL_INTEGER,
+                         SCIENTIFIC,
+                         GENERAL,
+                         DECIMAL_FLOAT,
+                         HEXADECIMAL_FLOAT,
+                         LINE_SEPARATOR -> true;
+                    default -> false;
+                };
+            } else {
+                return switch (c) {
+                    case BOOLEAN_UPPER,
+                         STRING_UPPER,
+                         HASHCODE_UPPER,
+                         CHARACTER_UPPER,
+                         HEXADECIMAL_INTEGER_UPPER,
+                         SCIENTIFIC_UPPER,
+                         GENERAL_UPPER,
+                         HEXADECIMAL_FLOAT_UPPER,
+                         PERCENT_SIGN -> true;
+                    default -> false;
+                };
+            }
         }

         // Returns true iff the Conversion is applicable to all objects.

`javap -v java.lang.Formatter$Conversion`

  static boolean isValid(char);
    descriptor: (C)Z
    flags: (0x0008) ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: iload_0
         1: bipush        97
         3: if_icmplt     122
         6: iload_0
         7: tableswitch   { // 97 to 120
                      97: 116
                      98: 116
                      99: 116
                     100: 116
                     101: 116
                     102: 116
                     103: 116
                     104: 116
                     105: 120
                     106: 120
                     107: 120
                     108: 120
                     109: 120
                     110: 116
                     111: 116
                     112: 120
                     113: 120
                     114: 120
                     115: 116
                     116: 120
                     117: 120
                     118: 120
                     119: 120
                     120: 116
                 default: 120
            }
       116: iconst_1
       117: goto          121
       120: iconst_0
       121: ireturn
       122: iload_0
       123: lookupswitch  { // 9
                      37: 204
                      65: 204
                      66: 204
                      67: 204
                      69: 204
                      71: 204
                      72: 204
                      83: 204
                      88: 204
                 default: 208
            }
       204: iconst_1
       205: goto          209
       208: iconst_0
       209: ireturn
 ```
 
 And sees an improvement similar to `@ForceInline` on the micro:
 ```
 Name            Cnt   Base   Error    Test   Error  Unit  Change
stringIntFormat  15 92,447 ? 2,497  82,912 ? 3,317 ns/op   1,11x (p = 0,000*)
  * = significant
  ```
Shrinking the size of the .class file by 121 bytes is a fun bonus.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2196585088

From nbenalla at openjdk.org  Fri Jun 28 10:44:05 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 28 Jun 2024 10:44:05 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java [v3]
In-Reply-To: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
Message-ID: <i_A5HxiRd1j1dLcY651PMXf-0XJ9H5Ex4ukGaMJH2N4=.ce865990-27a6-46b4-8e15-6882da545160@github.com>

> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files.
> 
> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `<body>` and `<html>`. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file.
> 
> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Improve package description based on  Efimov's suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19529/files
  - new: https://git.openjdk.org/jdk/pull/19529/files/1826633f..0104e4ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19529&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19529&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19529.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19529/head:pull/19529

PR: https://git.openjdk.org/jdk/pull/19529

From nbenalla at openjdk.org  Fri Jun 28 10:44:06 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 28 Jun 2024 10:44:06 GMT
Subject: RFR: 8332072: Convert package.html files in `java.naming` to
 package-info.java [v2]
In-Reply-To: <oubR0VYjzHiC9Jvs8cwX0ARLvN3743FJL-P1zHC5Zsg=.47e0d27a-139a-4627-97c5-65ff66afe4ed@github.com>
References: <ZosN0dGmTmniRsLJM8KiI2Af1oBqoOR28TlD1OSqAfI=.d54f7c6a-f60c-4e16-83db-c8cc1196ab2e@github.com>
 <eegXVDbCK3NE3hergX3pFItkeyLUi7TM_H9QjBOSv0U=.fa4b5596-4030-436b-b581-3e8ba3faa87d@github.com>
 <oubR0VYjzHiC9Jvs8cwX0ARLvN3743FJL-P1zHC5Zsg=.47e0d27a-139a-4627-97c5-65ff66afe4ed@github.com>
Message-ID: <L4bg497mNIBevLa42mDApSeX3GyusuIPZFiFPWG8tQU=.269dcb10-1ec8-49e6-9125-04b4611b07c4@github.com>

On Thu, 27 Jun 2024 10:27:03 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - use javadoc standards
>>  - Merge remote-tracking branch 'upstream/master' into naming
>>  - remove whitespace
>>  - 8332072: Convert package.html files in `java.naming` to package-info.java
>
> src/java.naming/share/classes/javax/naming/ldap/spi/package-info.java line 29:
> 
>> 27:  *
>> 28:  * Extends the {@code javax.naming.ldap} package to provide the classes
>> 29:  * and interfaces for the Service Provider Interface (SPI) for LDAP
> 
> The?`javax.naming.ldap.spi`?package only contains SPI classes that can customize DNS lookups when performing LDAP operations. It was added by [JDK-8160768](https://bugs.openjdk.org/browse/JDK-8160768)/[CSR](https://bugs.openjdk.org/browse/JDK-8192975).  
> Since the package only contains classes related to this SPI maybe we could change the wording to something like this:
> Suggestion:
> 
>  * Provides the Service Provider Interface for DNS lookups when
>  * performing LDAP operations.

Thanks, Fixed in [0104e4a](https://github.com/openjdk/jdk/pull/19529/commits/0104e4ac5a9bfe143822e72756771c29e0f32731)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19529#discussion_r1658495820

From nbenalla at openjdk.org  Fri Jun 28 11:11:51 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 28 Jun 2024 11:11:51 GMT
Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in
 java.base [v7]
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <IBD0_AMYf7zQCygu2z3RR4KNBG6J8ZQ3HrSXWMkr0gQ=.032e6176-313d-441e-9b8e-3aa4ce515f17@github.com>

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8330954
 - Add new line when having multi-line doc comment
 - Merge remote-tracking branch 'upstream/master' into 8330954
 - Merge remote-tracking branch 'upstream/master' into 8330954
 - (C)
 - (C)
 - Move security classes changes to pr18373
 - remove couple extra lines
 - Pull request is now only about `@since` tags, might add an other commit
 - add one more `{inheritDoc}` to `CompletableFuture.state`
 - ... and 4 more: https://git.openjdk.org/jdk/compare/f0a4fbe9...afca07bf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18954/files
  - new: https://git.openjdk.org/jdk/pull/18954/files/91df97f7..afca07bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=05-06

  Stats: 4488 lines in 130 files changed: 3244 ins; 715 del; 529 mod
  Patch: https://git.openjdk.org/jdk/pull/18954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18954/head:pull/18954

PR: https://git.openjdk.org/jdk/pull/18954

From duke at openjdk.org  Fri Jun 28 11:13:36 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 28 Jun 2024 11:13:36 GMT
Subject: RFR: 8335252: ForceInline j.u.Formatter.Conversion#isValid [v2]
In-Reply-To: <as3RnAQTqMhWe_Dd4AD5M0-BCBWA5xHqUYNb16XLuQ0=.c743cc48-c352-4cb4-b32e-465b5d1245c9@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <6al-jx7cKio1G4swwQ9W_FXrtOnqFNbnTNUrzEPczFA=.1af6db38-f7a5-41df-9092-bd754cdae0cf@github.com>
 <as3RnAQTqMhWe_Dd4AD5M0-BCBWA5xHqUYNb16XLuQ0=.c743cc48-c352-4cb4-b32e-465b5d1245c9@github.com>
Message-ID: <p9kHjEqrI7-x2d5wkGTL1PBIYD3Y-u1nGYeXd4S5608=.e8f97fdf-96a6-4460-82c9-3b51163583d6@github.com>

On Fri, 28 Jun 2024 10:22:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert & use `@ForceInline`
>
> So the compound issue here is that there's a heuristic which prevents inlining of large methods, and that a tableswitch on inputs spanning from `'%' (37)` to `'x' (120)` become expansive enough (350bytes) to make the JIT enforce that rule.
> 
> As an alternative to `@ForceInline` I tested splitting uppercase and lowercase chars into two switches. This looks a bit nasty, but actually reduces the size of the method:
> 
> diff --git a/src/java.base/share/classes/java/util/Formatter.java b/src/java.base/share/classes/java/util/Formatter.java
> index a7d95ee5780..50419f1ea23 100644
> --- a/src/java.base/share/classes/java/util/Formatter.java
> +++ b/src/java.base/share/classes/java/util/Formatter.java
> @@ -4947,30 +4947,36 @@ static class Conversion {
>          static final char PERCENT_SIGN        = '%';
> 
>          static boolean isValid(char c) {
> -            return switch (c) {
> -                case BOOLEAN,
> -                     BOOLEAN_UPPER,
> -                     STRING,
> -                     STRING_UPPER,
> -                     HASHCODE,
> -                     HASHCODE_UPPER,
> -                     CHARACTER,
> -                     CHARACTER_UPPER,
> -                     DECIMAL_INTEGER,
> -                     OCTAL_INTEGER,
> -                     HEXADECIMAL_INTEGER,
> -                     HEXADECIMAL_INTEGER_UPPER,
> -                     SCIENTIFIC,
> -                     SCIENTIFIC_UPPER,
> -                     GENERAL,
> -                     GENERAL_UPPER,
> -                     DECIMAL_FLOAT,
> -                     HEXADECIMAL_FLOAT,
> -                     HEXADECIMAL_FLOAT_UPPER,
> -                     LINE_SEPARATOR,
> -                     PERCENT_SIGN -> true;
> -                default -> false;
> -            };
> +            if (c >= 'a') {
> +                return switch (c) {
> +                    case BOOLEAN,
> +                         STRING,
> +                         HASHCODE,
> +                         CHARACTER,
> +                         DECIMAL_INTEGER,
> +                         OCTAL_INTEGER,
> +                         HEXADECIMAL_INTEGER,
> +                         SCIENTIFIC,
> +                         GENERAL,
> +                         DECIMAL_FLOAT,
> +                         HEXADECIMAL_FLOAT,
> +                         LINE_SEPARATOR -> true;
> +                    default -> false;
> +                };
> +            } else {
> +                return switch (c) {
> +                    case BOOLEAN_UPPER,
> +                         STRING_UPPER,
> +                         HASHCODE_UP...

@cl4es provided a better idea, which is to change the branch of switch instead of using ForceInline. I have another approach:


            return switch (c) {
                case BOOLEAN,
                     BOOLEAN_UPPER,
                     STRING,
                     STRING_UPPER,
                     HASHCODE,
                     HASHCODE_UPPER,
                     CHARACTER,
                     CHARACTER_UPPER,
                     DECIMAL_INTEGER,
                     OCTAL_INTEGER,
                     HEXADECIMAL_INTEGER,
                     HEXADECIMAL_INTEGER_UPPER,
                     SCIENTIFIC,
                     SCIENTIFIC_UPPER,
                     GENERAL,
                     GENERAL_UPPER,
                     DECIMAL_FLOAT,
                     HEXADECIMAL_FLOAT,
                     HEXADECIMAL_FLOAT_UPPER,
                     LINE_SEPARATOR -> true;
                default -> c == PERCENT_SIGN;
            };

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2196652531

From duke at openjdk.org  Fri Jun 28 11:27:47 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 28 Jun 2024 11:27:47 GMT
Subject: RFR: 8335252: ForceInline j.u.Formatter.Conversion#isValid [v3]
In-Reply-To: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
Message-ID: <eiQYGsyzUwaMdcPqYDFZopOK8F7wA1M0JptP4BJPaCE=.c7cfa855-5cdb-4c06-bb8f-95e6ebc000d1@github.com>

> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
> 
> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
> 
> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
> 
> 
> current version
> 
> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove ForceInline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19926/files
  - new: https://git.openjdk.org/jdk/pull/19926/files/d2bebbdf..192aa465

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19926&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19926&range=01-02

  Stats: 7 lines in 1 file changed: 1 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19926/head:pull/19926

PR: https://git.openjdk.org/jdk/pull/19926

From redestad at openjdk.org  Fri Jun 28 12:36:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Jun 2024 12:36:24 GMT
Subject: RFR: 8335252: ForceInline j.u.Formatter.Conversion#isValid [v3]
In-Reply-To: <eiQYGsyzUwaMdcPqYDFZopOK8F7wA1M0JptP4BJPaCE=.c7cfa855-5cdb-4c06-bb8f-95e6ebc000d1@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <eiQYGsyzUwaMdcPqYDFZopOK8F7wA1M0JptP4BJPaCE=.c7cfa855-5cdb-4c06-bb8f-95e6ebc000d1@github.com>
Message-ID: <8Zi6WThitAxt7UvQiWdgZ8pJLevkn7jbZ21I_gv4SIk=.139115e6-7a70-4d1b-aa6f-1b4f01f346be@github.com>

On Fri, 28 Jun 2024 11:27:47 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ForceInline

This looks better. Avoids a branch up front, minimized code changes. The comment is good, but perhaps move it down into the default case? 

Update bug description to something like "Reduce size of j.u.Formatter.Conversion#isValid" ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2196808696

From redestad at openjdk.org  Fri Jun 28 12:39:32 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Jun 2024 12:39:32 GMT
Subject: RFR: 8335182: Consolidate and streamline String concat code shapes
 [v2]
In-Reply-To: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
References: <RdqQkAHq4sGT8_Mtri4fROmNmHHKB-ge6dt9gQ14JJQ=.d9664395-4a2b-4c62-913f-3703d6abc20e@github.com>
Message-ID: <n98Cj23KDJZUG9OWCc3JbEbRj3VhvGLoQxfojNQC8BQ=.22769ff5-2d7d-4a7f-a274-deece1bc00fb@github.com>

> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. 
> 
> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
> 
> 
> Name                                    Cnt     Base     Error      Test     Error  Unit  Change
> StringConcat.concat13String              50   66.380 ?   0.189    53.017 ?   0.241 ns/op   1.25x (p = 0.000*)
> StringConcat.concat4String               50   13.620 ?   0.053    12.382 ?   0.089 ns/op   1.10x (p = 0.000*)
> StringConcat.concat6String               50   17.168 ?   0.070    16.046 ?   0.064 ns/op   1.07x (p = 0.000*)
> StringConcat.concatConst2String          50    9.820 ?   0.081     8.158 ?   0.041 ns/op   1.20x (p = 0.000*)
> StringConcat.concatConst4String          50   14.938 ?   0.124    12.800 ?   0.049 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConst6Object          50   56.115 ?   0.288    54.046 ?   0.214 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConst6String          50   19.032 ?   0.073    16.213 ?   0.093 ns/op   1.17x (p = 0.000*)
> StringConcat.concatConstBoolByte         50    8.486 ?   0.066     8.556 ?   0.050 ns/op   0.99x (p = 0.004*)
> StringConcat.concatConstInt              50    8.942 ?   0.052     7.677 ?   0.029 ns/op   1.16x (p = 0.000*)
> StringConcat.concatConstIntConstInt      50   12.883 ?   0.070    12.431 ?   0.070 ns/op   1.04x (p = 0.000*)
> StringConcat.concatConstString           50    7.523 ?   0.050     7.486 ?   0.044 ns/op   1.00x (p = 0.058 )
> StringConcat.concatConstStringConstInt   50   11.961 ?   0.032    11.699 ?   0.049 ns/op   1.02x (p = 0.000*)
> StringConcat.concatEmptyConstInt         50    7.778 ?   0.038     7.723 ?   0.037 ns/op   1.01x (p = 0.000*)
> StringConcat.concatEmptyConstString      50    3.506 ?   0.026     3.505 ?   0.015 ns/op   1.00x (p = 0.930 )
> StringConcat.concatEmptyLeft             50    3.573 ?   0.075     3.518 ?   0.057 ns/op   1.02x (p = 0.044 )
> StringConcat.concatEmptyRight            50    3.713 ?   0.049     3.622 ?   0.053 ns/op   1.02x (p = 0.000*)
> StringConcat.concatMethodConstString     50    7.418 ?   0.030     7.478 ?   0.066 ns/op   0.99x (p = 0.005*)
> StringConcat.concatMix4String        ...

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Copyrights

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19927/files
  - new: https://git.openjdk.org/jdk/pull/19927/files/6525e945..7c50d7dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19927&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19927&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19927.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19927/head:pull/19927

PR: https://git.openjdk.org/jdk/pull/19927

From duke at openjdk.org  Fri Jun 28 12:46:49 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 28 Jun 2024 12:46:49 GMT
Subject: RFR: 8335252: Reduce size of j.u.Formatter.Conversion#isValid [v4]
In-Reply-To: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
Message-ID: <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>

> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
> 
> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
> 
> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
> 
> 
> current version
> 
> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19926/files
  - new: https://git.openjdk.org/jdk/pull/19926/files/192aa465..5707dc67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19926&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19926&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19926/head:pull/19926

PR: https://git.openjdk.org/jdk/pull/19926

From redestad at openjdk.org  Fri Jun 28 12:58:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Jun 2024 12:58:19 GMT
Subject: RFR: 8335252: Reduce size of j.u.Formatter.Conversion#isValid [v4]
In-Reply-To: <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
Message-ID: <u-GS1b9pgAByK7phs2F1OOBPbLFQFyODZPPNncBtsvU=.5bc539d4-0508-4b95-96a2-ae5fe9587e49@github.com>

On Fri, 28 Jun 2024 12:46:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

Thanks for the updates. I think this is now a harmless and straightforward improvement.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19926#pullrequestreview-2147942903

From nbenalla at openjdk.org  Fri Jun 28 13:36:32 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 28 Jun 2024 13:36:32 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v11]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <ZvrMx6gMUd0a-GDpgSdmyVCjhzb8ysoQ4zPYIHhKA2Q=.ea66d0c9-9b33-4e76-8153-5cf0c567cc27@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Skip over files and packages that aren't found

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/62aebb0b..12d410af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=09-10

  Stats: 39 lines in 1 file changed: 10 ins; 7 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From nbenalla at openjdk.org  Fri Jun 28 13:36:34 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 28 Jun 2024 13:36:34 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v10]
In-Reply-To: <J1AlirvH4VWsU32jz7kTUnjVleI33dkiHsrLDPO1Vww=.57e84d9f-8dd4-4bdb-901e-d0c519169a29@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <J1AlirvH4VWsU32jz7kTUnjVleI33dkiHsrLDPO1Vww=.57e84d9f-8dd4-4bdb-901e-d0c519169a29@github.com>
Message-ID: <VPWVAzH25HmFCX2YgUglE7RBDkp5zqCeZHMvovJLp-o=.37869884-80ab-4376-b8f1-2fceed68ee85@github.com>

On Tue, 25 Jun 2024 08:29:42 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Move the tests to module/module_name directory for clearer naming
>  - (C)
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>    
>    # Conflicts:
>    #	test/jdk/TEST.groups
>  - Improve checker report messages
>  - Merge branch 'master' into source-based-since-checker
>  - - removed unused parameter `i`
>    - make rest of methods private
>    - ".toString" instead of "toString"
>    
>    Signed-off-by: Nizar Benalla <nizar.benalla at oracle.com>
>  - Add a few more legacy methods, needed a few more after changes to the checker
>  - checking for null values directly rather than catching NPE
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Now only skipping the common methods that every record class will have, and will never need a new `@since`
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/7baddc20...62aebb0b

I have a couple of small changes after the first approval, mainly improving the error messages. And avoiding false reports in case a file doesn't exist in `src.zip`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2196918888

From alanb at openjdk.org  Fri Jun 28 14:39:24 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Jun 2024 14:39:24 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v5]
In-Reply-To: <JFxVnwSfHRPIBR9Tw9rkO2viNZusJ-8MDL1wH44xEaI=.60fe1572-8c1d-4e20-ad78-e44d549ba15e@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <DrqUPKX-coCjefWEEp8qHguRuiFfX7KH9RAvSGx8O8U=.13c5f8bc-fb81-40b8-9e58-57fadbdab2ea@github.com>
 <JFxVnwSfHRPIBR9Tw9rkO2viNZusJ-8MDL1wH44xEaI=.60fe1572-8c1d-4e20-ad78-e44d549ba15e@github.com>
Message-ID: <ldRYGAiDIQpA5p1scGrttc70ZjOKgpSd7ULj-dZr4Xw=.10adde48-bdbc-44ce-bdb6-23558cb33689@github.com>

On Thu, 20 Jun 2024 19:37:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> It looks like it's possible to get even more custom by using a custom `HelpFormatter` as well, if we wanted.

I think what you have is okay for the first integration, just looks odd to have the help/usage say "String" and "Path". Using a help formatter can be something for a follow-up issue, assuming it feasible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2197088172

From sgehwolf at openjdk.org  Fri Jun 28 15:41:48 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Jun 2024 15:41:48 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v8]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <qwrLCWWzsXHeQy6jM21G7MSXxKroMi-rpUHhk-KCgfc=.ff4e4746-72b3-496f-bd57-4526858e2e31@github.com>

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Refactor mount info matching to helper function
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Remove problem listing of PlainRead which is reworked here
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Add doc for mountinfo scanning.
 - Unify naming of variables
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - ... and 8 more: https://git.openjdk.org/jdk/compare/486aa11e...1017da35

-------------

Changes: https://git.openjdk.org/jdk/pull/18201/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=07
  Stats: 411 lines in 20 files changed: 305 ins; 79 del; 27 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 sgehwolf at openjdk.org  Fri Jun 28 15:45:25 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Jun 2024 15:45:25 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v7]
In-Reply-To: <MoUVyHBhULriXYOy3Oe0DZSGPwDPe2qjR3E_4MDIURE=.559b5686-d2db-4740-8575-0478fbe3222f@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <CQKAmMQi9Ximz_RyCcHItG1XGnH9S2yLzLMN169_Ggc=.baef2e63-911a-40e9-b1fa-01567c8e54de@github.com>
 <MoUVyHBhULriXYOy3Oe0DZSGPwDPe2qjR3E_4MDIURE=.559b5686-d2db-4740-8575-0478fbe3222f@github.com>
Message-ID: <ld2s-c3DUaS_YChrtuPecV0B1We56eqdiviwhZap3DE=.7fedb12d-f695-44a8-b20f-4d582fb8763c@github.com>

On Thu, 27 Jun 2024 18:40:09 GMT, Larry Cable <duke 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 17 commits:
>> 
>>  - Refactor mount info matching to helper function
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - Remove problem listing of PlainRead which is reworked here
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - Add doc for mountinfo scanning.
>>  - Unify naming of variables
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - jcheck fixes
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/baafa662...532ea33b
>
> src/hotspot/share/prims/jvm.cpp line 504:
> 
>> 502: JVM_LEAF(jboolean, JVM_IsContainerized(void))
>> 503: #ifdef LINUX
>> 504:   if (OSContainer::is_containerized()) {
> 
> // nit: personal preference...
> 
> return OSContainer::isContainerized() ? JNI_TRUE : JNI_FALSE;

I've kept this as is, since the suggestion generates this code after preprocessing on Linux:


return OSContainer::is_containerized() ? JNI_TRUE : JNI_FALSE;
return JNI_FALSE;


over the existing version:


if (OSContainer::is_containerized()) {
    return JNI_TRUE;
}
return JNI_FALSE;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1658938198

From sgehwolf at openjdk.org  Fri Jun 28 15:49:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Jun 2024 15:49:21 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v8]
In-Reply-To: <qwrLCWWzsXHeQy6jM21G7MSXxKroMi-rpUHhk-KCgfc=.ff4e4746-72b3-496f-bd57-4526858e2e31@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <qwrLCWWzsXHeQy6jM21G7MSXxKroMi-rpUHhk-KCgfc=.ff4e4746-72b3-496f-bd57-4526858e2e31@github.com>
Message-ID: <BBw7hAO4YMwhzJ04mMoLkDeUB2JXMiY2aS7m59UMEig=.8e89509d-575d-4fcc-b546-0a1299b3c319@github.com>

On Fri, 28 Jun 2024 15:41:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Refactor mount info matching to helper function
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Remove problem listing of PlainRead which is reworked here
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/486aa11e...1017da35

@adinn @iklam Could one of you please help with a second review, please? Not sure if @larry-cable review gets recorded with him having no OpenJDK project role :-/ Thanks in advance!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2197212014

From duke at openjdk.org  Fri Jun 28 16:22:20 2024
From: duke at openjdk.org (duke)
Date: Fri, 28 Jun 2024 16:22:20 GMT
Subject: RFR: 8335252: Reduce size of j.u.Formatter.Conversion#isValid [v4]
In-Reply-To: <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
Message-ID: <c-YwtNPoKA87PNUeIeGFodyjRK_P5UCXNBGyWmYKNIQ=.8e79b51a-0245-4695-aeda-9382b5c539d6@github.com>

On Fri, 28 Jun 2024 12:46:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

@wenshao 
Your change (at version 5707dc675b5b7d4960d3e3121a5c8fe341862d7b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2197261960

From shade at openjdk.org  Fri Jun 28 16:29:28 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jun 2024 16:29:28 GMT
Subject: Integrated: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum
 should be final
In-Reply-To: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
References: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
Message-ID: <cJR1hsa3BzoitTZsGv_NihZNzfiBudvG8NIkurDf8us=.43c2e906-f79f-49c3-8254-5b58b6969d3f@github.com>

On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I was auditing the current uses of `@Stable` before relaxing its barriers ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an easy spot. 
> 
> `resolvedEnum` is not `final`. So technically publishing the object via data race can show `resolvedEnum` as `null`, which would break `test()` that does not expect it. Currently not a practical problem since its safety is covered by adjacent `final` fields, but should be more precise.

This pull request has now been integrated.

Changeset: 45c4eaa5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45c4eaa5600016d3da5ca769b2519df53835e4f7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum should be final

Reviewed-by: liach, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/19933

From psandoz at openjdk.org  Fri Jun 28 16:31:23 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 28 Jun 2024 16:31:23 GMT
Subject: RFR: 8335252: Reduce size of j.u.Formatter.Conversion#isValid [v4]
In-Reply-To: <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
Message-ID: <eUAYqhwSgTJX7GX_j_bpfUZy4_RvdAv5oo_bBMgcE44=.f6d5b3f7-eae2-44dd-9b88-2943c5f54abe@github.com>

On Fri, 28 Jun 2024 12:46:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

That's a clever change and more preferable (but still potentially fragile in the source to bytecode translation process). However I still don't understand the overall motivation, why does it matter?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2197275066

From jlahoda at openjdk.org  Fri Jun 28 16:41:31 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Jun 2024 16:41:31 GMT
Subject: RFR: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum
 should be final
In-Reply-To: <tNRw7n4sDwULFXauPc-6HXGGVVzfUHgAb4ykIWagI1s=.4c1c31b0-e3bb-4333-8d6a-320373843c23@github.com>
References: <rGCIaQ39hiwAjjPBuMIAQt_XR6LWaVcgc9bCFoEVw1I=.89a1e7de-0715-4d76-8e93-55dc026aa539@github.com>
 <tNRw7n4sDwULFXauPc-6HXGGVVzfUHgAb4ykIWagI1s=.4c1c31b0-e3bb-4333-8d6a-320373843c23@github.com>
Message-ID: <L5pirv1GySF5BAkrEq11sKUDx57hONtOIzTW_zN7H1s=.a7683e39-7cfb-42d5-99d3-7b55bb7dc604@github.com>

On Fri, 28 Jun 2024 09:33:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > FWIW, there are more `@Stable` uses here: #19906
> > if you would have a moment to check that, it may be helpful. Thanks.
> 
> That one looks fine: it is set outside of constructor, is intrinsically racy, and it has AFAICS the recovery paths when we read `null` out of `MappedEnumCache.generatedSwitch` or `MappedEnumCache.constantsMap`.

Thanks Aleksey!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19933#issuecomment-2197287772

From alanb at openjdk.org  Fri Jun 28 16:43:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Jun 2024 16:43:26 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v9]
In-Reply-To: <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
Message-ID: <TkGI8C346Y3Kyz7i5CtS3TmA_tTn92WD6fEpYvFRBrY=.99f14de0-c13e-4389-bc26-6a80f2e2f77a@github.com>

On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   de-dupe on path, not module name

test/langtools/tools/jnativescan/TestJNativeScan.java line 33:

> 31:  *     cases.classpath.app.App
> 32:  *     cases.classpath.unnamed_package.UnnamedPackage
> 33:  * @run testng TestJNativeScan

We've using JUnit rather than in TestNG for new tests, this one looks strange forward to move if we want.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659011377

From alanb at openjdk.org  Fri Jun 28 16:50:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Jun 2024 16:50:22 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v9]
In-Reply-To: <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
Message-ID: <iw_TD5m-YV9wgAJR1_2lXFzGVc3LdKJILcDnMDIBuYQ=.70fd7fb1-3466-4e0d-8805-372d3f16d94c@github.com>

On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   de-dupe on path, not module name

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 105:

> 103:                     for (String classPathEntry : classPathAttribute) {
> 104:                         Path otherJar = parentDir != null
> 105:                                 ? parentDir.resolve(classPathEntry)

We'lll need to create a follow on issue to re-examine this as the value of a Class-Path attribute aren't sequence of relative URIs (with an optional "file" URI scheme) rather than file paths. Treating it as a file path may work in some cases but won't work once you encounter cases that use escaping.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659018308

From alanb at openjdk.org  Fri Jun 28 16:57:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Jun 2024 16:57:22 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v9]
In-Reply-To: <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
Message-ID: <mQM8YFhuHK8PaBLn_K_kb_y0W3gp0Bp1jFkqCkDA3KU=.bea4e9b2-30bd-419c-9eab-ba4f298a3bfa@github.com>

On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   de-dupe on path, not module name

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 69:

> 67:         }
> 68:         Configuration config = Configuration.resolveAndBind(moduleFinder, List.of(systemConfiguration()),
> 69:                 ModuleFinder.of(), rootModules);

I think the module path should work like other tools so the "moduleFinder" should be "after" finder, not the "before" finder. In other words, the modules that are observable on the application module path don't override the system modules. If you want you can use an instance method here, like this:

`systemConfiguration().resovleAndBind(ModuleFinder.of(), moduleFinder, rootModules)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659028434

From duke at openjdk.org  Fri Jun 28 17:50:21 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 28 Jun 2024 17:50:21 GMT
Subject: RFR: 8335252: Reduce size of j.u.Formatter.Conversion#isValid [v4]
In-Reply-To: <eUAYqhwSgTJX7GX_j_bpfUZy4_RvdAv5oo_bBMgcE44=.f6d5b3f7-eae2-44dd-9b88-2943c5f54abe@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
 <eUAYqhwSgTJX7GX_j_bpfUZy4_RvdAv5oo_bBMgcE44=.f6d5b3f7-eae2-44dd-9b88-2943c5f54abe@github.com>
Message-ID: <XMCgSTusK80ItnFF4W3wPzYWh7tzPCNXApPKzFFFbS0=.201d6b11-1e57-4564-b673-157266555fde@github.com>

On Fri, 28 Jun 2024 16:29:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix comment
>
> That's a clever change and more preferable (but still potentially fragile in the source to bytecode translation process). However I still don't understand the overall motivation, why does it matter?

@PaulSandoz 
String.format is widely used. In some performance-critical scenarios, when doing performance profiling, it is often found that String.format calls consume a lot of time. My suggestion is to replace `String.format` with `String concat` or StringBuilder.


String info = String.format("xxxx %s", str);


replace to

String info = "xxxx %s" + str;


or

String info = new StringBuilder("xxxx ").append(str).toString();


Let's do a Benchmark comparison:

class StringFormat{
    @Benchmark
    public String stringIntFormat() {
        return "%s %d".formatted(s, i);
    }

    @Benchmark
    public String stringIntIndy() {
        return s + " " + i;
    }

    @Benchmark
    public String stringIntStringBuilder() {
        return new StringBuilder(s).append(" ").append(i).toString();
    }    
}




Benchmark                            Mode  Cnt   Score   Error  Units
StringFormat.stringIntFormat         avgt   15  87.451 ? 2.890  ns/op
StringFormat.stringIntIndy           avgt   15   6.471 ? 0.089  ns/op
StringFormat.stringIntStringBuilder  avgt   15   7.949 ? 0.067  ns/op


It can be seen that the performance of using StringConcat and StringBuilder is 10 times that of using String.format.

StringTemplate (JEP 430/459/465) was an attempt to improve performance, but the API was not friendly.

I was going to contribute to StringTemplate, (PR #16044 / PR #16021/PR #16017,) but StringTemplate has been removed.

I'm working on improving the performance of String.format.

The PR I submitted before: [8316704: Regex-free parsing of Formatter and FormatProcessor specifiers](https://github.com/openjdk/jdk/pull/15776)

This PR is a very minor improvement, We may also need to do further work to provide a fastpath for common scenarios to improve performance. I also plan to do such work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2197391335

From duke at openjdk.org  Fri Jun 28 18:04:23 2024
From: duke at openjdk.org (Larry Cable)
Date: Fri, 28 Jun 2024 18:04:23 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v8]
In-Reply-To: <qwrLCWWzsXHeQy6jM21G7MSXxKroMi-rpUHhk-KCgfc=.ff4e4746-72b3-496f-bd57-4526858e2e31@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <qwrLCWWzsXHeQy6jM21G7MSXxKroMi-rpUHhk-KCgfc=.ff4e4746-72b3-496f-bd57-4526858e2e31@github.com>
Message-ID: <tOHEzP8BDwFR4o_UTGj49qew9e4FQbX4eEaxYjcrky4=.4240719d-1510-4444-b00d-14e8830bf7a3@github.com>

On Fri, 28 Jun 2024 15:41:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Refactor mount info matching to helper function
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Remove problem listing of PlainRead which is reworked here
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/486aa11e...1017da35

On 6/28/24 8:47 AM, Severin Gehwolf wrote:
>
> @adinn 
> <https://urldefense.com/v3/__https://github.com/adinn__;!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9cWG6X3BQ$> 
> @iklam 
> <https://urldefense.com/v3/__https://github.com/iklam__;!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9dyhXpCrw$> 
> Could one of you please help with a second review, please? Not sure if 
> @larry-cable 
> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9cijrbcsw$> 
> review gets recorded with him having no OpenJDK project role :-/ 
> Thanks in advance!
>

yeah sorry - I'm a "newbie" ... only since 1.1 ... :)
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/18201*issuecomment-2197212014__;Iw!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9eqRE9O0w$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67RGGSXHJWFIRNCSGRLZJWARNAVCNFSM6AAAAABEQV4TGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXGIYTEMBRGQ__;!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9fmaD5wrA$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------UaLc7Fb3y3GBgvf0paImu5tU
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 6/28/24 8:47 AM, Severin Gehwolf
      wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/adinn/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/adinn__;!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9cWG6X3BQ$" ***@***.***</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/iklam/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/iklam__;!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9dyhXpCrw$" ***@***.***</a> Could one of you please help
        with a second review, please? Not sure if <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/larry-cable/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9cijrbcsw$" ***@***.***</a> review gets recorded
        with him having no OpenJDK project role :-/ Thanks in advance!</p>
    </blockquote>
    <br>
    yeah sorry - I'm a &quot;newbie&quot; ... only since 1.1 ... :)<br>
    <blockquote type="cite" ***@***.***">
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/18201*issuecomment-2197212014__;Iw!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9eqRE9O0w$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67RGGSXHJWFIRNCSGRLZJWARNAVCNFSM6AAAAABEQV4TGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXGIYTEMBRGQ__;!!ACWV5N9M2RV99hQ!JFioMWt3M387QFQK8UEgSmPMiy736aUVfLbZdVscJ-BDxoO9GjUqLFHtvCkNB5oG3MBadzdxxytGTNNNu9fmaD5wrA$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67R6DREAIZH7GP3I5PTZJWARNA5CNFSM6AAAAABEQV4TGSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUC63FW4.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/18201/c2197212014</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/18201#issuecomment-2197212014",
"url": "https://github.com/openjdk/jdk/pull/18201#issuecomment-2197212014",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------UaLc7Fb3y3GBgvf0paImu5tU--

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2197407053

From jvernee at openjdk.org  Fri Jun 28 19:43:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Jun 2024 19:43:36 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v10]
In-Reply-To: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
Message-ID: <oPEB5t9xHNYtr5HX23hnU-B7wgRHubMCXUChZD3bK4c=.b99657c9-8fe4-461f-8312-5461b49e3b71@github.com>

> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
> 
> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
> 
> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
> 
> 
> app.jar (ALL-UNNAMED):
>   main.Main:
>     main.Main::main(String[])void references restricted methods:
>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>     main.Main::m()void is a native method declaration
> 
> 
> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
> 
> Testing: 
> - `langtools_jnativescan` tests.
> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
> - tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  use instance resolveAndBind + use junit in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19774/files
  - new: https://git.openjdk.org/jdk/pull/19774/files/40ca91ed..c597f247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=08-09

  Stats: 68 lines in 5 files changed: 1 ins; 1 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/19774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774

PR: https://git.openjdk.org/jdk/pull/19774

From jvernee at openjdk.org  Fri Jun 28 19:43:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Jun 2024 19:43:36 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v9]
In-Reply-To: <iw_TD5m-YV9wgAJR1_2lXFzGVc3LdKJILcDnMDIBuYQ=.70fd7fb1-3466-4e0d-8805-372d3f16d94c@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <yp5imM3OzFc7cEf4YvHK74MVIPj2RcNVLOfcabQzPmo=.942af25c-c412-4473-bb42-aab3f08a8769@github.com>
 <iw_TD5m-YV9wgAJR1_2lXFzGVc3LdKJILcDnMDIBuYQ=.70fd7fb1-3466-4e0d-8805-372d3f16d94c@github.com>
Message-ID: <JY3aHYLl3y_QB7mspfOK8IMFywqTFWFRhC0lktDhsEg=.2158b61c-2d18-4efe-8fdd-13a97dead443@github.com>

On Fri, 28 Jun 2024 16:47:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   de-dupe on path, not module name
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 105:
> 
>> 103:                     for (String classPathEntry : classPathAttribute) {
>> 104:                         Path otherJar = parentDir != null
>> 105:                                 ? parentDir.resolve(classPathEntry)
> 
> We'lll need to create a follow on issue to re-examine this as the value of a Class-Path attribute aren't sequence of relative URIs (with an optional "file" URI scheme) rather than file paths. Treating it as a file path may work in some cases but won't work once you encounter cases that use escaping.

Okay, it seems that I didn't read the spec careful enough, and filtering valid URLs in the Class-Path attribute is actually a bit tricky. Let's handle this in a follow up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659242843

From liach at openjdk.org  Fri Jun 28 21:23:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Jun 2024 21:23:27 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v10]
In-Reply-To: <oPEB5t9xHNYtr5HX23hnU-B7wgRHubMCXUChZD3bK4c=.b99657c9-8fe4-461f-8312-5461b49e3b71@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <oPEB5t9xHNYtr5HX23hnU-B7wgRHubMCXUChZD3bK4c=.b99657c9-8fe4-461f-8312-5461b49e3b71@github.com>
Message-ID: <0PHxgNTkRZMje5FnSdeApu9R4hDlfp2hGT-jrdezg5w=.4f198913-4cf0-48fa-9189-4d485905bc91@github.com>

On Fri, 28 Jun 2024 19:43:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use instance resolveAndBind + use junit in tests

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/MethodRef.java line 38:

> 36:     }
> 37: 
> 38:     public static MethodRef ofMemberRefEntry(MemberRefEntry method) {

I recommend to change this to `ofInvokeInstruction`:

public static MethodRef ofInvokeInstruction(InvokeInstruction instruction) {
    return new MethodRef(instruction.owner().asSymbol(),
            instruction.name().stringValue(), instruction.typeSymbol());
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659345527

From liach at openjdk.org  Fri Jun 28 22:06:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Jun 2024 22:06:41 GMT
Subject: RFR: 8335290: Rename ClassFile::transform to ClassFile::transformClass
Message-ID: <5NG5xsfGLEgvpDSJSGtBTOtkkgypIE7UkWTNuUHO3wE=.5bd451ba-398e-4649-8e46-8d87a7f6d91e@github.com>

`ClassFile::transform` was initially `ClassModel::transform`, which transforms the receiver class model to a new class byte array. This functionality was in parallel with `ClassBuilder::transform`, which accepts a `ClassModel` and a `ClassTransform` and forwards the results to the receiver builder.

After the `ClassFile` context object introduction, `ClassModel::transform` becomes `ClassFile::transform`; now, its role is more similar to `ClassBuilder::transformMethod`, `ClassBuilder::transformField`, or `MethodBuilder::transformCode` (transforming subtypes), and it is confusing with `ClassFileBuilder::transform` (which accepts the same model type as the built type). We should rename `ClassFile::transform` to `ClassFile::transformClass` to make this method's role more clear.

This is separate from #19928 as this has much more user impact.

-------------

Commit messages:
 - Doc typo
 - Missed 3 files
 - ClassFile.transform -> transformClass

Changes: https://git.openjdk.org/jdk/pull/19952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335290
  Stats: 177 lines in 58 files changed: 2 ins; 5 del; 170 mod
  Patch: https://git.openjdk.org/jdk/pull/19952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19952/head:pull/19952

PR: https://git.openjdk.org/jdk/pull/19952

From liach at openjdk.org  Fri Jun 28 22:30:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Jun 2024 22:30:22 GMT
Subject: RFR: 8335252: Reduce size of j.u.Formatter.Conversion#isValid [v4]
In-Reply-To: <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
Message-ID: <1ekPqdcatJLtu06-Wn8X47iq6pSINBBj6PRRhQ0Pk7Q=.ea7385d9-3d08-4227-a122-a9ce0ee6e3e9@github.com>

On Fri, 28 Jun 2024 12:46:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

Thanks Wen Shaojin. Though in the long term we would avoid repeated parsing, this little optimization to speed up parsing is still very useful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2197731180

From duke at openjdk.org  Fri Jun 28 22:30:22 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 28 Jun 2024 22:30:22 GMT
Subject: Integrated: 8335252: Reduce size of j.u.Formatter.Conversion#isValid
In-Reply-To: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
Message-ID: <FReTBfXkow6HpkNA4tTLqyNMqnelICi0LFI3yg4HXCE=.6529cd46-f441-4af6-9eca-d3ae354a59ea@github.com>

On Thu, 27 Jun 2024 11:14:30 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
> 
> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
> 
> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
> 
> 
> current version
> 
> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)

This pull request has now been integrated.

Changeset: 5d866bf1
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d866bf17d96bd0f0e4545d7eee5912eda2e3a94
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8335252: Reduce size of j.u.Formatter.Conversion#isValid

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/19926

From naoto at openjdk.org  Fri Jun 28 22:49:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Jun 2024 22:49:29 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v14]
In-Reply-To: <qOVDXoFneudZhSqvCcLNuNYTZPYtZHrmE-sqgUmkFtg=.9a860676-b261-4235-9f82-a62161d9698c@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <qOVDXoFneudZhSqvCcLNuNYTZPYtZHrmE-sqgUmkFtg=.9a860676-b261-4235-9f82-a62161d9698c@github.com>
Message-ID: <BWdMn3IZdrxUM8FazC4TInUZYhQhdpleTDdmIgx_3J0=.a6e678aa-f520-4720-b373-967f8ddb3551@github.com>

On Fri, 28 Jun 2024 04:12:08 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic instructions.  But when run with JDK 11, there is no such problem. The reason is the removed biased locking.  
>> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods.
>> So I added support for some new methods that accept StringBuilder which is lock-free.
>> 
>> ### Benchmark testcase
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class JmhDecimalFormat {
>> 
>>     private DecimalFormat format;
>> 
>>     @Setup(Level.Trial)
>>     public void setup() {
>>         format = new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testNewAndFormat() throws InterruptedException {
>>         new DecimalFormat("#0.00000").format(9524234.1236457);
>>     }
>> 
>>     @Benchmark
>>     public void testNewOnly() throws InterruptedException {
>>         new DecimalFormat("#0.00000");
>>     }
>> 
>>     @Benchmark
>>     public void testFormatOnly() throws InterruptedException {
>>         format.format(9524234.1236457);
>>     }
>> }
>> 
>> 
>> ### Test result
>> #### Current JDK before optimize
>> 
>>  Benchmark                             Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly       avgt   50  642.099 ? 1.253  ns/op
>> JmhDecimalFormat.testNewAndFormat     avgt   50  989.307 ? 3.676  ns/op
>> JmhDecimalFormat.testNewOnly          avgt   50  303.381 ? 5.252  ns/op
>> 
>> 
>> 
>> #### Current JDK after optimize
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  351.499 ? 0.761  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  615.145 ? 2.478  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
>> 
>> 
>> ### JDK 11 
>> 
>> Benchmark                          Mode  Cnt    Score   Error  Units
>> JmhDecimalFormat.testFormatOnly    avgt   50  364.214 ? 1.191  ns/op
>> JmhDecimalFormat.testNewAndFormat  avgt   50  658.699 ? 2.311  ns/op
>> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
>
> lingjun-cg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8333396: Performance regression of DecimalFormat.format
>  - 8333396: Performance regression of DecimalFormat.format

Changes requested by naoto (Reviewer).

test/micro/org/openjdk/bench/java/text/DateFormatterBench.java line 9:

> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided
> 9:  * by Oracle in the LICENSE file that accompanied this code.

Copyright headers for test cases should not include this "classpath exception" clause. Applies to all new added test files.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2149080183
PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1659387122

From iris at openjdk.org  Fri Jun 28 23:21:32 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 28 Jun 2024 23:21:32 GMT
Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v14]
In-Reply-To: <BWdMn3IZdrxUM8FazC4TInUZYhQhdpleTDdmIgx_3J0=.a6e678aa-f520-4720-b373-967f8ddb3551@github.com>
References: <Eb-QepVk7_AKdSskWBEPieDbKEBYIrbg1H-EXvgyaXg=.c0dd5641-a3e0-45ac-ba0b-55d2413a7bb1@github.com>
 <qOVDXoFneudZhSqvCcLNuNYTZPYtZHrmE-sqgUmkFtg=.9a860676-b261-4235-9f82-a62161d9698c@github.com>
 <BWdMn3IZdrxUM8FazC4TInUZYhQhdpleTDdmIgx_3J0=.a6e678aa-f520-4720-b373-967f8ddb3551@github.com>
Message-ID: <27UZpRdOkTUJqnXHfEivFtATVqSXXQXy6HjrdmpyBWI=.5d17e17c-a9c5-4ed1-887d-7a9c45a5b30a@github.com>

On Fri, 28 Jun 2024 22:46:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8333396: Performance regression of DecimalFormat.format
>>  - 8333396: Performance regression of DecimalFormat.format
>
> test/micro/org/openjdk/bench/java/text/DateFormatterBench.java line 9:
> 
>> 7:  * published by the Free Software Foundation.  Oracle designates this
>> 8:  * particular file as subject to the "Classpath" exception as provided
>> 9:  * by Oracle in the LICENSE file that accompanied this code.
> 
> Copyright headers for test cases should not include this "classpath exception" clause. Applies to all new added test files.

GPL template available here: https://github.com/openjdk/jdk/blob/master/make/data/license-templates/gpl-header

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1659399065

From alanb at openjdk.org  Sat Jun 29 06:29:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Jun 2024 06:29:20 GMT
Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of
 restricted methods [v10]
In-Reply-To: <oPEB5t9xHNYtr5HX23hnU-B7wgRHubMCXUChZD3bK4c=.b99657c9-8fe4-461f-8312-5461b49e3b71@github.com>
References: <M9GiykCRzMpzWTtKFlnhUuL6oOKOGtgOIL_S2WcKzTQ=.8baa1e26-cc3a-4890-b754-35d426f0cf22@github.com>
 <oPEB5t9xHNYtr5HX23hnU-B7wgRHubMCXUChZD3bK4c=.b99657c9-8fe4-461f-8312-5461b49e3b71@github.com>
Message-ID: <xXKOYjZISSSRkKplPNbHcXDNycXqEPWZc65eU0NUaCE=.73d5145d-c77b-4021-a5d0-a15ed27555d0@github.com>

On Fri, 28 Jun 2024 19:43:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use instance resolveAndBind + use junit in tests

Thanks for all the work on this, it will be useful to have this tool in the JDK. I don't have any other comments. I assume you'll create follow-up issues in JBS for the Class-Path attribute, improvement the usage/help output to replace the "Path"/"String" types.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2149370644

From redestad at openjdk.org  Sat Jun 29 08:29:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 29 Jun 2024 08:29:21 GMT
Subject: RFR: 8335252: Reduce size of j.u.Formatter.Conversion#isValid [v4]
In-Reply-To: <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
References: <q_7K-VA76gUqgy-6RnUl0VmS4likozEnWF-EQsG_Skg=.0fba77db-ffd9-480e-bb37-698528ba46db@github.com>
 <FI4ydS0SHFr7Jr01rQmviyH5lsvxbKlhlpnitiXUmys=.c2cebd7c-98de-4de8-bc01-e1421705dc63@github.com>
Message-ID: <Iyr1YMooK9W33YuhIIOlDodt6Jljv0Urrdni0a5sryg=.d9545d57-8448-4184-91b6-c1f33fbf0626@github.com>

On Fri, 28 Jun 2024 12:46:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate.
>> 
>> use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master branch:
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (358 bytes)   failed to inline: hot method too big
>> 
>> 
>> current version
>> 
>> @ 109   java.util.Formatter$Conversion::isValid (10 bytes)   inline (hot)
>>   @ 4   jdk.internal.util.ImmutableBitSetPredicate$SmallImmutableBitSetPredicate::test (50 bytes)   inline (hot)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

I agree with improving the legacy `String.format` code, within reason due it's wide use and appeal. Doing so does not detract from the goal of providing smarter and faster formatting via `StringTemplates`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19926#issuecomment-2198045830

From duke at openjdk.org  Sat Jun 29 12:01:29 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 29 Jun 2024 12:01:29 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath
Message-ID: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>

We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.

This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.

The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.

Below is a comparison of String.format and concat-based and StringBuilder:

* benchmark java code

public class StringFormat {
    @Benchmark
    public String stringIntFormat() {
        return "%s %d".formatted(s, i);
    }

    @Benchmark
    public String stringIntConcat() {
        return s + " " + i;
    }

    @Benchmark
    public String stringIntStringBuilder() {
        return new StringBuilder(s).append(" ").append(i).toString();
    }
}


* benchmark number on macbook m1 pro

Benchmark                            Mode  Cnt   Score   Error  Units
StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op


>From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.

The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.

d
x
X
s

If necessary, we can add a few more.


Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.

-Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
-StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
-StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
-StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
-StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
-StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
-StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op

+Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
+StringFormat.complexFormat         avgt   15  863.156 ? 42.140  ns/op
+StringFormat.decimalFormat         avgt   15  287.342 ? 19.896  ns/op
+StringFormat.stringFormat          avgt   15    6.738 ?  0.027  ns/op
+StringFormat.stringIntFormat       avgt   15   17.046 ?  0.090  ns/op
+StringFormat.widthStringFormat     avgt   15    8.993 ?  0.073  ns/op
+StringFormat.widthStringIntFormat  avgt   15   17.602 ?  0.014  ns/op

-------------

Commit messages:
 - String.format fastpath

Changes: https://git.openjdk.org/jdk/pull/19956/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335366
  Stats: 362 lines in 3 files changed: 356 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Sat Jun 29 12:24:21 2024
From: duke at openjdk.org (Glavo)
Date: Sat, 29 Jun 2024 12:24:21 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <wfb-Ey4bVb7bZ2I_D9l0kiOV-Px6FfAfXtITtQNTtGY=.593c8dcf-c439-4ea2-a462-44e064e9610e@github.com>

On Sat, 29 Jun 2024 11:53:31 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

src/java.base/share/classes/java/lang/StringFormat.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Alibaba Group Holding Limited. All Rights Reserved.

Suggestion:

 * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659804684

From duke at openjdk.org  Sat Jun 29 16:49:20 2024
From: duke at openjdk.org (David Schlosnagle)
Date: Sat, 29 Jun 2024 16:49:20 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <Z5Zi3l6ceRhNo3nxmCWyQGVEt5Cnaoh9Ee4IZ4xo1mw=.6e3bb2a4-f0d5-4c6f-8f19-e82cb2146e42@github.com>

On Sat, 29 Jun 2024 11:53:31 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

src/java.base/share/classes/java/lang/StringFormat.java line 65:

> 63:         int max = format.length();
> 64:         int off = format.indexOf('%');
> 65:         if (off == -1 || off + 1 == max) {

If there is no `%` in the format string, should this just return the format string as result?

Suggestion:

        int off = format.indexOf('%');
        if (off == -1) {
            // no formatting to be done
            return format;
        }

        int max = format.length();
        if (off + 1 == max) {

src/java.base/share/classes/java/lang/StringFormat.java line 82:

> 80:                 conv = format.charAt(off + 2);
> 81:             }
> 82:         }

is it worth handling `width > 9`?

Suggestion:

        for (int i = 2; conv >= '1' && conv <= '9' && off + i < max; i++) {
            width = (width * 10) + (conv - '0');
            if (off + i < max) {
                conv = format.charAt(off + i);
            }
        }

src/java.base/share/classes/java/lang/StringFormat.java line 90:

> 88:         if (conv == STRING) {
> 89:             arg = String.valueOf(arg);
> 90:         }

should these conditions be combined?

Suggestion:

        if (conv == STRING) {
            if (isBigInt(arg)) {
                conv = DECIMAL_INTEGER;
            } else {
                arg = String.valueOf(arg);
            }
        }

src/java.base/share/classes/java/lang/StringFormat.java line 102:

> 100:         int max = format.length();
> 101:         int off0 = format.indexOf('%');
> 102:         if (off0 == -1 || off0 + 1 == max) {

similar to above, if `%` is not found, return `format`

Suggestion:

        int off0 = format.indexOf('%');
        if (off0 == -1) {
            // no formatting to be done
            return format;
        }

        int max = format.length();
        if (off0 + 1 == max) {

src/java.base/share/classes/java/lang/StringFormat.java line 110:

> 108:             width0 = conv0 - '0';
> 109:             if (off0 + 2 < max) {
> 110:                 conv0 = format.charAt(off0 + 2);

is it worth handling `width0 > 9`?

Suggestion:

        for (int i = 2; conv0 >= '1' && conv0 <= '9' && off0 + i < max; i++) {
            width0 = (width0 * 10) + (conv0 - '0');
            if (off0 + i < max) {
                conv0 = format.charAt(off0 + i);

src/java.base/share/classes/java/lang/StringFormat.java line 123:

> 121:             width1 = conv1 - '0';
> 122:             if (off1 + 2 < max) {
> 123:                 conv1 = format.charAt(off1 + 2);

is it worth handling `width1 > 9`?

Suggestion:

        for (int i = 2; conv1 >= '1' && conv1 <= '9' && off1 + i < max; i++) {
            width1 = (width1 * 10) + (conv1 - '0');
            if (off1 + i < max) {
                conv1 = format.charAt(off1 + i);

src/java.base/share/classes/java/lang/StringFormat.java line 151:

> 149:             coder |= str.coder();
> 150:             arg1 = String.valueOf(str);
> 151:         }

similar to above, should these conditions be consolidated?

Suggestion:

        String str;
        byte coder = format.coder();
        if (conv0 == STRING) {
            if (isBigInt(arg0)) {
                conv0 = DECIMAL_INTEGER;
            } else {
                str = String.valueOf(arg0);
                coder |= str.coder();
                arg0 = str;
            }
        }

        if (conv1 == STRING) {
            if (isBigInt(arg1)) {
                conv1 = DECIMAL_INTEGER;
            } else {
                str = String.valueOf(arg1);
                coder |= str.coder();
                arg1 = String.valueOf(str);
            }
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659880719
PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659888420
PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659881435
PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659882380
PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659888524
PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659888863
PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659882487

From duke at openjdk.org  Sat Jun 29 17:20:48 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 29 Jun 2024 17:20:48 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v2]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <UdPyTZRZtFLtnA4aUibv9Nb5mHI_W3LYSJVZua0O4Kc=.b4b35107-5967-4ad9-ba75-fc95f631005d@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/StringFormat.java
   
   Co-authored-by: David Schlosnagle <schlosna at gmail.com>
 - Update src/java.base/share/classes/java/lang/StringFormat.java
   
   Co-authored-by: David Schlosnagle <schlosna at gmail.com>
 - Update src/java.base/share/classes/java/lang/StringFormat.java
   
   Co-authored-by: David Schlosnagle <schlosna at gmail.com>
 - Update src/java.base/share/classes/java/lang/StringFormat.java
   
   Co-authored-by: David Schlosnagle <schlosna at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/f925339e..6a3dd494

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=00-01

  Stats: 49 lines in 1 file changed: 26 ins; 14 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Sat Jun 29 17:23:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 29 Jun 2024 17:23:18 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v2]
In-Reply-To: <Z5Zi3l6ceRhNo3nxmCWyQGVEt5Cnaoh9Ee4IZ4xo1mw=.6e3bb2a4-f0d5-4c6f-8f19-e82cb2146e42@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <Z5Zi3l6ceRhNo3nxmCWyQGVEt5Cnaoh9Ee4IZ4xo1mw=.6e3bb2a4-f0d5-4c6f-8f19-e82cb2146e42@github.com>
Message-ID: <5vWWpl0sbv1fMKUkZTV1XvKeSw40nzFh_WoRvfxgFtE=.e16ffd86-488e-4411-8ef3-511a3dbfafe8@github.com>

On Sat, 29 Jun 2024 16:17:32 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/java/lang/StringFormat.java
>>    
>>    Co-authored-by: David Schlosnagle <schlosna at gmail.com>
>>  - Update src/java.base/share/classes/java/lang/StringFormat.java
>>    
>>    Co-authored-by: David Schlosnagle <schlosna at gmail.com>
>>  - Update src/java.base/share/classes/java/lang/StringFormat.java
>>    
>>    Co-authored-by: David Schlosnagle <schlosna at gmail.com>
>>  - Update src/java.base/share/classes/java/lang/StringFormat.java
>>    
>>    Co-authored-by: David Schlosnagle <schlosna at gmail.com>
>
> src/java.base/share/classes/java/lang/StringFormat.java line 110:
> 
>> 108:             width0 = conv0 - '0';
>> 109:             if (off0 + 2 < max) {
>> 110:                 conv0 = format.charAt(off0 + 2);
> 
> is it worth handling `width0 > 9`?
> 
> Suggestion:
> 
>         for (int i = 2; conv0 >= '1' && conv0 <= '9' && off0 + i < max; i++) {
>             width0 = (width0 * 10) + (conv0 - '0');
>             if (off0 + i < max) {
>                 conv0 = format.charAt(off0 + i);

This is the fastpath code. I think it doesn't need to handle width > 9. Keep it small enough to reduce the fallback cost and leave room for supporting more others.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659912461

From duke at openjdk.org  Sat Jun 29 17:36:48 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 29 Jun 2024 17:36:48 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v3]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <snLMRykzc9aRHS-uTZNbBiWGR1CdsL_xEkMxFdwOmak=.3b5cc444-97d1-4521-bd83-338b45d4520e@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  rename `digit` to `width`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/6a3dd494..e1ed3706

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Sat Jun 29 17:44:19 2024
From: duke at openjdk.org (David Schlosnagle)
Date: Sat, 29 Jun 2024 17:44:19 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v3]
In-Reply-To: <Z5Zi3l6ceRhNo3nxmCWyQGVEt5Cnaoh9Ee4IZ4xo1mw=.6e3bb2a4-f0d5-4c6f-8f19-e82cb2146e42@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <Z5Zi3l6ceRhNo3nxmCWyQGVEt5Cnaoh9Ee4IZ4xo1mw=.6e3bb2a4-f0d5-4c6f-8f19-e82cb2146e42@github.com>
Message-ID: <wxzXejKO9WxbF3IsNYMGXIleJDbNZ4I-3tosDcv-H3c=.385afb44-7f4b-408e-a10d-fdf34e51d879@github.com>

On Sat, 29 Jun 2024 16:16:51 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename `digit` to `width`
>
> src/java.base/share/classes/java/lang/StringFormat.java line 82:
> 
>> 80:                 conv = format.charAt(off + 2);
>> 81:             }
>> 82:         }
> 
> is it worth handling `width > 9`?
> 
> Suggestion:
> 
>         for (int i = 2; conv >= '1' && conv <= '9' && off + i < max; i++) {
>             width = (width * 10) + (conv - '0');
>             if (off + i < max) {
>                 conv = format.charAt(off + i);
>             }
>         }

a quick local benchmark on 2021 MacBook M1 Pro before/after motivating this:


    @Benchmark
    public String wideStringIntFormat() {
        return "%123s %42d".formatted(s, i);
    }


#### Before:

Benchmark                          Mode  Cnt    Score    Error  Units
StringFormat.wideStringIntFormat   avgt   15  377.603 ? 85.742  ns/op


#### After:

Benchmark                          Mode  Cnt    Score    Error  Units
StringFormat.wideStringIntFormat   avgt   15   54.104 ?  0.079  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659916636

From eirbjo at openjdk.org  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into zipentry-external-attributes
 - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes
 - 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

-------------

Changes: https://git.openjdk.org/jdk/pull/16952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=04
  Stats: 56 lines in 12 files changed: 0 ins; 4 del; 52 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  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <9mdtCM7usK43fFPhH1w4Et3xYPtlqwwBYq6OWPfVa9A=.fb4d8f4e-250d-4dc6-a1ce-446f09bb00f5@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
 <9mdtCM7usK43fFPhH1w4Et3xYPtlqwwBYq6OWPfVa9A=.fb4d8f4e-250d-4dc6-a1ce-446f09bb00f5@github.com>
Message-ID: <gKjp0nyzMBkSSTPjb8AFIw1FbpHVyJmwn-25t4eOGxA=.c95e9ca2-45c8-4b36-95cb-403827f7f5b9@github.com>

On Sun, 12 May 2024 14:37:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> I believe this field only captures the 2 bytes at higher indices of External File Attribute; it's not the complete 4-byte external file attributes and this value is not captured unless "Version made by" field's larger index byte (byte 5) is 3. So this name may still be imperfect.

The purpose of this PR was mainly to reduce the risk of confusion with the "extra field", which is an entirely unrelated concept.

While I agree that the name `externalFileAttributes` might not express the full semantics of the field perfectly, I'm honestly not sure which name would, given that `APPNOTE.TXT` is pretty opaque in describing what these two bytes express, and as you point out, the field only carries data when "Version Made By" indicates Unix.

Instead of trying to find name which covers the full semantics, I suggest that we keep `externalFileAttributes` and instead seek to improve the comments relevant to this field:

* The field comment currently says `// File type, setuid, setgid, sticky, POSIX permissions`, we could prepend something clarifying that the field only carries data for Unix entries.
* Line 699 says `// read all bits in this field, including sym link attributes`, this could be improved to clarify that only the higher two "unix-bytes" are read ("all bits in this field" is a bit unclear now)
* Line 700 masks off the Unix bytes with `0xFFFF`, this isn't strictly necessary since `CENATX_PERMS` already only reads the two bytes we want. Perhaps clearer just to drop this masking.
* `ZipUtils.CENATX_PERMS` reads the full 16 bits of the Unix external file attributes, not just the permissions. The current name is confusing.

Since I don't want to delay the integration of the this PR any further, I suggest we tackle the above clarifications in a follow-up PR. Would that be ok with you, @liach ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198283812

From eirbjo at openjdk.org  Sat Jun 29 18:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 29 Jun 2024 18:24:46 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <iF6bpMXAAU3joVhZJwGU3bTPx6dBEZnYAtHgY-sJCPE=.6ffacb24-ab34-48d2-8120-68dd93a60dba@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
 <iF6bpMXAAU3joVhZJwGU3bTPx6dBEZnYAtHgY-sJCPE=.6ffacb24-ab34-48d2-8120-68dd93a60dba@github.com>
Message-ID: <J7HUrQoDGQzfTPObFhpkvw4GcDJ9PGXwvRQ6gj79Bx4=.69c20e3b-1d15-403d-8ed6-303116691a24@github.com>

On Thu, 9 May 2024 12:00:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Eirik, it will be better to merge with the latest master branch and run the tier tests before integrating.

Life happened, but I have now merged with the latest master and GHA runs green.

Did you want to run additional testing before integration @jaikiran ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198284302

From duke at openjdk.org  Sat Jun 29 18:36:52 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 29 Jun 2024 18:36:52 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v19]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <oMORwAG5hGMuZAYv1Kuw9P_em13sDe36T7XTmajjaW0=.aef9a37f-ae7d-458f-9de3-c6f43f43847a@github.com>

> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
> 
> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow,  consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  An optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/781ad35b..af3a36fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=17-18

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710

PR: https://git.openjdk.org/jdk/pull/19710

From duke at openjdk.org  Sat Jun 29 18:50:49 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 29 Jun 2024 18:50:49 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v4]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <Tqw0rQsLAikLYTWTwR0YJCT084DxW2ELFYllospdrfg=.c8bbac6a-8e1e-4f76-8507-f0f931d0e3e7@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Extract the same precondition check to the format method & reduce duplication of code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/e1ed3706..5bcbb358

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=02-03

  Stats: 91 lines in 1 file changed: 25 ins; 44 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Sat Jun 29 18:55:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 29 Jun 2024 18:55:18 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v4]
In-Reply-To: <wxzXejKO9WxbF3IsNYMGXIleJDbNZ4I-3tosDcv-H3c=.385afb44-7f4b-408e-a10d-fdf34e51d879@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <Z5Zi3l6ceRhNo3nxmCWyQGVEt5Cnaoh9Ee4IZ4xo1mw=.6e3bb2a4-f0d5-4c6f-8f19-e82cb2146e42@github.com>
 <wxzXejKO9WxbF3IsNYMGXIleJDbNZ4I-3tosDcv-H3c=.385afb44-7f4b-408e-a10d-fdf34e51d879@github.com>
Message-ID: <jyfYZnY_pogIveBp_J4Cc3znZXVof9XN9uFA7V-hAUI=.3cccad4a-207d-4e7e-97de-0db42f971a1c@github.com>

On Sat, 29 Jun 2024 17:41:47 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringFormat.java line 82:
>> 
>>> 80:                 conv = format.charAt(off + 2);
>>> 81:             }
>>> 82:         }
>> 
>> is it worth handling `width > 9`?
>> 
>> Suggestion:
>> 
>>         for (int i = 2; conv >= '1' && conv <= '9' && off + i < max; i++) {
>>             width = (width * 10) + (conv - '0');
>>             if (off + i < max) {
>>                 conv = format.charAt(off + i);
>>             }
>>         }
>
> a quick local benchmark on 2021 MacBook M1 Pro before/after motivating this:
> 
> 
>     @Benchmark
>     public String wideStringIntFormat() {
>         return "%123s %42d".formatted(s, i);
>     }
> 
> 
> #### Before:
> 
> Benchmark                          Mode  Cnt    Score    Error  Units
> StringFormat.wideStringIntFormat   avgt   15  377.603 ? 85.742  ns/op
> 
> 
> #### After:
> 
> Benchmark                          Mode  Cnt    Score    Error  Units
> StringFormat.wideStringIntFormat   avgt   15   54.104 ?  0.079  ns/op

But this is a fastpath optimization, is width > 9 common enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659951995

From duke at openjdk.org  Sat Jun 29 18:59:33 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 29 Jun 2024 18:59:33 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v5]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <dxGqb52sEIabP7XtXOAlM1BwLI0mXPvXStlpJPGT2pM=.8b46beeb-83e2-46a4-a28b-9b06ff8e82eb@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  private method & field

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/5bcbb358..39ef5815

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=03-04

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Sat Jun 29 19:08:18 2024
From: duke at openjdk.org (David Schlosnagle)
Date: Sat, 29 Jun 2024 19:08:18 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v5]
In-Reply-To: <dxGqb52sEIabP7XtXOAlM1BwLI0mXPvXStlpJPGT2pM=.8b46beeb-83e2-46a4-a28b-9b06ff8e82eb@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <dxGqb52sEIabP7XtXOAlM1BwLI0mXPvXStlpJPGT2pM=.8b46beeb-83e2-46a4-a28b-9b06ff8e82eb@github.com>
Message-ID: <XvxdHZ6HK3LQOjSAl82GKsP6Df_o2G9dNAjzMUakG8g=.996a0d37-f1cb-49b7-9bbb-403a94bde1b2@github.com>

On Sat, 29 Jun 2024 18:59:33 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   private method & field

src/java.base/share/classes/java/lang/StringFormat.java line 48:

> 46:     static String format(String format, Object... args) {
> 47:         if (args != null) {
> 48:             int off = format.indexOf('%');

nit: instead of not null check, should this short circuit for null/empty args?

Suggestion:

        if (args == null || args.length == 0) {
            // no formatting to be done
            return format;
        }

        int off = format.indexOf('%');

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659962265

From duke at openjdk.org  Sat Jun 29 19:13:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 29 Jun 2024 19:13:18 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v5]
In-Reply-To: <XvxdHZ6HK3LQOjSAl82GKsP6Df_o2G9dNAjzMUakG8g=.996a0d37-f1cb-49b7-9bbb-403a94bde1b2@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <dxGqb52sEIabP7XtXOAlM1BwLI0mXPvXStlpJPGT2pM=.8b46beeb-83e2-46a4-a28b-9b06ff8e82eb@github.com>
 <XvxdHZ6HK3LQOjSAl82GKsP6Df_o2G9dNAjzMUakG8g=.996a0d37-f1cb-49b7-9bbb-403a94bde1b2@github.com>
Message-ID: <MK2ILgiqEYFTycQxK8od9ijAkhB7S-YkheXKHrPsQvs=.67965446-9b1c-485c-bf6e-a6c8fe78e378@github.com>

On Sat, 29 Jun 2024 19:05:18 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   private method & field
>
> src/java.base/share/classes/java/lang/StringFormat.java line 48:
> 
>> 46:     static String format(String format, Object... args) {
>> 47:         if (args != null) {
>> 48:             int off = format.indexOf('%');
> 
> nit: instead of not null check, should this short circuit for null/empty args?
> 
> Suggestion:
> 
>         if (args == null || args.length == 0) {
>             // no formatting to be done
>             return format;
>         }
> 
>         int off = format.indexOf('%');

j.u.Formatter supports args == null

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1659964303

From duke at openjdk.org  Sun Jun 30 04:35:55 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 30 Jun 2024 04:35:55 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v6]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <NgTdZVkBF54elAjD96BKSCqe40gJLsbrD3VXapXEpJA=.0e8d4d78-d263-4fbf-8cf5-c0b9304940ec@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - isBigInt -> isLong
 - Fix localization of number formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/39ef5815..cafa25ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=04-05

  Stats: 41 lines in 1 file changed: 28 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From jpai at openjdk.org  Sun Jun 30 04:51:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 30 Jun 2024 04:51:31 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
Message-ID: <A1CrpCUTWpIWJYwh0OPZHZAvHkkyuOm9WIga5jl2tRs=.c23b1d13-e7f5-4b41-a392-feceae50606e@github.com>

On Sat, 29 Jun 2024 18:24:46 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes
>  - 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

Hello Eirik, I'll run some tests and review this PR this coming week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2198432408

From duke at openjdk.org  Sun Jun 30 04:54:35 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 30 Jun 2024 04:54:35 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v7]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <_UZLKTzQAzx47QJKLVohkzF71r8PH0yXjg6-vr7iJ7o=.79ffc36c-356a-44a2-971d-27795c6af56a@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  laze init for `decimal fast path locale`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/cafa25ed..6163e864

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=05-06

  Stats: 53 lines in 1 file changed: 29 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From iklam at openjdk.org  Sun Jun 30 05:51:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 30 Jun 2024 05:51:22 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v8]
In-Reply-To: <qwrLCWWzsXHeQy6jM21G7MSXxKroMi-rpUHhk-KCgfc=.ff4e4746-72b3-496f-bd57-4526858e2e31@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <qwrLCWWzsXHeQy6jM21G7MSXxKroMi-rpUHhk-KCgfc=.ff4e4746-72b3-496f-bd57-4526858e2e31@github.com>
Message-ID: <BVZmF7hkQCPjwiidXvF4g4t5VlFxbmbXiqy-WsvBun0=.f52aca24-c156-4ffa-b9e4-d6f98f5eb6f8@github.com>

On Fri, 28 Jun 2024 15:41:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Refactor mount info matching to helper function
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Remove problem listing of PlainRead which is reworked here
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Add doc for mountinfo scanning.
>  - Unify naming of variables
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/486aa11e...1017da35

Looks reasonable to me

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18201#pullrequestreview-2149956104

From eirbjo at gmail.com  Sun Jun 30 07:20:34 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 30 Jun 2024 09:20:34 +0200
Subject: java.util.zip.ZipError seems unused
Message-ID: <CA+pBWhvP14V=w3de0cPBsaEAFTPfSMtuLtqOzraS7RdDMD75zg@mail.gmail.com>

Hi!

The java.util.zip.ZipError class seems unused in OpenJDK. I assume this is
legacy from the native ZIP implementation in Java 8.

This exception class extends InternalError and seems to have been added in
Java 6 to help compatibility with existing code catching InternalError
(JDK-4615343)

This change also introduced the TestZipError test, which verified that
ZipError was thrown while enumerating a ZIP file which was changed after
being opened. The reimplementation of the ZIP implementation to Java
(JDK-8145260) updated this test to expect a ZipException instead of the
ZipError.

Given that this class has now fallen out of use in OpenJDK, should we:

1: Deprecate it
2: Deprecate it for removal
3: Do nothing, keeping it around has a low cost
4: Something else

It would also be useful if someone with access to a large code corpus could
search for usages of this class so we could assess compatibility concerns
of removing it.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240630/bae47502/attachment.htm>

From duke at openjdk.org  Sun Jun 30 10:07:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 30 Jun 2024 10:07:18 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v7]
In-Reply-To: <_UZLKTzQAzx47QJKLVohkzF71r8PH0yXjg6-vr7iJ7o=.79ffc36c-356a-44a2-971d-27795c6af56a@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <_UZLKTzQAzx47QJKLVohkzF71r8PH0yXjg6-vr7iJ7o=.79ffc36c-356a-44a2-971d-27795c6af56a@github.com>
Message-ID: <EJ_UpZBuC6GRlWZ3imiWpNDvg_GfeUJISSBjESr23hk=.5a5f05e1-ff07-4c9e-8a75-2c3c10d9a48c@github.com>

On Sun, 30 Jun 2024 04:54:35 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   laze init for `decimal fast path locale`

In most cases when calling String.format, the format parameter is a constant. Is there any chance that C2 can optimize this?


void my_func() {
    String str;
    int d;

    // ..

    String info = "info %s  %d".formatted(str, d);
}

final class StringFormat {
    final class StringFormat {
        @ForceInline
        static String format(String format, Object... args) {
            if (args != null) { // 1 
                int off = format.indexOf('%'); // 2
                if (off == -1) { // 3
                    return format;
                }

                int len = format.length(); // 4
                if (off + 1 != len) { // 5
                    int off1 = format.indexOf('%', off + 2); // 6
                    String s = null;
                    if (args.length == 1) { // 7
                        if (off1 == -1) { // 8
                            s = format1(format, off, args[0]);
                        }
                    } else if (args.length == 2) { // 9
                        if (off1 != -1 && off1 + 1 != len) { // 10
                            s = format2(format, off, off1, args[0], args[1]);
                        }
                    }
                    if (s != null) {
                        return s;
                    }
                }
            }

            return new Formatter().format(format, args).toString();
        }

        private static String format1(String format, int off, Object arg) {
            int len = format.length(); // 11
            char conv = format.charAt(off + 1); //12
            int width = 0;
            if (conv >= '1' && conv <= '9') { // 13
                width = conv - '0'; // 14
                if (off + 2 < len) { // 15
                    conv = format.charAt(off + 2); // 16
                }
            }

            if (conv == STRING) { // 17
                if (isLong(arg)) {
                    conv = DECIMAL_INTEGER;
                } else {
                    arg = String.valueOf(arg);
                }
            }

            int size = stringSize(conv, arg);
            if (size == -1) {
                return null;
            }
            return format1(format, off, conv, arg, width, size);
        }
    }
}

The 18 places in the code that can be optimized by C2 can further improve performance

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2198505435

From vklang at openjdk.org  Sun Jun 30 10:18:22 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sun, 30 Jun 2024 10:18:22 GMT
Subject: RFR: 8327854: Test
 java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java
 failed with RuntimeException
In-Reply-To: <XE6lPDBjL0xi1Fc1AtuqboMDM9EdeD1wq_O3NcXMj0Q=.acaacd2d-7a06-40d0-8208-8719b39721e0@github.com>
References: <XE6lPDBjL0xi1Fc1AtuqboMDM9EdeD1wq_O3NcXMj0Q=.acaacd2d-7a06-40d0-8208-8719b39721e0@github.com>
Message-ID: <nyGN7EsJ-R8UOWm_XFY4e7ZDNiL4uzJhnLVlQcvQcBc=.855f759f-2eb2-45f1-8ae0-755fd9308aed@github.com>

On Sat, 1 Jun 2024 11:49:39 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR improves the test failure output for the failing test case, and the underlying issue is likely going to be addressed by https://github.com/openjdk/jdk/pull/19131 /cc @DougLea

@AlanBateman @stuart-marks @PaulSandoz This is a PR which improves debug-ability if the test fails, please review at your discretion if possible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19508#issuecomment-2198508200

From lance.andersen at oracle.com  Sun Jun 30 12:54:06 2024
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 30 Jun 2024 12:54:06 +0000
Subject: java.util.zip.ZipError seems unused
In-Reply-To: <CA+pBWhvP14V=w3de0cPBsaEAFTPfSMtuLtqOzraS7RdDMD75zg@mail.gmail.com>
References: <CA+pBWhvP14V=w3de0cPBsaEAFTPfSMtuLtqOzraS7RdDMD75zg@mail.gmail.com>
Message-ID: <2E5AB0C6-9664-44B6-9513-41B1288B0E09@oracle.com>

Hi Eirik,

The removal of ZipError from ZipFile/ZipFileSystem/ZipFileSystemProvider  occurred via 8145260 and 8037394 for JDK 9

The test should also be re-written at this point

Jai or I can make a pass to see if there are any external usages via a corpus search but I tend to doubt it

On Jun 30, 2024, at 3:20?AM, Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

Hi!

The java.util.zip.ZipError class seems unused in OpenJDK. I assume this is legacy from the native ZIP implementation in Java 8.

This exception class extends InternalError and seems to have been added in Java 6 to help compatibility with existing code catching InternalError (JDK-4615343)

This change also introduced the TestZipError test, which verified that ZipError was thrown while enumerating a ZIP file which was changed after being opened. The reimplementation of the ZIP implementation to Java (JDK-8145260) updated this test to expect a ZipException instead of the ZipError.

Given that this class has now fallen out of use in OpenJDK, should we:

1: Deprecate it
2: Deprecate it for removal
3: Do nothing, keeping it around has a low cost
4: Something else

It would also be useful if someone with access to a large code corpus could search for usages of this class so we could assess compatibility concerns of removing it.

Thanks,
Eirik.

[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/20240630/15b993d0/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/20240630/15b993d0/oracle_sig_logo-0001.gif>

From zjx001202 at gmail.com  Sun Jun 30 14:18:15 2024
From: zjx001202 at gmail.com (Glavo)
Date: Sun, 30 Jun 2024 22:18:15 +0800
Subject: java.util.zip.ZipError seems unused
In-Reply-To: <CA+pBWhvP14V=w3de0cPBsaEAFTPfSMtuLtqOzraS7RdDMD75zg@mail.gmail.com>
References: <CA+pBWhvP14V=w3de0cPBsaEAFTPfSMtuLtqOzraS7RdDMD75zg@mail.gmail.com>
Message-ID: <CAJL5A3kED_+N4Ao1hwoBp6EqN26k27iiK6jF=X8YTLPyMD5pjA@mail.gmail.com>

I am the maintainer of HMCL and we need to catch ZipError in our program
because our program needs to be compatible with Java 8:

https://github.com/HMCL-dev/HMCL/blob/85b68ad135267bc33e03c3624b1bced9b7804c39/HMCLCore/src/main/java/org/jackhuang/hmcl/util/io/CompressingUtils.java#L218-L220

I'd love to see it deprecated, but I'm sure there are some use cases for
it, so please evaluate the risks carefully.

Glavo

On Sun, Jun 30, 2024 at 5:42?PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

> Hi!
>
> The java.util.zip.ZipError class seems unused in OpenJDK. I assume this is
> legacy from the native ZIP implementation in Java 8.
>
> This exception class extends InternalError and seems to have been added in
> Java 6 to help compatibility with existing code catching InternalError
> (JDK-4615343)
>
> This change also introduced the TestZipError test, which verified that
> ZipError was thrown while enumerating a ZIP file which was changed after
> being opened. The reimplementation of the ZIP implementation to Java
> (JDK-8145260) updated this test to expect a ZipException instead of the
> ZipError.
>
> Given that this class has now fallen out of use in OpenJDK, should we:
>
> 1: Deprecate it
> 2: Deprecate it for removal
> 3: Do nothing, keeping it around has a low cost
> 4: Something else
>
> It would also be useful if someone with access to a large code corpus
> could search for usages of this class so we could assess compatibility
> concerns of removing it.
>
> Thanks,
> Eirik.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240630/d9fa4c10/attachment.htm>

From duke at openjdk.org  Sun Jun 30 15:01:19 2024
From: duke at openjdk.org (David Schlosnagle)
Date: Sun, 30 Jun 2024 15:01:19 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v7]
In-Reply-To: <6QiPiiVIefSppBE1m0AKNQs3wjCQXh6dcuuef2KCAII=.4c3f6c4f-ee8c-4432-91cc-ae74bc9ba302@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <_UZLKTzQAzx47QJKLVohkzF71r8PH0yXjg6-vr7iJ7o=.79ffc36c-356a-44a2-971d-27795c6af56a@github.com>
 <6QiPiiVIefSppBE1m0AKNQs3wjCQXh6dcuuef2KCAII=.4c3f6c4f-ee8c-4432-91cc-ae74bc9ba302@github.com>
Message-ID: <Xr_mZT4lbLgC5X9NRAuECmzWhDZOA8KOHuv6GZMJk94=.0a659a5a-f5d7-4345-a763-e9b45b2d70e4@github.com>

On Sun, 30 Jun 2024 14:57:26 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   laze init for `decimal fast path locale`
>
> src/java.base/share/classes/java/lang/StringFormat.java line 142:
> 
>> 140:                 str = String.valueOf(arg1);
>> 141:                 coder |= str.coder();
>> 142:                 arg1 = String.valueOf(str);
> 
> nit: `arg1 = String.valueOf(str);` can be avoided by just using `str`:
> 
> Suggestion:
> 
>                 arg1 = str = String.valueOf(arg1);
>                 coder |= str.coder();

alternatively:
Suggestion:

                str = String.valueOf(arg1);
                coder |= str.coder();
                arg1 = str;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1660197249

From duke at openjdk.org  Sun Jun 30 15:01:19 2024
From: duke at openjdk.org (David Schlosnagle)
Date: Sun, 30 Jun 2024 15:01:19 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v7]
In-Reply-To: <_UZLKTzQAzx47QJKLVohkzF71r8PH0yXjg6-vr7iJ7o=.79ffc36c-356a-44a2-971d-27795c6af56a@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
 <_UZLKTzQAzx47QJKLVohkzF71r8PH0yXjg6-vr7iJ7o=.79ffc36c-356a-44a2-971d-27795c6af56a@github.com>
Message-ID: <6QiPiiVIefSppBE1m0AKNQs3wjCQXh6dcuuef2KCAII=.4c3f6c4f-ee8c-4432-91cc-ae74bc9ba302@github.com>

On Sun, 30 Jun 2024 04:54:35 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
>> 
>> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
>> 
>> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
>> 
>> Below is a comparison of String.format and concat-based and StringBuilder:
>> 
>> * benchmark java code
>> 
>> public class StringFormat {
>>     @Benchmark
>>     public String stringIntFormat() {
>>         return "%s %d".formatted(s, i);
>>     }
>> 
>>     @Benchmark
>>     public String stringIntConcat() {
>>         return s + " " + i;
>>     }
>> 
>>     @Benchmark
>>     public String stringIntStringBuilder() {
>>         return new StringBuilder(s).append(" ").append(i).toString();
>>     }
>> }
>> 
>> 
>> * benchmark number on macbook m1 pro
>> 
>> Benchmark                            Mode  Cnt   Score   Error  Units
>> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
>> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
>> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
>> 
>> 
>> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
>> 
>> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
>> 
>> d
>> x
>> X
>> s
>> 
>> If necessary, we can add a few more.
>> 
>> 
>> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
>> 
>> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
>> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
>> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
>> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
>> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
>> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
>> 
>> +Benchmark                ...
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   laze init for `decimal fast path locale`

src/java.base/share/classes/java/lang/StringFormat.java line 142:

> 140:                 str = String.valueOf(arg1);
> 141:                 coder |= str.coder();
> 142:                 arg1 = String.valueOf(str);

nit: `arg1 = String.valueOf(str);` can be avoided by just using `str`:

Suggestion:

                arg1 = str = String.valueOf(arg1);
                coder |= str.coder();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1660197061

From duke at openjdk.org  Sun Jun 30 17:29:55 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 30 Jun 2024 17:29:55 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v8]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <kiLvh2e2p6yMaDaFjLQvp1YBjwVS8QvxSk1rT4iTP_U=.6fb18686-6c63-49ac-ae93-8d42f628a6e9@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/StringFormat.java
  
  Co-authored-by: David Schlosnagle <schlosna at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/6163e864..e7283f0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From duke at openjdk.org  Sun Jun 30 18:21:52 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 30 Jun 2024 18:21:52 GMT
Subject: RFR: 8335366: Improve String.format performance with fastpath [v9]
In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com>
Message-ID: <nyDJf6K1LNCL1aB8If7oSzVFGVAqtsD_E7dUM9OCCSI=.f90dacd7-d5b2-4f46-9d4b-0f05864ba1e3@github.com>

> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough.
> 
> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter.
> 
> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath.
> 
> Below is a comparison of String.format and concat-based and StringBuilder:
> 
> * benchmark java code
> 
> public class StringFormat {
>     @Benchmark
>     public String stringIntFormat() {
>         return "%s %d".formatted(s, i);
>     }
> 
>     @Benchmark
>     public String stringIntConcat() {
>         return s + " " + i;
>     }
> 
>     @Benchmark
>     public String stringIntStringBuilder() {
>         return new StringBuilder(s).append(" ").append(i).toString();
>     }
> }
> 
> 
> * benchmark number on macbook m1 pro
> 
> Benchmark                            Mode  Cnt   Score   Error  Units
> StringFormat.stringIntConcat         avgt   15   6.541 ? 0.056  ns/op
> StringFormat.stringIntFormat         avgt   15  17.399 ? 0.133  ns/op
> StringFormat.stringIntStringBuilder  avgt   15   8.004 ? 0.063  ns/op
> 
> 
> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times.
> 
> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9.
> 
> d
> x
> X
> s
> 
> If necessary, we can add a few more.
> 
> 
> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement.
> 
> -Benchmark                          Mode  Cnt    Score    Error  Units (baseline)
> -StringFormat.complexFormat         avgt   15  895.954 ? 52.541  ns/op
> -StringFormat.decimalFormat         avgt   15  277.420 ? 18.254  ns/op
> -StringFormat.stringFormat          avgt   15   66.787 ?  2.715  ns/op
> -StringFormat.stringIntFormat       avgt   15   81.046 ?  1.879  ns/op
> -StringFormat.widthStringFormat     avgt   15   38.897 ?  0.114  ns/op
> -StringFormat.widthStringIntFormat  avgt   15  109.841 ?  1.028  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd)
> +StringFormat.complexF...

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  code style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19956/files
  - new: https://git.openjdk.org/jdk/pull/19956/files/e7283f0a..9b2bb485

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=07-08

  Stats: 21 lines in 1 file changed: 6 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956

PR: https://git.openjdk.org/jdk/pull/19956

From lance.andersen at oracle.com  Sun Jun 30 21:40:33 2024
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 30 Jun 2024 21:40:33 +0000
Subject: java.util.zip.ZipError seems unused
In-Reply-To: <CAJL5A3kED_+N4Ao1hwoBp6EqN26k27iiK6jF=X8YTLPyMD5pjA@mail.gmail.com>
References: <CA+pBWhvP14V=w3de0cPBsaEAFTPfSMtuLtqOzraS7RdDMD75zg@mail.gmail.com>
 <CAJL5A3kED_+N4Ao1hwoBp6EqN26k27iiK6jF=X8YTLPyMD5pjA@mail.gmail.com>
Message-ID: <E993092C-B227-42DE-A818-8A4E4B615F66@oracle.com>

The code you point to below is leveraging ZipFS, which provided as a demo in JDK 8 and  was not a supported part of Java until JDK 9 at which point ZipFS did not use ZipError.

So I understand your point but we also need to keep in mind that demo != supported as we consider the eventual removal of this class.


On Jun 30, 2024, at 10:18?AM, Glavo <zjx001202 at gmail.com> wrote:

I am the maintainer of HMCL and we need to catch ZipError in our program because our program needs to be compatible with Java 8:

https://github.com/HMCL-dev/HMCL/blob/85b68ad135267bc33e03c3624b1bced9b7804c39/HMCLCore/src/main/java/org/jackhuang/hmcl/util/io/CompressingUtils.java#L218-L220

I'd love to see it deprecated, but I'm sure there are some use cases for it, so please evaluate the risks carefully.

Glavo

On Sun, Jun 30, 2024 at 5:42?PM Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:
Hi!

The java.util.zip.ZipError class seems unused in OpenJDK. I assume this is legacy from the native ZIP implementation in Java 8.

This exception class extends InternalError and seems to have been added in Java 6 to help compatibility with existing code catching InternalError (JDK-4615343)

This change also introduced the TestZipError test, which verified that ZipError was thrown while enumerating a ZIP file which was changed after being opened. The reimplementation of the ZIP implementation to Java (JDK-8145260) updated this test to expect a ZipException instead of the ZipError.

Given that this class has now fallen out of use in OpenJDK, should we:

1: Deprecate it
2: Deprecate it for removal
3: Do nothing, keeping it around has a low cost
4: Something else

It would also be useful if someone with access to a large code corpus could search for usages of this class so we could assess compatibility concerns of removing it.

Thanks,
Eirik.

[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/20240630/55d66dd5/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/20240630/55d66dd5/oracle_sig_logo-0001.gif>